On Thursday, December 30, 2021 at 9:02:44 AM UTC+3, Paul Rubin wrote:
>
> Yeah, as for "future Forth", I don't think Python-like Forths have much
> attraction. Maybe of more interest is tethered Forths that move the
> text interpreter to a remote host, instead of just using a serial port
> and resident interpreter. This is already done with the professional
> Forths but I'd like to see it in hobbyist Forths. There should also be
> some modifications to e.g. DOES> to be friendlier for target cpus with
> program memory in flash instead of ram.

This will have hard competition with Flutter like systems, which are
able to update only changed parts of running program on target.

>
> This was also of interest: https://queue.acm.org/detail.cfm?id=3212479
>
> It says that the old flat-memory single-threaded cpu abstraction no
> longer really reflects the hardware. So maybe it's best to e.g. get rid
> of the cache hierarchy and explicitly expose multiple levels of slower
> and faster memory. If that results in new kinds of cpus, maybe Forth
> could be suitable for them.

Such point of view exist for long time. Yet we don't have adequate C
replacement.

On Friday, December 31, 2021 at 11:51:26 AM UTC+3, Marcel Hendrix wrote:
> Actually, I don't understand the need. Is there a program
> we can't express in Forth? If there is, "we need" to do
> something indeed.
>

We can also express "any program" in brainfuck.

The question stands differently -- How we convince other people
to use Forth? Because, language dies without programmers.

On Friday, December 31, 2021 at 2:17:07 PM UTC+3, the.bee...@gmail.com wrote:
> Try implementing 4tH's IO scheme in standard Forth. Good luck. Implementing Forths FILE wordset in 4tH is trivial, however. Just a bunch of oneliners.
>

Can you explain what is so unique in "4tH IO scheme"?

P.S. 4tH is probably the best Forth distribution in terms of features you get
out-of-the-box at present time.

"minf...@arcor.de" <minforth@arcor.de> writes:
>Anton Ertl schrieb am Dienstag, 28. Dezember 2021 um 19:32:49 UTC+1:
>> What Forth needs for that is more performance and IMO better
>> guarantees (C moves away from the niche by telling low-level
>> programmers that they should not have relied on properties that the C
>> standard does not guarantee).
>
>There are very few applications that need more processing speed in a single CPU.

Even if true, these applications are a potential niche.

As for the veracity of that claim: Security researchers claim that all
the high-level stuff that people write resides on a layer of C code.
This C code is not rewritten in Java or Python for performance
reasons. Rust is trying to move into that spot and provide more
security, and we will see how successful that approach is. Meanwhile,
I think that Rust is too rigid to support all of the techniques
useful for good performance.

>Programmer time has become much more important.

More than what? The software crisis (software costs more than
hardware) has already been proclaimed in 1968.

>This implies eg
>- compiler performance for high semantical expressiveness

Pardon?

>- catching as meany errors as possible in an early development stage

Forth's traditional answer has been "testing" along with writing
easily testable software. I think that's a good answer, but the way
it has sometimes been done in Forth is not good enough: Typing
something in at the command line and then looking at the results is
not good enough.

