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 1 of 4  [1] 2 3 4  Next page →

#51006 — Essential properties of current standard Forth

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/

[toc] | [next] | [standalone]

#51015

On Thursday, September 15, 2016 at 10:24:49 AM UTC-7, 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).

In this thread,
https://groups.google.com/forum/#!msg/comp.lang.forth/D0PmblPgthM/o6Ivh2RbAgAJ;context-place=forum/comp.lang.forth

I said this:

On Wednesday, May 4, 2016 at 5:03:16 PM UTC-7, hughag...@gmail.com wrote:
> I said earlier that I would be the "chief" and I would appoint the committee members (similar to how Elizabeth Rather appoints the committee members for Forth-200x). I'm not going to be like Leon Wagner though and tell everybody exactly what to believe, give them assignments, and write the specs for them (basically, treat them like code-monkeys). I just want to appoint the members so I can weed out people like Alex McDonald who claimed to "do standards for a living" (whatever the hell that means) and who knew very little about Forth. People can do whatever they want, so long as they adhere to the basic principles:
> 
> 1.) Minimalism. All that cruft in ANS-Forth will be discarded (for example: DO loops will go). I would expect the language to be less than half the size of ANS-Forth. As for the extension code-libraries, they will make the language bigger, but they are optional. They are containers (my list.4th and association.4th) or they are associated with a particular data-type (my string-stack.4th). The emphasis here should be on usefulness --- I was impressed by how Factor used "sequences" as a standard data-type, and this was my inspiration for list.4th --- also, almost all programs for desktop-computers are going to use strings, so having a standard library such as string-stack.4th is going to make the programs easy to read, rather than everybody doing something different in every program.
> 
> 2.) Behavior. The focus should be on standardizing behavior rather than implementation. One of the problems with ANS-Forth was that it standardized implementation. For example, ANS-Forth assumes that the >R data and the DO loops use the same stack, so they were standardizing on the PDP-11 implementation that had to do this because of a shortage of registers. Quite a lot of ANS-Forth assumes that the target processor is a PDP-11, apparently because that is the only processor that Elizabeth Rather is familiar with.
> 
> 3.) Quotations. My system with the fat-xt will be used to allow quotations to access the parent function's local variables. This is trivial to implement! This is the foundation to writing general-purpose data-structures --- I really see this as bring Forth into the 21st century --- make it comparable to the other desktop-computer language such as Lisp --- unlike Lisp though, we will not have garbage-collection or tagged data (we will not have Dynamic-OOP). The emphasis will still be on speed, and Dynamic-OOP is a dog, so leave that to the script kiddies.
> 
> 4.) Numerical. The 64-bit cell with the Fixed or Float data-type is fundamental to the language. I think this makes the language much simpler than ANS-Forth where integers and floats are distinct (so, this fits in with the minimalism idea). The "killer app" is CAM, but most machinists have experience primarily with using pocket calculators for figuring out gcode, and pocket calculators don't consider integers and floats to be distinct data-types. Also, it is important to define what the precision of the numbers is in the standard so the programmer knows what the results of numerical calculations are going to be and can expect the same results on every compliant compiler (so long as he sticks with either the Fixed or Float version, as they give different results from each other). I originally was only going to have the Fixed version, but Ilya Vasilyev convinced me to have a Float version also and to make them compatible with each other (except for a slight difference in the numeric results in some cases). This was here:
> https://groups.google.com/forum/#!searchin/comp.lang.forth/ilya%7Csort:date/comp.lang.forth/R7K3FWXnyKE/0_LJ13ZfBQAJ
> 
> 5.) Cross-Compilation. The compiler should have all the necessary features for writing a cross-compiler. This is actually pretty easy --- it is amazing that ANS-Forth failed at such a simple task (I'm highly suspicious that ANS-Forth was purposely sabotaged to make cross-compilation difficult in order to prevent common users from writing a cross-compiler in competition with Forth Inc. and MPE who make most of their money selling vendor-specific cross-compilers) --- I know how to write a cross-compiler, so I will make sure that this is supported.
> 
> These are the 5 principles of Straight-Forth. Who disagrees with any of these principles? Which ones? Why?
> 
> Note that LFTforth is for micro-controllers and would have different principles that it is based on --- that is really Raimond's thing, not mine.

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

#51256

On Thursday, September 15, 2016 at 8:58:15 PM UTC-4, hughag...@gmail.com wrote:

> > 3.) Quotations. My system with the fat-xt will be used to allow quotations to access the parent function's local variables. This is trivial to implement! This is the foundation to writing general-purpose data-structures --- I really see this as bring Forth into the 21st century 

Could you explain this more? Maybe an example?

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

#51261

On Saturday, September 24, 2016 at 6:48:13 PM UTC-7, tabcom...@gmail.com wrote:
> On Thursday, September 15, 2016 at 8:58:15 PM UTC-4, hughag...@gmail.com wrote:
> 
> > > 3.) Quotations. My system with the fat-xt will be used to allow quotations to access the parent function's local variables. This is trivial to implement! This is the foundation to writing general-purpose data-structures --- I really see this as bring Forth into the 21st century 
> 
> Could you explain this more? Maybe an example?

