Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #43009 > unrolled thread

who really use Forth ?

Back to article view | Back to comp.lang.forth

Contents

  who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-30 16:12 -0700
    Re: who really use Forth ? lehs <skydda.barnen@gmail.com> - 2015-10-30 16:27 -0700
      Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-30 16:53 -0700
        Re: who really use Forth ? lehs <skydda.barnen@gmail.com> - 2015-10-31 09:16 -0700
          Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 12:49 -0700
    Re: who really use Forth ? Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 01:27 +0100
    Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-10-31 00:26 +0000
      Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-10-31 10:46 +0000
        Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2016-06-18 01:35 +0000
    Re: who really use Forth ? Pablo Hugo Reda <pabloreda@gmail.com> - 2015-10-30 18:34 -0700
      Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-10-31 10:57 +0000
        Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 13:13 -0700
          Re: who really use Forth ? rickman <gnuarm@gmail.com> - 2015-10-31 17:22 -0400
        Re: who really use Forth ? "Rod Pemberton" <too@zxcvfeqad.cdm> - 2015-11-02 02:32 -0500
          Re: who really use Forth ? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-02 09:04 +0100
    Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-30 18:35 -1000
    Re: who really use Forth ? rickman <gnuarm@gmail.com> - 2015-10-31 02:51 -0400
    Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-10-30 23:52 -0700
    Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 00:04 -0700
      Re: who really use Forth ? rickman <gnuarm@gmail.com> - 2015-10-31 03:16 -0400
      Re: who really use Forth ? Pablo Hugo Reda <pabloreda@gmail.com> - 2015-10-31 06:00 -0700
      Re: who really use Forth ? Richard Owlett <rowlett@cloud85.net> - 2015-10-31 08:35 -0500
        Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 13:08 -0700
        Re: who really use Forth ? Paul Rubin <no.email@nospam.invalid> - 2015-10-31 13:40 -0700
          Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-10-31 13:55 -0700
      Re: who really use Forth ? hughaguilar96@gmail.com - 2015-10-31 14:10 -0700
        Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-11-01 11:15 +0000
          Re: who really use Forth ? Alfred Singlestone <vitonis@gmail.com> - 2015-11-02 05:37 -0800
            Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-02 05:59 -0800
    Re: who really use Forth ? stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 10:17 +0000
      Re: who really use Forth ? stephen@mpeforth.com (Stephen Pelc) - 2015-10-31 16:53 +0000
    Re: who really use Forth ? Ilya Tarasov <ilya74.tarasov@gmail.com> - 2015-10-31 14:04 -0700
      Re: who really use Forth ? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-11-02 10:57 +0100
    Re: who really use Forth ? lehs <skydda.barnen@gmail.com> - 2015-10-31 21:23 -0700
    Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-11-02 06:05 -0800
      Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-02 07:43 -0800
      Re: who really use Forth ? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 08:02 -0800
    Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-02 08:53 -0800
      Re: who really use Forth ? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 09:05 -0800
        Re: who really use Forth ? hughaguilar96@gmail.com - 2015-11-02 09:48 -0800
        Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 08:11 -1000
    Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-02 10:39 -0800
      Re: who really use Forth ? hughaguilar96@gmail.com - 2015-11-02 16:37 -0800
        Re: who really use Forth ? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-02 22:59 -0800
          Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-11-02 21:16 -1000
            Re: who really use Forth ? stephen@mpeforth.com (Stephen Pelc) - 2015-11-03 11:04 +0000
              Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-11-03 08:17 -1000
                Re: who really use Forth ? hughaguilar96@gmail.com - 2015-11-03 18:20 -0800
                  Re: who really use Forth ? François <francois.ganza@wanadoo.fr> - 2015-11-03 22:26 -0800
                  Re: who really use Forth ? lehs <skydda.barnen@gmail.com> - 2015-11-03 23:21 -0800
                Re: who really use Forth ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-04 09:33 +0000
            Re: who really use Forth ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-03 11:07 +0000
              Re: who really use Forth ? Mark Wills <markwills1970@gmail.com> - 2015-11-03 03:23 -0800
                Re: who really use Forth ? Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-03 22:24 +0100
          Re: who really use Forth ? Mark Wills <markwills1970@gmail.com> - 2015-11-03 01:35 -0800
          Re: who really use Forth ? rickman <gnuarm@gmail.com> - 2015-11-03 11:18 -0500
          Re: who really use Forth ? "WJ" <w_a_x_man@yahoo.com> - 2015-11-04 00:07 +0000
          Re: who really use Forth ? Alfred Singlestone <vitonis@gmail.com> - 2015-11-03 17:01 -0800
    Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-03 10:59 -0800
      Re: who really use Forth ? "Elizabeth D. Rather" <erather@forth.com> - 2015-11-03 10:00 -1000
        Re: who really use Forth ? Chris Curl <ccurl609@gmail.com> - 2015-11-03 13:31 -0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#43132

