Nickolay Kolchin <nbkolchin@gmail.com> writes:
>On Sunday, January 2, 2022 at 7:37:33 PM UTC+3, Anton Ertl wrote:
>> dxforth <dxf...@gmail.com> writes:
>> >Also I expect Python isn't a federation of implementers where each wants
>> >to 'have their cake and eat it too'.
>>
>> CPython has a number of implementors who need to agree on what they
>> do, because they all work on the same implementation.
>>
>
>You prefer to forget about Pypy, Jython, Pyston, GraalVM Python,
>MicroPython, etc...

Like the majority of Python users.

>> By contrast, there are many Forth systems, each with their own
>> implementor(s), and they can all go their own way, and do so.
>
>Name Forth system that appears in past 10 years and has evolved to
>something bigger than toy project.

What would be the point? But anyway, mecrisp-0.1.tar.gz was published
in August 2011, so it's slightly older than 10 years. Why would that
make a difference?

>> There
>> is the Forth200x effort to get some commonality among Forth systems,
>> but the difference to the CPython situation is: If the standard
>> stalls, a Forth system implementor can still implement whatever he
>> wants in his system; so there is much less reason for the participants
>> to find agreement in the Forth200x mechanism than in the PEP (Python
>> extension proposal) mechanism, and it's therefore also much slower.
>
>And here comes the biggest reality misunderstanding. Actually, people
>implement basic Forth system, make it compatible with ANS/2012 and
>stop at this step. Cause they treat your papers as current "top level" of
>language.

Do they? JonesForth appears to have been quite well received for a
while, and it had some deviations from the standard which seemed to
cause some confusion. Likewise, eForth deviates from the standard in
some respects.

Anyway, if your claim was true, what would follow from it? If the
standard would be a higher hurdle (as you seem to wish for), would
those who build a Forth system for the joy of it continue after
crossing that hurdle? Or would they stop earlier? Or would they
prefer to contribute to an existing Forth system?

- 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 2021: https://euro.theforth.net/2021

On Monday, January 3, 2022 at 6:26:51 PM UTC+3, Anton Ertl wrote:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> >And here comes the biggest reality misunderstanding. Actually, people
> >implement basic Forth system, make it compatible with ANS/2012 and
> >stop at this step. Cause they treat your papers as current "top level" of
> >language.
>
> Anyway, if your claim was true, what would follow from it? If the
> standard would be a higher hurdle (as you seem to wish for), would
> those who build a Forth system for the joy of it continue after
> crossing that hurdle? Or would they stop earlier? Or would they
> prefer to contribute to an existing Forth system?

Yes, they would. Cause this is an achievement. Standard must
represent the current topbar of the language. It should define the
future direction. And not be a legacy mess.

Nickolay Kolchin schrieb am Montag, 3. Januar 2022 um 17:24:47 UTC+1:
> On Monday, January 3, 2022 at 6:26:51 PM UTC+3, Anton Ertl wrote:
> > Nickolay Kolchin <nbko...@gmail.com> writes:
> > >And here comes the biggest reality misunderstanding. Actually, people
> > >implement basic Forth system, make it compatible with ANS/2012 and
> > >stop at this step. Cause they treat your papers as current "top level" of
> > >language.
> >
> > Anyway, if your claim was true, what would follow from it? If the
> > standard would be a higher hurdle (as you seem to wish for), would
> > those who build a Forth system for the joy of it continue after
> > crossing that hurdle? Or would they stop earlier? Or would they
> > prefer to contribute to an existing Forth system?
> Yes, they would. Cause this is an achievement. Standard must
> represent the current topbar of the language. It should define the
> future direction. And not be a legacy mess.

Working in industry I have to affirm that standards are important for setting
minimal and uniform functional and quality standards between different
products/services/vendors. They impose also a strong legal product liability burden.

Nowhere there is the idea of "define the future direction".