The quotation gets compiled elsewhere (not in the middle of the parent function). What gets compiled into the parent function is QXT that is like LIT except that it pushes the quotation's xt onto the data-stack. It knows the cfa at compile-time and it packs this into an xt. An xt is a 64-bit struct (Straight Forth has a 64-bit cell, but has 32-bit pointers). The xt contains the cfa (32-bit) and the pointer to the parent function's local-frame (32-bit) packed together. QXT has to obtain the pointer to the parent function's local-frame at run-time and pack it together with the quotations cfa which is a literal known at compile-time. An xt of a colon word is similar to an xt of a quotation except that the pointer to the local-frame is zero. EXECUTE can test the pointer to the local-frame to determine if the xt is of a quotation or a colon-word, and it behaves slightly differently. This is called the "fat-xt" system because the xt is a struct containing two pointers --- it is not just the cfa like in most Forth systems, but it also contains the parent-function's local-frame pointer (for a quotation).

What I have described above is pretty trivial to implement. I have a slightly more complicated version that allows EXECUTE to determine if a quotation is valid before executing it --- it can test that the parent function's local-frame is still valid, meaning that the quotation is okay to execute --- if the parent function's local-frame is no longer valid, that means that the parent function has executed, which means that EXECUTE will abort with an error message because this is illegal.

As for an example of using quotations, my hottie-counting program is pretty good:
https://groups.google.com/forum/#!topic/comp.lang.forth/ohE8mx7tWQU%5B101-125%5D
(see page-5)
This example uses rquotations rather than fat-xt quotations, but it does show quotation use. The fat-xt method is more robust --- we don't have the limitations of rquotations --- but those limitations aren't a problem most of the time anyway, so I don't actually have any examples of when the fat-xt method is needed and the rquotation method won't work.

I have a document started describing Straight Forth. I have two data-structures built-in (the array and the "chain"). The array is mostly for strings. I recommend that the chain be used for pretty much everything. I was impressed by how Factor has the "sequence" for everything, and this makes programs readable because they all look alike, and my chain (I just made up that term; it is something I invented) is based on this idea. Another advantage is that the compiler-writer can put some effort into making the hofs supporting the chain to be efficient (mine are pretty much all assembly-language, and they use registers internally). If the programmers use chains for all of their data, their programs should be pretty efficient, even if the compiler is doing minimal optimization for general code. Uniformity not only helps to make programs readable (uniform) but it also helps to make programs efficient --- the downside is that the chain may not always be the best choice for a particular application --- I think that it is a reasonable choice most of the time though (I would expect that 99% of all Straight Forth programs can use the chain as their only data-structure, and it will work fine).

The chain is an ordered container using a string as a key. Previously, Bernd Paysan called me stupid because I use a binary tree rather than a hash-table, because a hash-table provides faster random access (given enough memory that it doesn't overflow into a mess of linked-lists). My chains can be used as associations (which are all about random access), but this isn't my primary purpose for them, so I'm not all that concerned about efficiency of random-access. I am primarily assuming that the key will be a string representation of a number --- examples would be line-numbers in a cross-compiler, or a sparse array in a numeric program. The two "killer apps" for Straight Forth are the Forth cross-compiler and numeric programs --- the numeric programs would include CAM (Computer-Aided Manufacturing) that involves generating gcode for CNC machines, and statistics programs such as R is used for (R is slow as molasses though).

This is an excerpt from my document:
-----------------------------------------------------------------------------
A novice-level Straight Forth programmer should only use the built-in hofs; he should not write his own hofs and he should not use BEGIN WHILE REPEAT (iteration is a common source of bugs, which is why novices are discouraged from using BEGIN WHILE REPEAT). An intermediate-level Straight Forth programmer may write his own hofs and use BEGIN WHILE REPEAT inside of them, but should not use BEGIN WHILE REPEAT anywhere except inside of his hofs, and he should not write very many hofs. It is idiomatic for all Straight Forth programmers from novice to advanced to program in a novice-level manner (using the built-in hofs) as much as possible because this makes the programs easy to read by others who may be novice-level. The built-in data-structures are the array and the chain (an ordered container with a string as a key). These should be adequate for 99% of all Straight Forth programs. In rare circumstances it will be necessary to use some other data-structure, in which case hofs will have to be written to support that data-structure (a hof is used to traverse a data-structure). Straight Forth programmers should not introduce new data-structures unless necessary, because doing so makes their programs hard to read, but they should stick with novice-level techniques (using the two built-in data-structures) as much as possible --- the programmers should not strive to prove that they are intermediate-level or (woo hoo!) advanced-level --- the goal with Straight Forth is to write programs that do something useful and which are easy to read by everybody including novices.

This document describes how novice-level Straight Forth programmers write their programs (they use the built-in hofs and the two built-in data-structures). This document also describes how intermediate-level Straight Forth programmers write their programs (they implement new data-structures and write hofs containing BEGIN WHILE REPEAT to support those data-structures, but only when necessary). This document does not describe how advanced-level Straight Forth programmers write their programs --- this is because there are no advanced-level Straight Forth programmers (not even me the inventor) so we can't speculate on how they will write their programs --- after the language has been in use for a few years, advanced-level Straight Forth programmers might evolve (maybe not though; Python has been in use for decades, but no sober Python programmer claims to be advanced-level, and it is not expected to ever happen).

Straight Forth is completely different in spirit from ANS-Forth. Straight Forth is intended to be useful, and programs are intended to be simple and straight-forward (hence the name: Straight Forth). By comparison, ANS-Forth has been described as "sudoku for programmers," meaning that it is a toy language, but it can be fun like solving a puzzle (actually, like creating a puzzle). ANS-Forth programmers delight in writing complicated and hard-to-read programs to prove that they are more clever than the poor devil who is unable to figure out what they are doing. The ANS-Forth programmers motto seems to be: "If you can't dazzle them with brilliance, then baffle them with bull!" Forth-200x is the same pile of manure grown to a gigantic size and getting bigger every year. The Forth-200x programmers delight in writing "recognizers" that change the syntax of Forth-200x and hence totally baffle the reader. By comparison, Straight Forth is a traditional Forth that doesn't have any syntax (well, almost no syntax; we do have a few minor syntactical features that help to improve readability) --- Straight Forth programmers are definitely not allowed to create their own funky syntax, effectively creating their own custom language --- Straight Forth programs are supposed to be easily readable by all Straight Forth programmers (the maintainence programmer's life is already pretty miserable, but there is no good purpose in adding to his misery gratuitously).