On 11/2/15 7:05 AM, Raimond Dragomir wrote:
> luni, 2 noiembrie 2015, 18:53:10 UTC+2, Chris Curl a scris:
>> It looks like FIELD is a defining word ... in that it creates another word
>> that adds an offset to the address on the TOS.
>>
>> What you end up with is a set of words that refer to different spots in the
>> buffer. So that approach is one way to build a set of words that makes sense
>> of the contents of the buffer.
>>
>> There are other ways to end up with the exact same set of words that don't use
>> a defining word like FIELD. But a word like FIELD is elegant, because it takes
>> some of the grunt work out of creating the wordset by hand.
>>
>> Nice work!
>
> Yes, FIELD is exactly that. Very simple. Hugh's having it in the novice
> package. But it is not my invention, not even Hugh's. It is older. IMO it's
> a shame it is not in the 94 standard. The standard has PAD instead...

Yes, similar structures have been in use since the 70's. polyFORTH 
included a whole database package with files and record structures with 
different kinds of fields (strings, single & double integers, record 
pointers & links, etc.) and associated operators. They were also an 
integral feature of Open Firmware from the mid-80's.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43133

The "structure" constraint that I was referring to (and complaining about) was 
how C and C++ define it. In those languages, the word structure (or class) has a very specific meaning, there is a well-defined way you work with the thing 
(struct or class), and it is pretty much that way or the highway. Obviously, it 
works, but after 30 years of doing it THEIR way, I welcome the liberty to be 
able to do it MY way, whatever that way may be.

"We hold these truths to be self-evident, that all men are created equal, that 
they are endowed by their Creator with certain unalienable Rights, that among 
these are Life, Liberty and the pursuit of Happiness."

[toc] | [prev] | [next] | [standalone]

#43149

On Monday, November 2, 2015 at 11:39:19 AM UTC-7, Chris Curl wrote:
> The "structure" constraint that I was referring to (and complaining about) was 
> how C and C++ define it. In those languages, the word structure (or class) has a very specific meaning, there is a well-defined way you work with the thing 
> (struct or class), and it is pretty much that way or the highway. Obviously, it 
> works, but after 30 years of doing it THEIR way, I welcome the liberty to be 
> able to do it MY way, whatever that way may be.

C structs don't support inheritance. In the novice-package, inheritance is fundamental. For example in LIST.4TH we have:

list
    w field .line
constant seq

: init-seq ( str node -- node )
    init-list >r
    hstr    r@ .line !
    r> ;

: new-seq ( str -- node )
    seq alloc
    init-seq ;

Here the SEQ data-type inherits from the LIST data-type. This means that all the functions that work with LIST will work with SEQ. LIST by itself is actually useless because there is no payload --- LIST is only useful as a parent class to data-types such as SEQ that define some kind of payload (the .LINE field in this case). 

Notice how INIT-SEQ calls INIT-LIST first on its node to initialize all of the LIST fields, and then it initializes all of its own fields. INIT-SEQ is factored out of NEW-SEQ so that INIT-SEQ can be called similarly in the initializer for a data-type inheriting from the SEQ data-type. This is really the only purpose of having an INIT-SEQ function --- anybody using SEQ lists will use NEW-SEQ to create new nodes.

