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

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

A New Forth

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

Contents

  A New Forth tabcomputing@gmail.com - 2016-10-07 17:56 -0700
    Re: A New Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-07 23:05 -0400
      Re: A New Forth Walter Banks <walter@bytecraft.com> - 2016-10-08 10:07 -0400
    Re: A New Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-08 13:08 +0000
      Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 10:54 -0700
        Re: A New Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-08 18:03 +0000
          Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 11:13 -0700
      Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 11:17 -0700
      Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:44 -0700
        Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:53 -0700
          Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 15:04 -0700
          Re: A New Forth rickman <gnuarm@gmail.com> - 2016-10-13 22:55 -0400
    Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 12:11 -0700
      Re: A New Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-08 21:31 +0200
        Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 17:07 -0700
      Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 12:33 -0700
        Re: A New Forth missycurl@gmail.com - 2016-10-08 12:54 -0700
          Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 13:29 -0700
        Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 17:28 -0700
          Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 18:00 -0700
            Re: A New Forth trans <transfire@gmail.com> - 2016-10-09 09:00 -0700
              Re: A New Forth luser droog <mijoryx@yahoo.com> - 2016-10-09 11:19 -0700
              Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 01:09 -0700
                Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 08:24 -0700
                  Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 13:28 -0700
                    Re: A New Forth "Elizabeth D. Rather" <erather@forth.com> - 2016-10-10 11:14 -1000
                      Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 15:11 -0700
                        Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-11 21:46 -0400
                    Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 16:26 -0700
                      Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 18:58 -0700
                        Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 20:15 -0700
                Re: A New Forth Ron Aaron <rambamist@gmail.com> - 2016-10-11 07:26 +0300
                  Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 03:09 -0700
                    Re: A New Forth Ron Aaron <rambamist@gmail.com> - 2016-10-11 13:27 +0300
                  Re: A New Forth lawrencedo99@gmail.com - 2016-10-13 18:41 -0700
                    Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 19:08 -0700
                    Re: A New Forth Ron Aaron <rambamist@gmail.com> - 2016-10-14 07:58 +0300
            Re: A New Forth franck.bensusan@gmail.com - 2016-10-09 11:09 -0700
            Re: A New Forth lawrencedo99@gmail.com - 2016-10-13 18:45 -0700
          Re: A New Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-09 10:54 +0200
            Re: A New Forth missycurl@gmail.com - 2016-10-09 07:35 -0700
            Re: A New Forth Melzzzzz <mel@zzzzz.com> - 2016-10-11 06:23 +0200
            Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 21:31 -0700
            Re: A New Forth franck.bensusan@gmail.com - 2016-10-15 00:26 -0700
          Re: A New Forth Melzzzzz <mel@zzzzz.com> - 2016-10-13 19:16 +0200
            Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 11:46 -0700
              Re: A New Forth Melzzzzz <Melzzzzz@zzzzz.com> - 2016-10-13 19:04 +0000
          Re: A New Forth "WJ" <w_a_x_man@yahoo.com> - 2016-10-15 20:07 +0000
      Re: A New Forth luser droog <mijoryx@yahoo.com> - 2016-10-08 13:56 -0700
    Re: A New Forth polymorph self <jackvanc3@gmail.com> - 2016-10-08 19:58 -0700
    Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-10 19:22 -0700
      Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 20:18 -0700
        Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-11 11:14 -0700
          Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 14:22 -0700
            Re: A New Forth jim.brakefield@ieee.org - 2016-10-11 15:11 -0700
              Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 18:03 -0700
            Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-11 15:13 -0700
              Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-11 17:52 -0700
                Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 19:55 -0700
                Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:21 -0700
                  Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:36 -0700
              Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 18:08 -0700
                Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-11 18:21 -0700
                  Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 20:01 -0700
          Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 20:33 -0700
            Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-12 01:15 -0400
              Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 05:44 -0700
                Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-12 11:51 -0400
                  Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 09:47 -0700
                    Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-12 10:08 -0700
                      Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 11:48 -0700
                        Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-12 11:56 -0700
                    Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-12 13:41 -0400
                      Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 11:57 -0700
                        Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 12:02 -0700
                        Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-13 09:24 -0400
                          Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-13 10:33 -0400
                            Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 10:05 -0700
                    Re: A New Forth jim <anon@example.com> - 2016-10-12 19:01 +0100
                      Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 09:53 -0700
                        Re: A New Forth fred <anon@example.com> - 2016-10-14 12:37 +0100
                          Re: A New Forth jim <anon@example.com> - 2016-10-14 14:49 +0100
                          Re: A New Forth trans <transfire@gmail.com> - 2016-10-14 07:20 -0700
                            Re: A New Forth jim <anon@example.com> - 2016-10-15 11:58 +0100
                              Re: A New Forth tabcomputing@gmail.com - 2016-10-15 10:21 -0700
            Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-12 04:33 -0700
    Re: A New Forth Whammo <sidciavic@gmail.com> - 2016-10-15 12:23 -0700

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

