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

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

Forth reinvention

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

Contents

  Forth reinvention dambere@web.de - 2014-02-20 01:19 -0800
    Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 05:07 -0500
      Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-20 14:56 +0000
        Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 16:16 -0500
          Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-20 23:25 +0000
            Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 20:42 -0500
              Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 12:41 +0000
    Re: Forth reinvention Hans Bezemer <the.beez.speaks@gmail.com> - 2014-02-20 11:18 +0100
      Re: Forth reinvention dambere@web.de - 2014-02-20 02:36 -0800
        Re: Forth reinvention Hans Bezemer <the.beez.speaks@gmail.com> - 2014-02-20 17:35 +0100
          Re: Forth reinvention dambere@web.de - 2014-02-20 11:34 -0800
            Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-20 09:53 -1000
            Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-20 12:23 -0800
              Re: Forth reinvention dambere@web.de - 2014-02-20 14:00 -0800
                Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-20 14:23 -0800
                  Re: Forth reinvention dambere@web.de - 2014-02-22 02:21 -0800
                    Re: Forth reinvention AKK <akk@nospam.org> - 2014-02-22 12:02 +0100
                Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 04:38 -0600
            Re: Forth reinvention Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-20 12:35 -0800
              Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-20 13:38 -0800
    Re: Forth reinvention m.a.m.hendrix@tue.nl - 2014-02-20 03:59 -0800
      Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-20 15:11 +0000
        Re: Forth reinvention m.a.m.hendrix@tue.nl - 2014-02-20 07:41 -0800
    Re: Forth reinvention Richard Owlett <rowlett@pcnetinc.com> - 2014-02-20 06:38 -0600
      Re: Forth reinvention dambere@web.de - 2014-02-20 12:03 -0800
    Re: Forth reinvention Julian Fondren <julian.fondren@gmail.com> - 2014-02-20 07:08 -0800
    Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-20 09:37 -1000
      Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-20 20:50 +0000
        Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-20 15:39 -1000
          Re: Forth reinvention albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-21 10:50 +0000
          Re: Forth reinvention Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-02-21 11:10 +0000
            Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 13:50 +0000
          Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 05:46 -0600
            Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 12:55 +0000
            Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-21 15:11 +0000
              Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:23 -0600
          Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 12:38 +0000
          Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 13:29 +0000
            Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-22 07:52 -1000
              Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-22 19:06 +0000
              Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-23 13:40 +0000
      Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 20:40 -0500
        Re: Forth reinvention "Elizabeth D. Rather" <erather@forth.com> - 2014-02-20 18:43 -1000
          Re: Forth reinvention Hans Bezemer <the.beez.speaks@gmail.com> - 2014-02-21 13:16 +0100
        Re: Forth reinvention stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-21 10:49 +0000
      Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-21 14:50 +0000
        Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-21 16:28 +0000
          Re: Forth reinvention anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 12:54 +0000
            Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:27 -0500
            Re: Forth reinvention "Alex McDonald" <blog@rivadpm.com> - 2014-02-22 17:49 +0000
        Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-21 20:51 +0100
          Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:39 -0600
            Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 02:40 +0100
              Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-22 19:24 -0800
                Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 22:48 +0100
              Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:39 -0600
                Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 22:46 +0100
                  Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-02-23 14:26 -0800
                    Re: Forth reinvention Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-24 02:44 +0100
                      Re: Forth reinvention Spam@ControlQ.com - 2014-03-03 12:43 -0500
                      Re: Forth reinvention Paul Rubin <no.email@nospam.invalid> - 2014-03-03 10:06 -0800
                  Re: Forth reinvention Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-24 03:59 -0600
    Re: Forth reinvention mike73900@gmail.com - 2014-03-03 14:04 -0800
      Re: Forth reinvention mhx@iae.nl - 2014-03-05 06:59 -0800
        Re: Forth reinvention Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-03-05 16:33 +0100
        Re: Forth reinvention Mark Wills <markwills1970@gmail.com> - 2014-03-05 09:08 -0800
          Re: Forth reinvention mhx@iae.nl - 2014-03-05 10:47 -0800
    Re: Forth reinvention AKK <akk@nospam.org> - 2014-03-07 07:30 +0100
      Re: Forth reinvention Lars Brinkhoff <lars.spam@nocrew.org> - 2014-03-07 07:55 +0100
      Re: Forth reinvention albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 09:29 +0000
        Re: Forth reinvention AKK <akk@nospam.org> - 2014-03-07 12:04 +0100
        Re: Forth reinvention "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-07 17:03 -0500
          Re: Forth reinvention Mark Wills <markwills1970@gmail.com> - 2014-03-08 05:31 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#28595 — Forth reinvention