Notice also how INIT-SEQ pushes the node pointer to the return-stack and uses R@ for initializing each field. This is my convention --- this is helpful when there are a lot of fields to initialize --- I keep with the convention though even for simple data-types such as SEQ that have only one field to initialize.

The most important thing to notice is that a programmer can define a data-type such as SEQ that inherits from the LIST data-type, and he doesn't have to know how LIST works. He doesn't have to know what fields are in LIST or what they are used for, or anything else. In this case, that isn't very important because it is obvious how LIST is defined (there is one field called .FORE that is the forward link pointer). In other cases however, this information-hiding is more useful. For example, in ASSOCIATION.4TH I use an LLRB tree internally. I could later upgrade this to use an RB tree or an AVL tree or some such thing. All of the code that is written to use ASSOCIATION.4TH would continue to work after the upgrade is made, without needing to be rewritten --- the user is working with an abstract container and doesn't need to know how it is implemented internally.

[toc] | [prev] | [next] | [standalone]

#43154

I posted the tcpi/ip stack here just to show why you need structures.
Many forthers asked why you need structures. Of course, every field
definition can be made a colon definition, that adds the offset. This is
error prone because you need to manually counting the offsets...

Still, defining field words for every field is still better than not having
them defined. Just imagine the tcp/ip code with no named fields, adding the
offsets inline in every definition that uses them...

But after you find yourself defining tenths of "fields" this way, you 
probably will realize that something is wrong, and probably you will
come up with a FIELD word anyway...

This is how real programming for real world applications looks like.
It is not trivial, it doesn't look like:
: sq dup * ;

Many forthers claim that doing forth in the simplistic way is fun... Yup,
it's fun for a while. It's fun to not use locals, to not use fields, to use
only DUP OVER SWAP DROP.

But the fun is over when you finally have to do a real job, and suddenly
find that you are naked, no locals, no fields, no arrays, no nothing...

A simplistic language that people use for "fun" has a name: "toy language"

[toc] | [prev] | [next] | [standalone]

#43155

On 11/2/15 8:59 PM, Raimond Dragomir wrote:
> I posted the tcpi/ip stack here just to show why you need structures.
> Many forthers asked why you need structures. Of course, every field
> definition can be made a colon definition, that adds the offset. This is
> error prone because you need to manually counting the offsets...
>
> Still, defining field words for every field is still better than not having
> them defined. Just imagine the tcp/ip code with no named fields, adding the
> offsets inline in every definition that uses them...

It's really not necessary to labor this point. "Structures" of various 
kinds have been available in Forth since the 1970's. It involves about 2 
lines of code, and they will behave exactly as you want them to behave. 
The whole point in Forth is to be able to make your data objects work 
the way you want them to.

The reason they haven't been standardized isn't because they're hard or 
not useful or discouraged for any reason, it's because they're so easy 
and so easily adaptable to one's personal style or application need that 
it's easier to just make the one you want than to sweat bullets arguing 
about it or searching for a "library".

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43162

On Mon, 2 Nov 2015 21:16:53 -1000, "Elizabeth D. Rather"
<erather@forth.com> wrote:

>The reason they haven't been standardized isn't because they're hard or 
>not useful or discouraged for any reason, it's because they're so easy 
>and so easily adaptable to one's personal style or application need that 
>it's easier to just make the one you want than to sweat bullets arguing 
>about it or searching for a "library".

Actually ... see Forth 2012 in the facility word set.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#43185

On 11/3/15 1:04 AM, Stephen Pelc wrote:
> On Mon, 2 Nov 2015 21:16:53 -1000, "Elizabeth D. Rather"
> <erather@forth.com> wrote:
>
>> The reason they haven't been standardized isn't because they're hard or
>> not useful or discouraged for any reason, it's because they're so easy
>> and so easily adaptable to one's personal style or application need that
>> it's easier to just make the one you want than to sweat bullets arguing
>> about it or searching for a "library".
>
> Actually ... see Forth 2012 in the facility word set.

Cool. What is everyone fussing about, then?

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43207