The point of Straight Forth is that you don't have to be advanced-level, or even intermediate-level, for the language to be useful to you --- it is designed to be useful for novice-level programmers --- it is acceptable for a Straight Forth programmer to stay at the novice-level indefinitely (the point is to write useful programs, not to show off how clever you are; stick with sudoku puzzles for showing off how clever you are).
-----------------------------------------------------------------------------

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

#51283

On Sunday, September 25, 2016 at 12:47:10 AM UTC-4, hughag...@gmail.com wrote:
> On Saturday, September 24, 2016 at 6:48:13 PM UTC-7, tabcom...@gmail.com wrote:
> > On Thursday, September 15, 2016 at 8:58:15 PM UTC-4, hughag...@gmail.com wrote:
> > 
> > > > 3.) Quotations. My system with the fat-xt will be used to allow quotations to access the parent function's local variables. This is trivial to implement! This is the foundation to writing general-purpose data-structures --- I really see this as bring Forth into the 21st century 
> > 
> > Could you explain this more? Maybe an example?
> 
> The quotation gets compiled elsewhere (not in the middle of the parent function). What gets compiled into the parent function is QXT that is like LIT except that it pushes the quotation's xt onto the data-stack. It knows the cfa at compile-time and it packs this into an xt. An xt is a 64-bit struct (Straight Forth has a 64-bit cell, but has 32-bit pointers). The xt contains the cfa (32-bit) and the pointer to the parent function's local-frame (32-bit) packed together. QXT has to obtain the pointer to the parent function's local-frame at run-time and pack it together with the quotations cfa which is a literal known at compile-time. An xt of a colon word is similar to an xt of a quotation except that the pointer to the local-frame is zero. EXECUTE can test the pointer to the local-frame to determine if the xt is of a quotation or a colon-word, and it behaves slightly differently. This is called the "fat-xt" system because the xt is a struct containing two pointers --- it is not just the cfa like in most Forth systems, but it also contains the parent-function's local-frame pointer (for a quotation).
> 
> What I have described above is pretty trivial to implement. I have a slightly more complicated version that allows EXECUTE to determine if a quotation is valid before executing it --- it can test that the parent function's local-frame is still valid, meaning that the quotation is okay to execute --- if the parent function's local-frame is no longer valid, that means that the parent function has executed, which means that EXECUTE will abort with an error message because this is illegal.

Thanks. Very helpful. I am not adept in all the implementation details of Forth so this a touch over my head, but I understood enough. What notation are you using in Straight Forth -- `[:  ;]` ?
> The chain is an ordered container using a string as a key. Previously, Bernd Paysan called me stupid because I use a binary tree rather than a hash-table, 

I don't. BST is probably better for many reasons.

> The Forth-200x programmers delight in writing "recognizers" that change the syntax of Forth-200x and hence totally baffle the reader. By comparison, Straight Forth is a traditional Forth that doesn't have any syntax (well, almost no syntax; we do have a few minor syntactical features that help to improve readability) --- Straight Forth programmers are definitely not allowed to create their own funky syntax, effectively creating their own custom language --- Straight Forth programs are supposed to be easily readable by all Straight Forth programmers (the maintainence programmer's life is already pretty miserable, but there is no good purpose in adding to his misery gratuitously).

I basically agree with you about recognizers. They are new to me. But it didn't take me long to think maybe that is just going too far. Maybe it makes sense as an optional add on (however that might work) but for general use it would make programs harder to read. I think things need to be moving in the opposite direction. 

OTOH, they are interesting b/c it gives the programmer the power to create DSLs of almost any form. Of course using an extensible lexer could probably achieve much the same thing (which I think Factor does?).

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

#51310

On Sunday, September 25, 2016 at 8:11:15 AM UTC-7, tabcom...@gmail.com wrote:
> On Sunday, September 25, 2016 at 12:47:10 AM UTC-4, hughag...@gmail.com wrote:
> What notation are you using in Straight Forth -- `[:  ;]` ?

No, I use { ... } for quotations in Straight Forth.
I use LOCAL{ ...} for defining local variables.

I encourage programmers to write explicit iteration using BEGIN WHILE REPEAT but to use the hofs for the two built-in data-structures (arrays and chains) --- and if they do use BEGIN WHILE REPEAT to bury this inside of a hof --- consequently, quotations are going to be used quite a lot and so they get { } which is easy to type and easy to read.

I have the first chapter of my document about Straight Forth written, if you want to read it --- I can email it to you --- it includes the hottie-counting program upgraded for Straight Forth.