With regard to the discussion in 'Forth in oblivion', I have specifically asked the question what properties a Forth successor should have ?

I think important are the following aspects:

- switch to infix notation:
Personally I found RPN an elegant, mathematical notation both solving inconsistencies of traditional infix notations and ease parsing. However, in general people have an innate aversion to the adoption of unorthodox concepts nor are people able to think in abstract terms of implementation efficiency. For these psychological reasons, a RPN based programming language can hardly interest a wider audience without constraint, especially since most programmers these days are already grown with quite different (and much more complex) languages compared to Forth.
- Automatic parallelization:
The trend goes to multi core architectures. A programming language that is relieving the programmer from the not inconsiderable task of paralleling programs will necessarily be attractive.
- Lack of leadership:
To my knowledge, there exist no central leadership with financial impact to promote Forth by all means. This must change.

[toc] | [next] | [standalone]

#28596

On Thu, 20 Feb 2014 04:19:23 -0500, <dambere@web.de> wrote:

> With regard to the discussion in 'Forth in oblivion', I
> have specifically asked the question what properties a
> Forth successor should have ?
>
> I think important are the following aspects:
>
> - switch to infix notation:
> Personally I found RPN an elegant, mathematical notation both solving  
> inconsistencies of traditional infix notations and ease parsing.  
> However, in general people have an innate aversion to the adoption of  
> unorthodox concepts nor are people able to think in abstract terms of  
> implementation efficiency. For these psychological reasons, a RPN based  
> programming language can hardly interest a wider audience without  
> constraint, especially since most programmers these days are already  
> grown with quite different (and much more complex) languages compared to  
> Forth.

Good.

> - Automatic parallelization:
> The trend goes to multi core architectures. A programming language that  
> is relieving the programmer from the not inconsiderable task of  
> paralleling programs will necessarily be attractive.

Nice, but not necessary.  Single-threading is still useful, has
less overhead, and fewer environment specific requirements.

> - Lack of leadership:
> To my knowledge, there exist no central leadership with financial impact  
> to promote Forth by all means. This must change.

Not important.  "Too many cooks spoil the broth."  You need one
smart, visionary dictator to resurrect Forth anew.


In addition to eliminating RPN for infix, I would like to add the
following to the list:

-use of symbols for binary and logical operations like AND OR XOR
-name Forth words correctly for what they do
-eliminate the need for the user to maintain stack data
-use curly braces {} to delimit blocks


I know some people truly hate that last one, but it is critical.
It's so fundamental, it's even been added to Python now:

Python with Braces
http://www.pythonb.org/


Of course, once you eliminate infix from Forth, progress towards use
of symbols for logical, binary, math operations, begin to use curly
braces, and eliminate the work of the user keeping track of stack data,
someone is going to call it C warmed over ... which goes towards the
question of what *IS* Forth?  Once changed radically, is it still Forth?
Or, more critically, how can you resurrect Forth without recreating C,
or Ruby, or Perl, or Python, or some other existing language?


Rod Pemberton

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

#28606

on 20/02/2014 10:07:32, "Rod Pemberton" wrote:

> Of course, once you eliminate infix from Forth, progress towards use

You mean postfix.

> of symbols for logical, binary, math operations, begin to use curly

Forth doesn't have logical operations.

> braces, and eliminate the work of the user keeping track of stack

Forth doesn't have a block structure.

> data, someone is going to call it C warmed over ... which goes towards
> the question of what *IS* Forth? Once changed radically, is it still
> Forth? Or, more critically, how can you resurrect Forth without
> recreating C, or Ruby, or Perl, or Python, or some other existing
> language?
> 

Shorter answer: Forth is not what you want it to be, and resurrection is
for the religious.

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

#28623

On Thu, 20 Feb 2014 09:56:59 -0500, Alex McDonald <blog@rivadpm.com> wrote:
> on 20/02/2014 10:07:32, "Rod Pemberton" wrote:
>

>> Of course, once you eliminate infix from Forth, progress towards use
>
> You mean postfix.

Yes, true, sorry.  Technically, I meant to eliminate prefix too, not
just postfix.  So, unfortunately, 'eliminate' was actually the opposite
meaning of what I meant.

>> of symbols for logical, binary, math operations, begin to use curly
>
> Forth doesn't have logical operations.
>