On Tuesday, November 3, 2015 at 11:17:55 AM UTC-7, Elizabeth D. Rather wrote:
> On 11/3/15 1:04 AM, Stephen Pelc wrote:
> > On Mon, 2 Nov 2015 21:16:53 -1000, "Elizabeth D. Rather"
> > <erather@forth.com> wrote:
> >
> >> The reason they haven't been standardized isn't because they're hard or
> >> not useful or discouraged for any reason, it's because they're so easy
> >> and so easily adaptable to one's personal style or application need that
> >> it's easier to just make the one you want than to sweat bullets arguing
> >> about it or searching for a "library".
> >
> > Actually ... see Forth 2012 in the facility word set.
> 
> Cool. What is everyone fussing about, then?
> 
> Cheers,
> Elizabeth

Elizabeth Rather says: "it's easier to just make the one you want than to sweat bullets arguing about it or searching for a 'library'."

This is the same argument she made about arrays, and everything else. This is utter nonsense. Nobody needs to customize how structs or arrays work --- there just aren't that many different ways that they can work --- also, Elizabeth Rather's array definer in her book "Forth Applications" was horribly screwed up, indicating that she doesn't actually know how to write an array definer, and neither is there any evidence anywhere to indicate that she knows how to write FIELD or even knows what it does.

Forth-200x is not "cool" --- Forth-200x screws everything up, including the most simple things --- in this case, they failed to use the word FIELD that has been common practice since at least the 1980s, and they came up with their own word that has never been used before, requiring 30+ years of legacy code to need to be rewritten.

[toc] | [prev] | [next] | [standalone]

#43210

Some prefer to use swiss knife, i prefer use one tool for one problem.

But my first question is not about that :p

my first question was (ok, it was badly formulated) :
Why do YOU use Forth ? 

I'm sure the answers will explain the points of view of everyone on what should be the language. ;-)

First :
I use it for applications often connected to dedicated hardware (sensors, encoder, motors ... etc ...)
Often for my own use, to improve productivity (I make small industrial machinery and equipment)
I happened to make applications for clients, but I did not do it for the money, the programming is not my livelihood

[toc] | [prev] | [next] | [standalone]

#43212

Den onsdag 4 november 2015 kl. 03:20:06 UTC+1 skrev hughag...@gmail.com:
> On Tuesday, November 3, 2015 at 11:17:55 AM UTC-7, Elizabeth D. Rather wrote:
> > On 11/3/15 1:04 AM, Stephen Pelc wrote:
> > > On Mon, 2 Nov 2015 21:16:53 -1000, "Elizabeth D. Rather"
> > > <erather@forth.com> wrote:
> > >
> > >> The reason they haven't been standardized isn't because they're hard or
> > >> not useful or discouraged for any reason, it's because they're so easy
> > >> and so easily adaptable to one's personal style or application need that
> > >> it's easier to just make the one you want than to sweat bullets arguing
> > >> about it or searching for a "library".
> > >
> > > Actually ... see Forth 2012 in the facility word set.
> > 
> > Cool. What is everyone fussing about, then?
> > 
> > Cheers,
> > Elizabeth
> 
> Elizabeth Rather says: "it's easier to just make the one you want than to sweat bullets arguing about it or searching for a 'library'."
> 
> This is the same argument she made about arrays, and everything else. This is utter nonsense. Nobody needs to customize how structs or arrays work --- there just aren't that many different ways that they can work --- also, Elizabeth Rather's array definer in her book "Forth Applications" was horribly screwed up, indicating that she doesn't actually know how to write an array definer, and neither is there any evidence anywhere to indicate that she knows how to write FIELD or even knows what it does.
> 
> Forth-200x is not "cool" --- Forth-200x screws everything up, including the most simple things --- in this case, they failed to use the word FIELD that has been common practice since at least the 1980s, and they came up with their own word that has never been used before, requiring 30+ years of legacy code to need to be rewritten.

I think Elizabeth Rather has right. And this is significant for Forth: it's more easy in Forth to design as you wish, instead of thinking of the system or an extension of the system. 

