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

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

Essential properties of current standard Forth

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

Contents

  Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-15 14:19 +0000
    Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-15 17:58 -0700
      Re: Essential properties of current standard Forth tabcomputing@gmail.com - 2016-09-24 18:48 -0700
        Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-24 21:47 -0700
          Re: Essential properties of current standard Forth tabcomputing@gmail.com - 2016-09-25 08:11 -0700
            Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-25 20:14 -0700
              Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 11:12 +0200
                Re: Essential properties of current standard Forth Alex <alex@rivadpm.com> - 2016-09-26 12:16 +0100
                  Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 14:30 +0200
                    Re: Essential properties of current standard Forth Coos Haak <htrofhc@gmail.com> - 2016-09-26 15:10 +0200
                      Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 16:07 +0200
                  Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 13:43 +0000
                    Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-26 16:36 +0200
          Re: Essential properties of current standard Forth Rod Pemberton <NoHaveNotOne@zxdehrnyya.cam> - 2016-09-25 15:18 -0400
    Re: Essential properties of current standard Forth anotherreepca@gmail.com - 2016-09-18 09:01 -0700
      Re: Essential properties of current standard Forth Cecil Bayona <cbayona@cbayona.com> - 2016-09-18 11:35 -0500
        Re: Essential properties of current standard Forth minforth@arcor.de - 2016-09-19 03:21 -0700
          Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-19 09:49 -0500
            Re: Essential properties of current standard Forth minforth@arcor.de - 2016-09-19 12:38 -0700
              Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-20 11:23 -0500
                Re: Essential properties of current standard Forth lawrencedo99@gmail.com - 2016-09-20 12:55 -0700
                  Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-21 02:24 +0200
                Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-20 14:52 -0700
        Re: Essential properties of current standard Forth JUERGEN <epldfpga@aol.com> - 2016-09-19 10:12 -0700
          Re: Essential properties of current standard Forth Cecil Bayona <cbayona@cbayona.com> - 2016-09-19 12:40 -0500
      Re: Essential properties of current standard Forth stephen@mpeforth.com (Stephen Pelc) - 2016-09-21 10:09 +0000
    Re: Essential properties of current standard Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-19 13:29 +0200
      Re: Essential properties of current standard Forth foxaudioresearch@gmail.com - 2016-09-19 07:16 -0700
      Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-19 17:10 +0000
    Re: Essential properties of current standard Forth humptydumpty <ouatubi@gmail.com> - 2016-09-20 22:43 -0700
      Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-21 12:39 +0000
        Re: Essential properties of current standard Forth hughaguilar96@gmail.com - 2016-09-22 11:40 -0700
          Re: Essential properties of current standard Forth humptydumpty <ouatubi@gmail.com> - 2016-09-23 09:28 -0700
        Re: Essential properties of current standard Forth humptydumpty <ouatubi@gmail.com> - 2016-09-23 09:19 -0700
    Re: Essential properties of current standard Forth Paul Rubin <no.email@nospam.invalid> - 2016-09-23 20:11 -0700
      Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-24 10:55 +0000
        Re: Essential properties of current standard Forth Matthias Trute <matthias.trute@gmail.com> - 2016-09-24 11:14 -0700
          Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-25 03:01 -0500
            Re: Essential properties of current standard Forth Matthias Trute <matthias.trute@gmail.com> - 2016-09-25 02:21 -0700
              Re: Essential properties of current standard Forth lawrencedo99@gmail.com - 2016-09-25 14:01 -0700
              Re: Essential properties of current standard Forth Paul Rubin <no.email@nospam.invalid> - 2016-09-25 15:04 -0700
                Re: Essential properties of current standard Forth lawrencedo99@gmail.com - 2016-09-25 17:39 -0700
                  Re: Essential properties of current standard Forth Paul Rubin <no.email@nospam.invalid> - 2016-09-25 17:56 -0700
                Re: Essential properties of current standard Forth Mikael Nordman <oh2aun@gmail.com> - 2016-09-25 20:34 -0700
                  Re: Essential properties of current standard Forth Paul Rubin <no.email@nospam.invalid> - 2016-09-25 22:37 -0700
                Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-26 02:34 -0500
                  Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 14:04 +0000
                    Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-26 10:40 -0500
                      Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-28 06:43 +0000
                        Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-28 04:48 -0500
            Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 14:58 +0000
              Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-26 11:02 -0500
                Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 23:28 +0000
                  Re: Essential properties of current standard Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-27 03:49 -0500
                Re: Essential properties of current standard Forth Alex <alex@rivadpm.com> - 2016-09-27 11:43 +0100
          Standardization (was: Essential properties of current standard Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 16:01 +0000
            Re: Standardization (was: Essential properties of current standard Forth) stephen@mpeforth.com (Stephen Pelc) - 2016-09-26 20:06 +0000
              Re: Standardization (was: Essential properties of current standard Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-27 14:49 +0000
                Re: Standardization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-27 11:20 -0500
                Re: Standardization (was: Essential properties of current standard Forth) stephen@mpeforth.com (Stephen Pelc) - 2016-09-28 12:07 +0000
                  Re: Standardization (was: Essential properties of current standard Forth) Bernd Paysan <bernd@net2o.de> - 2016-09-29 02:07 +0000
                    Re: Standardization (was: Essential properties of current standard Forth) hughaguilar96@gmail.com - 2016-09-28 19:40 -0700
                      Re: Standardization (was: Essential properties of current standard Forth) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-09-29 15:22 -0700
                    Re: Standardization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-29 04:12 -0500
                    Re: Standardization (was: Essential properties of current standard Forth) stephen@mpeforth.com (Stephen Pelc) - 2016-09-29 10:15 +0000
                  Re: Standardization (was: Essential properties of current standard Forth) Matthias Trute <matthias.trute@gmail.com> - 2016-09-29 10:38 -0700
        Re: Essential properties of current standard Forth trans <transfire@gmail.com> - 2016-09-26 18:04 -0700
          Re: Essential properties of current standard Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-27 13:37 +0000
    Re: Essential properties of current standard Forth jim.brakefield@ieee.org - 2016-09-28 13:54 -0700

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

#51452 — Re: Standardization (was: Essential properties of current standard Forth)

Am Wed, 28 Sep 2016 12:07:00 +0000 schrieb Stephen Pelc:

> However, recognisers implicitly suggest a major restructuring of the
> Forth text interpreter.

It replaces a hard-coded structure by one that is extensible by the user. 
We all have long done that, but in an incompatible way that is sometimes 
not even stable across versions (Klaus Schleisiek got stuck with Gforth 
0.6.2, because we changed one of the lesser documented hooks in the text 
interpreter, and his code that extends the text interpreter doesn't work 
with newer versions).

So the problem of extending the text interpreter has always been there, 
and had various incompatible solutions, which have been added in an ad hoc 
fashion to the diverging implementations.

Conceptually, the Forth outer interpreter always was a sequence of 
matches, first words in the dictionary, then (if that failed) numbers, 
and then, if loaded, floating point numbers.  The recognizers generalize 
that concept, makes it extensible, but does not fundamentally change it.

> That veers towards mandating implementation, which worries me.

I'm trying hard to make the recognizers abstract enough that it's not 
mandating too much of a particular implementation.  E.g. amForth's 
recognizer return tables are actual tables, Gforth's are not.  The way a 
word is dealt with can be different from system to system, my 
implementation for VFX e.g. puts uses the immediate flag to select the 
appropriate return table; other options are to return a name token 
instead of an xt.

Same with numbers, to satisfy the existing hook in VFX, there's only one 
R:NUM as a recognizer return token for literals, while Gforth has R:NUM, 
R:DNUM, R:FLOAT for the different data types.

> There are other committee members who have expressed
> worry in public.

Yes, Andrew Haley was worried about "too much empowerment" for the 
programmer.  Hey, we are not doing Java here, we do Forth.

The recognizer proposal came partly as a response of exactly you two 
asking for standardizing OOP or thinking about some "common grounds" like 
Common Lisp's generic OOP system, so one obviously open question was how 
to add something like a dot parser, which you advocated, to a system 
without making that a special-purpose hook.

Your outer interpreter has a CLASSHOOK before, and a CUNDEFINED after the 
traditional interpreter; however, the actual components of the text 
interpreter like DONUMBER?, C#FLITERAL and C#LITERAL are also all hooks.  
The only thing that isn't a hook in the outer part is FIND, even COMPILE, 
and CEXECUTE are hooks.

This entire thing is hooks calling other hooks.  Do you see the design 
problem with this?  Once you have the recognizer embraced, you can stop 
that: There's just one list of hooks which gets processed in a generic 
loop: All are the same structure.  If you need to replace parts of the 
outer interpreter, e.g. for a cross compiler, just replace them on the 
recognizer stack.  No need for special-purpose-hooks everywhere.

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

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

#51453 — Re: Standardization (was: Essential properties of current standard Forth)

On Wednesday, September 28, 2016 at 7:07:45 PM UTC-7, Bernd Paysan wrote:
> Am Wed, 28 Sep 2016 12:07:00 +0000 schrieb Stephen Pelc:
> > That veers towards mandating implementation, which worries me.
> 
> I'm trying hard to make the recognizers abstract enough that it's not 
> mandating too much of a particular implementation.  
> ... 
> > There are other committee members who have expressed
> > worry in public.
> 
> Yes, Andrew Haley was worried about "too much empowerment" for the 
> programmer.  Hey, we are not doing Java here, we do Forth.

Well, Bernd Paysan assumes that he alone knows how "we do Forth" --- very arrogant!

Recognizers are the complete opposite of how we "do" Straight Forth --- the name "Straight Forth" implies that it is a traditional Forth without all of the weird ambiguity of ANS-Forth, and without all of the weird everything of Forth-200x.

I see recognizers as being the wedge that splits the Forth community into two camps --- Forth-200x for those who want recognizers --- Straight Forth for those who just want a straight Forth.

> The recognizer proposal came partly as a response of exactly you two 
> asking for standardizing OOP or thinking about some "common grounds" like 
> Common Lisp's generic OOP system, so one obviously open question was how 
> to add something like a dot parser, which you advocated, to a system 
> without making that a special-purpose hook.
> 
> Your outer interpreter has a CLASSHOOK before, and a CUNDEFINED after the 
> traditional interpreter; however, the actual components of the text 
> interpreter like DONUMBER?, C#FLITERAL and C#LITERAL are also all hooks.  
> The only thing that isn't a hook in the outer part is FIND, even COMPILE, 
> and CEXECUTE are hooks.

Straight Forth won't support polymorphism. 

Most likely I will just have a super-simple OOP system such as described here:
https://groups.google.com/forum/#!searchin/comp.lang.forth/is-a%7Csort:relevance/comp.lang.forth/cH-pGXhBCfE/b13O8gNFAwAJ

I might go with a VMT like in Mini-OOF but I doubt it as the method calls are slower.

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

#51462 — Re: Standardization (was: Essential properties of current standard Forth)

> I see recognizers as being the wedge that splits the Forth community into two camps --- Forth-200x for those who want recognizers --- Straight Forth for those who just want a straight Forth.

It seems like theory of compilation becomes more popular and gets over the edge where has been found by forthers. This is absolutely useless thing to discuss recognizers as a part of standard. It is just a kind of application which can be written on Forth.

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

#51454 — Re: Standardization

Bernd Paysan <bernd@net2o.de> wrote:
> Yes, Andrew Haley was worried about "too much empowerment" for the 
> programmer.  Hey, we are not doing Java here, we do Forth.

Heh.  If anyone wants to know what I actually said, they can read it.
:-)

Andrew.

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

#51455 — Re: Standardization (was: Essential properties of current standard Forth)

On Thu, 29 Sep 2016 02:07:32 -0000 (UTC), Bernd Paysan
<bernd@net2o.de> wrote:

>> However, recognisers implicitly suggest a major restructuring of the
>> Forth text interpreter.
>
>It replaces a hard-coded structure by one that is extensible by the user. 
>We all have long done that, but in an incompatible way that is sometimes 
>not even stable across versions

A very nice post - I've even printed it. Thanks.

Stephen

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

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

#51460 — Re: Standardization (was: Essential properties of current standard Forth)

> >You mean, until now you don't take RfDs for new practice seriously,
> >but once the "experimental proposal" sticker is put on it, you will?
> 
> There are so many ideas to be tried that, as always, we encourage
> natural selection by asking a "champion" to put a proposal together.

It seems that system providers are not the best people to talk
with when it comes to changes, may they be as little as 1char=1 or
as (only potentially fundamental) as recognizers. The users are the 
ones to ask the question "is feature xy useful". System providers
will always follow their customers.

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

#51349

On Saturday, September 24, 2016 at 8:14:58 AM UTC-4, Anton Ertl wrote:

> >Another idea is to have a standard Forth with pseudo-static typing:
> >i.e., have a testing/debugging mode where every cell is accompanied by a
> >tag field that's checked at runtime, signalling errors that might
> >otherwise be missed.  Then once debugged, you can turn off the checks.
> >No idea how useful this is.
> 
> Again, you need a type system, but this one might be easier than a
> statically checkable one.

I think one of trending ideas now in language research is hybrid type systems.[1] Basically the language uses static typing where it can and falls back to dynamic typing when it can't. It's been dubbed "soft typing" from Mike Fagan's dissertation on the subject.[2]

1. https://www.ics.uci.edu/~lopes/teaching/inf212W12/readings/rdl04meijer.pdf
2. https://scholarship.rice.edu/handle/1911/16439

Static tying works fine until you have to load a YAML document, or want to write a method than can return 12 different types of objects.

On the other hand dynamic type systems can eat memory. A 32 bit type header for every 8 bit integer seems pretty wasteful. And of course they are slower. Although V8 has proven they don't necessarily have to be so slow.

Forth is an interesting case, b/c it is (typically) statically typed, but you wouldn't know it b/c there are only a few types: integer, fixed and/or float and the cell. Everything else is just built on top of those. In a way it is bit of trick. We just use different words for for different types. That's basically how it works for any actual type that gets implemented in Forth. It transfers responsibility from a type system to word names and the programmer has to use the appropriate ones. Which isn't type safe, obviously, but can be quite flexible in the hands of a good coder.

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

#51387

trans <transfire@gmail.com> writes:
>Forth is an interesting case, b/c it is (typically) statically typed, but y=
>ou wouldn't know it b/c there are only a few types: integer, fixed and/or f=
>loat and the cell. Everything else is just built on top of those. In a way =
>it is bit of trick. We just use different words for for different types. Th=
>at's basically how it works for any actual type that gets implemented in Fo=
>rth. It transfers responsibility from a type system to word names and the p=
>rogrammer has to use the appropriate ones. Which isn't type safe, obviously=
>, but can be quite flexible in the hands of a good coder.

Every useful program has certain static properties; that follows from
programmers having to reason how the program works.  In Forth that's
all there is: the system does not check any of the properties, so it's
all in the programmer's head (and in the comments in the program).

Some languages try to check static properties with the compiler; they
either force the programmer to state properties (e.g., how many
parameters are passed, and what types they have), or they try to infer
it from the program and still check it (type inference).

Applied to Forth, a pretty good static property is stack depth.

If we then try to extend this to types, there are things that have to
be wrong (at least in portable code), such as

5 'a' !

but others are less clear:

5 'a' *

That may be an index into an array with 5-byte elements; or maybe some
part of a hash computation; or ...  So we should probably accept it.

However, if we have 

4 5 'a' * X + !

with X being an array of cells, there's probably a type error here
(and, on some architectures, an alignment error); the array is not
accessed using a multiple-of-cell offset, and there my be a CELLS
missing, or something else is funny.

Designing Forth type-checking rules beyond stack depth checking that
catch many errors without producing lots of false positives is an
unsolved problem.  And even stack-depth checking is not trivial; e.g.,
if you write a defining word for a method, the defined methods can
have very different stack effects, but each method typically has only
one stack effect.

- 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]