> I basically agree with you about recognizers. They are new to me. But it didn't take me long to think maybe that is just going too far. Maybe it makes sense as an optional add on (however that might work) but for general use it would make programs harder to read. I think things need to be moving in the opposite direction. 

The problem with recognizers is that they don't allow the reader of the source-code to look up words that he doesn't know. Usually, if you see a word that you don't know, then you can look it up with LOCATE or in a reference manual. You can't look up a recognizer-specific word however --- for example, if you don't know what $BEAD means, how are you going to look it up?

Also, there are likely going to be a lot of recognizers, and they will clash with each other --- a program that runs on one system won't run on another system unless the same recognizers are used and the recognizers are loaded in the same order --- programs aren't going to be portable between systems, which is supposed to be the point of having a Standard.

> OTOH, they are interesting b/c it gives the programmer the power to create DSLs of almost any form. Of course using an extensible lexer could probably achieve much the same thing (which I think Factor does?).

VFX has a BNF lexer --- I haven't looked into it --- I might provide something like this for Straight Forth (I glanced over VFX's BNF lexer and it appeared to be pretty easy to implement).

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

#51318

In article <e8f43052-8ead-4025-b90b-72a2e2a505ca@googlegroups.com>,
 <hughaguilar96@gmail.com> wrote:
 <SNIP>
>The problem with recognizers is that they don't allow the reader of the sou=
>rce-code to look up words that he doesn't know. Usually, if you see a word =
>that you don't know, then you can look it up with LOCATE or in a reference =
>manual. You can't look up a recognizer-specific word however --- for exampl=
>e, if you don't know what $BEAD means, how are you going to look it up?

That is a good point.
And remember if it is hard for a computer to parse it probably is
also for a human, and vice versa.
In my book only prefixes are allowed. That
means you look up $ , then $B, then $BEA etc. If it is known that
the largest prefix is one character, it is swiftly found as $ would be
the only candidate.
(or e.g. you only restrict prefixes to the minimum search order aka ONLY
wordlist).
ciforth interprets/compiles all char's, strings, numbers in weird BASE's
etc. using only one char prefixes.
The only 2-char prefix is "0x" for hex (which goes better if you want
reserve $ for Unix environment queries). It is not even loadable,
you must define it yourself with
   WANT $
   '$ ALIAS 0x
(To be honest. If it starts with a 7 it is a number. What kind of
number, single double float hex, is left to the prefix 7 to sort out.)

I originally invented this mechanism from my experience with tForth
and Marcel Hendrix. There were too many prefixes, and I absolutely
didn't want the $-prefix and the #-prefix etc. in my kernel and indeed
they are made loadable in the ciforth (lina) kernel.
That is the same feeling you have about recognizers now.

>
>Also, there are likely going to be a lot of recognizers, and they will clas=
>h with each other --- a program that runs on one system won't run on anothe=
>r system unless the same recognizers are used and the recognizers are loade=
>d in the same order --- programs aren't going to be portable between system=
>s, which is supposed to be the point of having a Standard.

I can see that you fear that from the proposal. It probably isn't that
bad, but maybe it is.

>
>> OTOH, they are interesting b/c it gives the programmer the power to creat=
>e DSLs of almost any form. Of course using an extensible lexer could probab=
>ly achieve much the same thing (which I think Factor does?).
>
>VFX has a BNF lexer --- I haven't looked into it --- I might provide someth=
>ing like this for Straight Forth (I glanced over VFX's BNF lexer and it app=
>eared to be pretty easy to implement).

I doubt that BNF is an advantage, not for the kernel system.

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]

#51323

On 26/09/16 10:12, Albert van der Horst wrote:
> In article <e8f43052-8ead-4025-b90b-72a2e2a505ca@googlegroups.com>,
>  <hughaguilar96@gmail.com> wrote:
>  <SNIP>
>> The problem with recognizers is that they don't allow the reader of the sou=
>> rce-code to look up words that he doesn't know. Usually, if you see a word =
>> that you don't know, then you can look it up with LOCATE or in a reference =
>> manual. You can't look up a recognizer-specific word however --- for exampl=
>> e, if you don't know what $BEAD means, how are you going to look it up?
>
> That is a good point.
> And remember if it is hard for a computer to parse it probably is
> also for a human, and vice versa.
> In my book only prefixes are allowed. That
> means you look up $ , then $B, then $BEA etc. If it is known that
> the largest prefix is one character, it is swiftly found as $ would be
> the only candidate.
>

We already have several classes of words like 1.0e-1 that cannot be 
LOCATEd.