If that were true, there would be no need for a "well formed flag" in  
Forth.

That was debated here recently and it seems you've supported use of "well
formed flags" in other threads.

>> braces, and eliminate the work of the user keeping track of stack
>
> Forth doesn't have a block structure.

It does.

E.g., this is a block structure:

( ... singular pre-computed condition on data stack ... )
IF
   ( ... block ... )
ELSE
   ( ... block ... )
THEN

Of course, Forth is not always expressed as well formatted text,
and doesn't have to be.

All of Forth's control-flow has words to mark the beginning and
ending of each block.  This is like many other languages, but
especially block oriented scripting languages.  But, I'll
demonstrate in COBOL (a language I've never programmed BTW):

IF ( ... set of conditions ... )
THEN
    ( ... block ... )
ELSE
    ( ... block ... )
END-IF

The THEN keyword for Forth and END-IF keyword for COBOL are needed
because they're block structured.  Inherently, all programming
languages are.

Of course, in C the syntax uses braces, if the block is more
than just one statement:

if  /* conditions */
{
   /* block */
}
else
{
   /* block */
}

You can do the same thing with any other control flow too, e.g.,
DO .. LOOP , ?DO .. +LOOP , BEGIN .. AGAIN , BEGIN .. UNTIL ,
BEGIN .. WHILE .. REPEAT , Eaker's case, etc.

Basically, the curly braces mark some of the locations where
branches for assembly or binary are placed in C.  These locations
correspond to where they are used in Forth control-flow words too.
Some Forths use BRANCH and 0BRANCH or ?BRANCH to place these branches.
The keywords in C mark some of other locations just as in Forth.
The rest are escape control-flow words like UNLOOP and EXIT in
Forth or 'break', 'continue' or 'goto' in C.

Block
http://en.wikipedia.org/wiki/Block_(programming)

Control-flow
http://en.wikipedia.org/wiki/Control_flow


Rod Pemberton

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

#28630

on 20/02/2014 21:16:16, "Rod Pemberton" wrote:
> On Thu, 20 Feb 2014 09:56:59 -0500, Alex McDonald <blog@rivadpm.com>
> > wrote:
>> on 20/02/2014 10:07:32, "Rod Pemberton" wrote:
> > wrote:
>>
> wrote:
> 
>>> Of course, once you eliminate infix from Forth, progress towards use
>>
>> You mean postfix.
> 
> Yes, true, sorry.  Technically, I meant to eliminate prefix too, not
> just postfix. So, unfortunately, 'eliminate' was actually the opposite
> meaning of what I meant.
> 
>>> of symbols for logical, binary, math operations, begin to use curly
>>
>> Forth doesn't have logical operations.
>>
> 
> If that were true, there would be no need for a "well formed flag" in
> Forth.
> 
> That was debated here recently and it seems you've supported use of
> "well formed flags" in other threads.

I mean in the sense of C's && and ||. There are no Forth equivalent
logical operators, and Forth's IF does not test for false or true; it
tests against zero.

> 
>>> braces, and eliminate the work of the user keeping track of stack
>>
>> Forth doesn't have a block structure.
> 
> It does.
> 
> E.g., this is a block structure:
> 
> ( ... singular pre-computed condition on data stack ... )
> IF
> ( ... block ... )
> ELSE
> ( ... block ... )
> THEN
> 
> Of course, Forth is not always expressed as well formatted text,
> and doesn't have to be.
> 
> All of Forth's control-flow has words to mark the beginning and
> ending of each block.  This is like many other languages, but
> especially block oriented scripting languages.  But, I'll
> demonstrate in COBOL (a language I've never programmed BTW):
> 
> IF ( ... set of conditions ... )
> THEN
> ( ... block ... )
> ELSE
> ( ... block ... )
> END-IF
> 
> The THEN keyword for Forth and END-IF keyword for COBOL are needed
> because they're block structured.  Inherently, all programming
> languages are.
> 
> Of course, in C the syntax uses braces, if the block is more
> than just one statement:
> 
> if  /* conditions */
> {
> /* block */
> }
> else
> {
> /* block */
> }
> 
> You can do the same thing with any other control flow too, e.g.,
> DO .. LOOP , ?DO .. +LOOP , BEGIN .. AGAIN , BEGIN .. UNTIL ,
> BEGIN .. WHILE .. REPEAT , Eaker's case, etc.
> 
> Basically, the curly braces mark some of the locations where
> branches for assembly or binary are placed in C.  


Rubbish. This is legal C that has no blocks.

  if ( x==y ) then a=1; else b=1;

> These locations
> correspond to where they are used in Forth control-flow words too.
> Some Forths use BRANCH and 0BRANCH or ?BRANCH to place these branches.
> The keywords in C mark some of other locations just as in Forth. The
> rest are escape control-flow words like UNLOOP and EXIT in Forth or
> 'break', 'continue' or 'goto' in C.
> 
> Block
> http://en.wikipedia.org/wiki/Block_(programming)
> 
> Control-flow
> http://en.wikipedia.org/wiki/Control_flow
> 
> 

Control flow doesn't make it a block structured language (and the
articles you provide make that clear).

{ int a; a=1; f(a) } { int b; b=2; f(b) } 

and not a control flow in sight.

> Rod Pemberton
> 

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

#28633

On Thu, 20 Feb 2014 18:25:04 -0500, Alex McDonald <blog@rivadpm.com> wrote:
> on 20/02/2014 21:16:16, "Rod Pemberton" wrote:
>> On Thu, 20 Feb 2014 09:56:59 -0500, Alex McDonald <blog@rivadpm.com>

>> Of course, in C the syntax uses braces, if the block is more
>> than just one statement:
>>
>> [snip]
>
> This is legal C that has no blocks.
>
>   if ( x==y ) then a=1; else b=1;
>

Sorry, it's not legal C.  C has no "then" ...  :-)

Did you catch that after you posted and cringe?  ;-)

