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

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

LOCALS| and {:

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

Contents

  LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-16 11:59 +0100
    Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-16 12:31 +0100
    Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-16 13:31 +0000
    Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-16 21:50 +0200
    Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-17 08:51 +0000
      Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-18 20:10 +0100
        Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-18 23:32 +0200
        Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-18 15:47 -0700
          Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-19 15:10 +0100
        Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 09:46 +0000
          Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-22 20:15 +0100
        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 07:17 -0500
          Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 14:18 +0000
            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 10:25 -0500
              Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 15:39 +0000
                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 11:26 -0500
              Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-20 11:25 +0000
                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 10:05 -0500
                  Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-21 14:38 +0200
                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 11:48 -0500
                      Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-21 16:50 +0000
                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:18 -0500
                          Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-22 12:33 +0000
                            Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-22 15:26 +0200
                              Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:25 -0500
                                Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:24 +0200
                                  Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:12 -0500
                                    Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 01:22 +0200
                                      Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 02:56 -0500
                                  Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 01:49 -0700
                                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:52 -0500
                                      Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 08:10 -0700
                                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:00 -0500
                                          Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 13:46 -0700
                                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 03:01 -0500
                                              Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-24 03:24 -0700
                                                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 12:51 -0500
                                                  Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-25 11:44 -0700
                                                  Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
                                    Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
                                    Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:42 +0000
                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:24 -0500
                              Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 11:50 +0000
                                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 08:13 -0500
                                  Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 13:55 +0000
                                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:05 -0500
                                      Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-24 10:36 +0000
                                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 13:05 -0500
                                          Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 22:44 +0200
                                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 04:29 -0500
                                              Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 20:15 +0200
                                                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 15:51 -0500
                                                  Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 23:27 +0200
                                                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-26 03:19 -0500
                                                      Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-26 20:38 +0200
                                                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-27 11:52 -0500
                                                          Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-28 03:52 +0200
                                                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-28 11:55 -0500
                                              Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-26 11:36 +0000
                                              Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
                        Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-21 10:36 -0700
                    Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-21 17:22 +0000
                      Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:34 -0500
                        Re: LOCALS| and {: mhx@iae.nl - 2013-08-21 23:05 -0700
                          Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 03:15 -0500
                            Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-22 14:49 -0700
                              Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:07 +0200
                                Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-26 20:51 -0700
                                  Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-27 15:55 +0200
                                    Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 10:22 -0700
                                      Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-27 17:33 +0000
                                      Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-27 23:02 +0000
                                        Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 22:02 -0700
                                    Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-27 11:08 -0700
                                    Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-27 21:16 -0700
                              Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:56 +0000
                Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 20:10 +0000
            Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:49 +0000
              Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-20 07:14 +0000
          Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-21 10:28 +0100
      Re: LOCALS| and {: "Elizabeth D. Rather" <erather@forth.com> - 2013-08-18 10:04 -1000
        Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-19 20:08 +0100
          Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:54 +0000
      Re: LOCALS| and {: Mark Wills <markrobertwills@yahoo.co.uk> - 2013-08-20 02:19 -0700
        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 04:37 -0500
    Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-17 13:58 +0200
    Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-17 18:49 -0700
    Re: LOCALS| and {: "Ed" <invalid@invalid.com> - 2013-08-23 17:37 +1000

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

#25352

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> I am wondering, though, why the people who defined these functions did
> define the function themselves in that way.  The problem for C with
> these functions is the same as in Forth.

I remember the original X libraries way to pass the args for those calls
as a list of name-value pairs using something like varargs.  It's been a
while since I programmed that stuff, so maybe the API has changed.

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

#25353

On Wed, 21 Aug 2013 14:38:51 +0200, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>The 14 argument function worked pretty straight-forward:
>
>: ?? ( bitset n -- c-flag )  rshift 1 and ;
>: assign ( addr u family flags width height -- )
>  { family flags w h }
>  name-string $0! \ make zero-terminated string
>  name-string $@ dup IF  drop  ELSE  nip  THEN \ 0 if no name
>  family
>  ANTIALIASED_QUALITY CLIP_DEFAULT_PRECIS OUT_TT_PRECIS DEFAULT_CHARSET
>  flags 2 ??  flags 1 ??  flags 0 ??
>  0 0 0 w h CreateFont id ! ;
>
>Of course, when programming such an API, you have absolutely make sure to 
>wear a soft cussion on your forehead, so that you won't damage anything when 
>facepalming yourself ;-).

For your information, see also:
HFONT CreateFontIndirect(
  _In_  const LOGFONT *lplf
);
where a LOGFONT structure soaks up the nastiness.

Most of the appalling API calls are still there (compatibility) but
additional calls with a structure have appeared. The "See also"
sections of the online API references are always worth a look.

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]

#25354

Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Wed, 21 Aug 2013 14:38:51 +0200, Bernd Paysan <bernd.paysan@gmx.de>
> wrote:
> 
>>The 14 argument function worked pretty straight-forward:
>>
>>: ?? ( bitset n -- c-flag )  rshift 1 and ;
>>: assign ( addr u family flags width height -- )
>>  { family flags w h }
>>  name-string $0! \ make zero-terminated string
>>  name-string $@ dup IF  drop  ELSE  nip  THEN \ 0 if no name
>>  family
>>  ANTIALIASED_QUALITY CLIP_DEFAULT_PRECIS OUT_TT_PRECIS DEFAULT_CHARSET
>>  flags 2 ??  flags 1 ??  flags 0 ??
>>  0 0 0 w h CreateFont id ! ;
>>
>>Of course, when programming such an API, you have absolutely make sure to 
>>wear a soft cussion on your forehead, so that you won't damage anything when 
>>facepalming yourself ;-).
> 
> For your information, see also:
> HFONT CreateFontIndirect(
>  _In_  const LOGFONT *lplf
> );
> where a LOGFONT structure soaks up the nastiness.

Mmm, yes, exactly.  Way to go, Microsoft!  :-)

UNIX does this for all its comples system calls, but traditionally
these have always been limited to passing args in a few registers.
That's good.

Andrew.

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

#25358

On Wednesday, August 21, 2013 7:34:54 PM UTC+2, Andrew Haley wrote:
> Stephen Pelc <stephenXXX@mpeforth.com> wrote:
[..]
> > where a LOGFONT structure soaks up the nastiness.
> Mmm, yes, exactly.  Way to go, Microsoft!  :-)
> UNIX does this for all its comples system calls, but traditionally
> these have always been limited to passing args in a few registers.
> 
> That's good.
> 
> Andrew.