I'm working with a special simulation program for some time and without thinking of it I designed a special field-like structure to program the simulation. It might be so that there are more efficient ways to implement that structure, but it suits me fine to think about the task instead of thinking about what other possibilities there are.

This is a facility of creativity in Forth, the confidence about that every thing is possible and you don't need help from outside. Mostly!

[toc] | [prev] | [next] | [standalone]

#43213

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 11/3/15 1:04 AM, Stephen Pelc wrote:
>> On Mon, 2 Nov 2015 21:16:53 -1000, "Elizabeth D. Rather"
>> <erather@forth.com> wrote:
>>
>>> The reason they haven't been standardized isn't because they're hard or
>>> not useful or discouraged for any reason, it's because they're so easy
>>> and so easily adaptable to one's personal style or application need that
>>> it's easier to just make the one you want than to sweat bullets arguing
>>> about it or searching for a "library".
>>
>> Actually ... see Forth 2012 in the facility word set.
>
>Cool. What is everyone fussing about, then?

It seems that Forth-2012 has yet to arrive in "everybody"'s head.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#43166

"Elizabeth D. Rather" <erather@forth.com> writes:
>The reason they haven't been standardized

They have been standardized:

http://forth-standard.org/standard/facility/PlusFIELD

and the words referenced from that entry.

>isn't because they're hard or 
>not useful or discouraged for any reason, it's because they're so easy 
>and so easily adaptable to one's personal style or application need that 
>it's easier to just make the one you want than to sweat bullets arguing 
>about it or searching for a "library".

If anyone really wants to use a personal variant, they still can, but
I find that the standardized ones are good enough that I don't.  There
are two advantages:

1) The system-supplied words may be implemented more efficiently than
user-defined words.

2) Readers of the program don't need to learn the personal variant of
the program's author.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#43167

On Tuesday, 3 November 2015 11:19:46 UTC, Anton Ertl  wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
> >The reason they haven't been standardized
> 
> They have been standardized:
> 
> http://forth-standard.org/standard/facility/PlusFIELD
> 
> and the words referenced from that entry.
> 
> >isn't because they're hard or 
> >not useful or discouraged for any reason, it's because they're so easy 
> >and so easily adaptable to one's personal style or application need that 
> >it's easier to just make the one you want than to sweat bullets arguing 
> >about it or searching for a "library".
> 
> If anyone really wants to use a personal variant, they still can, but
> I find that the standardized ones are good enough that I don't.  There
> are two advantages:
> 
> 1) The system-supplied words may be implemented more efficiently than
> user-defined words.
> 
> 2) Readers of the program don't need to learn the personal variant of
> the program's author.
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

3) It's portable

:-)

[toc] | [prev] | [next] | [standalone]

#43197

Mark Wills wrote:

> 3) It's portable

Writing your own definition of +FIELD and <type>FIELD: is portable, too.  
It's just maybe not so well-optimized.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#43158

On Tuesday, 3 November 2015 06:59:45 UTC, Raimond Dragomir  wrote:
> I posted the tcpi/ip stack here just to show why you need structures.
> Many forthers asked why you need structures. Of course, every field
> definition can be made a colon definition, that adds the offset. This is
> error prone because you need to manually counting the offsets...
> 
> Still, defining field words for every field is still better than not having
> them defined. Just imagine the tcp/ip code with no named fields, adding the
> offsets inline in every definition that uses them...
> 
> But after you find yourself defining tenths of "fields" this way, you 
> probably will realize that something is wrong, and probably you will
> come up with a FIELD word anyway...
> 
> This is how real programming for real world applications looks like.
> It is not trivial, it doesn't look like:
> : sq dup * ;
> 
> Many forthers claim that doing forth in the simplistic way is fun... Yup,
> it's fun for a while. It's fun to not use locals, to not use fields, to use
> only DUP OVER SWAP DROP.
> 
> But the fun is over when you finally have to do a real job, and suddenly
> find that you are naked, no locals, no fields, no arrays, no nothing...
> 
> A simplistic language that people use for "fun" has a name: "toy language"

^^^^^^^^^^ What he said! :-)

[toc] | [prev] | [next] | [standalone]

#43178