So, your example, fixed:

   if ( x==y ) a=1; else b=1;

That example does too have blocks.  They just don't need to
be marked.  I mentioned that above:

RP> "if the block is more than just one statement"

Those blocks are only one statement.

The fixed example is the same as this:

if(x==y)
   a=1;
else
   b=1;

which is the same as this:

/* braces optional */
/* indicates location of the block */

if(x==y)
{
   a=1;
}
else
{
   b=1;
}

You only need the braces for more than one statement per block:

/* braces required */

if(x==y)
{
   a=1;
   c=2;
}
else
{
   b=1;
   d=3;
}

Of course, most "skilled" C programmers prefer to format C (oddly)
like so:

/* with spaces, offset braces */

if ( x == y ) {
   a = 1;
   c = 2;
}
else {
   b = 1;
   d = 3;
}

The problem with that is it leads to misaligned braces and/or
indentation over time.

And, of course, in C, you can write that without any formatting
or spacing at all:

if(x==y){a=1;c=2;}else{b=1;d=3;}

But, you (generally) need a space here, although it's not required:

if(x==y)a=1;else b=1;

That space depends on the parsing implementation.  Most C parsers need it.
Otherwise, IIRC, the only place C requires a space is for "long long".   
Other
C types are just one word, not including sign: "int" "short" "long" "char".

>> These locations
>> correspond to where they are used in Forth control-flow words too.
>> Some Forths use BRANCH and 0BRANCH or ?BRANCH to place these branches.
>> The keywords in C mark some of other locations just as in Forth. The
>> rest are escape control-flow words like UNLOOP and EXIT in Forth or
>> 'break', 'continue' or 'goto' in C.
>>
>> Block
>> http://en.wikipedia.org/wiki/Block_(programming)
>>
>> Control-flow
>> http://en.wikipedia.org/wiki/Control_flow
>
> Control flow doesn't make it a block structured language (and the
> articles you provide make that clear).
>

I don't know what you're replying to here.  You seem to be conflating
control flow with block structured languages.  Then, you're ascribing
it to me ...

> { int a; a=1; f(a) } { int b; b=2; f(b) }
>
> and not a control flow in sight.
>

C has blocks.  Blocks aren't marked by keywords.  They're marked by
braces.  C's not a block structured language.

Forth has blocks.  Blocks are marked by keywords.  Forth is a block
structured language.  Those keywords correspond to control flow.

Even if we throw C's procedures and Forth's colon-definition into
the mix, I don't see that anything changes.  Those mark blocks too.


Rod Pemberton

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

#28655

on 21/02/2014 01:42:31, "Rod Pemberton" wrote:

[snipped]

I can't respond to this. Life's too short.

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

#28597

dambere@web.de wrote:

