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

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

What's so great about Forth, anyway?

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

Contents

  What's so great about Forth, anyway? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-14 13:07 -0500
    Re: What's so great about Forth, anyway? Julian Fondren <julian.fondren@gmail.com> - 2017-03-14 11:54 -0700
      Re: What's so great about Forth, anyway? rickman <gnuarm@gmail.com> - 2017-03-14 15:53 -0400
      Re: What's so great about Forth, anyway? Julian Fondren <julian.fondren@gmail.com> - 2017-03-14 19:24 -0700
      Re: What's so great about Forth, anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-15 10:00 +0000
        Re: What's so great about Forth, anyway? rickman <gnuarm@gmail.com> - 2017-03-15 12:57 -0400
          Re: What's so great about Forth, anyway? Julian Fondren <julian.fondren@gmail.com> - 2017-03-15 11:09 -0700
            Re: What's so great about Forth, anyway? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-16 04:05 -0500
          Re: What's so great about Forth, anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-16 09:41 +0000
            Re: What's so great about Forth, anyway? hughaguilar96@gmail.com - 2017-03-16 10:57 -0700
              Re: What's so great about Forth, anyway? rickman <gnuarm@gmail.com> - 2017-03-16 14:41 -0400
        Re: What's so great about Forth, anyway? hughaguilar96@gmail.com - 2017-03-15 11:34 -0700
        Re: What's so great about Forth, anyway? franck.bensusan@gmail.com - 2017-03-22 03:24 -0700
          Re: What's so great about Forth, anyway? "Elizabeth D. Rather" <erather@forth.com> - 2017-03-22 11:24 -1000
            Re: What's so great about Forth, anyway? franck.bensusan@gmail.com - 2017-03-23 14:51 -0700
          Re: What's so great about Forth, anyway? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-23 04:25 -0500
            Re: What's so great about Forth, anyway? franck.bensusan@gmail.com - 2017-03-23 14:58 -0700
              Re: What's so great about Forth, anyway? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-24 03:03 -0500
                Re: What's so great about Forth, anyway? franck.bensusan@gmail.com - 2017-03-24 04:52 -0700
                  Re: What's so great about Forth, anyway? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-24 09:06 -0500
          Re: What's so great about Forth, anyway? Julian Fondren <julian.fondren@gmail.com> - 2017-03-23 07:47 -0700
          Re: What's so great about Forth, anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-25 17:13 +0000
            Re: What's so great about Forth, anyway? franck.bensusan@gmail.com - 2017-03-28 13:48 -0700
          Re: What's so great about Forth, anyway? Brad Eckert <hwfwguy@gmail.com> - 2017-03-28 18:34 -0700
            Re: What's so great about Forth, anyway? Julian Fondren <julian.fondren@gmail.com> - 2017-03-28 18:52 -0700
              Re: What's so great about Forth, anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-29 11:53 +0000
                Re: What's so great about Forth, anyway? Ron Aaron <rambamist@gmail.com> - 2017-03-29 15:09 +0300
                  Re: What's so great about Forth, anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-29 13:58 +0000
                    Re: What's so great about Forth, anyway? Ron Aaron <rambamist@gmail.com> - 2017-03-29 17:24 +0300
                  Re: What's so great about Forth, anyway? The Beez <the.beez.speaks@gmail.com> - 2017-04-04 03:04 -0700
                    Re: What's so great about Forth, anyway? Ron Aaron <rambamist@gmail.com> - 2017-04-04 15:30 +0300
                      Re: What's so great about Forth, anyway? The Beez <the.beez.speaks@gmail.com> - 2017-04-06 05:36 -0700
                    Re: What's so great about Forth, anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-04 16:35 +0000
                      Re: What's so great about Forth, anyway? hughaguilar96@gmail.com - 2017-04-05 11:46 -0700
            Re: What's so great about Forth, anyway? "Elizabeth D. Rather" <erather@forth.com> - 2017-03-28 16:12 -1000
              Re: What's so great about Forth, anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-29 11:59 +0000
            Re: What's so great about Forth, anyway? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-29 10:24 +0000
            Re: What's so great about Forth, anyway? franck.bensusan@gmail.com - 2017-04-04 04:05 -0700
        Re: What's so great about Forth, anyway? gavino himself <jackvanc3@gmail.com> - 2017-03-22 13:18 -0700
    Re: What's so great about Forth, anyway? NN <november.nihal@gmail.com> - 2017-03-14 12:20 -0700
    Re: What's so great about Forth, anyway? gavino himself <jackvanc3@gmail.com> - 2017-04-02 19:52 -0700
    Nothing's great about Forth "Robert L." <No_spamming@noWhere_7073.org> - 2017-04-04 10:45 +0000
      Re: Nothing's great about Forth Julian Fondren <julian.fondren@gmail.com> - 2017-04-04 08:00 -0700
      Re: Nothing's great about Forth lehs <skydda.barnen@gmail.com> - 2017-04-04 08:16 -0700
      Re: Nothing's great about Forth Mark Wills <markwills1970@gmail.com> - 2017-04-04 09:11 -0700
      Re: Nothing's great about Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-06 06:42 -0700

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

#55780 — What's so great about Forth, anyway?

Every now and then the question "What's good about Forth, anyway?"
comes up.  I found this at http://www.paulgraham.com/popular.html, and
it rang some bells:

  The dream language is beautiful, clean, and terse. It has an
  interactive toplevel that starts up fast. You can write programs to
  solve common problems with very little code. Nearly all the code in
  any program you write is code that's specific to your
  application. Everything else has been done for you.
  
  The syntax of the language is brief to a fault. You never have to
  type an unnecessary character, or even to use the shift key much.
  
  Using big abstractions you can write the first version of a program
  very quickly. Later, when you want to optimize, there's a really
  good profiler that tells you where to focus your attention. You can
  make inner loops blindingly fast, even writing inline byte code if
  you need to.
  
  There are lots of good examples to learn from, and the language is
  intuitive enough that you can learn how to use it from examples in a
  couple minutes. You don't need to look in the manual much. The
  manual is thin, and has few warnings and qualifications.
  
  The language has a small core, and powerful, highly orthogonal
  libraries that are as carefully designed as the core language. The
  libraries all work well together; everything in the language fits
  together like the parts in a fine camera. Nothing is deprecated, or
  retained for compatibility. The source code of all the libraries is
  readily available. It's easy to talk to the operating system and to
  applications written in other languages.
  
  The language is built in layers. The higher-level abstractions are
  built in a very transparent way out of lower-level abstractions,
  which you can get hold of if you want.
  
  Nothing is hidden from you that doesn't absolutely have to be. The
  language offers abstractions only as a way of saving you work,
  rather than as a way of telling you what to do. In fact, the
  language encourages you to be an equal participant in its
  design. You can change everything about it, including even its
  syntax, and anything you write has, as much as possible, the same
  status as what comes predefined.

