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

#51136

On Wednesday, September 21, 2016 at 4:23:26 AM UTC+12, Andrew Haley wrote:
> Not every worthwhile language has ten million
> developers.

What is the ratio of people doing things with the language, to those coming up with yet another implementation of the language?

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

#51142

In article <b0d05878-6616-4349-af44-4cd03b214322@googlegroups.com>,
 <lawrencedo99@gmail.com> wrote:
>On Wednesday, September 21, 2016 at 4:23:26 AM UTC+12, Andrew Haley wrote:
>> Not every worthwhile language has ten million
>> developers.
>
>What is the ratio of people doing things with the language, to those coming up with yet another implementation of the language?

Let's hope that those coming up with implementations, also do things
with the language ...
Anyway, at a certain point the board of the Dutch Forth consists of
5 persons. I was the last among them to build my own Forth.
The percentage of Forthers that build their own compiler is probably
larger than for most languages, except maybe Lisp.

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]

#51138

On Tuesday, September 20, 2016 at 9:23:26 AM UTC-7, Andrew Haley wrote:
> 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.

Andrew Haley is an employee of Forth Inc. and so Elizabeth Rather appointed him to the Forth-200x committee --- he has no purpose except to vote as his boss at Forth Inc. tells him to vote --- he doesn't think for himself.

This 10,000,000 figure is indicative of Andrew Haley's delusions of grandeur regarding his own importance --- he fantasizes about having millions of followers depending upon the Forth-200x committee to provide them with a standard --- he doesn't want to face the truth that ANS-Forth (and now Forth-200x) are just a marketing gimmick from Forth Inc. and that nobody has ever written a commercial ANS-Forth program (for example, Stephen Pelc routinely abandons ANS-Forth and makes all of his software VFX-specific).

I would estimate that there are 200 to 400 Forth programmers in the world.

There are about 20 ANS-Forth programmers in the world, and all of them are on the Forth-200x mailing list braying about how they set the standard for Forth that 10 million Forth programmers depend upon --- none of them are actually writing Forth programs --- most of them know little or nothing about computer programming.

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

The problem with ANS-Forth is not that it has too small of a core. I say that ANS-Forth is at least twice as big as necessary. ANS-Forth has a lot of redundancy, such as having both VALUE and VARIABLE that do the same thing, and this causes confusion among novices because they don't know which they should use. In Straight Forth I get rid of TO and VALUE (and also get rid of TO for local variables) and use @ and ! throughout for consistency. I also get rid of DO loops and use BEGIN WHILE REPEAT throughout for consistency. I also get rid of UNTIL which is yet more cruft. A lot of this cruft was introduced in the 1970s when optimizing compilers weren't available. Now a compiler should be smart enought to notice that WHILE and REPEAT don't have any code between them, and compile the code efficiently --- in the 1970s compilers weren't this smart and it was necessary to provide UNTIL (in those days, every source-code word compiled into threaded-code word one-to-one). Similarly, I get rid of AGAIN --- I allow any number of WHILE to be between the BEGIN and REPEAT, so if you have no WHILE in there then you effectively have an infinite loop (typically exited with EXIT).