#51729

On Saturday, October 8, 2016 at 9:00:31 PM UTC-4, Paul Rubin wrote:
> trans <transfire@gmail.com> writes:
> > It's static as much as possible and dynamic otherwise,
> 
> Normally I think of "dynamic" as meaning "runtime type tags".  Maybe
> that's approximately what you plan to do with jump tables.

I'm still working out feasibility, but the idea is the type tags only need to exist for the compiler which reduces them into jump tables (if there is a runtime decision to be made about which type to use).
 
> You might look at Oforth, 8th, Factor, and Postscript as someone
> mentioned.  

I will give OForth and Postscript a look. I've already checked out the other two. Correct me if I am wrong. 8th is really just Forth, modernized a little -- nothing really new going on? And Factor, is it considered a "actual" Forth? It uses an AST, so that made me think it wasn't. Pretty sure neither is statically typed.

> I myself haven't yet understood the attraction of Forth-like
> syntax in those languages, at least for humans: once you're willing to
> have that many moving parts in an implementation, you might as well
> offer an automatic way to tell (e.g.) where the arg list for a function
> begins and ends.  So you end up with something like Lisp instead of
> Forth.  

I thought about that too. But the problem is we loose the elegant compose-ability of RPN and the parentheses start flying. APL is the only other language that has some how worked around this, but now that I think about I am not 100% sure how. But I don't know APL very well.

> There's also Strongforth which may have already come up here.

I started studying that for ideas. It uses a parallel type stack, which makes sense as it is trying add types on top of Forth as it is. 

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

#51732

On Sunday, October 9, 2016 at 11:00:18 AM UTC-5, trans wrote:

> I thought about that too. But the problem is we loose the elegant compose-ability of RPN and the parentheses start flying. APL is the only other language that has some how worked around this, but now that I think about I am not 100% sure how. But I don't know APL very well.
> 

I've done some exploring into this. The original APL book heavily
cites Lukasiewicz and an early implementation by Burkes, Warren,
and Wright.

http://cs.stackexchange.com/questions/24571/extending-the-type-scheme-for-burks-warren-wright-machine-to-handle-operators-on
http://stackoverflow.com/questions/22366141/how-to-understand-the-f-function-in-burks-warren-wrights-lukasiewicz-logic-mach

For lots of implementation suggestions and ideas for APL, please
see Tim Rentsch's posts to my review thread:
https://groups.google.com/d/topic/comp.lang.c/X7BzyIKpogg/discussion
For evaluating it uses a stack of (type, object) tuples. 
But this analysis could also be factored-out in a compiling stage.

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

#51736

trans <transfire@gmail.com> writes:
> I'm still working out feasibility, but the idea is the type tags only
> need to exist for the compiler which reduces them into jump tables (if
> there is a runtime decision to be made about which type to use).

You can sometimes infer the type, but in general, how do you know which
index to use into the jump table?

>> You might look at Oforth, 8th, Factor, and Postscript as someone
>> mentioned.  

> 8th is really just Forth, modernized a little -- nothing really new
> going on? 

I don't think of it that way, but it depends on your philosophical view
of "really just Forth" means.  I'd say that 8th, Oforth, and Factor are
all Lisp-like languages (dynamic types, complicated objects like
strings, garbage collection) with Forth-like syntax.  But I haven't used
any of them and may have mistaken impressions.

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

#51740

On Monday, October 10, 2016 at 4:09:08 AM UTC-4, Paul Rubin wrote:
> trans <transfire@gmail.com> writes:
> > I'm still working out feasibility, but the idea is the type tags only
> > need to exist for the compiler which reduces them into jump tables (if
> > there is a runtime decision to be made about which type to use).
> 
> You can sometimes infer the type, but in general, how do you know which
> index to use into the jump table?