On Monday, January 3, 2022 at 7:47:35 PM UTC+3, minf...@arcor.de wrote:
> Nickolay Kolchin schrieb am Montag, 3. Januar 2022 um 17:24:47 UTC+1:
> > On Monday, January 3, 2022 at 6:26:51 PM UTC+3, Anton Ertl wrote:
> > > Nickolay Kolchin <nbko...@gmail.com> writes:
> > > >And here comes the biggest reality misunderstanding. Actually, people
> > > >implement basic Forth system, make it compatible with ANS/2012 and
> > > >stop at this step. Cause they treat your papers as current "top level" of
> > > >language.
> > >
> > > Anyway, if your claim was true, what would follow from it? If the
> > > standard would be a higher hurdle (as you seem to wish for), would
> > > those who build a Forth system for the joy of it continue after
> > > crossing that hurdle? Or would they stop earlier? Or would they
> > > prefer to contribute to an existing Forth system?
> > Yes, they would. Cause this is an achievement. Standard must
> > represent the current topbar of the language. It should define the
> > future direction. And not be a legacy mess.
> Working in industry I have to affirm that standards are important for setting
> minimal and uniform functional and quality standards between different
> products/services/vendors. They impose also a strong legal product liability burden.
>
> Nowhere there is the idea of "define the future direction".

Let me disagree with you:

- C++ standard (compilers are almost always behind)
- Any FAA/ARINC standard (they have to look forward, cause they are
mandatory and if they just "fix" current situation, they'll stop the whole
industry evolution. That doesn't prevent them from being ugly mess
though...)
- even W3C standards (browsers lag behind)

On 2022-01-03, minf...@arcor.de <minforth@arcor.de> wrote:
> I don't think that this is bad per se. It proves that Forth's core idea is sound
> and when you develop for a MCU you don't need much more in addition than
> MCU-specific interfaces, perhaps multitasking.
>
> Things look different for desktop systens though, and when you wish to
> share software with other people.

Bad? No. Annoying? Yeah. The number of MCUs in general practice today
that could get by with a single-tasked Forth is probably vanishingly
small. Most MCUs these days have at least some concept of a HAL.

meff schrieb am Montag, 3. Januar 2022 um 20:34:12 UTC+1:
> On 2022-01-03, minf...@arcor.de <minf...@arcor.de> wrote:
> > I don't think that this is bad per se. It proves that Forth's core idea is sound
> > and when you develop for a MCU you don't need much more in addition than
> > MCU-specific interfaces, perhaps multitasking.
> >
> > Things look different for desktop systens though, and when you wish to
> > share software with other people.
> Bad? No. Annoying? Yeah. The number of MCUs in general practice today
> that could get by with a single-tasked Forth is probably vanishingly
> small. Most MCUs these days have at least some concept of a HAL.

What's HAL? If you mean HLA, the most prominent high-level assembler there is C.
But C doesn't give you interactivity or on-board interpreter/compiler et cetera.
Micropython is still to fat and serves only a handful of processors.

minf...@arcor.de schrieb am Montag, 3. Januar 2022 um 21:15:16 UTC+1:
> meff schrieb am Montag, 3. Januar 2022 um 20:34:12 UTC+1:
> > On 2022-01-03, minf...@arcor.de <minf...@arcor.de> wrote:
> > > I don't think that this is bad per se. It proves that Forth's core idea is sound
> > > and when you develop for a MCU you don't need much more in addition than
> > > MCU-specific interfaces, perhaps multitasking.
> > >
> > > Things look different for desktop systens though, and when you wish to
> > > share software with other people.
> > Bad? No. Annoying? Yeah. The number of MCUs in general practice today
> > that could get by with a single-tasked Forth is probably vanishingly
> > small. Most MCUs these days have at least some concept of a HAL.
> What's HAL? If you mean HLA, the most prominent high-level assembler there is C.
> But C doesn't give you interactivity or on-board interpreter/compiler et cetera.
> Micropython is still to fat and serves only a handful of processors.

Talking about 'fat' languages - I found this article fascinating:
https://justine.lol/sectorlisp2/

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> What is a GADT? The Wikipedia page is totally unenlightening.