The problem with ANS-Forth is that it was written by a sales-person who has never written a Forth program in her life and whose only programming experience was in COBOL --- if you want to have "mass and momentum" you have to have a standard written by actual Forth programmers --- this is my goal with Straight Forth, and is why I solicit input on the design from Forth programmers (so far the only input I've gotten is for the ANS-Forth cult members to say that my Forth code is "crap" and "sucks").

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

That isn't true. ANS-Forth was full of new "features" (arguably "bugs" would be a better term) that had never been seen before in any previous Forth. 

For example, ANS-Forth has a very bizarre construct in which THEN can be used after a BEGIN WHILE REPEAT loop and will match up with the WHILE inside. Perhaps later a doctor with a flashlight can show us where this idea came from.

ANS-Forth has LOCAL| for defining local variables. The names of the locals are listed backwards though! Obviously, nobody ever tested this before they put it into the ANS-Forth standard document and shipped the document off to ANSI to be rubber-stamped --- even one day of testing would have been adequate to reveal that the names were backwards --- the reason why nobody tested ANS-Forth in 1994 is that no ANS-Forth compiler existed until 1997 (that was SwiftForth which was so bug-ridden as to be unuable; it wasn't until many years later that a usable ANS-Forth compiler was written).

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

#51108

On Sunday, September 18, 2016 at 5:35:40 PM UTC+1, Cecil - k5nwa wrote:
> 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

Cecil, on a completely other front ( like regarding Novix ): as you know I am CDP1802. 
There will be a free implementation for FPGA on github this year in VHDL. 
As such, my BMP802 will be more interesting for people. 
Any chance you run the BMP802 through your  system so I can update the book with ASCII as you suggested for Ting's Footsteps ?  At 12 MB it is a bit large and could look a lot better in ASCII. See http://www.exemark.com/Microcontrollers/BMP802.pdf

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

#51111

On 9/19/2016 12:12 PM, JUERGEN wrote:
>
>> 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
>
> Cecil, on a completely other front ( like regarding Novix ): as you know I am CDP1802.
> There will be a free implementation for FPGA on github this year in VHDL.
> As such, my BMP802 will be more interesting for people.
> Any chance you run the BMP802 through your  system so I can update the book with ASCII as you suggested for Ting's Footsteps ?  At 12 MB it is a bit large and could look a lot better in ASCII. See http://www.exemark.com/Microcontrollers/BMP802.pdf
>

Thanks for the manual.

I am very interested in the Novix 4016 and the RTX2000 to that end I was 
willing to create a computer readable text version of the Footsteps 
book, I have a book copy now, and hopefully soon I will have a up to 
date electronic version to hand back to Dr Ting. It turns out to be a 
horrendous amount of work so I took a lot more than what I can chew, but 
we will try it anyway.

I do have some interest in the CDP1802 CPU also but not as high as the 
Novix 4016 and the RTX 2000, so I will be interested in a VHDL version 
when available but at this point I'm not ready to commit to re-type 
another book as it's a lot harder than anticipated. Maybe later  I might 
get interested but right now I have too many projects going on.
-- 
Cecil - k5nwa

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

#51147

On Sun, 18 Sep 2016 09:01:46 -0700 (PDT), anotherreepca@gmail.com
wrote:

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

All the wordsets in the Forth-2012 are optional. If you want to
provide them, you can even supply them as source code. This has been
true for at least 20 years now.

>I guess what I'm trying to say is that it would be great to have standardiz=
>ed 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 ot=
>herwise - not even with a C interface, because that would only work on syst=
>ems with that shared library. 

Source libraries and experimental proposals were discussed at the
standards meeting in Reichenau on September 9-11, 2016. They will
appear. See
  http://theForth.net
  http://forth-standard.org
  http://www.forth200x.org/

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]

#51103

In article <2016Sep15.161930@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> 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.

I'm sympathetic to that idea. With 64 bit systems in mind we could
get rid of some cruft.
This is a setup for the 202x standard

- unsigned numbers can go, or at least must be banned to an
   optional wordset
- double numbers can go, or at least must be banned equally.
  As part of this, only one non-obsolescent notation for doubles
  remains: a point before *and* after a number, like so
  .340282366920938463463374607431768211455.
  This notation must not be mixed with any other prefix, or recognizer
  shit, just the current BASE, that's it.
- related to this, number formatting must be cleaned up to
  use only signed single precision numbers. All # stuff banned to the
  double wordset. %-words can be used instead. We must have something
  like that for floats.
- only one floating point wordset with an "implementation defined" precision,
  which soon will be 256 bits.
- >IN must be replaced by a handle that abstracts the position
   in the input stream. UNFILL replaces the idiom `` 0 >IN ! ''
- The normal casing of Forth words becomes lower case.
  ISO Forth words must be recognized if in all upper case.
- Embracing bytes (address units) as the basic storage units.
  All c-cruft must go, that refers to characters where we want bytes.
  The following words become byte-based
     B@ (or we could keep C@)
     B! (or we could keep C!)
     ERASE FILL MOVE  (maybe BLANKs)
     new : CORA (compare two byte areas)
           EXCHANGE (exchange areas over a byte length)
   Dictionary search becomes byte based, hence language
   dependancy is restricted to screen views
   So if I talk to a chinese forth I can build a string using
   c"\67~_\A0\90" and it will find it. (that is the chinese
   character for DROP, by the way).   1]
   (c" is cooked string, " is literal).

I hope this doesn't look like I'm promoting yourforth. It is just
that I've been experimenting there.

>- anton

1] Just kidding.
-- 
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]

#51105