The basic idea is that every word has a set of possible return type signatures. To keep things simple lets say a word returns one value, but it can be either a Int32 or a String. So we have what other languages call a Union type, (Int32 | String). My idea is to assign each possibility a jump index. So in this case, 0 for Int32 and 1 for String. Then, instead of compiling the next word as a pointer to a word definition in the dictionary per usual (which we can't b/c we need to know the type), we compile it to a pointer to a "jump definition" that uses the jump index to look up the pointer in its mini jump table (just two entries in this case) which points to the correct definition for that type. Of course it gets more complicated when you add multiple arguments, but its still the same basic idea.

Hope I explained that well enough. If not I can draw a diagram, which should make it clear. 

The only thing I am not sure about is how to actually handle the jump indexes, do they go on a separate stack, or the data stack or what? And how does the compiler figure them for a given word definition? In that respect there may be something I've not considered that makes this infeasible, but it seems like it should be possible.

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

#51744

trans <transfire@gmail.com> writes:
> instead of compiling the next word as a pointer to a word definition
> in the dictionary per usual (which we can't b/c we need to know the
> type), we compile it to a pointer to a "jump definition" that uses the
> jump index to look up the pointer in its mini jump table (just two
> entries in this case) which points to the correct definition for that
> type.

You mean every word needs a separate definition for each possible input
parameter type?  Or worse, every combination of parameter types?  That
doesn't sound practical.  If you want runtime polymorphism like that, I
think you need type tags like every other dynamically typed language
uses.

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

#51745

On 10/10/16 10:28 AM, Paul Rubin wrote:
> trans <transfire@gmail.com> writes:
>> instead of compiling the next word as a pointer to a word definition
>> in the dictionary per usual (which we can't b/c we need to know the
>> type), we compile it to a pointer to a "jump definition" that uses the
>> jump index to look up the pointer in its mini jump table (just two
>> entries in this case) which points to the correct definition for that
>> type.
>
> You mean every word needs a separate definition for each possible input
> parameter type?  Or worse, every combination of parameter types?  That
> doesn't sound practical.  If you want runtime polymorphism like that, I
> think you need type tags like every other dynamically typed language
> uses.
>

In my experience, words don't randomly return things of different 
types... they do what their stack comments indicate, and those show 
types to the extent there are any. To be sure, there are words like DUP 
that are inherently untyped, except for things indicating the size or 
whereabouts of the item (e.g., 2DUP for paired items, FDUP operating on 
the FP stack), but surely that can be accommodated without excess 
complexity.

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]

#51746

"Elizabeth D. Rather" <erather@forth.com> writes:
> In my experience, words don't randomly return things of different
> types... they do what their stack comments indicate, and those show
> types to the extent there are any. To be sure, there are words like
> DUP that are inherently untyped, 

I'd say DUP is polymorphic (takes a value of any type, and pushes a
value of the same type); preferred Forth practice is that most or all
words have static signatures like that.  However, Trans is explicitly
wanting arbitrary words to return types determined at runtime.  This is
sometimes done in dynamically typed languages but even then, it should
only be done when there's a clear reason.

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

#51783

On 10/10/16 6:11 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> In my experience, words don't randomly return things of different
>> types... they do what their stack comments indicate, and those show
>> types to the extent there are any. To be sure, there are words like
>> DUP that are inherently untyped,
>
> I'd say DUP is polymorphic (takes a value of any type, and pushes a
> value of the same type);

If DUP were truly polymorphic then FDUP (or $DUP for a string stack,
etc.) would not be needed. Oforth has a polymorphic DUP.

-Doug

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

#51747

On Monday, October 10, 2016 at 4:28:13 PM UTC-4, Paul Rubin wrote:
> trans <transfire@gmail.com> writes:
> > instead of compiling the next word as a pointer to a word definition
> > in the dictionary per usual (which we can't b/c we need to know the
> > type), we compile it to a pointer to a "jump definition" that uses the
> > jump index to look up the pointer in its mini jump table (just two
> > entries in this case) which points to the correct definition for that
> > type.
> 
> You mean every word needs a separate definition for each possible input
> parameter type?  Or worse, every combination of parameter types?  That
> doesn't sound practical.  If you want runtime polymorphism like that, I
> think you need type tags like every other dynamically typed language
> uses.

Well, that's the idea, EXCEPT it doesn't need a definition for *every combination* of parameter types, just the ones that are actually used. For core words this is, of course, unavoidable -- `Int Int +` has to has a different definition than `String String +`. But for words built out of core words, I did not really think the "code bloat" this created would be too great if it is limited to utilized signatures. But maybe I am underestimating that? I don't want to rely on dynamic dispatch (i.e. lookup a word at runtime based on type signatures) b/c my understanding is that it always slooooooow. Is there a way to avoid the code duplication and dynamic dispatch? I am open to suggestions.

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

#51750

trans <transfire@gmail.com> writes:
> Well, that's the idea, EXCEPT it doesn't need a definition for *every
> combination* of parameter types, just the ones that are actually
> used.