So where does Forth sit?  I'm not sure that it's intuitive enough to
learn in a few minutes, and many simple coding errors errors result in
obscure crashes.  Forth has never been big on big abstractions, and
the idea that "everything else has been done for you" is very far from
true.  We're still very short of libraries, and that this rate
probably always will be.  I've not seen tools like profilers.

But Forth ticks some of the other boxes, I think.  The idea that "you
can change everything, and anything you write has the same status as
what comes predefined" certainly rings true.  Beautiful, clean, and
terse might be a bit controverisal, but good Forth is definitely
terse.

"Nothing is deprecated, or retained for compatibility" is more Chuck
Moore than Standard Forth, for sure.

Andrew.

[toc] | [next] | [standalone]

#55782

On Tuesday, March 14, 2017 at 1:08:00 PM UTC-5, Andrew Haley wrote:
> Every now and then the question "What's good about Forth, anyway?"
> comes up.  I found this at http://www.paulgraham.com/popular.html, and
> it rang some bells:
> 

Forth is also not "brief to a fault", with words like VARIABLE taking
5-7 more letters than Paul Graham would like. The experience of
writing a Forth is not "using big abstractions" to write a first
version really quickly, whereafter you replace inner loops with "inline
byte code", guided by a profiler.

Of 'intuitive', people can learn Forth almost immediately, but then
they become dissatisfied and say that they can't do anything with it.

Anyway I don't read this as a genuine paean for an ideal language, but
just as Paul Graham thinking ahead about Arc. "People will complain
about the hackish terse words -- I'll praise that." "People will
prefer Common Lisp -- I'll put in a gibe about code that's retained
for compatibility." "It's not going to be fast -- I'll say what every
scripting language advocate says about that." You could probably write
just as prettily about Forth, saying things like "the ideal language
should not throw vowels away just to make long and complex words more
tolerable to type (from 'function' to 'fn'), but should use short and
direct words in the first place, while making effective use of
punctuation." Why not give it a try?

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

#55785

On 3/14/2017 2:54 PM, Julian Fondren wrote:
> On Tuesday, March 14, 2017 at 1:08:00 PM UTC-5, Andrew Haley wrote:
>> Every now and then the question "What's good about Forth, anyway?"
>> comes up.  I found this at http://www.paulgraham.com/popular.html, and
>> it rang some bells:
>>
>
> Forth is also not "brief to a fault", with words like VARIABLE taking
> 5-7 more letters than Paul Graham would like. The experience of
> writing a Forth is not "using big abstractions" to write a first
> version really quickly, whereafter you replace inner loops with "inline
> byte code", guided by a profiler.

I'm not sure that brevity requires that word names be entropy encoded. 
I think what is being referred to is the reduction of tons of overhead 
as you find in VhDL.


> Of 'intuitive', people can learn Forth almost immediately, but then
> they become dissatisfied and say that they can't do anything with it.
>
> Anyway I don't read this as a genuine paean for an ideal language, but
> just as Paul Graham thinking ahead about Arc. "People will complain
> about the hackish terse words -- I'll praise that." "People will
> prefer Common Lisp -- I'll put in a gibe about code that's retained
> for compatibility." "It's not going to be fast -- I'll say what every
> scripting language advocate says about that." You could probably write
> just as prettily about Forth, saying things like "the ideal language
> should not throw vowels away just to make long and complex words more
> tolerable to type (from 'function' to 'fn'), but should use short and
> direct words in the first place, while making effective use of
> punctuation." Why not give it a try?
>


-- 

Rick C

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

#55799

On Tuesday, March 14, 2017 at 1:54:53 PM UTC-5, Julian Fondren wrote:
> ... You could probably write
> just as prettily about Forth, saying things like "the ideal language
> should not throw vowels away just to make long and complex words more
> tolerable to type (from 'function' to 'fn'), but should use short and
> direct words in the first place, while making effective use of
> punctuation." Why not give it a try?

No? Nobody?

Something like this:

The dream language is fast, responsive, and close to the machine - in
a way it is as much a language of the machine as it is the language of
man, as a language have to be if it were the shared tongue that man
and machine communicate by, which is exactly what it feels like to use
the dream language.  You type words, the machine responds to them, and
then answers you, and there is a clear shared understand as to what
the words mean.

Even when you write a program in paragraphs and sentences, you can
zoom in and see what any particular word is doing. It's rare that code
only makes sense through the lens of some or several abstractions -
there is always something concrete happening. And whereas most
languages have a barrier at which you can't pass - or rather, which
you can't pass while remaining yourself, while speaking your same
language (to dig into the guts of Perl you must leave Perl behind and
become a C programmer, and speak its tongue) - the dream language has
none of these artificial barriers.

Use minimal abstractions you can write the first version of a program
very directly.  Later, when you want to generalize it, there's very
little of the interesting code that needs to change - the blur of
generalization enters the words you use, not your use of them. For
example a function may operate on named variables which later become
fields of a structure and then later again fields of an object in an
array of objects - without this function changing at all.  Whereas
every line of most languages' code screams, "I am operating on a list
now, OK now this time a hash," and if either fact were to change the
code would nearly have to be thrown away, the dream language can speak
more implicitly about such things.

This is also true of simple data flow.  In most languages you can find
the odd matryoshka doll of function calls, an accidental construct
that permits he flow of a single value implicitly through several
functions on a single path. In the dream langauge practically all data
flow looks like this, passing more like water through a stream of
words that inspect, modify, or alter the data accordingly. In some
cases the data that's actually passed around can change drastically
without the words themselves changing.

The dream language has a generally well thought-out standard and a
mature, respectful community of implementors. There is no language
dictator who will wake up one day and break all your code because he
decided he liked lazy evaluation. There are no serious defects that
would justify an incompatible revision to the language. Previously
good systems do not optimize for bookmarks and break your code - only
to sneer that you were doing it wrong if your code broke. Code in the
dream language does not rot away due to the fiat, novelty-seeking, or
disregard of others.