So, in order to finish this OS-bashing thread, we have to find a system
call with over 14 parameters that obviously carry *no state*.
In my use of CreateFontIndirectX the graphics package needs to 
remember e.g. escapement, weight, width, height etc. when 
implementing some kind of graphical terminal interface. To be
multitasking safe the logfont needs to be thread-local.

-marcel

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

#25360

mhx@iae.nl wrote:
> On Wednesday, August 21, 2013 7:34:54 PM UTC+2, Andrew Haley wrote:
>> Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> [..]
>> > where a LOGFONT structure soaks up the nastiness.
>> Mmm, yes, exactly.  Way to go, Microsoft!  :-)
>> UNIX does this for all its comples system calls, but traditionally
>> these have always been limited to passing args in a few registers.
>> 
> 
> So, in order to finish this OS-bashing thread,

Come on Marcel, no-one has bashed an OS in this thread.

> we have to find a system call with over 14 parameters that obviously
> carry *no state*.

That'd be difficult.

Andrew.

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

#25368

On Thursday, August 22, 2013 1:15:13 AM UTC-7, Andrew Haley wrote:
> mhx@iae.nl wrote:
> > So, in order to finish this OS-bashing thread,
> 
> Come on Marcel, no-one has bashed an OS in this thread.
> 
> > we have to find a system call with over 14 parameters that obviously
> > carry *no state*.
> 
> That'd be difficult.

It is not just in OS calls that the need for a lot of locals comes up. In my xARRAY definer words, I use a lot of locals. Because Win32Forth is limited to 8 local variables, I had to comment out the 5ARRAY and 6ARRAY definers to allow my novice package to compile under Win32Forth, as I had something like 12 locals in use.

The reason why I use locals, is to work around a bug in the ANS-Forth standard. The ANS-Forth standard uses the parameter stack as the control-flow stack. Totally stupid! This prevents the programmer from passing data into the definition of a colon word at compile-time to be used by LITERAL. One way to work around this bug, is to push the data onto the return-stack and then use R@ (inside of square brackets) to get at it inside of the colon definition. This only works when there are a very few data (only one or maybe two at the most). If there are a lot of data, then the only realistic work-around for the ANS-Forth bug is to pass the data in local variables. And, btw for Andrew: none of these locals carry any state information.