> With regard to the discussion in 'Forth in oblivion', I have specifically
> asked the question what properties a Forth successor should have ?
> 
> I think important are the following aspects:
> 
> - switch to infix notation:
> Personally I found RPN an elegant, mathematical notation both solving
> inconsistencies of traditional infix notations and ease parsing. However,
> in general people have an innate aversion to the adoption of unorthodox
> concepts nor are people able to think in abstract terms of implementation
> efficiency. For these psychological reasons, a RPN based programming
> language can hardly interest a wider audience without constraint,
> especially since most programmers these days are already grown with quite
> different (and much more complex) languages compared to Forth. - Automatic
> parallelization: The trend goes to multi core architectures. A programming
> language that is relieving the programmer from the not inconsiderable task
> of paralleling programs will necessarily be attractive. - Lack of
> leadership: To my knowledge, there exist no central leadership with
> financial impact to promote Forth by all means. This must change.
You can't grasp what Forth is. So, if you can't appreciate it, just use
another language.

I'll tell you what Forth is. Forth is Centre Pompidou - instead of hiding
all the tubing, it is exposed to the outside.

- Most compilers work with stacks. But instead of hiding them, Forth exposes
them. That puts the effort of handling them on the programmer, not the
compiler.
- Most compilers work with RPN - or close to it. Instead of hiding that,
Forth exposes that.

Thus, by "abstracting" those feats you're going against each and every
aspect which Forth IS - so it's no longer Forth. That's ok, there are
plenty of languages you can choose from.

Another example: although ColorForth has gone way beyond of what Forth is,
it preserved and even enforces the aspects I've highlighted. It's
completely the reverse of what you're suggesting. Another example is
Factor, which incorporates some newer concepts into Forth. But it doesn't
touch the bare essence.

So, please go back to whatever the poison is which you prefer and stop
making ill-conceived and stupid posts here.

Hans Bezemer

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

#28598

Am Donnerstag, 20. Februar 2014 11:18:21 UTC+1 schrieb The Beez:
> dambere@web.de wrote:
> 
> 
> 
> > With regard to the discussion in 'Forth in oblivion', I have specifically
> 
> > asked the question what properties a Forth successor should have ?
> 
> > 
> 
> > I think important are the following aspects:
> 
> > 
> 
> > - switch to infix notation:
> 
> > Personally I found RPN an elegant, mathematical notation both solving
> 
> > inconsistencies of traditional infix notations and ease parsing. However,
> 
> > in general people have an innate aversion to the adoption of unorthodox
> 
> > concepts nor are people able to think in abstract terms of implementation
> 
> > efficiency. For these psychological reasons, a RPN based programming
> 
> > language can hardly interest a wider audience without constraint,
> 
> > especially since most programmers these days are already grown with quite
> 
> > different (and much more complex) languages compared to Forth. - Automatic
> 
> > parallelization: The trend goes to multi core architectures. A programming
> 
> > language that is relieving the programmer from the not inconsiderable task
> 
> > of paralleling programs will necessarily be attractive. - Lack of
> 
> > leadership: To my knowledge, there exist no central leadership with
> 
> > financial impact to promote Forth by all means. This must change.
> 
> You can't grasp what Forth is. So, if you can't appreciate it, just use
> 
> another language.
> 
> 
> 
> I'll tell you what Forth is. Forth is Centre Pompidou - instead of hiding
> 
> all the tubing, it is exposed to the outside.
> 
> 
> 
> - Most compilers work with stacks. But instead of hiding them, Forth exposes
> 
> them. That puts the effort of handling them on the programmer, not the
> 
> compiler.
> 
> - Most compilers work with RPN - or close to it. Instead of hiding that,
> 
> Forth exposes that.
> 
> 
> 
> Thus, by "abstracting" those feats you're going against each and every
> 
> aspect which Forth IS - so it's no longer Forth. That's ok, there are
> 
> plenty of languages you can choose from.
> 
> 
> 
> Another example: although ColorForth has gone way beyond of what Forth is,
> 
> it preserved and even enforces the aspects I've highlighted. It's
> 
> completely the reverse of what you're suggesting. Another example is
> 
> Factor, which incorporates some newer concepts into Forth. But it doesn't
> 
> touch the bare essence.
> 
> 
> 
> So, please go back to whatever the poison is which you prefer and stop
> 
> making ill-conceived and stupid posts here.
> 
> 
> 
> Hans Bezemer

Please read my post again and search for a way to argument rational based on the argument given. This requires the ability to not decrease people in their personal integrity, thanks.

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