The dream language does not lure you into traps and it does not set
you up for betrayal. Your efficiently-designed program will not be
slow because of the language. Your flexibly-designed program will not
be inflexible because of the language. When a minor increment of
functionality is asked of your program, the language will not suddenly
and without warning demand a major increment of effort, to reach it.
Other languages can promise the speed of a bullet train but then take
you in the wrong direction or will stop well short of your desination
-- and you with too much luggage and not the right shoes to keep
walking, even if you wanted to.

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

#55808

Julian Fondren <julian.fondren@gmail.com> writes:
>Anyway I don't read this as a genuine paean for an ideal language, but
>just as Paul Graham thinking ahead about Arc. "People will complain
>about the hackish terse words -- I'll praise that." "People will
>prefer Common Lisp -- I'll put in a gibe about code that's retained
>for compatibility." "It's not going to be fast -- I'll say what every
>scripting language advocate says about that."

Conversely, he may have described what likes and does not like about
Common Lisp, and then decided to do something about the "not-likes",
and designed Arc.

And yes, one could do similar things wrt Forth, and its dialects.
Typically, people have been more on the "do" side than on the "write"
side of this (e.g., Chuck Moore, Hans Bezemer, Slava Pestov, Ron
Aaron, Franck Benunsan), with Hugh Aguilar being the exception that
proves the rule.

- 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 2016: http://www.euroforth.org/ef16/

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

#55813

On 3/15/2017 6:00 AM, Anton Ertl wrote:
> Julian Fondren <julian.fondren@gmail.com> writes:
>> Anyway I don't read this as a genuine paean for an ideal language, but
>> just as Paul Graham thinking ahead about Arc. "People will complain
>> about the hackish terse words -- I'll praise that." "People will
>> prefer Common Lisp -- I'll put in a gibe about code that's retained
>> for compatibility." "It's not going to be fast -- I'll say what every
>> scripting language advocate says about that."
>
> Conversely, he may have described what likes and does not like about
> Common Lisp, and then decided to do something about the "not-likes",
> and designed Arc.
>
> And yes, one could do similar things wrt Forth, and its dialects.
> Typically, people have been more on the "do" side than on the "write"
> side of this (e.g., Chuck Moore, Hans Bezemer, Slava Pestov, Ron
> Aaron, Franck Benunsan), with Hugh Aguilar being the exception that
> proves the rule.

I'm not sure what you mean by the "do" side and the "write" side.  By 
"do" do you mean designing and writing programs?  By "write" do you mean 
discuss things rather than writing code????

I never thought of Hugh as a non-doer.  Yes, he has a great deal of 
trouble working with people, but certainly he is not shy of doing 
work.... or did I miss something?

-- 

Rick C

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

#55817

On Wednesday, March 15, 2017 at 11:57:20 AM UTC-5, rickman wrote:
> On 3/15/2017 6:00 AM, Anton Ertl wrote:
> >
> > And yes, one could do similar things wrt Forth, and its dialects.
> > Typically, people have been more on the "do" side than on the "write"
> > side of this (e.g., Chuck Moore, Hans Bezemer, Slava Pestov, Ron
> > Aaron, Franck Benunsan), with Hugh Aguilar being the exception that
> > proves the rule.
>
> I'm not sure what you mean by the "do" side and the "write" side.  By
> "do" do you mean designing and writing programs?  By "write" do you mean
> discuss things rather than writing code????
>
> I never thought of Hugh as a non-doer.

Well there are examples, and they're all people who have written
variously incompatible Forth-like languages. And the subject is not
"code" or "programs" but Paul Graham's dream language. And Hugh has
published zero implementations of his dream variant of Forth, but has
written two or three novels about it here on clf. You can today use
colorForth, 4th, et al.; you can only read about Straight Forth.

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

#55842

Julian Fondren <julian.fondren@gmail.com> wrote:
> 
> Well there are examples, and they're all people who have written
> variously incompatible Forth-like languages. And the subject is not
> "code" or "programs" but Paul Graham's dream language.

I didn't intend it to be about Paul Graham, and it's certainly not
just about retrofitting some kind of philosophy about a dream language
onto Forth.  I was more thinking about what the desiderata of an ideal
language might be, and from there to what we're missing.

Andrew.

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

#55844

rickman <gnuarm@gmail.com> writes:
>On 3/15/2017 6:00 AM, Anton Ertl wrote:
>> Julian Fondren <julian.fondren@gmail.com> writes:
>>> Anyway I don't read this as a genuine paean for an ideal language, but
>>> just as Paul Graham thinking ahead about Arc. "People will complain
>>> about the hackish terse words -- I'll praise that." "People will
>>> prefer Common Lisp -- I'll put in a gibe about code that's retained
>>> for compatibility." "It's not going to be fast -- I'll say what every
>>> scripting language advocate says about that."
>>
>> Conversely, he may have described what likes and does not like about
>> Common Lisp, and then decided to do something about the "not-likes",
>> and designed Arc.
>>
>> And yes, one could do similar things wrt Forth, and its dialects.
>> Typically, people have been more on the "do" side than on the "write"
>> side of this (e.g., Chuck Moore, Hans Bezemer, Slava Pestov, Ron
>> Aaron, Franck Benunsan), with Hugh Aguilar being the exception that
>> proves the rule.
>
>I'm not sure what you mean by the "do" side and the "write" side.  By 
>"do" do you mean designing and writing programs?  By "write" do you mean 
>discuss things rather than writing code????

In the present case I mean with "write" writing down and publishing a
set of requirements, as cited in the first posting in this thread.
With "do" I mean actually implementing (and publishing) a program that
is intended to satisfy this set of requirements.

>I never thought of Hugh as a non-doer.  Yes, he has a great deal of 
>trouble working with people, but certainly he is not shy of doing 
>work.... or did I miss something?

Well, Paul Graham wrote this stuff in 2001 and the first release of
Arc happened in 2008.  Hugh Aguilar first wrote about Straight Forth
in IIRC 2011, so if he manages to get Straight Forth out before 2018,
he will be more of a doer than Paul Graham.  And I have until 2020 to
present an implementation of PAF:-).

- 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 2016: http://www.euroforth.org/ef16/

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

#55856