On Monday, September 19, 2016 at 7:20:11 AM UTC-4, Albert van der Horst wrote:
> In article <2016Sep15.161930@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> 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.
> 
> I'm sympathetic to that idea. With 64 bit systems in mind we could
> get rid of some cruft.
> This is a setup for the 202x standard
> 
> - unsigned numbers can go, or at least must be banned to an
>    optional wordset
> - double numbers can go, or at least must be banned equally.
>   As part of this, only one non-obsolescent notation for doubles
>   remains: a point before *and* after a number, like so
>   .340282366920938463463374607431768211455.
>   This notation must not be mixed with any other prefix, or recognizer
>   shit, just the current BASE, that's it.
> - related to this, number formatting must be cleaned up to
>   use only signed single precision numbers. All # stuff banned to the
>   double wordset. %-words can be used instead. We must have something
>   like that for floats.
> - only one floating point wordset with an "implementation defined" precision,
>   which soon will be 256 bits.
> - >IN must be replaced by a handle that abstracts the position
>    in the input stream. UNFILL replaces the idiom `` 0 >IN ! ''
> - The normal casing of Forth words becomes lower case.
>   ISO Forth words must be recognized if in all upper case.
> - Embracing bytes (address units) as the basic storage units.
>   All c-cruft must go, that refers to characters where we want bytes.
>   The following words become byte-based
>      B@ (or we could keep C@)
>      B! (or we could keep C!)
>      ERASE FILL MOVE  (maybe BLANKs)
>      new : CORA (compare two byte areas)
>            EXCHANGE (exchange areas over a byte length)
>    Dictionary search becomes byte based, hence language
>    dependancy is restricted to screen views
>    So if I talk to a chinese forth I can build a string using
>    c"\67~_\A0\90" and it will find it. (that is the chinese
>    character for DROP, by the way).   1]
>    (c" is cooked string, " is literal).
> 
> I hope this doesn't look like I'm promoting yourforth. It is just
> that I've been experimenting there.
> 
> >- anton
> 
> 1] Just kidding.
> -- 
> 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

An idea I have been toying with is that a minimalist Forth system should have a standard way to be extended.  We have never specified in detail the order of "includes" that one should expect to work correctly. (as far as I know)

So starting from some "standard" minimal system, what file can I next load that will give me the next "level" of Forth and so on.

I guess I am asking for some system level standards as well as language internals standards.

In other words, can we specify how to move to a higher levels of functionality in a standard way so that after including a set number of "standard" files, "myForth" has the same words as "yourforth" so to speak.  Dependancies could still be stated (word size, memory allocations etc) but at least a programmer would know the words that she has at her disposal and that stack arguments are consistent for those words.


BF

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

#51110

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>- Embracing bytes (address units) as the basic storage units.
>  All c-cruft must go, that refers to characters where we want bytes.
>  The following words become byte-based
>     B@ (or we could keep C@)
>     B! (or we could keep C!)
>     ERASE FILL MOVE  (maybe BLANKs)
>     new : CORA (compare two byte areas)
>           EXCHANGE (exchange areas over a byte length)
>   Dictionary search becomes byte based, hence language
>   dependancy is restricted to screen views
>   So if I talk to a chinese forth I can build a string using
>   c"\67~_\A0\90" and it will find it. (that is the chinese
>   character for DROP, by the way).   1]
>   (c" is cooked string, " is literal).

That's pretty much already there.  1 chars = 1, for comparing two
blocks of address units/chars, you can use COMPARE; dictionary search
is now address-unit based, and you can build a string using
s\" \x67~_\xA0\x90"; or you can just write the Chinese character you
are interested in directly in S"; that will be no less readable to
those who don't read Chinese, and more readable to those who can.

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

#51143

On Thursday, September 15, 2016 at 8:24:49 PM UTC+3, 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/

Hi!

Maybe lack of (domestic use of) continuations?
Is something very basic, that could be useful,
as  stack of continuations provides subroutines,
and queue of continuations provides  coroutines.

Have a nice day,
humptydumpty

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

#51152

humptydumpty <ouatubi@gmail.com> writes:
>Hi!
>
>Maybe lack of (domestic use of) continuations?
>Is something very basic, that could be useful,
>as  stack of continuations provides subroutines,
>and queue of continuations provides  coroutines.

Do you mean return-address manipulations (I have noticed that you use
"continuation" to mean one return address, whereas in general usage
the term means much more)?

The main problem with return-address manipulations is that they don't
combine well with locals.  So if you want to standardize them, you
either have to de-standardize locals, or you create a bunch of
ambiguous conditions when return-address manipulations are combined
with locals.  Both are not very likely to find consensus.

Is a "next standard" without locals and with return-address
manipulation likely to find widespread acceptance?  I doubt it, but I
may be wrong.

What else could be done?  Instead of return-address manipulations,
something closer to the general concept of continuations could be
created; the general concept includes the whole program state, and is
hard to implement in Forth.  But something more in the Forth tradition
is tasks (which include only the stacks and the user variable).

By transferring control (and data) between two tasks, you get
coroutines, and more general ones than available by just changing one
return address (e.g., the two coroutines can each traverse a tree
recursively, with different tree structures).

There is a subcommittee working on multi-tasking, but from what I
overheard from them, the present idea is to have traditional
statically allocated and named Forth tasks, not dynamically created
tasks.  But that's still subject to change.

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

#51177