#28612

dambere@web.de wrote:
> Please read my post again and search for a way to argument rational based
> on the argument given. This requires the ability to not decrease people in
> their personal integrity, thanks.

That's the whole point: it isn't rational. What you suggest is equal
to "let's add wings to a car, so it can fly". Then it wouldn't be a car
anymore, it would be a plane. We are petrol heads. We like cars. If you
wanna fly, use another vehicle.

Don't comment on things you don't comprehend. It has nothing to do
with "personal integrity". I absolutely and truly believe you're honest -
but ignorant.

Hans Bezemer

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

#28615

Am Donnerstag, 20. Februar 2014 17:35:36 UTC+1 schrieb The Beez:
> dambere@web.de wrote:
> 
> > Please read my post again and search for a way to argument rational based
> 
> > on the argument given. This requires the ability to not decrease people in
> 
> > their personal integrity, thanks.
> 
> 
> 
> That's the whole point: it isn't rational. What you suggest is equal
> 
> to "let's add wings to a car, so it can fly". Then it wouldn't be a car
> 
> anymore, it would be a plane. We are petrol heads. We like cars. If you
> 
> wanna fly, use another vehicle.
> 
> 
> 
> Don't comment on things you don't comprehend. It has nothing to do
> 
> with "personal integrity". I absolutely and truly believe you're honest -
> 
> but ignorant.
> 
> 
> 
> Hans Bezemer

Please note that my initial post do not refer to Forth as language in terms of a language *progression* but questioned the possible characterisation of a Forth *successor* in the sense B was one BCPL inspired language for example; This hypothetical language must not take necessarily elementary concepts of its predecessor.

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

#28617

On 2/20/14 9:34 AM, dambere@web.de wrote:
...
>
> Please note that my initial post do not refer to Forth as language in terms of a language *progression* but questioned the possible characterisation of a Forth *successor* in the sense B was one BCPL inspired language for example; This hypothetical language must not take necessarily elementary concepts of its predecessor.
>

Many of the folks here are using modern Forths in real-world 
applications. We are seeking to improve them. Designing a "language of 
tomorrow" is a potentially interesting project, but should ideally be 
address not in this group but in the context of a backer (either 
academic or commercial) capable of providing the financial support for 
people to explore and implement ideas and then present them to potential 
users. Otherwise, all we have is empty speculation.

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]

#28619

dambere@web.de writes:
> Please note that my initial post do not refer to Forth as language in
> terms of a language *progression* but questioned the possible
> characterisation of a Forth *successor* 

Let's see, you want to get rid of 

 1) postfix notation
 2) tradtionally very simple implementation (since you want to
    parallelize automatically, which is complicated)
 3) individualistic variations on the language (since you want
    centralized leadership)
 
What parts of Forth do you actually want to keep?

I actually think the claim that other languages use stacks (i.e. they
are like Forth beyond some syntax sugar) is subtly wrong: other
languages use extensible arrays as stacks, so they freely access and
modify the interior cells of the stacks.  You can approximate that in
Forth by using locals or PICK freely, but Forth purists frown on that,
and preferred Forth style does most operations on the top one or two
stack cells, in combination with some stack juggling operators like DUP
and SWAP.  That by itself adds considerable hassle to Forth programming,
probably enough to repel many programmers who just want to get stuff
done, but it's part of the Zen of Forth.  It keeps Forth implementations
(hardware and software) very simple, and Forth applications concise and
memory-efficient, at the expense of some extra coding effort.

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

#28626

Am Donnerstag, 20. Februar 2014 21:23:02 UTC+1 schrieb Paul Rubin:
> dambere@web.de writes:
> 
> > Please note that my initial post do not refer to Forth as language in
> 
> > terms of a language *progression* but questioned the possible
> 
> > characterisation of a Forth *successor* 
> 
> 
> 
> Let's see, you want to get rid of 
> 
> 
> 
>  1) postfix notation 
>  2) tradtionally very simple implementation (since you want to
>     parallelize automatically, which is complicated)
>  3) individualistic variations on the language (since you want
>     centralized leadership)
> 
>  
> 
> What parts of Forth do you actually want to keep?

To 1:
If you see Forth as a language which is based upon (not only of course) functional concatenation instead of functionality application, the notation get interchangeable between post and infix notations as long as latter is free of side-rules. It is often forgotten that in addition to UPN there exist also appropriate infix notations. The difference between both should be theoretical negligible in relation to possible implementation details so the simple procedure of Forth specific "parsing" is one part which should get comparable (more or less).

