Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #51099
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Essential properties of current standard Forth |
| Date | 2016-09-18 11:35 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <nrmfok$5pu$1@dont-email.me> (permalink) |
| References | <2016Sep15.161930@mips.complang.tuwien.ac.at> <d420afc2-dbe5-4b4d-a706-e1d435fccb0c@googlegroups.com> |
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
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web