Generalized Algebraic Data Type. A tagged union where the union members
have different types. You match the tag using a case statement, and the
type checker then knows the type of the selected member. This is a
limited form of dependent types since you can (e.g.) encode numbers in
types, and the type checker can do a limited amount of arithmetic.

Here is an example that I thought was impressive (I linked it a few days
ago too):

https://www.reddit.com/r/haskell/comments/ti5il/redblack_trees_in_haskell_using_gadts_existential/

This encodes the invariants of a red-black tree in the type, so if the
code type checks then the invariants are satisfied. Some later GHC
extensions allow writing the types a little more cleanly, but it is the
same idea.

On 2022-01-03, minf...@arcor.de <minforth@arcor.de> wrote:
> What's HAL? If you mean HLA, the most prominent high-level assembler there is C.
> But C doesn't give you interactivity or on-board interpreter/compiler et cetera.
> Micropython is still to fat and serves only a handful of processors.

HAL = Hardware Abstraction Layer. Think STM32Cube's HAL,Android's binder,
or PlatformIO.

Paul Rubin schrieb am Montag, 3. Januar 2022 um 21:40:18 UTC+1:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > What is a GADT? The Wikipedia page is totally unenlightening.
> Generalized Algebraic Data Type. A tagged union where the union members
> have different types. You match the tag using a case statement, and the
> type checker then knows the type of the selected member. This is a
> limited form of dependent types since you can (e.g.) encode numbers in
> types, and the type checker can do a limited amount of arithmetic.
>
> Here is an example that I thought was impressive (I linked it a few days
> ago too):
>
> https://www.reddit.com/r/haskell/comments/ti5il/redblack_trees_in_haskell_using_gadts_existential/
>
> This encodes the invariants of a red-black tree in the type, so if the
> code type checks then the invariants are satisfied. Some later GHC
> extensions allow writing the types a little more cleanly, but it is the
> same idea.

Perhaps I still don't get it. Where's the difference to a class-based type system?
Or Visual Basic variants?

Gerry Jackson <do-not-use@swldwa.uk> writes:
>ISTM that the problem with libraries is that people have their own
>libraries with different words and names, albeit providing more or less
>the same functionality. Assuming a miracle happens and a string library,
>say, is agreed everybody with their own string library would be
>unwilling to change their existing software to use the new string
>library. The same goes for OO packages.

That's not necessarily a problem. I used to use my own struct library
http://www.complang.tuwien.ac.at/forth/compat/struct.fs; then
Forth200x standardized +FIELD and friends, and since then I have used
the standard words; Some of my existing programs continue to use the
old words, but my new code (and sometimes also updates of existing
code use the standardized words).

The problem I see with strings (and other areas) is that the way
memory management is handled leads to many mutually incompatible
approaches, each of which is good for certain usages and not so great
for different usage patterns [ertl13-strings]. In that environment
the kind of seamless transition that we have seen from struct.fs to
the standardized structure words is not possible.

@InProceedings{ertl13-strings,
author = {M. Anton Ertl},
title = {Standardize Strings Now!},
crossref = {euroforth13},
pages = {39--43},
url = {http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-strings.pdf},
OPTnote = {not refereed},
abstract = {This paper looks at the issues in string words: what
operations may be required, various design options,
and why this has lead to the current state of
standardization of string operations that is
insufficient in the eyes of many.}
} @Proceedings{euroforth13,
title = {29th EuroForth Conference},
booktitle = {29th EuroForth Conference},
year = {2013},
key = {EuroForth'13},
url = {http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/proceedings.pdf}
}

>The big mistake in Forth 200X is that it is open to all and sundry to
>comment and vote on whether something is accepted into the standard.
>This invariably results in an outcry from the rabid standard haters who
>object to anything new. Sometimes the 'discussion' is so vicious and
>offensive that potential proposers of a new feature are reluctant to
>write an RfD.

I think that this openness is necessary for a standard. And certainly
for me it's not the standard haters that have discouraged me from
making proposals recently.

>IMHO the best way forward is to do what they claim and form a small
>closed group to develop a new system - don't call it a standard but a
>project. This group should probably have no more than 4 or 5 members and
>keep their work private until they have something significant to
>announce. Perhaps even keep the group membership secret. Also it would
>be best to exclude commercial vendors because they have little incentive
>to change anything for good commercial reasons.

Sounds like Gforth:-). Or actually any other non-commercial system.