That's one example.

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

#28627

dambere@web.de writes:
> the notation get interchangeable between post and infix notations as
> long as latter is free of side-rules. 

OK, here is a simple Forth word:

  : SQUARE ( n -- n ) DUP * ;

What is the equivalent infix notation?  That would help me understand
what you are suggesting.

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

#28674

Am Donnerstag, 20. Februar 2014 23:23:07 UTC+1 schrieb Paul Rubin:
> dambere@web.de writes:
> 
> > the notation get interchangeable between post and infix notations as
> 
> > long as latter is free of side-rules. 
> 
> 
> 
> OK, here is a simple Forth word:
> 
> 
> 
>   : SQUARE ( n -- n ) DUP * ;
> 
> 
> 
> What is the equivalent infix notation?  That would help me understand
> 
> what you are suggesting.

that would be:

: SQUARE Ø * Ø ; Where 'Ø' is a monadic operator returning TOS.

In reference to the earlier discussion, it was written an infix notation would not be possible without some kind of preference. To show this is not true and explain above declaration let me allow to exemplary it:

There exist two possible (as I remember) infix notations which are side-rule ( preference) free. The first one declare evaluation from left to right where the second from right to left. Both have in common that special side-rules are avoided though 1. equivalence of all operators and 2. inclusion of three operation types: Monadic, Unaric and Dyadic ones. Then, for a Forth 'inspired' kind of "parsing", the second notation variant is always directly equivalent to a RPN notation (with one exception) -

For example, let us exemplary 'parse' the following sequence:

Z := cub x + pot y + 2 * x + n

Because we calculate these formula from right to left the sequence is evaluated this way:

n +,
x *,
2 +,
y pot,
x cub.

→

cub x + pot y + 2 * x + n = n + x * 2 + y pot x cub

As every one can see this notation is equivalent to the selection of one possible RPN notation as long as both, infix and postfix notation can be combined to a palindromic sequence. Because above explained notation ensuring this, such infix notation can be principally 'parsed' the same way as it is common in (standard) Forth. There exist only one exception which need to be handled differently; Dyadic operators are placed between there operands which can occur by logic at the start of a formula. Either the parser fetch 3 tokens, separated by space and then compile different code dependent of the operator type or simply transform dyadic operators to a sequence of unaric ones at typing (which was done in the formula above). Both is easily implementable.
Anyhow, monadic operators do not need to be specially handled because there do not depend on given parameters, so the statement:

Ø * Ø is simply curried to:

Ø * Ø = pot Ø

which is equivalent to:

dup *

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

#28675

Am 22.02.2014 11:21, schrieb dambere@web.de:
> Am Donnerstag, 20. Februar 2014 23:23:07 UTC+1 schrieb Paul Rubin:
>> dambere@web.de writes:
>>
>>> the notation get interchangeable between post and infix notations as
>>
>>> long as latter is free of side-rules.
>>
>>
>>
>> OK, here is a simple Forth word:
>>
>>
>>
>>    : SQUARE ( n -- n ) DUP * ;
>>
>>
>>
>> What is the equivalent infix notation?  That would help me understand
>>
>> what you are suggesting.
>
> that would be:
>
> : SQUARE Ø * Ø ; Where 'Ø' is a monadic operator returning TOS.
>
> In reference to the earlier discussion, it was written an infix notation would not be possible without some kind of preference. To show this is not true and explain above declaration let me allow to exemplary it:
>
> There exist two possible (as I remember) infix notations which are side-rule ( preference) free. The first one declare evaluation from left to right where the second from right to left. Both have in common that special side-rules are avoided though 1. equivalence of all operators and 2. inclusion of three operation types: Monadic, Unaric and Dyadic ones. Then, for a Forth 'inspired' kind of "parsing", the second notation variant is always directly equivalent to a RPN notation (with one exception) -
>
> For example, let us exemplary 'parse' the following sequence:
>
> Z := cub x + pot y + 2 * x + n
>
> Because we calculate these formula from right to left the sequence is evaluated this way:
>
> n +,
> x *,
> 2 +,
> y pot,
> x cub.
>
> →
>
> cub x + pot y + 2 * x + n = n + x * 2 + y pot x cub
>
> As every one can see this notation is equivalent to the selection of one possible RPN notation as long as both, infix and postfix notation can be combined to a palindromic sequence. Because above explained notation ensuring this, such infix notation can be principally 'parsed' the same way as it is common in (standard) Forth. There exist only one exception which need to be handled differently; Dyadic operators are placed between there operands which can occur by logic at the start of a formula. Either the parser fetch 3 tokens, separated by space and then compile different code dependent of the operator type or simply transform dyadic operators to a sequence of unaric ones at typing (which was done in the formula above). Both is easily implementable.
> Anyhow, monadic operators do not need to be specially handled because there do not depend on given parameters, so the statement:
>
> Ø * Ø is simply curried to:
>
> Ø * Ø = pot Ø
>
> which is equivalent to:
>
> dup *
>