On Wednesday, September 21, 2016 at 7:39:26 AM UTC-7, Anton Ertl wrote:
> humptydumpty <ouatubi@gmail.com> writes:
> >Hi!
> >
> >Maybe lack of (domestic use of) continuations?
> >Is something very basic, that could be useful,
> >as  stack of continuations provides subroutines,
> >and queue of continuations provides  coroutines.
> 
> Do you mean return-address manipulations (I have noticed that you use
> "continuation" to mean one return address, whereas in general usage
> the term means much more)?
> 
> The main problem with return-address manipulations is that they don't
> combine well with locals.  So if you want to standardize them, you
> either have to de-standardize locals, or you create a bunch of
> ambiguous conditions when return-address manipulations are combined
> with locals.  Both are not very likely to find consensus.
> 
> Is a "next standard" without locals and with return-address
> manipulation likely to find widespread acceptance?  I doubt it, but I
> may be wrong.

My rquotations (a slightly upgraded version of HumptyDumpty's rquotations) work fine with locals. The rule is that the hof has to have local variables (HumptyDumpty's rule was that the hof was not allowed to have local variables) --- my rule is better because you usually want the hof to have local variables (because you need to hold the xt in a local out of the way while doing the iteration which is typically a BEGIN WHILE REPEAT loop).

Most of the complaints about rquotations come from people who don't understand how they work --- just a lot of hand-wringing and: "OMG! This can't possibly work! This should be banned because I don't understand it!" --- I didn't understand how HumptyDumpty's rquotations worked either at first, and it took me a couple of hours of thinking to figure them out, and now I consider them to be pretty awesome.

Thinking is the key to understanding stuff!

> What else could be done?  Instead of return-address manipulations,
> something closer to the general concept of continuations could be
> created; the general concept includes the whole program state, and is
> hard to implement in Forth.  But something more in the Forth tradition
> is tasks (which include only the stacks and the user variable).
> 
> By transferring control (and data) between two tasks, you get
> coroutines, and more general ones than available by just changing one
> return address (e.g., the two coroutines can each traverse a tree
> recursively, with different tree structures).
> 
> There is a subcommittee working on multi-tasking, but from what I
> overheard from them, the present idea is to have traditional
> statically allocated and named Forth tasks, not dynamically created
> tasks.  But that's still subject to change.

P.S. for HumptyDumpty --- do you know Icon?

I know Icon somewhat, but I haven't played with that in 20 years --- I intend to get back into that again, for the purpose of possibly implementing something similar in Straight Forth.

Since you seem to be big on continuations, I would definitely be interested in your input on the subject. The reason I talk about Straight Forth but don't release it, is because I want input on the design --- I don't want to be like Elizabeth Rather and say: "Here is a language design that has never been tested, but it is now written in stone and can never be changed, and everybody must follow it or be non-standard." My name is not Moses --- I'm not bring Straight Forth down from the mountain --- I want Straight Forth to be a grassroots effort.

I have a document started that describes Straight Forth. It is not complete, and is very much in flux. If anybody wants to read what I have so far, I can email it.  

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

#51188

On Thursday, September 22, 2016 at 9:41:05 PM UTC+3, hughag...@gmail.com wrote:
> On Wednesday, September 21, 2016 at 7:39:26 AM UTC-7, Anton Ertl wrote:
> > humptydumpty writes:
> > >Hi!
> > >
> > >Maybe lack of (domestic use of) continuations?
> > >Is something very basic, that could be useful,
> > >as  stack of continuations provides subroutines,
> > >and queue of continuations provides  coroutines.
> > 
> > Do you mean return-address manipulations (I have noticed that you use
> > "continuation" to mean one return address, whereas in general usage
> > the term means much more)?
> > 
> > The main problem with return-address manipulations is that they don't
> > combine well with locals.  So if you want to standardize them, you
> > either have to de-standardize locals, or you create a bunch of
> > ambiguous conditions when return-address manipulations are combined
> > with locals.  Both are not very likely to find consensus.
> > 
> > Is a "next standard" without locals and with return-address
> > manipulation likely to find widespread acceptance?  I doubt it, but I
> > may be wrong.
> 
> My rquotations (a slightly upgraded version of HumptyDumpty's rquotations) work fine with locals. The rule is that the hof has to have local variables (HumptyDumpty's rule was that the hof was not allowed to have local variables) --- my rule is better because you usually want the hof to have local variables (because you need to hold the xt in a local out of the way while doing the iteration which is typically a BEGIN WHILE REPEAT loop).
> 
> Most of the complaints about rquotations come from people who don't understand how they work --- just a lot of hand-wringing and: "OMG! This can't possibly work! This should be banned because I don't understand it!" --- I didn't understand how HumptyDumpty's rquotations worked either at first, and it took me a couple of hours of thinking to figure them out, and now I consider them to be pretty awesome.
> 
> Thinking is the key to understanding stuff!
> 
> > What else could be done?  Instead of return-address manipulations,
> > something closer to the general concept of continuations could be
> > created; the general concept includes the whole program state, and is
> > hard to implement in Forth.  But something more in the Forth tradition
> > is tasks (which include only the stacks and the user variable).
> > 
> > By transferring control (and data) between two tasks, you get
> > coroutines, and more general ones than available by just changing one
> > return address (e.g., the two coroutines can each traverse a tree
> > recursively, with different tree structures).
> > 
> > There is a subcommittee working on multi-tasking, but from what I
> > overheard from them, the present idea is to have traditional
> > statically allocated and named Forth tasks, not dynamically created
> > tasks.  But that's still subject to change.
> 
> P.S. for HumptyDumpty --- do you know Icon?
> 
> I know Icon somewhat, but I haven't played with that in 20 years --- I intend to get back into that again, for the purpose of possibly implementing something similar in Straight Forth.
> 
> Since you seem to be big on continuations, I would definitely be interested in your input on the subject. The reason I talk about Straight Forth but don't release it, is because I want input on the design --- I don't want to be like Elizabeth Rather and say: "Here is a language design that has never been tested, but it is now written in stone and can never be changed, and everybody must follow it or be non-standard." My name is not Moses --- I'm not bring Straight Forth down from the mountain --- I want Straight Forth to be a grassroots effort.
> 
> I have a document started that describes Straight Forth. It is not complete, and is very much in flux. If anybody wants to read what I have so far, I can email it.