On Thursday, March 16, 2017 at 2:48:49 AM UTC-7, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
> >I never thought of Hugh as a non-doer.  Yes, he has a great deal of 
> >trouble working with people, but certainly he is not shy of doing 
> >work.... or did I miss something?
> 
> Well, Paul Graham wrote this stuff in 2001 and the first release of
> Arc happened in 2008.  Hugh Aguilar first wrote about Straight Forth
> in IIRC 2011, so if he manages to get Straight Forth out before 2018,
> he will be more of a doer than Paul Graham.  And I have until 2020 to
> present an implementation of PAF:-).

Straight Forth is supposed to be a standard --- not just another non-standard implementation --- the whole point of talking about it was to get collaboration on the definition.

Everybody criticizes me for not releasing it --- but when I do release an implementation, everybody will say that it is not what they wanted.

All I can be certain of is that nobody wants ANS-Forth or Forth-200x --- at least, nobody with a brain --- so far, it is only salespeople who want ANS-Forth and Forth-200x as their standard, plus non-programming "programming experts" who do a lot of talking about recognizers and don't know that Forth is not supposed to have a syntax.

BTW: I already have a document describing PFA (portable Forth assembler). PFA is different from your PAF which I didn't like --- for one thing, yours is 32-bit, but the ARM already is the 32-bit portable assembly-language --- mine is loosely based on the 16-bit x86 and is intended for 16-bit processors such as the PIC24 or MSP_430, or FPGA implementations.

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

#55857

On 3/16/2017 1:57 PM, hughaguilar96@gmail.com wrote:
> On Thursday, March 16, 2017 at 2:48:49 AM UTC-7, Anton Ertl wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> I never thought of Hugh as a non-doer.  Yes, he has a great deal
>>> of trouble working with people, but certainly he is not shy of
>>> doing work.... or did I miss something?
>>
>> Well, Paul Graham wrote this stuff in 2001 and the first release
>> of Arc happened in 2008.  Hugh Aguilar first wrote about Straight
>> Forth in IIRC 2011, so if he manages to get Straight Forth out
>> before 2018, he will be more of a doer than Paul Graham.  And I
>> have until 2020 to present an implementation of PAF:-).
>
> Straight Forth is supposed to be a standard --- not just another
> non-standard implementation --- the whole point of talking about it
> was to get collaboration on the definition.

Really?  *YOU* are asking for others to collaborate with you when you 
couldn't even get along well enough to collaborate with the ANS 
committee?  Why do you think this would work any better?  Because you 
would be in charge?


> Everybody criticizes me for not releasing it --- but when I do
> release an implementation, everybody will say that it is not what
> they wanted.

I expect that is accurate.  The whole reason for doing it is to produce 
something *YOU* will like.  You don't leave any wiggle room for it to 
become what anyone else would like.  Although there are a couple of 
posters here who seem to agree with you some.  Are you getting any help 
from them?


> All I can be certain of is that nobody wants ANS-Forth or Forth-200x
> --- at least, nobody with a brain --- so far, it is only salespeople
> who want ANS-Forth and Forth-200x as their standard, plus
> non-programming "programming experts" who do a lot of talking about
> recognizers and don't know that Forth is not supposed to have a
> syntax.

I feel like the Wizard of Oz Tinman....  "If I only had a brain"  :)


> BTW: I already have a document describing PFA (portable Forth
> assembler). PFA is different from your PAF which I didn't like ---
> for one thing, yours is 32-bit, but the ARM already is the 32-bit
> portable assembly-language --- mine is loosely based on the 16-bit
> x86 and is intended for 16-bit processors such as the PIC24 or
> MSP_430, or FPGA implementations.

Let us know how well it is received by... well, *anyone*.

-- 

Rick C

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

#55818

On Wednesday, March 15, 2017 at 3:11:01 AM UTC-7, Anton Ertl wrote:
> Julian Fondren <julian.fondren@gmail.com> writes:
> >Anyway I don't read this as a genuine paean for an ideal language, but
> >just as Paul Graham thinking ahead about Arc. "People will complain
> >about the hackish terse words -- I'll praise that." "People will
> >prefer Common Lisp -- I'll put in a gibe about code that's retained
> >for compatibility." "It's not going to be fast -- I'll say what every
> >scripting language advocate says about that."
> 
> Conversely, he may have described what likes and does not like about
> Common Lisp, and then decided to do something about the "not-likes",
> and designed Arc.
> 
> And yes, one could do similar things wrt Forth, and its dialects.
> Typically, people have been more on the "do" side than on the "write"
> side of this (e.g., Chuck Moore, Hans Bezemer, Slava Pestov, Ron
> Aaron, Franck Benunsan), with Hugh Aguilar being the exception that
> proves the rule.

Anton Ertl is angry at me because I wrote the rquotations that killed his RfD for Paysan-faked quotations --- that is why he says that I'm incapable of writing code --- all of Elizabeth Rather's sycophants say that I'm incapable of writing code, and don't even know what quotations are.