> (most users/customers don't accept crashing as "bug detection facility")

If that was true, software would look differently.

>- good integration with powerful development and maintenance tools

We have that in Forth.

- 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

Andy Valencia <vandys@vsta.org> writes:
>However, if things really go off the rails:
>
>' flush-file ok
>. 187650824918704 ok
>: d 100000 0 do 0 i 187650824918704 + ! loop ; ok
>d ok
>
>
>Quit.
>(No response at all, not ^C, took ^\ to abort out to the shell.)

Yes, Gforth is not bullet-proof, and the second thing in the Gforth
tutorial is the crash course
<https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Crash-Course-Tutorial.html#Crash-Course-Tutorial>.

This is rarely a problem in my experience. We could organize Gforth
to turn off write permission from as much of the system as possible,
allowing to increase the bullet-resistance (but you can still corrupt
it through writing to data (like deferred words) that have to stay
writable), but for now the benefit/cost ratio is too low.

- 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

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

By contrast, there are many Forth systems, each with their own
implementor(s), and they can all go their own way, and do so. 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.

Some may think that Python's way is better, leading to faster
advances. If so, what properties of Python and Forth have lead to
this? Maybe it's because it's much easier to write a basic Forth than
a basic Python. So people just do that; the result does not have all
the conveniences of, say, Gforth, but it's also less complex. The end
result is that programmers with an urge to work on language
implementations don't work on improving, say, Gforth, but on first
creating and them improving their own Forth. And maybe that's the
right way for Forth. By contrast, despite CPython being more complex
than Gforth, programmers with an urge for working on Python
implementation like to work on CPython rather than on their own Python
implementation.

- 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 Sunday, January 2, 2022 at 6:55:47 PM UTC+3, Anton Ertl wrote:

> >- good integration with powerful development and maintenance tools
> We have that in Forth.

What? You have LSP? Or ability to debug at machine level code? Or maybe
there is a Forth that can generate DWARF format, so we can just use
common tools for debugging. Or maybe you have profilers, at least
functionally equivalent to gprof. Or maybe you have "lint" tools?

The Forth ecosystem stuck somewhere in late 80th from past century...

On Wednesday, December 29, 2021 at 2:43:48 AM UTC+1, Andy Valencia wrote:
> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > You can ^C out of Gforth and other Forth systems, with some
> > differences in functionality.
> And you and your folks have done great things with gforth!
> And I find there's quite a bit of memory safety:
>
> : a 1000000 0 do 0 i ! loop ; ok
> a
> :2: Invalid memory address
> >>>a<<<
> Backtrace:
> $FFFFAE0E25D0 !
> $0
> $F4240
>
> However, if things really go off the rails:
>
> ' flush-file ok
> . 187650824918704 ok
> : d 100000 0 do 0 i 187650824918704 + ! loop ; ok
> d ok
If you want that kind of protection, you need 4tH:

$ pp4th -x test0.4th
Executing; Word 7: Bad variable
$ cat test0.4th
: d 100000 0 do 0 i dup . 187650824918704 + ! loop ;

d
$

I tested - NOTHING was written. 4tH was designed for exactly that by putting the whole thing in a sandbox.

Hans Bezemer

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

> 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. I can name only zeptoforth.

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

On 2022-01-02 18:58, Nickolay Kolchin wrote:
> 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...
>
>> 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. I can name only zeptoforth.

Perhaps you don't consider 8th a Forth, or perhaps you think it's a toy
project?

Paul Rubin <no.email@nospam.invalid> writes:
>There should also be
>some modifications to e.g. DOES> to be friendlier for target cpus with
>program memory in flash instead of ram.

I have made some suggestions on better approaches for that problem,
but there has been little resonance, so it seems to me that those
working on such targets are happy with the not-quite-standard way they
implement DOES> for now.

Thinking about it again, Gforth now has CREATE-FROM:

: create-from ( nt "name" -- ) \ gforth
\G Create a word @i{name} that behaves like @i{nt}, but with an
\G empty body. @i{nt} must be the nt of a named word. The
\G resulting header is not yet revealed.

In Gforth CREATE-FROM is used for performance, and you can still use
IMMEDIATE, DOES>, SET-OPTIMIZER etc. on the word (but throw away the
performance advantage if you do). But it inspires the idea that on a
flash system one could define a template for other words, ideally in a
way that does not require overwriting, and then have a word like
CREATE-FROM that generates a header, again without overwriting.

E.g., instead of:

: myconst
create ,
does>
@ ;

one might write something like

template: myconst-template
' @ set-does> ;template

: myconst
['] myconst-template define-from , ;

>This was also of interest: https://queue.acm.org/detail.cfm?id=3212479
>
>It says that the old flat-memory single-threaded cpu abstraction no
>longer really reflects the hardware. So maybe it's best to e.g. get rid
>of the cache hierarchy and explicitly expose multiple levels of slower
>and faster memory.

This is nonsense in every area where the software crisis reigns (i.e.,
pretty much everything but supercomputing, and even there they have
been using cached CPUs for a long while). Nevertheless, the idea is
apparently very seductive, as can be seen from this article, but even
higher-profile was the Cell architecture of the PlayStation 3.

The Cell chip in the PS3 has one regular PPC (with caches), and 7
special PPCs (SPEs) each with their own 256KB of SRAM (but not as
caches). Software has to arrange for the data to get into the SPEs
RAM so that the SPE can work on it.

Apparently Sony thought that the software crisis does not reign in
games development (at least not in the part they intended for the
SPEs), and that game developers would be willing to invest the extra
development effort to get the additional performance from the SPEs;
after all, much of the CPU time is spent in a few kernels, and it
should not be so hard to adapt these to the SPEs. From what I hear,
they were wrong, and game developers had difficulty getting good
performance out of a PS3. The PS4 certainly used a more conventional
architecture with 8 (small) cores that can access main memory and that
have caches.

Anyway, the flat memory abstraction combined with caches and hardware
prefetching has proven to work very well, for both programmability and
performance. For special cases processors have software prefetch
instructions (but it has often turned out that using them produced a
slowdown, i.e., hardware prefetching works just as well), and store
instructions that tell the cache that the data will not be used soon
(so the cache will not hold onto that data).

- 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 Sunday, January 2, 2022 at 5:39:50 PM UTC+1, Nickolay Kolchin wrote:
> On Sunday, January 2, 2022 at 6:55:47 PM UTC+3, Anton Ertl wrote:
>
> > >- good integration with powerful development and maintenance tools
> > We have that in Forth.
> What? You have LSP? Or ability to debug at machine level code? Or maybe
> there is a Forth that can generate DWARF format, so we can just use
> common tools for debugging. Or maybe you have profilers, at least
> functionally equivalent to gprof. Or maybe you have "lint" tools?

In iForth I can open a C-server debug build and then attach to a
running iwserver.exe. It is then possible to debug in Forth as
usual (on the Forth command line), and at the same time
inspect and debug with the C tools (normally from within
the Visual Studio GUI). Display of memory and structures
is easier done in Forth (you can type in Forth on-the-fly
macros to help and do introspection, even for the C-side)
but step-by-step running and debugging of FPU stack-ops
is much easier in C.
These features helps quite a bit when calling DLLs and
handling callbacks, because it is possible to see both
sides of the transaction in their respective native
format. It also saves time when looking up native C
and OS magic constants and untangling C macro's:
just look at the meory from the Forth side.

I seldom need to do this, but indeed, it is nice to have.

-marcel

On Sunday, January 2, 2022 at 9:11:45 PM UTC+3, Marcel Hendrix wrote:
> On Sunday, January 2, 2022 at 5:39:50 PM UTC+1, Nickolay Kolchin wrote:
> > On Sunday, January 2, 2022 at 6:55:47 PM UTC+3, Anton Ertl wrote:
> >
> > > >- good integration with powerful development and maintenance tools
> > > We have that in Forth.
> > What? You have LSP? Or ability to debug at machine level code? Or maybe
> > there is a Forth that can generate DWARF format, so we can just use
> > common tools for debugging. Or maybe you have profilers, at least
> > functionally equivalent to gprof. Or maybe you have "lint" tools?
> In iForth I can open a C-server debug build and then attach to a
> running iwserver.exe. It is then possible to debug in Forth as
> usual (on the Forth command line), and at the same time
> inspect and debug with the C tools (normally from within
> the Visual Studio GUI). Display of memory and structures
> is easier done in Forth (you can type in Forth on-the-fly
> macros to help and do introspection, even for the C-side)
> but step-by-step running and debugging of FPU stack-ops
> is much easier in C.
> These features helps quite a bit when calling DLLs and
> handling callbacks, because it is possible to see both
> sides of the transaction in their respective native
> format. It also saves time when looking up native C
> and OS magic constants and untangling C macro's:
> just look at the meory from the Forth side.
>
> I seldom need to do this, but indeed, it is nice to have.
>

That's great, but fills only single entry from my list.

On Sunday, January 2, 2022 at 8:07:53 PM UTC+3, Ron AARON wrote:
> On 2022-01-02 18:58, Nickolay Kolchin wrote:
> > 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...
> >
> >> 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. I can name only zeptoforth.
> Perhaps you don't consider 8th a Forth, or perhaps you think it's a toy
> project?

I treat 8th in same category as Factor. Different language that has
Forth as one of the ancestors.

On Sunday, January 2, 2022 at 9:11:45 PM UTC+3, Marcel Hendrix wrote:
> On Sunday, January 2, 2022 at 5:39:50 PM UTC+1, Nickolay Kolchin wrote:
> > On Sunday, January 2, 2022 at 6:55:47 PM UTC+3, Anton Ertl wrote:
> >
> > > >- good integration with powerful development and maintenance tools
> > > We have that in Forth.
> > What? You have LSP? Or ability to debug at machine level code? Or maybe
> > there is a Forth that can generate DWARF format, so we can just use
> > common tools for debugging. Or maybe you have profilers, at least
> > functionally equivalent to gprof. Or maybe you have "lint" tools?
> In iForth I can open a C-server debug build and then attach to a
> running iwserver.exe. It is then possible to debug in Forth as
> usual (on the Forth command line), and at the same time
> inspect and debug with the C tools (normally from within
> the Visual Studio GUI). Display of memory and structures
> is easier done in Forth (you can type in Forth on-the-fly
> macros to help and do introspection, even for the C-side)
> but step-by-step running and debugging of FPU stack-ops
> is much easier in C.
> These features helps quite a bit when calling DLLs and
> handling callbacks, because it is possible to see both
> sides of the transaction in their respective native
> format. It also saves time when looking up native C
> and OS magic constants and untangling C macro's:
> just look at the meory from the Forth side.
>
> I seldom need to do this, but indeed, it is nice to have.
>

Btw, do you have coverage support in iForth?

On Sunday, January 2, 2022 at 7:39:17 PM UTC+1, Nickolay Kolchin wrote:
> On Sunday, January 2, 2022 at 9:11:45 PM UTC+3, Marcel Hendrix wrote:
[..]
> > I seldom need to do this, but indeed, it is nice to have.
> >
> Btw, do you have coverage support in iForth?

No, but you can automate lprofiler.frt ( published in FD, CLF, or here
http://www.iaehv.nl/users/mhx/programs.html ) to emit a report.

-marcel

On 2022-01-02, Nickolay Kolchin <nbkolchin@gmail.com> wrote:
> You prefer to forget about Pypy, Jython, Pyston, GraalVM Python,
> MicroPython, etc...

Yes and they've always been plagued by a lack of interest by most
developers as mindshare remains in CPython. This has been a point of
much complaint by folks behind Pypy for example.

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

I really disagree with this. I do think there's a type of compilers'
interested software engineer who loves to make programming languages
that finds themselves irresistably attracted to Forth. They'll come
in, talk about how elegant the Forth interpreter is, make a barebones
Forth, and then leave. I think this type of engineer does "damage" to
the Forth "brand", but I mean, they are independent engineers free to
do what they wish.

Retro Forth is another Forth I suggest you take a look at if you're
interested in modern Forths.

- meff

On Sunday, January 2, 2022 at 11:29:59 PM UTC+3, Marcel Hendrix wrote:
> On Sunday, January 2, 2022 at 7:39:17 PM UTC+1, Nickolay Kolchin wrote:
> > On Sunday, January 2, 2022 at 9:11:45 PM UTC+3, Marcel Hendrix wrote:
> [..]
> > > I seldom need to do this, but indeed, it is nice to have.
> > >
> > Btw, do you have coverage support in iForth?
> No, but you can automate lprofiler.frt ( published in FD, CLF, or here
> http://www.iaehv.nl/users/mhx/programs.html ) to emit a report.
>

Link broken. 404.

On Monday, January 3, 2022 at 2:29:20 AM UTC+3, meff wrote:
> On 2022-01-02, Nickolay Kolchin <nbko...@gmail.com> wrote:
> > You prefer to forget about Pypy, Jython, Pyston, GraalVM Python,
> > MicroPython, etc...
> Yes and they've always been plagued by a lack of interest by most
> developers as mindshare remains in CPython. This has been a point of
> much complaint by folks behind Pypy for example.

True. Maybe this is part of Python general success?

> > 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.
> I really disagree with this. I do think there's a type of compilers'
> interested software engineer who loves to make programming languages
> that finds themselves irresistably attracted to Forth. They'll come
> in, talk about how elegant the Forth interpreter is, make a barebones
> Forth, and then leave. I think this type of engineer does "damage" to
> the Forth "brand", but I mean, they are independent engineers free to
> do what they wish.

I don't follow you.

>
> Retro Forth is another Forth I suggest you take a look at if you're
> interested in modern Forths.

I've looked at it briefly and found nothing interesting. The combinators
are more complete in Factor. Sigils are dubious concept imho.

On 2022-01-03, Nickolay Kolchin <nbkolchin@gmail.com> wrote:
> True. Maybe this is part of Python general success?

Maybe, maybe not. I'm not particularly sympathetic to the folks who
crave more attention from CPython developers because of just how good
CPython is.

>> I really disagree with this. I do think there's a type of compilers'
>> interested software engineer who loves to make programming languages
>> that finds themselves irresistably attracted to Forth. They'll come
>> in, talk about how elegant the Forth interpreter is, make a barebones
>> Forth, and then leave. I think this type of engineer does "damage" to
>> the Forth "brand", but I mean, they are independent engineers free to
>> do what they wish.
>
> I don't follow you.

Forth's core interpreter is very simple, right? It means that somebody
with a decent understanding of basic computer architecture works can
have the core intpreter working inefficiently. A lot of folks who like
building languages come into this community, build the basic
interpreter, and then leave once the rest of the work becomes building
all the scaffolding words around the interpreter and less about making
a language from scratch.

meff schrieb am Montag, 3. Januar 2022 um 07:58:31 UTC+1:
> On 2022-01-03, Nickolay Kolchin <nbko...@gmail.com> wrote:
> > True. Maybe this is part of Python general success?
> Maybe, maybe not. I'm not particularly sympathetic to the folks who
> crave more attention from CPython developers because of just how good
> CPython is.
> >> I really disagree with this. I do think there's a type of compilers'
> >> interested software engineer who loves to make programming languages
> >> that finds themselves irresistably attracted to Forth. They'll come
> >> in, talk about how elegant the Forth interpreter is, make a barebones
> >> Forth, and then leave. I think this type of engineer does "damage" to
> >> the Forth "brand", but I mean, they are independent engineers free to
> >> do what they wish.
> >
> > I don't follow you.
> Forth's core interpreter is very simple, right? It means that somebody
> with a decent understanding of basic computer architecture works can
> have the core intpreter working inefficiently. A lot of folks who like
> building languages come into this community, build the basic
> interpreter, and then leave once the rest of the work becomes building
> all the scaffolding words around the interpreter and less about making
> a language from scratch.

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.

On Monday, January 3, 2022 at 6:42:23 AM UTC+1, Nickolay Kolchin wrote:
> On Sunday, January 2, 2022 at 11:29:59 PM UTC+3, Marcel Hendrix wrote:
> > On Sunday, January 2, 2022 at 7:39:17 PM UTC+1, Nickolay Kolchin wrote:
> > > On Sunday, January 2, 2022 at 9:11:45 PM UTC+3, Marcel Hendrix wrote:
> > [..]
> > > > I seldom need to do this, but indeed, it is nice to have.
> > > >
> > > Btw, do you have coverage support in iForth?
> > No, but you can automate lprofiler.frt ( published in FD, CLF, or here
> > http://www.iaehv.nl/users/mhx/programs.html ) to emit a report.
> >
> Link broken. 404.

http://home.iae.nl/users/mhx/lprofile.frt
http://home.iae.nl/users/mhx/lprof.frt

On Monday, January 3, 2022 at 11:17:54 AM UTC+3, Marcel Hendrix wrote:
> On Monday, January 3, 2022 at 6:42:23 AM UTC+1, Nickolay Kolchin wrote:
> > On Sunday, January 2, 2022 at 11:29:59 PM UTC+3, Marcel Hendrix wrote:
> > > On Sunday, January 2, 2022 at 7:39:17 PM UTC+1, Nickolay Kolchin wrote:
> > > > On Sunday, January 2, 2022 at 9:11:45 PM UTC+3, Marcel Hendrix wrote:
> > > [..]
> > > > > I seldom need to do this, but indeed, it is nice to have.
> > > > >
> > > > Btw, do you have coverage support in iForth?
> > > No, but you can automate lprofiler.frt ( published in FD, CLF, or here
> > > http://www.iaehv.nl/users/mhx/programs.html ) to emit a report.
> > >
> > Link broken. 404.
> http://home.iae.nl/users/mhx/lprofile.frt
> http://home.iae.nl/users/mhx/lprof.frt

That's just great. Pity it can't be expressed in Standard Forth...

P.S. Actually, this is a great example of what makes Forth unique.

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> And then he uses enforced run-time guarding to guarantee that control
>> flow never reaches the words unless the type is correct. I.e.,
>>
>> empty-board (board-empty) 1 1 x-move ( board ) 0 0 o-move
>>
>> would result in a type error at the second move, because move just
>> returns the board supertype, but not one of the types that MOVE
>> accepts.
>
>The idea is that an X move returns a board state waiting for an O move
>and vice versa.

Nope. An x move returns either a finished board (and no move is
possible) or an unfinished board where an o move can be made;
therefore the result of x-move is a superclass of board-finished and
board-next-o: board.

>So that example would be
>
>empty-board ( board-empty ) 1 1 x-move ( board-next-o ) 0 0 o-move

This would fail the requirement that no move can be compiled unless
you know that the game is not yet finished.

>> Something like having o-move in the board-next-o wordlist, and having
>> a guarding word, used like this:
>>
>> ( board ) 0 0 rot guard-board-next-o o-move 2drop
>
>1) this still seems like a runtime check since initial board state
>doesn't say whose turn it is,

I am sorry that I was overly terse and only showed the changed part.
The whole replacement for the example above is:

empty-board (board-empty) 1 1 x-move
( board ) 0 0 rot guard-board-next-o o-move 2drop

GUARD-BOARD-NEXT-O indeed performs a run-time check, just like a
typical type-case in any other language that can satisfy his
requirements. Instead of GUARD-BOARD-NEXT-O, one might also instead
use something along the lines of

empty-board (board-empty) 1 1 x-move
( board ) 0 0 rot case
board-next-o-of o-move \ no OF ENDOF, because BOARD-NEXT-O-OF parses O-MOVE
board-finished-of ...
assert( false )
endcase

But of course you are right that you can always satisfy the static
type checker (in all such languages) by wrapping the statically
type-checked word in a dynamically type-checked guard. That's why I
find his insistence on static type checking so unconvincing.

>2) the board state is passed on the (untyped) Forth stack, so even if
>its state was once known, stack operations can interfere with the
>wordlist based type checking,

Take a look at the source code of GUARD-BOARD-NEXT-O; it checks the
type of the item on the top-of-stack, and only if it is correct,
performs O-MOVE. If you swap something else to the TOS,
GUARD-BOARD-NEXT-O will find that it is not the right type, and will
perform the 2DROP instead.

Admittedly, you might pass an integer on the TOS that happens to have
the same bit pattern as a valid board address, but the chances of that
happening by chance are very small.

>3) the API "o-move" is now replaced by two words that must be invoked
>consecutively, one of which is part of the official API and the other of
>which is not. Maybe that is ok, but it leaves the API client to (maybe
>incorrectly) implement guard-board-next-o.

GUARD-BOARD-NEXT-O is the replacement for the type-guard or type-case
built into a statically typed language. Yes, GUARD-BOARD-NEXT-O may
be implemented incorrectly, but so can be the compiler of the
statically typed language.

>The original premise of the
>exercise was for the API implementer to hand over some type declarations
>and say "if the compiler doesn't accept that your data satisfies those
>types, then something is wrong with your data". Thus it places faith
>in the compiler's typechecker that it doesn't place in the API client
>implementation.

Then consider GUARD-BOARD-NEXT-O, or the generator that would generate
it in a more worked-out example, as part of the type checker.

- 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:
>Paul Rubin <no.email@nospam.invalid> writes:
>> empty-board ( board-empty ) 1 1 x-move ( board-next-o ) 0 0 o-move
>
>Oh actually you write, x-move must contain a wrapped object containing
>either board-next-o or board-finished. So the client must distinguish
>those two at runtime and only call o-move in the event that the X move
>returned board-next-o.
>
>My Haskell solution did the above with a GADT

What is a GADT? The Wikipedia page is totally unenlightening.

>and type refinement using
>a case statement, iirc.

I expected so, and my sketch goes in the same direction (but with a
guard instead of a case for simplicity).

- 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