But yes, that avenue is open to anyone. And some have taken it and
produced nice systems with nice features. We have yet to see a Forth
system that becomes as dominant as, e.g., CPython is in the Python
landscape, a system that defines what a proper Python implementation
should include.

- 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 2021: https://euro.theforth.net/2021

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> What is a GADT? The Wikipedia page is totally unenlightening.
>
>Generalized Algebraic Data Type. A tagged union where the union members
>have different types. You match the tag using a case statement, and the
>type checker then knows the type of the selected member.

Seems to be what I have been thinking about in this context, only I
used a different term (type guard).

- 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 2021: https://euro.theforth.net/2021

On 2022-01-08, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Sounds like Gforth:-). Or actually any other non-commercial system.
>
> But yes, that avenue is open to anyone. And some have taken it and
> produced nice systems with nice features. We have yet to see a Forth
> system that becomes as dominant as, e.g., CPython is in the Python
> landscape, a system that defines what a proper Python implementation
> should include.

I think building a community around an implementation would be a lot
easier if the implementation has good documentation. It's usually the
reason why I point folks interested in Forth to Gforth. The docs are
much better than most other Forths and it has examples to boot.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Generalized Algebraic Data Type.
> Seems to be what I have been thinking about in this context, only I
> used a different term (type guard).
I may not completely understand the type guard idea. I will have to
look at your post again. The GADT allows the program to select on a
runtime value (board state) and enforce at compile time that you can't
make an illegal move (one inconsistent with that state).

What makes GADT's different from ordinary types is a Haskell case
expression (I mis-used the term "case statement" before, but it is
really an expression) can refine its type depending on the value it
examines. A normal case expression (like any expression) must have a
unique type, e.g.

case x of { 1 -> "foo"; 2 -> "bar" }

has type string, which is fine. Its value is one of two different
strings, but both are of the same type. While an expression like

case x of { 1 -> "foo"; 2 -> False }

has an output type that is either string or bool, dependent on the
input. That is called a dependent type and statically enforcing
type-correctness with dependent types turns out to be Turing-complete.
E.g. you can specify a type for prime numbers, then write a program that
does some calculation with an input value and passes the result to a
function expecting a prime. That means the program should only pass the
type checker if the type checker (maybe with programmer assistance) can
mathematically prove that the calculation always ends up with a prime
number. Dependently typed languages are generally used as proof
assistants rather than for programming.

GADT's are a limited form of dependent type that can't do as much as
full-fledged ones, but that can (usually) be type checked automatically.
The red-black tree example I gave was a good example, I thought. It
would be interesting if the type-guard approach could do something
similar. If it can, maybe it can also do full dependent types, in which
case you would need a way to write proof terms through wordlist
manipulation. Maybe it is doable it seems kind of mind boggling.

I've used GADT's but haven't tried real dependent types yet. This book
is supposed to be good and I have been wanting to work through some of
it: https://softwarefoundations.cis.upenn.edu/

Among other things it is an introduction to the dependently typed
language Coq. It looks pretty readable.

"minf...@arcor.de" <minforth@arcor.de> writes:
> Perhaps I still don't get it. Where's the difference to a class-based
> type system?

Basically the GADT in that example is a datatype for red-black trees (RB
trees) that encodes the rules for RB trees directly in the type
signature: a red node can only have black children, etc. So if you have
a value of that RB type, it must be a valid RB tree. If you look at RB
tree implementations in C or other languages, they are usually full of
assert statements or debug conditionals or unit tests to make sure that
after you do an insert operation, those invariants (conditions) still
all hold. In the Haskell example, it is impossible to for those tests
or assertions to fail on a value of RB type, because if you made a
mistake putting the tree together, you will get a compile time type error.

https://en.wikipedia.org/wiki/Red-black_tree