Use a 4 STATE recognizer; EXECUTE COMPILE, POSTPONE and EXPLAIN. It can 
then provide an explanation if it recognises the string (and a LOCATEion 
if that's appropriate).


-- 
Alex

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

#51324

In article <nsb02g$ple$1@dont-email.me>, Alex  <alex@rivadpm.com> wrote:
>On 26/09/16 10:12, Albert van der Horst wrote:
<SNIP>
>
>We already have several classes of words like 1.0e-1 that cannot be
>LOCATEd.

LOCATE means look the source up. Nobody expects denotations to be
programmed in the source. So that's okay.

>
>Use a 4 STATE recognizer; EXECUTE COMPILE, POSTPONE and EXPLAIN. It can
>then provide an explanation if it recognises the string (and a LOCATEion
>if that's appropriate).

I would say featuritis. Having EXPLAIN could be nice, it could try a
LOCATE and failing that it could try to tell you what denotation you
have. There is no STATE for SEE and I see no state for EXPLAIN.

But really. Somebody who needs EXPLAIN to understand what 12 means,
is certainly not able to read tutorials where EXPLAIN is explained.

>--
>Alex

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]

#51325

Op Mon, 26 Sep 2016 14:30:26 +0200 (CEST) schreef Albert van der Horst:

> In article <nsb02g$ple$1@dont-email.me>, Alex  <alex@rivadpm.com> wrote:
>>On 26/09/16 10:12, Albert van der Horst wrote:
> <SNIP>
>>
>>We already have several classes of words like 1.0e-1 that cannot be
>>LOCATEd.
> 
> LOCATE means look the source up. Nobody expects denotations to be
> programmed in the source. So that's okay.
> 
>>
>>Use a 4 STATE recognizer; EXECUTE COMPILE, POSTPONE and EXPLAIN. It can
>>then provide an explanation if it recognises the string (and a LOCATEion
>>if that's appropriate).
> 
> I would say featuritis. Having EXPLAIN could be nice, it could try a
> LOCATE and failing that it could try to tell you what denotation you
> have. There is no STATE for SEE and I see no state for EXPLAIN.
> 
> But really. Somebody who needs EXPLAIN to understand what 12 means,
> is certainly not able to read tutorials where EXPLAIN is explained.
> 
>>--
>>Alex
> 
> Groetjes Albert

I am that one. I can type 'help forth' or 'help if' and the glossary
of these words are displayed.
But I can also type 'help %1100' and read that this is the number twelve.
help "abacadabra" says that this is a string of ten characters.
help &A says that this is the letter A with value 65.
Just in case anyone wants it.

groet Coos

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

#51327

In article <1j1l33ju3gvb4$.9drt1iosj0f2$.dlg@40tude.net>,
Coos Haak  <htrofhc@gmail.com> wrote:
>Op Mon, 26 Sep 2016 14:30:26 +0200 (CEST) schreef Albert van der Horst:
>
>> In article <nsb02g$ple$1@dont-email.me>, Alex  <alex@rivadpm.com> wrote:
>>>On 26/09/16 10:12, Albert van der Horst wrote:
>> <SNIP>
>>>
>>>We already have several classes of words like 1.0e-1 that cannot be
>>>LOCATEd.
>>
>> LOCATE means look the source up. Nobody expects denotations to be
>> programmed in the source. So that's okay.
>>
>>>
>>>Use a 4 STATE recognizer; EXECUTE COMPILE, POSTPONE and EXPLAIN. It can
>>>then provide an explanation if it recognises the string (and a LOCATEion
>>>if that's appropriate).
>>
>> I would say featuritis. Having EXPLAIN could be nice, it could try a
>> LOCATE and failing that it could try to tell you what denotation you
>> have. There is no STATE for SEE and I see no state for EXPLAIN.
>>
>> But really. Somebody who needs EXPLAIN to understand what 12 means,
>> is certainly not able to read tutorials where EXPLAIN is explained.
>>
>>>--
>>>Alex
>>
>> Groetjes Albert
>
>I am that one. I can type 'help forth' or 'help if' and the glossary
>of these words are displayed.
>But I can also type 'help %1100' and read that this is the number twelve.
>help "abacadabra" says that this is a string of ten characters.
>help &A says that this is the letter A with value 65.
>Just in case anyone wants it.

And would you've found that if it was called EXPLAIN ?
>
>groet Coos
-- 
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]

#51328

Alex <alex@rivadpm.com> writes:
>On 26/09/16 10:12, Albert van der Horst wrote:
>> In article <e8f43052-8ead-4025-b90b-72a2e2a505ca@googlegroups.com>,
>>  <hughaguilar96@gmail.com> wrote:
>>  <SNIP>
>>> The problem with recognizers is that they don't allow the reader of the sou=
>>> rce-code to look up words that he doesn't know. Usually, if you see a word =
>>> that you don't know, then you can look it up with LOCATE or in a reference =
>>> manual. You can't look up a recognizer-specific word however --- for exampl=
>>> e, if you don't know what $BEAD means, how are you going to look it up?

Well, $BEAD is already a "word" that is recognized by the standard,
how do you look that up?  Or the "word" 1.

I am more of the school of thought of avoiding conflicting recognizers
(at least not having them intentionally) and having tight recognizers
(that do recognizes only the minimal set of "words"), but Bernd Paysan
embraces loose recognizers, conflicting recognizers, and letting thr
priority order resolve conflicts.  In order to allow the user to sort
out what's going on in puzzling cases, Bernd has added a trace
facility to Gforth's recognizers; you can turn it on with

' .name is trace-recognizer

and it shows which recognizer is used for every recognized string.

So when I write "1 .", it says

1 . rec:num rec:word 1  ok

So "1" is recognized by rec:num, and "." is recognized by rec:word;
the rest is the usual output of interpreting "1 .".

So, let's answer your question:

$BEAD rec:num  ok

>Use a 4 STATE recognizer; EXECUTE COMPILE, POSTPONE and EXPLAIN. It can 
>then provide an explanation if it recognises the string (and a LOCATEion 
>if that's appropriate).

TRACE-RECOGNIZER is just a hook in the recognizer handling, no extra
state necessary.  I am not sure if it is the right user interface in
most cases, however.  Maybe SEE should also be reocgnizer-aware, so
that the user can do

see 1

and gets information that 1 is recognized by REC:NUM, and maybe a
decompilation of REC:NUM; and similar for LOCATE and EDIT on those
systems that support them.

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

#51330

In article <2016Sep26.154334@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Alex <alex@rivadpm.com> writes:
>>On 26/09/16 10:12, Albert van der Horst wrote:
>>> In article <e8f43052-8ead-4025-b90b-72a2e2a505ca@googlegroups.com>,
>>>  <hughaguilar96@gmail.com> wrote:
>>>  <SNIP>
>>>> The problem with recognizers is that they don't allow the reader of the sou=
>>>> rce-code to look up words that he doesn't know. Usually, if you see a word =
>>>> that you don't know, then you can look it up with LOCATE or in a reference =
>>>> manual. You can't look up a recognizer-specific word however --- for exampl=
>>>> e, if you don't know what $BEAD means, how are you going to look it up?
>
>Well, $BEAD is already a "word" that is recognized by the standard,
>how do you look that up?  Or the "word" 1.

I hope it is not in the CORE set. This is what you get in lina64

 OK
 $BEAD
 $BEAD ? ciforth ERROR # 12 : NOT RECOGNIZED

 OK
 WANT $-PREFIX
# : ISN'T UNIQUE
$-PREFIX : (WARNING) NOT PRESENT, THOUGH WANTED
 OK
 $BEAD
 OK
 .
 48813  OK

>
>I am more of the school of thought of avoiding conflicting recognizers
>(at least not having them intentionally) and having tight recognizers

I agree with that. 7 is a recognizer in my book. There is a kind of
conflict here that 7 may be the prefix of a single or a double number.
That conflict is an internal affair in the word 7 itself.

>(that do recognizes only the minimal set of "words"), but Bernd Paysan
>embraces loose recognizers, conflicting recognizers, and letting thr
>priority order resolve conflicts.  In order to allow the user to sort
>out what's going on in puzzling cases, Bernd has added a trace
>facility to Gforth's recognizers; you can turn it on with
>
>' .name is trace-recognizer
>
>and it shows which recognizer is used for every recognized string.
>
>So when I write "1 .", it says
>
>1 . rec:num rec:word 1  ok
>
>So "1" is recognized by rec:num, and "." is recognized by rec:word;
>the rest is the usual output of interpreting "1 .".
>
>So, let's answer your question:
>
>$BEAD rec:num  ok
>
>>Use a 4 STATE recognizer; EXECUTE COMPILE, POSTPONE and EXPLAIN. It can
>>then provide an explanation if it recognises the string (and a LOCATEion
>>if that's appropriate).
>
>TRACE-RECOGNIZER is just a hook in the recognizer handling, no extra
>state necessary.  I am not sure if it is the right user interface in
>most cases, however.  Maybe SEE should also be reocgnizer-aware, so
>that the user can do
>
>see 1
>
>and gets information that 1 is recognized by REC:NUM, and maybe a
>decompilation of REC:NUM; and similar for LOCATE and EDIT on those
>systems that support them.

I've still 1 as a constant in the kernel.
The recognizer is only visible after hiding that.

 OK
 SEE 1

0000,0000,0000,0001 CONSTANT 1
 OK
 '1 HIDDEN
  OK
  SEE 1

: 1
FFFF,FFFF,FFFF,FFFF PP   +!   (NUMBER)   POSTPONE SDLITERAL
; IMMEDIATE  PREFIX
 OK

SEE 12
SEE 12 ? ciforth ERROR # 11 : WORD IS NOT FOUND

So in my book 12 is not a recognizer, it is a recognizee.
recognizees are not Forth words, because they are not in
the dictionary. SEE works on Forth words.

(Strange word recognizee, but the term denotation didn't catch on).

>
>- anton

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

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

#51293

On Sat, 24 Sep 2016 21:47:09 -0700 (PDT)
hughaguilar96@gmail.com wrote:

> I have a document started describing Straight Forth. I have two
> data-structures built-in (the array and the "chain"). The array is
> mostly for strings. I recommend that the chain be used for pretty
> much everything. 

Forth is criticized for all the stack manipulation.  C should be
criticized for professors over-emphasizing linked-lists and binary
trees.  What I've found over the years is that nearly every problem
that can be solved by using them, can be also be solved by using arrays
and LIFO stacks.  This takes far less coding and has less code overhead.
This produces faster code too since stacks are push/pop and arrays are
simply indexed.  There is no searching nor traversing of them.
Reworking the problem for this is much like finding the optimal stack
juggling solution in Forth.

> Previously, Bernd Paysan called me stupid because I use a binary tree
> rather than a hash-table, because a hash-table provides faster random
> access (given enough memory that it doesn't overflow into a mess of
> linked-lists).

Que?


Rod Pemberton

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

#51098

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/

(I tried to post this last night, unfortunately via google groups... the text box grayed out after clicking "post" and I assumed it was going to post it... came back this morning, it's still grayed out and not posted. Wow. The text isn't selectable, so I can't even copy and paste it here, I have to manually re-type it.)

I (relative noob here), in my silliness, think that if I were to think up a separate standard from ANS Forth, I would emphasize optional wordsets. One of the problems I've seen in the Lisp world (or at least, I think I've seen) is that often each implementation will provide useful capabilities outside of the standard, but with different names and interfaces and slightly different behavior. Consequently portability libraries had to be developed that abstract away the differences.

I guess what I'm trying to say is that it would be great to have standardized libraries. And by "libraries" I don't mean common abstractions that can be built using the core wordset like it seems a lot of other languages have, I mean a minimalist set of capabilities that couldn't be used portably otherwise - not even with a C interface, because that would only work on systems with that shared library. Optionally-included bare-minimum forth-style batteries, basically. And the core wordset could include a simple way to test whether optional wordsets are supported, which might vary not only based on implementation but also based on hardware ("how the heck am I supposed to use graphics without a display, or networking without any physical way to connect, or serial without any serial port..." etc). Perhaps this is a symptom of coming from languages where interaction with assembler is extremely uncommon (where being part of the language is often the entire difference between "works smoothly" and "almost impossible"), but having these capabilities be accessible in a standard way (or inaccessible in a standard way, for that matter) sounds really useful.

In short, what I'm trying to say is that it seems (I could be wrong, like I said, I'm a noob) like it's hard to handle non-portability portably. Different Forth implementations often have different goals, and the least we can do is have the Forths with similar capabilities present similar interfaces. To this end, I'd like more optional wordsets that may be more specialized and a way in the core wordset to query which wordsets the current implementation supports for simple compatibility matching. Sockets, graphics (even if it's just a common interface to openGL or Vulkan), I/O beyond just text (mouse? sound?), possible a C interface - these are the sort of things that are necessary in order to make generally useful programs (I love playing with algorithms and extending the language as much as anyone else, but at some point stuff needs to get done), and there should be a common way of using that functionality where it is available.

Am I off-base here? Is this contrary to the goals of the Forth community? Is this an irrelevant comment for the current discussion? Is the wall of text uncomfortably large? I don't know. I hope it's relevant. Thanks for taking the time to read!

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

#51099

On 9/18/2016 11:01 AM, anotherreepca@gmail.com wrote:
> 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/
>
> (I tried to post this last night, unfortunately via google groups... the text box grayed out after clicking "post" and I assumed it was going to post it... came back this morning, it's still grayed out and not posted. Wow. The text isn't selectable, so I can't even copy and paste it here, I have to manually re-type it.)
>
> I (relative noob here), in my silliness, think that if I were to think up a separate standard from ANS Forth, I would emphasize optional wordsets. One of the problems I've seen in the Lisp world (or at least, I think I've seen) is that often each implementation will provide useful capabilities outside of the standard, but with different names and interfaces and slightly different behavior. Consequently portability libraries had to be developed that abstract away the differences.
>
> I guess what I'm trying to say is that it would be great to have standardized libraries. And by "libraries" I don't mean common abstractions that can be built using the core wordset like it seems a lot of other languages have, I mean a minimalist set of capabilities that couldn't be used portably otherwise - not even with a C interface, because that would only work on systems with that shared library. Optionally-included bare-minimum forth-style batteries, basically. And the core wordset could include a simple way to test whether optional wordsets are supported, which might vary not only based on implementation but also based on hardware ("how the heck am I supposed to use graphics without a display, or networking without any physical way to connect, or serial without any serial port..." etc). Perhaps this is a symptom of coming from languages where interaction with assembler is extremely uncommon (where being part of the language is often the entire difference between "works smoothly" and "almost impossible"), but having these capabilities be accessible in a standard way (or inaccessible in a standard way, for that matter) sounds really useful.
>
> In short, what I'm trying to say is that it seems (I could be wrong, like I said, I'm a noob) like it's hard to handle non-portability portably. Different Forth implementations often have different goals, and the least we can do is have the Forths with similar capabilities present similar interfaces. To this end, I'd like more optional wordsets that may be more specialized and a way in the core wordset to query which wordsets the current implementation supports for simple compatibility matching. Sockets, graphics (even if it's just a common interface to openGL or Vulkan), I/O beyond just text (mouse? sound?), possible a C interface - these are the sort of things that are necessary in order to make generally useful programs (I love playing with algorithms and extending the language as much as anyone else, but at some point stuff needs to get done), and there should be a common way of using that functionality where it is available.
>
> Am I off-base here? Is this contrary to the goals of the Forth community? Is this an irrelevant comment for the current discussion? Is the wall of text uncomfortably large? I don't know. I hope it's relevant. Thanks for taking the time to read!
>
I'm by no means an expert but it seems that there are conflicting 
requirements for Forth but they are not unsolvable.

On the one hand some want Forth to be lean and mean, leaner that the 
Standard calls for this would be handy for embedded applications where 
one does not want any fluff that is above bare minimum, some also prefer 
a lean Forth for desktop applications simply because that is what they like.

The other option is Rolls Royce Forth for use with desktops where lots 
of resources are available and one could use more tools to make the 
writing of software easier.

There is something to be said by both cases and I would think with 
careful thought both classes of programming style can be accommodated. 
The present Standard allows for a Core and for additions to the core, 
that feature can be used to help both camps to be better pleased with Forth.

To make Forth leaner the core functions can be reduced to bare minimum, 
with additional optional word sets to build Forth to the level one 
desires, it could be lean, or it could be fat and juicy, or it could be 
something in-between, it would be up to the individual.

There are some items that would pose some issues such as type checking 
of variables but with careful though they might be possible to implement 
them while still retaining the ability to not have such a feature after 
all Forth allows words to be re-defined at ones pleasure.
-- 
Cecil - k5nwa

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

#51101

Am Sonntag, 18. September 2016 18:35:40 UTC+2 schrieb Cecil - k5nwa:
> On 9/18/2016 11:01 AM, anotherreepca@gmail.com wrote:
> > 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/
> >
> > (I tried to post this last night, unfortunately via google groups... the text box grayed out after clicking "post" and I assumed it was going to post it... came back this morning, it's still grayed out and not posted. Wow. The text isn't selectable, so I can't even copy and paste it here, I have to manually re-type it.)
> >
> > I (relative noob here), in my silliness, think that if I were to think up a separate standard from ANS Forth, I would emphasize optional wordsets. One of the problems I've seen in the Lisp world (or at least, I think I've seen) is that often each implementation will provide useful capabilities outside of the standard, but with different names and interfaces and slightly different behavior. Consequently portability libraries had to be developed that abstract away the differences.
> >
> > I guess what I'm trying to say is that it would be great to have standardized libraries. And by "libraries" I don't mean common abstractions that can be built using the core wordset like it seems a lot of other languages have, I mean a minimalist set of capabilities that couldn't be used portably otherwise - not even with a C interface, because that would only work on systems with that shared library. Optionally-included bare-minimum forth-style batteries, basically. And the core wordset could include a simple way to test whether optional wordsets are supported, which might vary not only based on implementation but also based on hardware ("how the heck am I supposed to use graphics without a display, or networking without any physical way to connect, or serial without any serial port..." etc). Perhaps this is a symptom of coming from languages where interaction with assembler is extremely uncommon (where being part of the language is often the entire difference between "works smoothly" and "almost impossible"), but having these capabilities be accessible in a standard way (or inaccessible in a standard way, for that matter) sounds really useful.
> >
> > In short, what I'm trying to say is that it seems (I could be wrong, like I said, I'm a noob) like it's hard to handle non-portability portably. Different Forth implementations often have different goals, and the least we can do is have the Forths with similar capabilities present similar interfaces. To this end, I'd like more optional wordsets that may be more specialized and a way in the core wordset to query which wordsets the current implementation supports for simple compatibility matching. Sockets, graphics (even if it's just a common interface to openGL or Vulkan), I/O beyond just text (mouse? sound?), possible a C interface - these are the sort of things that are necessary in order to make generally useful programs (I love playing with algorithms and extending the language as much as anyone else, but at some point stuff needs to get done), and there should be a common way of using that functionality where it is available.
> >
> > Am I off-base here? Is this contrary to the goals of the Forth community? Is this an irrelevant comment for the current discussion? Is the wall of text uncomfortably large? I don't know. I hope it's relevant. Thanks for taking the time to read!
> >
> I'm by no means an expert but it seems that there are conflicting 
> requirements for Forth but they are not unsolvable.
> 
> On the one hand some want Forth to be lean and mean, leaner that the 
> Standard calls for this would be handy for embedded applications where 
> one does not want any fluff that is above bare minimum, some also prefer 
> a lean Forth for desktop applications simply because that is what they like.
> 

Not to forget those who think Forth is a compiler, while otheres like it to be a "system", and then the fraction of DSL enthusiasts.

But the most important issue is: why standardize a half-dead horse?

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

#51106

minforth@arcor.de wrote:
>
> Not to forget those who think Forth is a compiler, while otheres
> like it to be a "system", and then the fraction of DSL enthusiasts.

Is anyone who knows Forth crazy enough to describe it as merely "a
compiler?"  Of course, it is often a whole system and sometimes runs
atop some OS.  And right from the get go, Forth has always been about
creating a domain-specific language: Chuck Moore originally called
Forth programming as creating a "Problem-Oriented-Language".

> But the most important issue is: why standardize a half-dead horse?

Eh?  Is this flamebait, or is there a real question?

Andrew.

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

#51116

Am Montag, 19. September 2016 16:49:19 UTC+2 schrieb Andrew Haley:
> minforth@arcor.de wrote
> > But the most important issue is: why standardize a half-dead horse?
> 
> Eh?  Is this flamebait, or is there a real question?
> 
> Andrew.

No and yes.  ;-) Forth

a) lacks mass and momentum i.e. the user base is so small that standardization seems a microscopic endeavour

b) by its nature Forth embraces flexibility - however standardization can be countereffective to flexibility   

Please understand me correctly: I do not want to belittle the work and love others are putting into new standards. But I'd rather prefer to see more new features instead of decades old repetitions.

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

#51133

minforth@arcor.de wrote:
> Am Montag, 19. September 2016 16:49:19 UTC+2 schrieb Andrew Haley:
>> minforth@arcor.de wrote
>> > But the most important issue is: why standardize a half-dead horse?
>> 
>> Eh?  Is this flamebait, or is there a real question?
> 
> No and yes.  ;-) Forth
> 
> a) lacks mass and momentum i.e. the user base is so small that
> standardization seems a microscopic endeavour

There are real users, and it is an interesting language.  I think it's
worth the effort.  Not every worthwhile language has ten million
developers.

> b) by its nature Forth embraces flexibility - however
> standardization can be countereffective to flexibility

I don't believe that at all.  In fact, I'm sure that is nonsense.
There is no way that having a standard small language core can
possibly adversely affect flexibility.  This is obviously true, given
that any system developer can take or leave any standard language
features.

> Please understand me correctly: I do not want to belittle the work
> and love others are putting into new standards. But I'd rather
> prefer to see more new features instead of decades old repetitions.

Standardization is not language design.  They are separate (but
related) activities.

Andrew.

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

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

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

csiph-web