\ ******
\ ****** R[ ]R quotations.
\ ****** https://groups.google.com/forum/#!topic/comp.lang.forth/3LSqmBIZuzY
\ ****** This is highly non-standard! ANS-Forth (section 3.2.3.3.) says:
\ ****** A program shall not access values on the return stack (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R;
\ ******

\ In the stack-picture comments, RQ is a continuation (a vector to a quotation).

\ HumptyDumpty invented rquotations --- this was very good programming --- I hadn't thought of it.
\ What I call REX0 he called RCALL --- also, he didn't have REX which I invented (this only works in VFX and SwiftForth).
\ If only REX0 is used, rquotations can be used under any ANS-Forth system (theoretically non-standard though).
\ REX is a lot more useful though because the HOF almost always needs to have locals.

\ My improved version for VFX or SwiftForth should be easy to port to other ANS-Forth systems --- any Forth system with locals.
\ Some assembly-language is required, but it is pretty straight forward.

VFX? SwiftForth? or [if]

: rexit     ( --   )    rdrop ;
: (r:)      ( -- rq )   r@ 5 + ;    \ 5 is the size of a JMP instruction in 32-bit x86
: r[        ( -- rq )   postpone (r:)  postpone ahead ;  immediate
: ]r        ( --   )    postpone rexit  postpone then ;  immediate

: rex0      ( rq -- )   >r ;                                    \ requires the HOF to not have locals

\ REX0 is the same as EXECUTE
\ We don't use EXECUTE however because in the other version (not VFX or SwiftForth) REX0 is different.
    
VFX? [if]

code rex    ( rq -- )                                           \ requires the HOF to have locals
    push edi                    \ this is the HOF's LF which won't be used by the quotation
    mov edi, 0 [edi]            \ this is the parent's LF which will be used by the quotation
    mov eax, ebx
    mov ebx, 0 [ebp]  lea ebp, w [ebp]
    call eax
    pop edi                     \ restore HOF's LF
    next, end-code
    
[then]

SwiftForth? [if]

156 constant lf-offset  \ this is the offset for the local-frame in the user-variables (ESI is the user-variable base)

code rex    ( rq -- )                                           \ requires the HOF to have locals
    lf-offset [esi] edx mov
    edx push                    \ this is the HOF's LF which won't be used by the quotation
    -4 [edx] eax mov            \ this is the old ESP
    0 [eax] eax mov             \ this is the parent's LF which will be used by the quotation
    eax lf-offset [esi] mov
    ebx eax mov  [drop]
    eax call
    lf-offset [esi] pop         \ restore HOF's LF  
    ret end-code
    
[then]

[else] \ this was written by HumptyDumpty and works on gForth, SwiftForth and VFX

: rexit     ( --   )        RDROP ;
: (r:)      ( -- rq )       R@  false ;
: r[        ( -- rq )       postpone (r:)   postpone IF   ;     immediate
: ]r        ( --   )        postpone REXIT  postpone THEN ;     immediate

: rex0      ( rq -- )       >R  true ;                          \ requires the HOF to not have locals

\ REX is not supported in HumptyDumpty's code.

[then]

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

#56087

Le mercredi 15 mars 2017 11:11:01 UTC+1, Anton Ertl a écrit :

> Conversely, he may have described what likes and does not like about
> Common Lisp, and then decided to do something about the "not-likes",
> and designed Arc.
> 
> And yes, one could do similar things wrt Forth, and its dialects.
> Typically, people have been more on the "do" side than on the "write"
> side of this (e.g., Chuck Moore, Hans Bezemer, Slava Pestov, Ron
> Aaron, Franck Benunsan), with Hugh Aguilar being the exception that
> proves the rule.
> 
> - 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 2016: http://www.euroforth.org/ef16/

What you are asking (if I understand) is not easy because I don't think one 
can be neutral, here.

But let's try.

Of course, all this is just my opinion : "should" 
means : "I think that it should".


What is great in Forth (no need to elaborate, I think).

1) Two stacks (data and return stacks).
2) Dictionary
2) Outer interpreter (the best and simple JIT compiler I know).
3) No syntax, Forth mostly written in Forth.
4) Can be a high level language.
5) Interactivity and REPL loop.
7) Extendable language, even during runtime.
9) Exception word set (but should be CORE).
10) Compilation "on the flow", no separated compilation phase.

==> imo, the ultimate "WebAssembly", if only ...


Requirements : 

0) Keep what is great.

1) Security features.
Never say "No security to bother on embedded".

A Forth system is an open bar for hackers : 
- Often data mixed with code.
- Return stack is wide-open, a hacker can jump wherever he wants.
- No buffer underflow/overflow checks, ...
- Definitions can be redefined.
- Defer can't be frozen.

Checking for overflow is nothing if the return stack remains open
(overflow is only a way to update the return stack addresses and take
control of the program).
==> Make the return stack only handled by the compiler
==> Remove words like >R, R>, R@, ...
==> Values on the return stack are only available through locals.


2) Packages
Remove vocabularies and word lists, list order, ...
Instead, robust packages must be provided.
This should be CORE.


3) Burden for the Forth writer, not for the Forth user.
Simplicity too often means simplicity for the Forth writer.
And, in order to have the most simpler outer interpreter, burden
is handled by the user.
- Still a space needed after some words ( " , ...).
- ' is not used for characters 
- [char], ['], S", S\", <#, #, ">, #S, [COMPILE], ...
- Multiple name for the same operation : +, F+, D+, ...

Case sensitive interpreter is mandatory, of course.

And there is this subject about semantics, immediate, 
compilation, execution, interpretation, one xt, two xt, ...
to clarify.
==> Define a clear metamodel for Words.


4) Memory management.
Direct and not controlled access to memory is prone to bugs and
open security holes.
There should have a higher level of abstraction for memory.
Not securised direct access to memory is forbidden.
This should be CORE.


5) Blocks (or "quotations")
This should be CORE.
NONAME should be removed.
With use of parent locals (closures or in the scope of the parent).


6) Effective locals
Locals should be CORE.
Needed if the return stack is not directly accessible.
Locals should be fully optimized, stored directly on the
return stack for efficiency.
They are the only way to communicate with the return stack.


7) Effective multi-tasking features.
Not just mapping OS threads or cooperative multi-threading.
Implement a modern multi-tasking design : 
- Isolated tasks.
- non blocking threads (wait, I/O, TCP, ...).
- Channels to communicate between tasks.
- Reenforced immutability, 
- Tasks with separated data stack and return stack for each.
- No global mutable values => remove VARIABLE
- Data stack separated from return stack helps a lot.

And this should be CORE : interpreter runs into a task and
waits for keys in a non blocking way.


8) Make Data stack unique with 1 cell = 1 object. 
- Strings need 2 cells -> to be changed.
- Double need 2 cells -> to be removed (with all double words).
- Characters value should be unicode
- String should be UTF8 and take 1 cell on the stack.
- No dedicated stacks (floats, strings, ...).

Required to have effective multi-tasking features.
(you can't create/save n stacks by task).


9) Same for return stack
- Only one kind of local.
- Local value = 1 object (float, string, array, ...). 


10) Built-in collections and HOF 
Minimum is Array (users are not here to implement arrays).
Dedicated word for array syntax.
Checks for array access (out of bounds).
This should be CORE.
HOF that can take words, quotations, closures as parameters.


11) Efficiency, but not before requirements.
All this should be done keeping effeciency (and, if possible,
small memory footprint).
But first the requirements, then optimize.



That's it, I think (there are other requirements but not as important). 

All is all, most requirements come from security purposes and multi-tasking
model. But they have deep impacts...

Franck

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

#56141