But if it's an interactive, Forth-like system, you compile code when a
word is defined, and then its callers are defined later.  So you don't
know in advance what arg types the word will receive.


> I did not really think the "code bloat" this created would be too
> great if it is limited to utilized signatures.  But maybe I am
> underestimating that?

It depends.

> I don't want to rely on dynamic dispatch b/c my understanding is that
> it always slooooooow. Is there a way to avoid the code duplication and
> dynamic dispatch? I am open to suggestions.

Dynamic dispatch isn't that bad on today's hardware, especially if your
compiler does some type inference and/or can accept hints from the
programmer.  You won't compete with C compilers in pure performance but
hopefully you're not trying to.

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

#51753

On Monday, October 10, 2016 at 9:58:45 PM UTC-4, Paul Rubin wrote:
> But if it's an interactive, Forth-like system, you compile code when a
> word is defined, and then its callers are defined later.  So you don't
> know in advance what arg types the word will receive.

That's a really good point. That means it would have to be a JIT. I guess if that's the only way I can live with it, but I would prefer to find another way.

> > I did not really think the "code bloat" this created would be too
> > great if it is limited to utilized signatures.  But maybe I am
> > underestimating that?
> 
> It depends.
> 
> > I don't want to rely on dynamic dispatch b/c my understanding is that
> > it always slooooooow. Is there a way to avoid the code duplication and
> > dynamic dispatch? I am open to suggestions.
> 
> Dynamic dispatch isn't that bad on today's hardware, especially if your
> compiler does some type inference and/or can accept hints from the
> programmer.  You won't compete with C compilers in pure performance but
> hopefully you're not trying to.

Nonetheless, I'd like to get as close as possible.

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

#51756

On 10/10/2016 11:09, Paul Rubin wrote:
> trans <transfire@gmail.com> writes:

>> 8th is really just Forth, modernized a little -- nothing really new
>> going on? 

> I don't think of it that way, but it depends on your philosophical view
> of "really just Forth" means.  I'd say that 8th, Oforth, and Factor are
> all Lisp-like languages (dynamic types, complicated objects like
> strings, garbage collection) with Forth-like syntax.  But I haven't used
> any of them and may have mistaken impressions.

Really?  I thought the defining nature of "Lisp" was that it manipulates
"lists", and that the defining nature of "Forth" was that it manipulates
"stacks"?  Not to mention that the syntax of Lisps involves tons of
parentheses, and Forths don't need such things.

As for whether 8th is 'really just Forth', I agree that that depends on
what you think a Forth is.

As the author of 8th, one of my goals was to make a more
useful-out-of-the-box Forth-based system.  Whether or not I've succeeded
at that remains an open question; you can ask on the 8th forum.

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

#51760

I'd say that you have. I've looked at 8ths docs and you have done an excellent job. Is there another Forth implementation out there as well presented as 8th? 

By "just a Forth" I meant only in contrast to what I am trying to do, which in my mind is still "a Forth" in principle, but quite different from traditional Forth in some significant ways.

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

#51763

On 11/10/2016 13:09, trans wrote:
> I'd say that you have. I've looked at 8ths docs and you have done an excellent job.

Thank you

> Is there another Forth implementation out there as well presented as 8th? 

4th is well documented.  I think the Retro family is also well
documented (and my former Reva Forth was a Retro derivative).  Then
there's SwiftForth and others.  The docs style is different from mine,
but that's a matter of taste more than of content and completeness,  I
think.

> By "just a Forth" I meant only in contrast to what I am trying to do, which in my mind is still "a Forth" in principle, but quite different from traditional Forth in some significant ways.

Understood.

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

#51850

On Tuesday, October 11, 2016 at 5:26:03 PM UTC+13, Ron Aaron wrote:
> I thought the defining nature of "Lisp" was that it manipulates
> "lists", and that the defining nature of "Forth" was that it manipulates
> "stacks"?

Lists are first-class objects in Lisp, stacks are not first-class objects in Forth.

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

#51852

On Thursday, October 13, 2016 at 9:41:28 PM UTC-4, lawren...@gmail.com wrote:
> On Tuesday, October 11, 2016 at 5:26:03 PM UTC+13, Ron Aaron wrote:
> > I thought the defining nature of "Lisp" was that it manipulates
> > "lists", and that the defining nature of "Forth" was that it manipulates
> > "stacks"?
> 
> Lists are first-class objects in Lisp, stacks are not first-class objects in Forth.

Well two of them are. The only two.

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

#51854