err, please excuse, but I am preferring the late Julian Nobles formula 
translator .. it works in plain Forth.

why one would want to throw the KISS principle over board when 
"reinventing Forth" is way beyond me.

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

#28644

dambere@web.de wrote:
> Am Donnerstag, 20. Februar 2014 21:23:02 UTC+1 schrieb Paul Rubin:
>> dambere@web.de writes:
>> 
>> > Please note that my initial post do not refer to Forth as language in
>> > terms of a language *progression* but questioned the possible
>> > characterisation of a Forth *successor* 
>> 
>> Let's see, you want to get rid of 
>> 
>>  1) postfix notation 
>>  2) tradtionally very simple implementation (since you want to
>>     parallelize automatically, which is complicated)
>>  3) individualistic variations on the language (since you want
>>     centralized leadership)
>> 
>> What parts of Forth do you actually want to keep?
> 
> To 1:
> If you see Forth as a language which is based upon (not only of
> course) functional concatenation instead of functionality
> application, the notation get interchangeable between post and infix
> notations as long as latter is free of side-rules. It is often
> forgotten that in addition to UPN there exist also appropriate infix
> notations. The difference between both should be theoretical
> negligible in relation to possible implementation details so the
> simple procedure of Forth specific "parsing" is one part which
> should get comparable (more or less).

Let's talk practicalities.  If you have infix notation then you
probably have to define some sort of operator precedence.  Not
necessarily: Smalltalk didn't bother, but people don't really like to
put parentheses in 2+a*x.  How are you going to do this?  In Forth
*everything* in an operator; or everything is a function.

Also, you are going to need to define lexing rules.  I have looked at
this and it's difficult.  Infix code where every token is delimited by
spaces just looks wrong.  You can start imposing rules about what
words can be called, but that restricts people's ability to define
problem-specific notations.

Finally, if a language is to be used interactively it has to be
concise: there shouldn't be complex syntax to type.  Even something
like

  fred 5 dump

is better than

  dump(fred, 5)

A Smalltalk-ish syntax might be

  Fred dump: 5

lisp would be

  (dump fred 5)

This really does matter: interactivity is important.

Andrew.

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

#28621

It's already there. Just use factor, with all is bells and whistles. At least it preserves the essence of Forth. You can see the Forth DNA running through it. Your argument re RPN is nieve in my opinion. An example would be to say that we should only make tricycles because bicycles are really hard to ride. Yet the truth is that millions upon millions of people can ride a bicycle with no problem. Same with Forth. The first day is hard. By the second day you're getting it. By the fifth day you don't even give it a second thought. "It's as easy as riding a bike" :-)

Another point re RPN and pre/post fix et Al: Forth may be hard for us when starting out but that's mainly because we bring our "mainstream" language with us. When learning Forth, we should really leave it at the door; it just weighs you down. Sit a child down at a Forth console. He has no pre-conceptions of what a programing language should be. He wouldn't give it a second thought. 

Regards

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

#28624

Mark Wills <markrobertwills@yahoo.co.uk> writes:
> It's already there. Just use factor, with all is bells and
> whistles. At least it preserves the essence of Forth. You can see the
> Forth DNA running through it. 

I don't see that at all.  Factor is more like a postfix Lisp.  It has
runtime type tags, garbage collection, primitive variable-sized objects
like strings, etc.[1] It was originally implemented in Java, for crying
out loud ;-).  Forth to me is characterized by being very simple
implementation that stays close to machine primitives, manual memory
management, and an idiomatic style that does most calculations by
explicit stack operations (i.e.  local variables and PICK are avoided).
This in turn puts a bunch of non-typical incentives on development
practices that are probably significant components of Forth "Zen".

[1] http://en.wikipedia.org/wiki/Factor_%28programming_language%29

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web