On 3/22/17 12:24 AM, franck.bensusan@gmail.com wrote:
> Le mercredi 15 mars 2017 11:11:01 UTC+1, Anton Ertl a écrit :
>
>> Conversely, he may have described what likes and does not like about
>> Common Lisp, and then decided to do something about the "not-likes",
>> and designed Arc.
>>
>> And yes, one could do similar things wrt Forth, and its dialects.
>> Typically, people have been more on the "do" side than on the "write"
>> side of this (e.g., Chuck Moore, Hans Bezemer, Slava Pestov, Ron
>> Aaron, Franck Benunsan), with Hugh Aguilar being the exception that
>> proves the rule.
>>
>> - 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 2016: http://www.euroforth.org/ef16/
>
> What you are asking (if I understand) is not easy because I don't think one
> can be neutral, here.
>
> But let's try.
>
> Of course, all this is just my opinion : "should"
> means : "I think that it should".
>
>
> What is great in Forth (no need to elaborate, I think).
>
> 1) Two stacks (data and return stacks).
> 2) Dictionary
> 2) Outer interpreter (the best and simple JIT compiler I know).
> 3) No syntax, Forth mostly written in Forth.
> 4) Can be a high level language.
> 5) Interactivity and REPL loop.
> 7) Extendable language, even during runtime.
> 9) Exception word set (but should be CORE).
> 10) Compilation "on the flow", no separated compilation phase.
>
> ==> imo, the ultimate "WebAssembly", if only ...
>
>
> Requirements :
>
> 0) Keep what is great.
>
> 1) Security features.
> Never say "No security to bother on embedded".
>
> A Forth system is an open bar for hackers :
> - Often data mixed with code.
> - Return stack is wide-open, a hacker can jump wherever he wants.
> - No buffer underflow/overflow checks, ...
> - Definitions can be redefined.
> - Defer can't be frozen.
>
> Checking for overflow is nothing if the return stack remains open
> (overflow is only a way to update the return stack addresses and take
> control of the program).
> ==> Make the return stack only handled by the compiler
> ==> Remove words like >R, R>, R@, ...
> ==> Values on the return stack are only available through locals.
>
>
> 2) Packages
> Remove vocabularies and word lists, list order, ...
> Instead, robust packages must be provided.
> This should be CORE.
>
>
> 3) Burden for the Forth writer, not for the Forth user.
> Simplicity too often means simplicity for the Forth writer.
> And, in order to have the most simpler outer interpreter, burden
> is handled by the user.
> - Still a space needed after some words ( " , ...).
> - ' is not used for characters
> - [char], ['], S", S\", <#, #, ">, #S, [COMPILE], ...
> - Multiple name for the same operation : +, F+, D+, ...
>
> Case sensitive interpreter is mandatory, of course.
>
> And there is this subject about semantics, immediate,
> compilation, execution, interpretation, one xt, two xt, ...
> to clarify.
> ==> Define a clear metamodel for Words.
>
> 4) Memory management.
> Direct and not controlled access to memory is prone to bugs and
> open security holes.
> There should have a higher level of abstraction for memory.
> Not securised direct access to memory is forbidden.
> This should be CORE.
>
> 5) Blocks (or "quotations")
> This should be CORE.
> NONAME should be removed.
> With use of parent locals (closures or in the scope of the parent).
>
> 6) Effective locals
> Locals should be CORE.
> Needed if the return stack is not directly accessible.
> Locals should be fully optimized, stored directly on the
> return stack for efficiency.
> They are the only way to communicate with the return stack.
>
> 7) Effective multi-tasking features.
> Not just mapping OS threads or cooperative multi-threading.
> Implement a modern multi-tasking design :
> - Isolated tasks.
> - non blocking threads (wait, I/O, TCP, ...).
> - Channels to communicate between tasks.
> - Reenforced immutability,
> - Tasks with separated data stack and return stack for each.
> - No global mutable values => remove VARIABLE
> - Data stack separated from return stack helps a lot.
>
> And this should be CORE : interpreter runs into a task and
> waits for keys in a non blocking way.
>
> 8) Make Data stack unique with 1 cell = 1 object.
> - Strings need 2 cells -> to be changed.
> - Double need 2 cells -> to be removed (with all double words).
> - Characters value should be unicode
> - String should be UTF8 and take 1 cell on the stack.
> - No dedicated stacks (floats, strings, ...).
>
> Required to have effective multi-tasking features.
> (you can't create/save n stacks by task).
>
> 9) Same for return stack
> - Only one kind of local.
> - Local value = 1 object (float, string, array, ...).
>
> 10) Built-in collections and HOF
> Minimum is Array (users are not here to implement arrays).
> Dedicated word for array syntax.
> Checks for array access (out of bounds).
> This should be CORE.
> HOF that can take words, quotations, closures as parameters.
>
> 11) Efficiency, but not before requirements.
> All this should be done keeping effeciency (and, if possible,
> small memory footprint).
> But first the requirements, then optimize.
>
> That's it, I think (there are other requirements but not as important).
>
> All is all, most requirements come from security purposes and multi-tasking
> model. But they have deep impacts...

You are certainly welcome to develop and use such a system, but it 
doesn't much resemble Forth.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#56202

Le mercredi 22 mars 2017 22:25:01 UTC+1, Elizabeth D. Rather a écrit :
> 
> You are certainly welcome to develop and use such a system, but it 
> doesn't much resemble Forth.

Well, I don't know.

I don't have the feeling that the result is so different than using a 
Forth system + an OO extension but perhap's you are right.

Franck
 
> Cheers,
> Elizabeth
> 
> -- 
> Elizabeth R. Conklin
> FORTH, Inc.
> 6080 Center Drive, Suite 600
> Los Angeles, CA  90045
> USA

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

#56167

franck.bensusan@gmail.com wrote:
> 
> What is great in Forth (no need to elaborate, I think).
> 
> 1) Two stacks (data and return stacks).
> 2) Dictionary
> 2) Outer interpreter (the best and simple JIT compiler I know).
> 3) No syntax, Forth mostly written in Forth.
> 4) Can be a high level language.
> 5) Interactivity and REPL loop.
> 7) Extendable language, even during runtime.
> 9) Exception word set (but should be CORE).
> 10) Compilation "on the flow", no separated compilation phase.

I agree with most of these things, but I'm not totally convinced that
the explicit stack is vital.  It's more of a way of making an
implementation very simple, both to extend and to write in the first
place.  Having said that, I know of no other way to do it: I don't
think there is any way to write such a simple system without the
stack.