Hi!

I don't know Icon. I was interested on Icon, had some lectures from
an Icon book.  Very interesting, but no more than Forth :)

Somehow I'm interested to know of Forth, from much basic concepts.

Have a nice day,
humptydumpty

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

#51187

On Wednesday, September 21, 2016 at 5:39:26 PM UTC+3, Anton Ertl wrote:
> humptydumpty writes:
> >Hi!
> >
> >Maybe lack of (domestic use of) continuations?
> >Is something very basic, that could be useful,
> >as  stack of continuations provides subroutines,
> >and queue of continuations provides  coroutines.
> 
> Do you mean return-address manipulations (I have noticed that you use
> "continuation" to mean one return address, whereas in general usage
> the term means much more)?
> 

Hi!

I think that Andrew Read title "An axiomatic approach to Forth" give
an insight that concepts that compose "forth axioms" should not be
formulated in Forth terms.  To be safe, I'll put here on not
computer related terms, but somehow in a intuitive way.

Let here be a imaginary dictionary book and suppose I search definition
of "Word", whose entry looks like:

    Word : word0 word1 .. wordN ; 

Now suppose that I don't know what "word0" means.
I'll put bookmark  (near as possible to hinge of dictionary, 
                      with condition to not shadow earlier placed bookmarks)
on *continuation* of "word0" inside definition of "Word"
( sequence "word1 .. wordN" till ";" ) and go search for "word0".

When done understanding "word0" ( hit "word0" end-of-definition ";" )
I'll return to continuation on last-bookmark (far away from hinge),
clean-up and put away that bookmark.

At a given time, this ordered set of bookmarks (by distance from
book hinge) is a stack of continuations.

Digression:
Dictionary book compress knowledge in limited number of files,
as factored subroutines compress "actions" in limited memory.

Now, back to Forth, an return address is an unique identifier for
a continuation.


> The main problem with return-address manipulations is that they don't
> combine well with locals.  So if you want to standardize them, you
> either have to de-standardize locals, or you create a bunch of
> ambiguous conditions when return-address manipulations are combined
> with locals.  Both are not very likely to find consensus.
> 

Now, only I could think of a stack of locals that somehow synchronizes
with return stack, for automatic de-allocation (question:
is automatic de-allocation worth to complexify things? ).

> Is a "next standard" without locals and with return-address
> manipulation likely to find widespread acceptance?  I doubt it, but I
> may be wrong.
> 
> What else could be done?  Instead of return-address manipulations,
> something closer to the general concept of continuations could be
> created; the general concept includes the whole program state, and is
> hard to implement in Forth.  But something more in the Forth tradition
> is tasks (which include only the stacks and the user variable).
> 


> By transferring control (and data) between two tasks, you get
> coroutines, and more general ones than available by just changing one
> return address (e.g., the two coroutines can each traverse a tree
> recursively, with different tree structures).
> 

I looked over "tasker.fs"; for me is a bit overhead to think coroutines
in terms of tasks.  Intuitively, for me is straightforward to say
"put this continuation to wait its turn and continue with whatever
is first on queue".
Provided '>co' which put into a circular queue and 'co>' which retrive it,
coroutines could be provided with:
: co-start	  co> >R ;
: 0CO	( -- )	  CQ Head ! CQ Tail ! ;   \ init circular queue
: CO:	( -- )	  R> >co ;   \ register into coroutines queue
: CO	( -- )	  R> >co co> >R ;   \ coroute
: GO	( -- )	  BEGIN Head @ Tail @ <> WHILE co-start REPEAT ;  \ squeeze out

I'm interested of such example where two coroutines can each traverse a tree
recursively, with different tree structures.