On 11/3/2015 1:59 AM, Raimond Dragomir wrote:
> I posted the tcpi/ip stack here just to show why you need structures.
> Many forthers asked why you need structures. Of course, every field
> definition can be made a colon definition, that adds the offset. This is
> error prone because you need to manually counting the offsets...
>
> Still, defining field words for every field is still better than not having
> them defined. Just imagine the tcp/ip code with no named fields, adding the
> offsets inline in every definition that uses them...
>
> But after you find yourself defining tenths of "fields" this way, you
> probably will realize that something is wrong, and probably you will
> come up with a FIELD word anyway...
>
> This is how real programming for real world applications looks like.
> It is not trivial, it doesn't look like:
> : sq dup * ;
>
> Many forthers claim that doing forth in the simplistic way is fun... Yup,
> it's fun for a while. It's fun to not use locals, to not use fields, to use
> only DUP OVER SWAP DROP.
>
> But the fun is over when you finally have to do a real job, and suddenly
> find that you are naked, no locals, no fields, no arrays, no nothing...
>
> A simplistic language that people use for "fun" has a name: "toy language"

So many times people create straw-man arguments and put words in the 
mouths of others.  I don't know these people who say "forth in the 
simplistic way is fun".  I don't even know what "forth in the simplistic 
way" means.  I seldom see people who use Forth saying you shouldn't use 
this or that.  Sometimes they may say, "I don't use this" or "that". 
But then they have another way of doing it which is not so simple as  : 
sq dup * ;    If that were all it needed we would all do it that way.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#43203

Raimond Dragomir wrote:

> Many forthers claim that doing forth in the simplistic way is fun... Yup,
> it's fun for a while. It's fun to not use locals, to not use fields, to use
> only DUP OVER SWAP DROP.
> 
> But the fun is over when you finally have to do a real job, and suddenly
> find that you are naked, no locals, no fields, no arrays, no nothing...
> 
> A simplistic language that people use for "fun" has a name: "toy language"


Ruby:

  s = 'A simplistic language that people use for "fun" has a name:'
  puts s, [[14,2],[2,1],[1,1],[38,3],[22,2]].map{|x| s[*x]}.join.upcase

A simplistic language that people use for "fun" has a name:
ANS FORTH

[toc] | [prev] | [next] | [standalone]

#43204

On Tuesday, November 3, 2015 at 1:59:45 AM UTC-5, Raimond Dragomir wrote:
> Many forthers claim that doing forth in the simplistic way is fun... Yup,
> it's fun for a while. It's fun to not use locals, to not use fields, to use
> only DUP OVER SWAP DROP.
> 
> But the fun is over when you finally have to do a real job, and suddenly
> find that you are naked, no locals, no fields, no arrays, no nothing...
> 
> A simplistic language that people use for "fun" has a name: "toy language"

The chances are very slim indeed that I'll ever find myself having to use Forth to make a living. Until that happens, I'm content to use it for fun. Got something against fun?

[toc] | [prev] | [next] | [standalone]

#43187

Maybe I've been programming too long, but to me, it's a no-brainer 
that for a non-trivial application that works with blocks of memory
that contain multiple fields, you need a mechanism that can refer 
to the different fields. In Forth, that means words that make it 
easy to refer the different fields.

That is the power of Forth ... you can build a custom lexicon to 
describe and solve whatever problem you are addressing. Words that
work with the fields are just part of the lexicon.

[toc] | [prev] | [next] | [standalone]

#43193

On 11/3/15 8:59 AM, Chris Curl wrote:
> Maybe I've been programming too long, but to me, it's a no-brainer
> that for a non-trivial application that works with blocks of memory
> that contain multiple fields, you need a mechanism that can refer
> to the different fields. In Forth, that means words that make it
> easy to refer the different fields.
>
> That is the power of Forth ... you can build a custom lexicon to
> describe and solve whatever problem you are addressing. Words that
> work with the fields are just part of the lexicon.
>

As I have noted here, Forth systems have provided means of doing this 
for 40 years, although they have only been standardized recently in 2012 
(as Stephen has pointed out).

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web