I would also say that a vital feature is that the abstractions of the
base system are very shallow, and therefore easy to understand.
Another way to say that is that, at base, Forth is a fairly low-level
langauge.  But it can (and must) be extended by the user to provide
higher-level abstractions suitable for application programming.

> Requirements : 
> 
> 0) Keep what is great.
> 
> 1) Security features.
> Never say "No security to bother on embedded".
> 
> A Forth system is an open bar for hackers : 
> - Often data mixed with code.
> - Return stack is wide-open, a hacker can jump wherever he wants.
> - No buffer underflow/overflow checks, ...
> - Definitions can be redefined.
> - Defer can't be frozen.
> 
> Checking for overflow is nothing if the return stack remains open
> (overflow is only a way to update the return stack addresses and take
> control of the program).
> ==> Make the return stack only handled by the compiler
> ==> Remove words like >R, R>, R@, ...
> ==> Values on the return stack are only available through locals.

I don't really see how his would make a system secure.  The
implementation would necessarily be much more complex, and could be
attacked via its own mistakes.

> 2) Packages
> Remove vocabularies and word lists, list order, ...
> Instead, robust packages must be provided.
> This should be CORE.

Umm, what?  Packages, OK.  Several Forth package systems have been
designed.  But in CORE?  What on Earth for?

> 7) Effective multi-tasking features.
> Not just mapping OS threads or cooperative multi-threading.
> Implement a modern multi-tasking design : 
> - Isolated tasks.
> - non blocking threads (wait, I/O, TCP, ...).
> - Channels to communicate between tasks.
> - Reenforced immutability, 
> - Tasks with separated data stack and return stack for each.
> - No global mutable values => remove VARIABLE
> - Data stack separated from return stack helps a lot.
> 
> And this should be CORE : interpreter runs into a task and
> waits for keys in a non blocking way.

Interesting.  I agree there should be multi-tasking features.  I would
have thought, though, that in a low-level language intended for system
implementation you have to have global state somewhere.

> That's it, I think (there are other requirements but not as important). 
> 
> All is all, most requirements come from security purposes and multi-tasking
> model. But they have deep impacts...

The most significant of which is the loss of the transparency of the
language and its implementation, I would have thought.

Thanks for that.  It was very thought-provoking.

Andrew.

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

#56203

Le jeudi 23 mars 2017 10:25:16 UTC+1, Andrew Haley a écrit :
> franck.bensusan@gmail.com wrote:
> > 
> > What is great in Forth (no need to elaborate, I think).
> > 
> > 1) Two stacks (data and return stacks).
> > 2) Dictionary
> > 2) Outer interpreter (the best and simple JIT compiler I know).
> > 3) No syntax, Forth mostly written in Forth.
> > 4) Can be a high level language.
> > 5) Interactivity and REPL loop.
> > 7) Extendable language, even during runtime.
> > 9) Exception word set (but should be CORE).
> > 10) Compilation "on the flow", no separated compilation phase.
> 
> I agree with most of these things, but I'm not totally convinced that
> the explicit stack is vital.  It's more of a way of making an
> implementation very simple, both to extend and to write in the first
> place.  Having said that, I know of no other way to do it: I don't
> think there is any way to write such a simple system without the
> stack.
> 
> I would also say that a vital feature is that the abstractions of the
> base system are very shallow, and therefore easy to understand.
> Another way to say that is that, at base, Forth is a fairly low-level
> langauge.  But it can (and must) be extended by the user to provide
> higher-level abstractions suitable for application programming.
> 
> > Requirements : 
> > 
> > 0) Keep what is great.
> > 
> > 1) Security features.
> > Never say "No security to bother on embedded".
> > 
> > A Forth system is an open bar for hackers : 
> > - Often data mixed with code.
> > - Return stack is wide-open, a hacker can jump wherever he wants.
> > - No buffer underflow/overflow checks, ...
> > - Definitions can be redefined.
> > - Defer can't be frozen.
> > 
> > Checking for overflow is nothing if the return stack remains open
> > (overflow is only a way to update the return stack addresses and take
> > control of the program).
> > ==> Make the return stack only handled by the compiler
> > ==> Remove words like >R, R>, R@, ...
> > ==> Values on the return stack are only available through locals.
> 
> I don't really see how his would make a system secure.  The
> implementation would necessarily be much more complex, and could be
> attacked via its own mistakes.
>

Yes I agree. The more complex the implementation is, the more it
could be attacked by its own mistakes. But : 

1) Those mistakes can be fixed by a new versions.

2) I don't see why such a system would be much more complex.

It is perfectly viable to define a system without >R, R>, ...
defined as primitives until locals are available.
Some words use a bit more stack shuffling, but not so
much. Of course, you have to define locals implementation as soon 
as possible.

 
> > 2) Packages
> > Remove vocabularies and word lists, list order, ...
> > Instead, robust packages must be provided.
> > This should be CORE.
> 
> Umm, what?  Packages, OK.  Several Forth package systems have been
> designed.  But in CORE?  What on Earth for?
> 

If you talking about "loading a package", yes, it is not required
to be core.

The question is : what about FIND ? If a system relies on packages,
does FIND need to know what is a package and how to search a word
according to the current package ? imo, yes.
Hence packages (at least definition) in core.


> > 7) Effective multi-tasking features.
> > Not just mapping OS threads or cooperative multi-threading.
> > Implement a modern multi-tasking design : 
> > - Isolated tasks.
> > - non blocking threads (wait, I/O, TCP, ...).
> > - Channels to communicate between tasks.
> > - Reenforced immutability, 
> > - Tasks with separated data stack and return stack for each.
> > - No global mutable values => remove VARIABLE
> > - Data stack separated from return stack helps a lot.
> > 
> > And this should be CORE : interpreter runs into a task and
> > waits for keys in a non blocking way.
> 
> Interesting.  I agree there should be multi-tasking features.  I would
> have thought, though, that in a low-level language intended for system
> implementation you have to have global state somewhere.
>

At the kernel level, yes, of course, you need global states and you
need locks, mutexes, ... to handle them in a multi-tasking context.
But you don't need to expose this to the programmer.

For instance, a task/channel model does not requires to expose
thoses states or locks or mutexes to the user. It is perfectly 
possible to have a true isolation between tasks ie not share a mutable
value, communicating using only channels.

Of course, immutable values like constants, words, ... can be shared
between tasks.