On 14/10/2016 4:41, lawrencedo99@gmail.com wrote:
> On Tuesday, October 11, 2016 at 5:26:03 PM UTC+13, Ron Aaron wrote:
>> I thought the defining nature of "Lisp" was that it manipulates
>> "lists", and that the defining nature of "Forth" was that it manipulates
>> "stacks"?
> 
> Lists are first-class objects in Lisp, stacks are not first-class objects in Forth.
> 

They are in 8th: you can get the data or return stacks as actual items
on which to operate (and you can make as many stacks as you like).

They are in some other Forths as well; you can get references to the
data-stack in Retro for instance.

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

#51731

Le dimanche 9 octobre 2016 03:00:31 UTC+2, Paul Rubin a écrit :

> You might look at Oforth, 8th, Factor, and Postscript as someone
> mentioned.  I myself haven't yet understood the attraction of Forth-like
> syntax in those languages, at least for humans: once you're willing to
> have that many moving parts in an implementation, you might as well
> offer an automatic way to tell (e.g.) where the arg list for a function
> begins and ends.  So you end up with something like Lisp instead of
> Forth.  There's also Strongforth which may have already come up here.
> 

There are so many reasons to choose Forth syntax and principles... 
Among them :

1) Native code generation : 

With RPN notation and Forth syntax, with immediate words and the outer 
intepreter, you can generate native code on the flow while keeping an
interpretive language.

More, this native code generation can be written in Forth itself.
This is simple, fast and does not use memory.

So you have the strenght of dynamic languages and REPL with the runtime
performance of compiled languages (and the compilation speed is faster).

I don't know any other language model an syntax than Forth model that can 
do this so easily.


2) Multi-tasking

A Forth model suits so well for implementing a task/channel model
for multi-tasking.

First, having a return stack separated from data stack makes context 
switchs between tasks fast and easy. 
Whatever the way you handle a task's return stack (segmented stacks, 
copying, guard page, ...), the return stack is very small and easily hnadled.
And the data stack don't have to be copied. 
This makes context switches between tasks very fast.

Another feature is that the return stack does not
hold pointers to the return stack (like in C or other languages). 
So you can copy it as you want, run it on another thread, ...

All in all, with a return stack separated from the data stack,
I don't know other principles that suit so well with 
a task/channel model than Forth principles.


3) Declaring parameters of a function's call

In Oforth, there is a way to tell where the arg list for
a function begins and ends.

#( #, and #) words can be used to declare parameters for a function call.
This, of course, is not mandatory : 

: dist		\ a b -- f
   sq swap sq + sqrt ;

12 13 dist .
dist( 12, 13 ) .

12 13 dist 14 dist .
dist( dist ( 12, 13), 14 ) .

But, with this syntax, you don't end up with something like Lisp. This is
only sugar notation handled by the outer interpreter.

Franck

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

#51851

On Sunday, October 9, 2016 at 2:00:31 PM UTC+13, Paul Rubin wrote:
> You might look at Oforth, 8th, Factor, and Postscript as someone
> mentioned.  I myself haven't yet understood the attraction of Forth-like
> syntax in those languages, at least for humans: once you're willing to
> have that many moving parts in an implementation, you might as well
> offer an automatic way to tell (e.g.) where the arg list for a function
> begins and ends.

PostScript fitted in nicely with certain design constraints for its time: being a high-level graphics language to avoid pumping large raster buffers around slow networks, yet having an almost trivial parser (simpler than Forth) to reduce implementation overhead.

Of course, all those design constraints have gone away...

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

#51723

In article <763508c2-cb4c-476f-96d1-95c603729e73@googlegroups.com>,
trans  <transfire@gmail.com> wrote:
>On Saturday, October 8, 2016 at 3:33:58 PM UTC-4, Paul Rubin wrote:
<SNIP>
>
>> It sounds like you've been using C++.  If you want exposure to fancier
>> uses of type systems, you might give Haskell a try.
>> http://learnyouahaskell.com is a good place to start.
>
>Oh, I have explored Haskell. Lots of interesting ideas. A bit too "interest=
>ing" I think. On the surface Haskell seems great, but as I explored it more=
> the extreme focus on types, pure functionality and heavy academics, starts=
> to wear on code clarity, at least it seemed that way to me. Just look up h=
>ow to generate a random number for instance.
>

I've seen a lot of solutions to Euler problems where the Haskell code
was very short and not understandable to me.
The only thing that suggests to me that there is an interesting language
to study, not that it is lacking in code clarity, and certainly that it
is more than just interestign idea's.

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]

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

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

csiph-web