> There is a subcommittee working on multi-tasking, but from what I
> overheard from them, the present idea is to have traditional
> statically allocated and named Forth tasks, not dynamically created
> tasks.  But that's still subject to change.
> 
> - 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/

Have a nice day,
humptydumpty

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

#51207

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> At EuroForth Andrew Read gave an impromptu talk where he suggested a
> next-standard effort that would not be shackled by

Are there any slides or video about this?

> the talk got me thinking about what is essential in the current line
> of Forth standards 

I'd be interested in your thoughts about what is essential in the
current line of Forth standards, and which parts if any of that are NOT
essential to a (subjective) higher-level concept of what Forth is.

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

Is it really just syntax?  I don't really understand how Colorforth
works but I gather that it separates "edit time" from "compile time"
much more than traditional or ANS Forth does.  Also its treatment of
macros (black words) seems different, though I don't know exactly how.
I've been wondering about this.

> Pretty essential: Statically determined stack depth: Requiring that,
> as sketched for PAF, 

At that point maybe you want to depart from Forth tradition and have
named stack slots (ouch!).  I do think dynamic stack effects (while
misused sometimes) have valid uses, like variable sized arg lists, e.g.

   : foo ( a1 a2 .. an n -- ) ...     \ n is # of args

Most languages have some mechanism for that, such as varargs in C etc.

Also, do you want for conforming implementations to actually enforce
this rule?  Overall it sounds like a difficult sell even though PAF and
other compilers would benefit from it.

> Static type checking: StrongForth did that

This also seems like a hard sell, since StrongForth didn't get much
traction.  It also sounds harder to implement than traditional Forth.
Do you really think of it as essential?  

> 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). 

No please don't do that ;-).  It's one of the fail points of Javascript
and older versions of Lua and maybe others as well.  And users of low
level languages like Forth will often expect to be able to twiddle the
bits in cells.

> Dynamically typed stack items (e.g., Factor, 8th, Oforth,...)

I wonder how many users of those systems actually started out as Forth
users.  I haven't tried them since I lump them with other dynamic
languages such as Python, so their attractiveness mostly comes from
features like GUI toolkit integration, which I haven't needed so far.
If Forth users are actually willing to try this approach, it might be a
good way to move the community forward.

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.

Meanwhile some other imho essentials missing from your list: 1) design
changes to accomodate processors with flash program storage, 2) changes
to accomodate cross-compilation, 3, 4...) (forgot).

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

#51240

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> At EuroForth Andrew Read gave an impromptu talk where he suggested a
>> next-standard effort that would not be shackled by
>
>Are there any slides or video about this?

IIRC he used the flip chart, but in any case I have no electronic
slides.  There may be a video, the videos have not been published yet.

>> the talk got me thinking about what is essential in the current line
>> of Forth standards 
>
>I'd be interested in your thoughts about what is essential in the
>current line of Forth standards, and which parts if any of that are NOT
>essential to a (subjective) higher-level concept of what Forth is.

My original posting was an exploration of that.  My conclusion is that
the lines are not as clearly drawn as I thought before: 

For the standard, the issue is not so much what is essential, but
what finds consensus, and how long it takes and how much work it takes
to change it.  In theory, we could move almost everywhere.  In
practice, we hardly move at all.

But does that mean there should be a "next-standard" effort that goes
where it is too hard to reach with the current standards effort?  I
have my doubts that there will be consensus on such a next standard.
How much commonality is there among systems that do not follow the
standard?  And would the implementors of these systems really be
interested in finding consensus on a next standard?

I think that a Turbo-Pascal like effect is more likely: While the
Pascal standard was pretty limited, and it took until 1990 to publish
the "Extended Pascal" standard, Turbo Pascal added all the features
its designers considered useful, without letting themselves be
shackled by the Pascal standard, and became the dominant Pascal
implementation in terms of percentage of written code and installed
systems, making the Pascal standards irrelevant.  So, if a Forth
system manages to grab a large percentage of the Forth market, that
would be the "next standard".

Which parts of the standard are not essential?  Lots; machine Forth is
a Forth, and it has little in common with the standard.  I did not
consider systems with any form of type checking to be "Forth" before
starting this thread, but now this does not seem so clear-cut to me.

>> 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 ...
>
>Is it really just syntax?  I don't really understand how Colorforth
>works but I gather that it separates "edit time" from "compile time"
>much more than traditional or ANS Forth does.

Yes, I dimly remember something along these lines; I am not sure that
that really makes a fundamental difference.

By contrast, I found Holon/HolonForth's approach does take away some
features that I consider fundamental in Forth, while also providing
cool features (Wolf Wejgaard gave a nice presentation at EuroForth).
In Holon the dictionary is constructed at edit time, and the source
code and executable code hangs from the dictionary, which is
browsable.

An important (IMO) Forth feature Holon takes away is the ability to
create words at run-time.