#51450

On Thursday, September 15, 2016 at 12:24:49 PM UTC-5, Anton Ertl wrote:
> At EuroForth Andrew Read gave an impromptu talk where he suggested a
> next-standard effort that would not be shackled by
> backwards-compatibility with the current (Forth-83/94/2012) line of
> standards.
> 
> While there was not that much desire for such an effort in the
> audience, the talk got me thinking about what is essential in the
> current line of Forth standards and which features of a Forth system
> would require such a next-standard effort (if there are people that
> want to have a standard for that).
> 
> What is not essential:
> 
> Of course, there are people (including committee members) who disagree
> with some choices made in the standard, but that's a matter of opinion
> and not the kind of "essential" I have in mind; In particular, if
> people could not find a consensus on a different choice earlier, will
> it help to start from scratch?  In at least one case, there actually
> has been consensus on taking a different choice than an earlier
> standard (standardizing "{:" and making "LOCALS|" obsolescent), so if
> that happens, the current standard process can change choices, too,
> slowly.  We don't need a from-scratch effort for that.
> 
> Another issue is removing features, to achieve some form of
> minimalism.  We have a mechanism in the standards process for removing
> features (it takes it's time, though), so if the community decided we
> really want minimality, and if we actually could find consensus on
> what we want in a minimal system, we could go there; in practice, this
> will not happen, but that has more to do with there being no consensus
> that we want a minimal system and no consensus on what it would look
> like.
> 
> Another issue is that of names.  While machine Forth calls the
> exclusive-or operation OR, I don't consider that an essential feature
> of machine Forth.  It would be pretty much the same if Chuck Moore had
> chosen to call it XOR.  Conversely, if we wanted to remove inclusive
> OR, later add an OR that's a synonym for XOR, and then remove XOR,
> this could be done, very slowly, over several standards releases.
> 
> Possibly essential:
> 
> The syntax difference between machine Forth and Color Forth (color
> that indicates how to text-interpret the string) cannot be
> accommodated in the current line of standards; while it's just syntax,
> it's a change that does not allow a transition period, so it would
> make no sense to try to do it in the current line of standards.
> 
> Pretty essential:
> 
> Statically determined stack depth: Requiring that, as sketched for
> PAF, would disallow some standard programs (and a lot of buggy
> programs).  I guess we could get there in the current line of
> standards, but I don't expect it.
> 
> Static type checking: StrongForth did that, but also implemented
> overloading (e.g., DUP worked as 2DUP when there was a double on the
> TOS).  Static type checking would first require a type system; it
> would probably disallow more standard programs, especially if you want
> to have a somewhat safe type system; the actual repercussions would
> depend on the type system.  Overloading would be even more disruptive,
> by a lot.
> 
> Data stack items: In the current standards, the data stack item is a
> machine word (cell), used as integer, address, or a group of bits and
> its interpretation depends on the operation; there are a number of
> systems that deviate from this:
> 
> Floats: There is one suggestion (and a Russion system that works this
> way) to use floats as stack items, with words like + working on
> floats, and IIRC addresses represented by NaNs (or maybe by
> interpreting the bit pattern as address).  That's pretty far from the
> current standard.
> 
> Dynamically typed stack items (e.g., Factor, 8th, Oforth, with Factor
> also doing static type checking to some extent), with dynamic type
> checking in the operations and possible overloading, and possible
> automatic memory reclamation.  That's even further from the current
> line of standards.  Looking at the number of systems that go that way,
> there seems to be quite a bit of interest in that direction, so maybe
> that's something where such a standard that's not rooted in the
> current line of standards might make sense.  But I guess that the
> implementors and users of these systems have to work it out if they
> need a standard for that, or if they are happy with the different
> systems that they have now.
> 
> - 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 is essential in the current line of Forth standards and which
]> features of a Forth system would require such a next-standard effort

Not a Forth expert, think I know enough to pose the following:

Been watching the "recognizer" discussion and have realized that my problem
is not there but with the interpret/compile distinction.  Immediate words that apply only to the following word are OK.  Basically, want to eliminate the compile state!(1)  This implies that quotations are a form of string/list constant and are used in word definitions: ":" word "{:" quotation ";}" ";" or better yet: "'" word "{:" quotation ";}" ";" ( where "{:" and ";}" are adjusted to suit your tastes.  Also implies a formal stack effect string/list "constant" or an inferred stack effect (added by the text editor?).

(1) 8th allows stack operations within a quotation by use of a start/stop single character word.  This seems OK.

The basic problem is in reading Forth code and knowing where the changes between interpret and compile take place.  Now in line with the Forth spirit it is good to let the programmer have access and control over this state.(2)  However, for the uninitiated, limiting such state changes to three or four single character bracket words is much better. 

(2) another way to distinguish is to show compile text in italics or underline?

[toc] | [prev] | [standalone]

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

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

csiph-web