The whole novice package is full of work-arounds for bugs in either the ANS-Forth standard itself, or various Forth implementations. The limit of 8 locals, which was enforced by Win32Forth, is really a bug in the ANS-Forth standard. Allowing the parameter stack to be used as the control-flow stack, is a grotesque bug --- this indicates a complete failure of the ANS-Forth committee to understand that colon words can generate other colon words during their run-time using POSTPONE, which is a very fundamental aspect of Forth (pretty much unique to Forth). Also, SwiftForth-v.2 has a bug in LOCALS| that causes it to crash the computer --- this is why my implementation of { uses (LOCAL) rather than LOCALS| (Anton's implementation of {: crashes SwiftForth every time, and I never could get it to work, although there is nothing wrong with his implementation of {: in itself). 

I think the reason why the Forth-200x committee are so opposed to my novice package (saying that it "sucks" and is "crap" and that I'm a novice myself), is because all of these work-arounds to bugs in the ANS-Forth standard and/or in the SwiftForth implementation tends to shine a spotlight on their own incompetence. If they hadn't screwed everything up, I wouldn't need all of those work-arounds in my novice package, and my job would have been a lot easier.

Also, why didn't the ANS-Forth committee just provide novice-level support code like { and MACRO: and FIELD, themselves??? How is it even possible to write an application program without the support code provided in the novice package? Why should I have to write this stuff myself 15 years after the ANS-Forth standard came out, and (coincidentally) 15 years after Forth died out in the greater programming world? It is no wonder that essentially everybody who tries to learn Forth gives up after a few weeks --- none of the necessary support for application-writing is provided!

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

#25369

hughaguilar96@yahoo.com wrote:
> Also, why didn't the ANS-Forth committee just provide novice-level support
> code like { and MACRO: and FIELD, themselves???

Because the ANS Forth committee is no more; instead of revising the standard 
under ANS rules, it disbanded, and the Forth200x commitee took over.  There 
is a very small personal overlap between ANS and Forth200x, as ANS was an US 
endeaver (the "A" in ANS should be a hint ;-), while Forth200x is driven by 
the European Forth community.

Forth200x has { (renamed to {:), and a structure package which does 
something similar to FIELD.  We don't have MACRO:, though.

> How is it even possible to
> write an application program without the support code provided in the
> novice package?

The most dearly needed support package I have is my string package.  I think 
it just depends on what kind of application you want to write.  Stephen Pelc 
said, most of the core part of the standard are done (though he possibly is 
about to revise that with respect to compilation semantics, IMMEDIATE and 
STATE and stuff), and we need to add some sort of libraries.

The main critics you got here was on your symtab dictonary, because you 
refused to benchmark it.

> Why should I have to write this stuff myself 15 years
> after the ANS-Forth standard came out, and (coincidentally) 15 years after
> Forth died out in the greater programming world?

ANS Forth is called Forth-94, and with my calculation, that is 19 years.  
The death of Forth was in the late 80s, IMHO mostly due to the fact that 
computers got big enough to run bloated development systems like MSVC.  
People absolutely love bloatware, and hate anything simple and elegant.  
Especially they can't think simple, they always like to throw the most 
complicated tools they have at the problem.

If you look at a typical program in a modern language like Ruby or Python, 
it's full of regexps, lists, sets, hashes, and whatnot.  Often just because 
you can, not because it is really needed.

> It is no wonder that
> essentially everybody who tries to learn Forth gives up after a few weeks
> --- none of the necessary support for application-writing is provided!

One of the big problems with Forth is that people always lament that the 
standard killed Forth.  This is that way since Forth-83, which arguable did 
the most harm to Forth, because it changed several things to the better from 
Forth-79.  People absolutely hate changes, even changes to the better.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#25421

On Thursday, August 22, 2013 5:07:30 PM UTC-7, Bernd Paysan wrote:
> hughaguilar96@yahoo.com wrote:
> > It is no wonder that
> > essentially everybody who tries to learn Forth gives up after a few weeks
> > --- none of the necessary support for application-writing is provided!
> 
> One of the big problems with Forth is that people always lament that the 
> standard killed Forth.  This is that way since Forth-83, which arguable did 
> the most harm to Forth, because it changed several things to the better from 
> Forth-79.  People absolutely hate changes, even changes to the better.

It is not that people hate changes, even changes to the better, but they hate small changes. Forth-83 was incompatible with Forth-79, so a lot of work was needed to upgrade programs, but it only provided a few small improvements --- so people believed that the benefit didn't justify the investment in work.

Then a lot of time (12 years) went by before ANS-Forth came out, and ANS-Forth was totally screwed up when it finally came out. ANS-Forth was too wishy-washy --- throughout it says that one thing "may" be done, or another thing "may" be done. May??? What exactly is being standardized??? ANS-Forth is a standard that tries to satisfy everybody with their variety of incompatible implementations, and ends up satisfying nobody. This is why Forth died.

I think I can come up with a standard that makes sense, and people will accept it, even though it will be incompatible with ANS-Forth/Forth-200x --- nobody has ever cared about ANS-Forth, not in 1994 and not today --- ANS-Forth was a steaming pile of vagueness, and Forth-200x is a house founded upon this which is even softer than sand.

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

#25427

hughaguilar96@yahoo.com wrote:

> On Thursday, August 22, 2013 5:07:30 PM UTC-7, Bernd Paysan wrote:
>> People absolutely hate changes, even changes to the better.
> 
> It is not that people hate changes, even changes to the better, but they
> hate small changes. Forth-83 was incompatible with Forth-79, so a lot of
> work was needed to upgrade programs, but it only provided a few small
> improvements --- so people believed that the benefit didn't justify the
> investment in work.

That's the reason why people hate changes.  I don't see any problem with my 
statement.  If Forth-83 would have been a big change, the work would have 
been a lot more, and therefore, the hate would have been much bigger.

> Then a lot of time (12 years) went by before ANS-Forth came out,

and during that time, the word "If you have seen one Forth system, you have 
seen one Forth system" described the Forth world.  Forth died during this 
time of confusion, and ANS Forth came too late (and was too little and again 
too controversial to rescue).  In 1994, Forth already had lost most of the 
popularity it had in the early 80s.

> and
> ANS-Forth was totally screwed up when it finally came out. ANS-Forth was
> too wishy-washy --- throughout it says that one thing "may" be done, or
> another thing "may" be done. May??? What exactly is being standardized???

The fact that if you have seen one Forth system, you have seen one Forth 
system.  The ANS TC made a big effort to study lots of systems and to find a 
least common denominator.  A number of other language standards are quite 
similar, for similar reasons.  Usually, people avoid that mess by sticking 
to a particular implementation (like GCC or MSVC in the C world).  The GCC 
team has offended quite a number of people (the Gforth team included) by 
taking too many "may"s in the C standard as entitlement to break code.

> ANS-Forth is a standard that tries to satisfy everybody with their variety
> of incompatible implementations, and ends up satisfying nobody. This is
> why Forth died.

It had been close to dead by that time, and the "satisfy nobody by trying to 
satisfy everybody" is the symptom, not the cause.  Forth programmers are 
individualists, and Chuck was absolutely right with "standards are good, 
everybody ought to have one".

> I think I can come up with a standard that makes sense, and people will
> accept it, even though it will be incompatible with ANS-Forth/Forth-200x
> --- nobody has ever cared about ANS-Forth, not in 1994 and not today ---
> ANS-Forth was a steaming pile of vagueness, and Forth-200x is a house
> founded upon this which is even softer than sand.

Nobody will adopt your standard, for the same reason the ANS Forth is so 
wishy-washy:  Nobody wants to change his code.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#25429

On Tuesday, August 27, 2013 3:55:54 PM UTC+2, Bernd Paysan wrote:
> It had been close to dead by that time, and the "satisfy nobody by trying to
> satisfy everybody" is the symptom, not the cause.  Forth programmers are
> individualists, and Chuck was absolutely right with "standards are good,
> everybody ought to have one".

Don't you throw away your first program versions? Maybe we should try 
it on standards too. I think the hassle with standardizing Forth has 
delivered quite some insights on how to do it right.

Maybe it is time for another FORML. Develop 'the next Forth' on the 
extra EuroForth day. The strain to have to adapt one's favorite isn't
there then. Who knows what comes from it.

-marcel

 

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

#25430

mhx@iae.nl writes:
>Maybe it is time for another FORML. Develop 'the next Forth' on the 
>extra EuroForth day.

Not sure what you mean with "extra day".  EuroForth was once called
EuroFORML, so that's what you can and should do on the main
conference, and there are papers in that direction there.  I am going
to present one this year.  It would be great to see you there again.

- 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 2013: http://www.euroforth.org/ef13/

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

#25440

In article <21f895d5-8554-4437-99c7-498bb81bc79a@googlegroups.com>,
 <mhx@iae.nl> wrote:
>On Tuesday, August 27, 2013 3:55:54 PM UTC+2, Bernd Paysan wrote:
>> It had been close to dead by that time, and the "satisfy nobody by trying to
>> satisfy everybody" is the symptom, not the cause.  Forth programmers are
>> individualists, and Chuck was absolutely right with "standards are good,
>> everybody ought to have one".
>
>Don't you throw away your first program versions? Maybe we should try
>it on standards too. I think the hassle with standardizing Forth has
>delivered quite some insights on how to do it right.
>
>Maybe it is time for another FORML. Develop 'the next Forth' on the
>extra EuroForth day. The strain to have to adapt one's favorite isn't
>there then. Who knows what comes from it.

I know: yourforth. And you complained that it is not ISO.
I just added a pdf to it at bitbucket. (Three chapters worth of
exercises debugged.)

>
>-marcel

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#25444

On Wednesday, August 28, 2013 1:02:27 AM UTC+2, Albert van der Horst wrote:
[..]
>>Maybe it is time for another FORML. Develop 'the next Forth' on the
>>extra EuroForth day. The strain to have to adapt one's favorite isn't
>>there then. Who knows what comes from it.

> I know: yourforth. And you complained that it is not ISO.

Yes, mandating an implementation down to the nuts and bolts would be one 
possible experiment.

BTW I was not thinking of ISO Forth in this context. Why is it relevant that
yourforth is or isn't ISO? 

-marcel

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

#25431

Bernd Paysan <bernd.paysan@gmx.de> writes:
> That's the reason why people hate changes.  I don't see any problem
> with my statement.  If Forth-83 would have been a big change, the work
> would have been a lot more, and therefore, the hate would have been
> much bigger.

I'm not so sure of that.  Python 2 is a nice language though not
perfect.  It's received lots of the improvements that could be made
without breaking people's code.  It also has a number of small design
warts that can't be fixed without causing minor breakage, and some
larger improvements would be possible by introducing more serious
breakage.  It's not permitted to break people's code in Python 2 so
there was a long period of understanding that any incompatible changes
would be made in Python 3, which came out a few years ago.

Unfortunately (caveat: opinions vary and this is just my personal take
on it): Python 3's incompatible changes from Python 2 concentrated on
relatively minor stuff.  They were unwilling to create more serious
incompatibility, limiting it to cases that could be fixed easily.  So
the benefit from upgrading from 2 to 3 is not all that significant,
while the downside is having to go change user code that already works
perfectly well.  Converting is pretty easy, but why bother?

Result: most people still use Python 2, even for starting new projects.
IMHO, if the Python 3 designers had been willing to make a bigger break
from Python 2, then a number (minority but not trivial) of existing
programs probably would have had to stay with Python 2.  But Python 3
would be significantly more attractive both for new programs, and for
existing programs (most of them) that could be converted without too
much pain.

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

#25443

On Tuesday, August 27, 2013 6:55:54 AM UTC-7, Bernd Paysan wrote:
> hughaguilar96@yahoo.com wrote:
> > I think I can come up with a standard that makes sense, and people will
> > accept it, even though it will be incompatible with ANS-Forth/Forth-200x
> > --- nobody has ever cared about ANS-Forth, not in 1994 and not today ---
> > ANS-Forth was a steaming pile of vagueness, and Forth-200x is a house
> > founded upon this which is even softer than sand.
> 
> Nobody will adopt your standard, for the same reason the ANS Forth is so 
> wishy-washy:  Nobody wants to change his code.

There is no code to change. When was the last time anybody wrote an application program in Forth? This is 2013 --- there is no legacy code remaining --- essentially all old Forth programs got rewritten in C a decade or two ago.

My language will be for new programs being written from scratch --- what is carried over will be the knowledge in the programmer's head. Almost everybody on comp.lang.forth is here because they are interested in writing a Forth interpreter as a possibly fun and definitely weird hobby project --- they have zero interest in writing application programs in Forth --- unless they get interested in application-program writing however, they won't make the jump to my language, as my language will be for writing programs.

Also, considering how few people under the age of 40 know about Forth, a significant number of users will just see it as a new language, and will not have any historical perspective in the sense that they know that it is related to a language that was used in the late 1970s and early 1980s (long before most of them were born).

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

#25470

hughaguilar96@yahoo.com wrote:

> Also, why didn't the ANS-Forth committee just provide
> novice-level support code like { and MACRO: and FIELD,
> themselves??? How is it even possible to write an application
> program without the support code provided in the novice
> package? Why should I have to write this stuff myself 15 years
> after the ANS-Forth standard came out, and (coincidentally) 15
> years after Forth died out in the greater programming world?

(I broke your lines for you.  Anybody who knows anything
whatsoever about usenet knows that he must limit the length
of his lines.)

Because they were stupid and ignorant and lazy and they wanted
to make things easy for themselves and for Forth implementors.
They had no desire to make things easy for users of Forth.

Why don't you limit the length of your lines?

Because you are stupid and ignorant and lazy.

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

#25325

In article <521351cb.464555845@news.demon.co.uk>,
Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>On Mon, 19 Aug 2013 10:25:29 -0500, Andrew Haley
><andrew29@littlepinkcloud.invalid> wrote:
>
>>Humm.  I'm not trying to subvert anything, just making an observation.
>>There's no need to spread a Windows call over many lines.
>
>According to a client, they use on call that has 22 parameters.
>
>There's plenty of sample Windows code (in any language) that spreads
>a Windows call over multiple lines.

I tend to use a line for each parameter, like in the beer example:

----------
"Do you need additional place to put the cola?"  Z CONSTANT _message
"Bar top configuration"                       Z CONSTANT _caption

\ Return a FLAG indicating whether we need a place for beer.
: need-place-for-beer?
    MB_ICONQUESTION MB_YESNO  OR
    _caption
    _message
    0
    MessageBoxA CALL
    IDYES =
;

----------

Not always though:
-------------
: make-place-for-beer
         0 0 0 _cmd_open  mciSendStringA CALL THROW
         0 0 0 _cmd_eject mciSendStringA CALL THROW
         0 0 0 _cmd_close mciSendStringA CALL THROW
;

---------------

What was the subject again? Locals?

>
>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
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#25312

In article <2013Aug19.161856@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Ian van Breda <igvb@btopenworld.com> wrote:
>>>
>>> It is important, though, that the LOCALS|/{: should cover more that
>>> one line of source text, to allow named variables that are easy to
>>> read later.
>>
>>Color me skeptical.  I'm guessing that if you really need to do this
>>your definitions are too long.
>
>Possibly.  However, the number of locals was raised from 8 to 16.  If
>we write one {: ... :} definition with 16 locals on an 80 char line,
>an average local name must not be longer than 3.7 chars.  That's quite
>short in many cases, especially if you have 16 locals.  So we either
>need locals definitions across lines (as in VFX when the source is in
>a file), or support for multiple locals definitions (as in Gforth).
>
>Sure, you could say that 16 locals indicates that the definition is
>too long, but enough people found it useful to vote it into the
>standard (IIRC Windows calls were an argument for it).  In any case,
>it's wrong to try to subvert this decision by keeping other limits
>around.  It will not make the code better if programmers use the same
>high number of locals, but with very short names.

I beg to differ. I can imagine a math formula with 16 variables,
but not if they have java_type_long_supposedly_meaningful_names.

So if you have 16 locals they better be have names such as
R R' d d' q q'

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#25314

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>I can imagine a math formula with 16 variables,
>but not if they have java_type_long_supposedly_meaningful_names.
>
>So if you have 16 locals they better be have names such as
>R R' d d' q q'

Forth programs are not math formulas, and in programming the names
tend to be longer than in math.  Even if we take example from
Thinking Forth, "oedipus complex" is longer than 3.7 chars.

- 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 2013: http://www.euroforth.org/ef13/

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

#25339

Andrew Haley wrote on 19/08/2013 13:17:

> Color me skeptical.  I'm guessing that if you really need to do this
> your definitions are too long.  I haven't seen your code, so I might
> be wrong about this.
> 

In my parser, there are only 7 out of 160 LOCALS| that use the full 8 local
identifiers permitted in a single list, with a maximum of 7 initialised
values, one uninitialised.  There is only one list that needs to use 9
values and this was accommodated by using >R and R> anyway.  The number of
locals that cover more that one line is 17, consisting of six to eight
locals.

This compares with {: which can accommodate 16 locals in one list,
essentially double the number that I use (or need).  I consider this,
nevertheless, to be a conceptually complex application.

The reason that I need to use more that one line for the locals is that I
use compound names (never more that double) in order to make the definitions
much easier to read later and to maintain.

Ian

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

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

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

csiph-web