>> Pretty essential: Statically determined stack depth: Requiring that,
>> as sketched for PAF, 
>
>At that point maybe you want to depart from Forth tradition and have
>named stack slots (ouch!).

Actually Glass [glass83] proposed this 30 years ago, and it has a
certain cuteness, but I don't see any benefits over removing them from
the data stack.  For PAF, for which both stack items and locals are
just pseudo-registers, there is little difference, and for the
programmer, it means that he has a hard time accessing stack items
lower on the stack than the locals.

@InCollection{glass83,
  author = 	"Harvey Glass",
  title = 	"Towards a More Writable {Forth} Syntax",
  crossref =	"ouverson86",
  chapter = 	"21",
  pages = 	"169--181",
  note = 	"Reprinted from {\em Proceedings of the 1983 Rochester
		 Forth Applications Conference}"
}
@Book{ouverson86,
  booktitle = 	 {Dr.\ Dobb's Toolbook of Forth},
  publisher = 	 {M\&T Books},
  year = 	 {1986},
  editor =	 {Marlin Ouverson},
  address =	 {Redwood City, CA 94063}
}

>I do think dynamic stack effects (while
>misused sometimes) have valid uses, like variable sized arg lists, e.g.
>
>   : foo ( a1 a2 .. an n -- ) ...     \ n is # of args
>
>Most languages have some mechanism for that, such as varargs in C etc.

And they cause complications and external costs in the calling
convention.

There are uses for that kind of stuff, but they are rare and can be
avoided without too much effort.  If avoiding it did cost too much, I
would add the common patterns to PAF; basically a sequence like
"a1...an n" would be treated as one stack item, allowing the rest of
the stack to be handled statically.

>Also, do you want for conforming implementations to actually enforce
>this rule?  Overall it sounds like a difficult sell even though PAF and
>other compilers would benefit from it.

A PAF-only compiler should produce an error message on such code,
because it cannot produce the machine code that does what the
programmer expects.  If a compiler is extended from PAF to Forth, it
would generate code that does what the programmer expects, and such a
compiler would either produce a warning (in PAF mode) or be quiet (in
Forth mode) when encountering such code.

It may be a hard sell to Forth programmers (not very hard, though,
IMO), but the idea of PAF is not as a replacement for Forth, but as an
intermediate language for compilers; and the compiler writers will not
find it at all hard to comply with these restrictions; the hard sell
to them will be to sell them a Forth-like language.

>> Static type checking: StrongForth did that
>
>This also seems like a hard sell, since StrongForth didn't get much
>traction.  It also sounds harder to implement than traditional Forth.
>Do you really think of it as essential?  

Obviously not, or I would have worked on it more, and maybe used
StrongForth.

The question was if the "weak"ness of standard Forth is essential.
Before to original posting, I thought so, but, depending on the type
system, this is just a step further in the Forth->PAF progression.
The problem is actually defining a type system that catches most/all
of the things that Forth programmers consider a type error, but does
not or only rarely annoys programmers with false positives.  It may be
an issue of the programmer and the type system getting used to each
other (the Stockholm syndrome seems to be very common in these kinds
of situations).

>> 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). 
>
>No please don't do that ;-).  It's one of the fail points of Javascript
>and older versions of Lua and maybe others as well.

Lua went away from that?  Interesting.  What's the story behind that?

>> Dynamically typed stack items (e.g., Factor, 8th, Oforth,...)
>
>I wonder how many users of those systems actually started out as Forth
>users.

Does it matter?  If these systems attract new users to the family of
Forth-like languages, is that bad?

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

>Meanwhile some other imho essentials missing from your list: 1) design
>changes to accomodate processors with flash program storage,

Does not appear too hard to me and reachable within the standard
framework, at least in theory.  In practice people who used to
complain about the problems CREATE DOES> causes in this regard have
apparently given up or are content to have found workarounds for the
problems.

> 2) changes
>to accomodate cross-compilation

I think that cross-compilation and the hard compilation/run-time
boundary it requires destroys an essential property of Forth, but
that's a minority position.  Anyway, many systems have some form of
cross compilation, but there does not seem to be consensus on a common
approach.  And apparently there is still enough movement in this area
that the existing cross-compilation proposal is now deemed outdated by
its proponents, and dropped from the standardization effort.

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

#51243

> 
> For the standard, the issue is not so much what is essential, but
> what finds consensus, and how long it takes and how much work it takes
> to change it.  In theory, we could move almost everywhere.  In
> practice, we hardly move at all.

I think that's the consequence of the design principle of the Forth
standard process: codify existing practice and consolidate it. Other
standard bodies follow a different approach: define something and declare
it standard, or standard extension. E.g. the WLAN or Ethernet standards
follow this model. First you get the specs, the implementation follows.

Forth could use both. There is a core feature set like the stacks, some words (in CORE) and the interpreter/compile model, and there are a number of extension wordsets. These extension wordsets could be managed more freely than the core.