The only "global" variables you may need is at user level (ie USER 
variables, with a value by task). For instance, the interpreter 
running on a task needs to keep various states of the current definition
to compile it.

 
> > That's it, I think (there are other requirements but not as important). 
> > 
> > All is all, most requirements come from security purposes and multi-tasking
> > model. But they have deep impacts...
> 
> The most significant of which is the loss of the transparency of the
> language and its implementation, I would have thought.
> 
> Thanks for that.  It was very thought-provoking.
> 
> Andrew.

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

#56216

franck.bensusan@gmail.com wrote:
> Le jeudi 23 mars 2017 10:25:16 UTC+1, Andrew Haley a ?crit :
>> franck.bensusan@gmail.com wrote:
>> > 
>> > Requirements : 
>> > 
>> > 0) Keep what is great.
>> > 
>> > 1) Security features.
>> > Never say "No security to bother on embedded".
>> > 
>> > A Forth system is an open bar for hackers : 
>> > - Often data mixed with code.
>> > - Return stack is wide-open, a hacker can jump wherever he wants.
>> > - No buffer underflow/overflow checks, ...
>> > - Definitions can be redefined.
>> > - Defer can't be frozen.
>> > 
>> > Checking for overflow is nothing if the return stack remains open
>> > (overflow is only a way to update the return stack addresses and take
>> > control of the program).
>> > ==> Make the return stack only handled by the compiler
>> > ==> Remove words like >R, R>, R@, ...
>> > ==> Values on the return stack are only available through locals.
>> 
>> I don't really see how his would make a system secure.  The
>> implementation would necessarily be much more complex, and could be
>> attacked via its own mistakes.
> 
> Yes I agree. The more complex the implementation is, the more it
> could be attacked by its own mistakes. But : 
> 
> 1) Those mistakes can be fixed by a new versions.
> 
> 2) I don't see why such a system would be much more complex.

Really?  OK.

>> > 2) Packages
>> > Remove vocabularies and word lists, list order, ...
>> > Instead, robust packages must be provided.
>> > This should be CORE.
>> 
>> Umm, what?  Packages, OK.  Several Forth package systems have been
>> designed.  But in CORE?  What on Earth for?
> 
> If you talking about "loading a package", yes, it is not required
> to be core.
> 
> The question is : what about FIND ? If a system relies on packages,
> does FIND need to know what is a package and how to search a word
> according to the current package ? imo, yes.
> Hence packages (at least definition) in core.

I see.

>> > 7) Effective multi-tasking features.
>> > Not just mapping OS threads or cooperative multi-threading.
>> > Implement a modern multi-tasking design : 
>> > - Isolated tasks.
>> > - non blocking threads (wait, I/O, TCP, ...).
>> > - Channels to communicate between tasks.
>> > - Reenforced immutability, 
>> > - Tasks with separated data stack and return stack for each.
>> > - No global mutable values => remove VARIABLE
>> > - Data stack separated from return stack helps a lot.
>> > 
>> > And this should be CORE : interpreter runs into a task and
>> > waits for keys in a non blocking way.
>> 
>> Interesting.  I agree there should be multi-tasking features.  I would
>> have thought, though, that in a low-level language intended for system
>> implementation you have to have global state somewhere.
> 
> At the kernel level, yes, of course, you need global states and you
> need locks, mutexes, ... to handle them in a multi-tasking context.
> But you don't need to expose this to the programmer.

But this is Forth!  By definition, everything is exposed to the
programmer: there is no magic, nothing hidden behind the curtain.  If
ever there was a single Big Idea in Forth, it's that.  

Andrew.

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

#56222

Le vendredi 24 mars 2017 09:03:26 UTC+1, Andrew Haley a écrit :
> franck.bensusan@gmail.com wrote:
> > Le jeudi 23 mars 2017 10:25:16 UTC+1, Andrew Haley a ?crit :
> >> franck.bensusan@gmail.com wrote:
> > 
> > At the kernel level, yes, of course, you need global states and you
> > need locks, mutexes, ... to handle them in a multi-tasking context.
> > But you don't need to expose this to the programmer.
> 
> But this is Forth!  By definition, everything is exposed to the
> programmer: there is no magic, nothing hidden behind the curtain.  If
> ever there was a single Big Idea in Forth, it's that.  
> 
> Andrew.

I understand but I disagree.

Not everything is exposed to the programmer and there is no "by definition".

For instance, most Forth systems provide SP0, SP@ and SP! but the standard
does not expose them to the programmer. Are they "magic" words ?

If a programmer wants to use them, it is at its own risks, and it
is no more a standard programm.

imo, global states and words that implement multi-tasking are at
the same level as words like SP@ : they should not be exposed to the
programmer, nor described by a standard.

All this is debatable of course (but not "by definition"... :) ).

Franck

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

#56225

franck.bensusan@gmail.com wrote:
> Le vendredi 24 mars 2017 09:03:26 UTC+1, Andrew Haley a ?crit :
>> franck.bensusan@gmail.com wrote:
>> > Le jeudi 23 mars 2017 10:25:16 UTC+1, Andrew Haley a ?crit :
>> >> franck.bensusan@gmail.com wrote:
>> > 
>> > At the kernel level, yes, of course, you need global states and you
>> > need locks, mutexes, ... to handle them in a multi-tasking context.
>> > But you don't need to expose this to the programmer.
>> 
>> But this is Forth!  By definition, everything is exposed to the
>> programmer: there is no magic, nothing hidden behind the curtain.  If
>> ever there was a single Big Idea in Forth, it's that.  
> 
> I understand but I disagree.
> 
> Not everything is exposed to the programmer and there is no "by definition".
> 
> For instance, most Forth systems provide SP0, SP@ and SP! but the standard
> does not expose them to the programmer. Are they "magic" words ?

I think we're talking pasy each other about the difference between
what Forth systems do and what the standard language guarantees.
Sure, some words are not standard, but forth systems themselves don't
conventionally make any affort to prevent programmers from seeing what
is going on for real.  I agree that it would be quite possible to
write a Forth system which isn't transparent in the way and that Forth
could be standard but IMO it would not be good.

> If a programmer wants to use them, it is at its own risks, and it
> is no more a standard programm.
> 
> imo, global states and words that implement multi-tasking are at
> the same level as words like SP@ : they should not be exposed to the
> programmer, nor described by a standard.
> 
> All this is debatable of course (but not "by definition"... :) ).

OK.  It's interesting to see the spread of opinions.  That's why I
asked.

Andrew.

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

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

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

csiph-web