No, I'm not complaining about the quotations or recognizers beeing discussed so badly. Or the object models. But they are a good example that the community will hardly reach "consensus before standardization" and progress is no longer possible. In such situations many forks happen. Strongforth, oforth or factor or or. All of them are nice and find their followers. They follow the TurboPascal model, hopefully with better luck. But converging them back to a common Forth base seems unlikely.

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

#51269

Matthias Trute <matthias.trute@gmail.com> wrote:
>> 
>> For the standard, the issue is not so much what is essential, but
>> what finds consensus, and how long it takes and how much work it takes
>> to change it.  In theory, we could move almost everywhere.  In
>> practice, we hardly move at all.
> 
> I think that's the consequence of the design principle of the Forth
> standard process: codify existing practice and consolidate it. Other
> standard bodies follow a different approach: define something and declare
> it standard, or standard extension. E.g. the WLAN or Ethernet standards
> follow this model. First you get the specs, the implementation follows.
> 
> Forth could use both. There is a core feature set like the stacks,
> some words (in CORE) and the interpreter/compile model, and there
> are a number of extension wordsets. These extension wordsets could
> be managed more freely than the core.
> 
> No, I'm not complaining about the quotations or recognizers beeing
> discussed so badly. Or the object models. But they are a good
> example that the community will hardly reach "consensus before
> standardization" and progress is no longer possible.

Huh?  I don't understand what you believe is bad about the dicussions
around quotations and recognizers.

> In such situations many forks happen. Strongforth, oforth or factor
> or or. All of them are nice and find their followers. They follow
> the TurboPascal model, hopefully with better luck. But converging
> them back to a common Forth base seems unlikely.

The early history of Forth is instructive here.  Forth, Inc. wrote
applications for customers.  Sometimes, particular factors turned out
to be useful, and entered their toolbox.  Some of these were generally
useful, and eventually entered the standard system and the language.
Some didn't make the grade and were kicked out.  But everything was
tested in the fire of real-world usage.  That's a distinctive feature
of Forth: it's about getting stuff done, not "cute" features.

Quotations are neat, but they don't add a great deal of power to the
language.  On the other hand, their cost and footprint is small.  I
think that they'll turn out to be useful enough to be standardized,
but once a word is in the standard it's hard to get rid of it.

Andrew.

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

#51271

> The early history of Forth is instructive here.  Forth, Inc. wrote
> applications for customers.

That was like the Turbo Pascal era for Pascal. Borland did add
a great amount of library code (anyone remember the BGI or the
Turbo Vision libraries?) that matched the demands of many users.

Expectations moved since then. Today a language by itself is less important.
Erlang or ruby did not run into real world application because of their
theoretical features but because of their libraries. Has anyone written
a real forth application server? Ruby got it's success with
rails (IMHO only because of it). Erlang came from the telcos and now a 
few real hot software packages use it (CouchDB, RabbitMQ). Python
replaced perl because perl de facto stopped development for 20 years.
(perl6 only recently came into public).

> tested in the fire of real-world usage.  That's a distinctive feature
> of Forth: it's about getting stuff done, not "cute" features.

Forth became an unknown hidden language, that's a tragedy. Erlang is a 
hidden language too, but a well known one, considered for new projects.

> Quotations are neat, but they don't add a great deal of power to the
> language.  On the other hand, their cost and footprint is small.  I
> think that they'll turn out to be useful enough to be standardized,
> but once a word is in the standard it's hard to get rid of it.

Maybe this is the gist of the matter. I think that there should be a
language core feature set, more or less what CORE is now. Discussions
here are worth any effort. The same effort for the optional word sets
is overkill. The optional wordsets are more or less a standard library
that shall be changeable more easily (that is extended, keeping
backward compatibility is not a bug).

So, quotations are fine, just have them as candidate wordset in the
standard (a new section in the text). published as standard 2017, to
be reviewed in standard 2019. Next one, please. (the years are examples).
I agree that recognizers are not that fine tuned yet. That's why I didn't
start a CfV.

Matthias

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

#51296

On Sunday, September 25, 2016 at 10:21:38 PM UTC+13, Matthias Trute wrote:
> Today a language by itself is less important.

Good libraries need a good core language to build on. This is why Python has become popular. For example, Python offers an elegantly simple way to define custom overloads of operators: compare the cumbersome way C++ does it, and Java doesn’t allow it at all--and both are much more complex languages than Python.

For instance, I am able to define vector arithmetic in my own Python module, so that a geometrical calculation like <https://github.com/ldo/qahirah_examples/blob/master/fillet>

    t1 = p1 + Vector.unit((p0 - p1).angle()) * inset
        # fillet tangent point on line (p0, p1)

can determine both x- and y-coordinates at once, instead of having to write out the same formulas twice.

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

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

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

csiph-web