A more mainstream application is in REQUIRE.
A source is included and it is discovered that the facility
has already been loaded, so the remainder of the source is
discarded.
A word that abandons the current input source is long overdue,
and I'm not quite sure that EXIT is the right name.
albert@cherry.(none) (albert) writes:
A more mainstream application is in REQUIRE.
A source is included and it is discovered that the facility
has already been loaded, so the remainder of the source is
discarded.
In Gforth we implement REQUIRE by checking first if the file has
already been loaded. IIRC the reference implementation of REQUIRED
and REQUIRE also does this. No need to discard the rest of the source
for this.
I hope I made the case that it is useful.A word that abandons the current input source is long overdue,
It seems that we have not needed such a word in Gforth, because we
don't have one. Others have such a word, so there seems to be some
need for it.
and I'm not quite sure that EXIT is the right name.
Probably not, because EXIT has no interpretation semantics. The EXIT
and INTERPRET implementations on some systems may work to achieve the
effects you have in mind (although I doubt that it works for INCLUDED
and friends on many systems, because INCLUDED is one level out from
the processing that EVALUATE and LOAD perform).
As for the interpretation semantics of EXIT, we tried hard to give
Gforth's EXIT it's execution semantics as interpretation semantics;
this work is described in [ertl15]. However, in addition to the >complications described there, we found that we still had not covered
all the bases, requiring even more complications, so we reverted the
changes to EXIT, and in the development version EXIT is an immediate
word that *compiles* the execution semantics of EXIT when used >interpretively.
@InProceedings{ertl15,
author = {M. Anton Ertl and Bernd Paysan},
title = {From \texttt{exit} to \texttt{set-does>} --- A Story
of {Gforth} Re-Implementation},
crossref = {euroforth15},
pages = {41--47},
url = {http://www.euroforth.org/ef15/papers/ertl.pdf},
url-slides = {http://www.euroforth.org/ef15/papers/ertl-slides.pdf},
OPTnote = {not refereed},
abstract = {We changed \code{exit} from an immediate to a
non-immediate word; this requires changes in the
de-allocation of locals, which leads to changes in
the implementation of colon definitions, and to
generalizing \code{does>} into \code{set-does>}
which allows the defined word to call arbitrary
execution tokens. The new implementation of locals
cleanup can usually be optimized to similar
performance as the old implementation. The new
implementation of \code{does>} has performance
similar to the old implementation, while using
\code{set-does>} results in speedups in certain
cases.}
}
- anton
This confirms my suspicion that LOCAL is the root of all evil ;-)
none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
This confirms my suspicion that LOCAL is the root of all evil ;-)
You'll love closures then. :-)
Newsgroups: comp.lang.forth
Subject: Interpretation semantics for EXIT
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
For ages now I have used the documented property of ciforth
that EXIT in interpretation mode exits INTERPRET.
A simple example would be
S" 1 2 EXIT 3 4" EVALUATE
that leaves `` 1 2 '' on the stack.
EVALUATE takes care that the original input source is
restored, and so does LOAD and INCLUDE.
I use this extensively in blocks; a block intended
for 32 bits MS-Windows is abandoned in 64 bits, or
Linux.
I am working on a lisp interpreter, inspired by
(Chuck Moore's?) BASIC interpreter. In lisp nested data
structures abound even more.
(+ 1 2 (* 2 3 4))
is a typical lisp phrase.
The basic idea is to start INTERPRET in `` ( '' with a special
CONTEXT and start a **new INSTANCE** of INTERPRET with
each next `` ( ''. However in this case you don't
save and restore the input source, but leave it as is.
Now define
' EXIT ALIAS )
and you can build a partial datastructure starting
with the corresponding `` ( '' as soon as the INTERPRET
has finished.
A more mainstream application is in REQUIRE.
A source is included and it is discovered that the facility
has already been loaded, so the remainder of the source is
discarded.
A word that abandons the current input source is long overdue,
and I'm not quite sure that EXIT is the right name.
Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
In article <2022Apr18.174806@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
albert@cherry.(none) (albert) writes:
A more mainstream application is in REQUIRE.
A source is included and it is discovered that the facility
has already been loaded, so the remainder of the source is
discarded.
In Gforth we implement REQUIRE by checking first if the file has
already been loaded. IIRC the reference implementation of REQUIRED
and REQUIRE also does this. No need to discard the rest of the source
for this.
This is one implementation possibility. What I described is common
in c.
I hope I made the case that it is useful.
A standard program according ISO can not use EXIT in interpretation
state.
That is not a dogma, but a design decision.
In my implementation EXIT performs a return, i.e. pops a
continuation address for the program counter, and jumps there.
If I remove the ?EXEC (that serves to forbid EXIT in compilation
state), suddenly it performs the useful function of ending INTERPRET.
Making Forth better by removing a line, isn't that the tao of
Forth?
I promote the case that EXIT in interpretation mode exits
INTERPRET. Much to my surprise INTERPRET is not ISO standard.
The description would be:
repeat getting words from the input and perform compilation and execution >according to STATE until the input is exhausted.
A quick check reveals that most system has it:
gforth mpeforth swiftforth.
I wonder whether it WORD and FIND could make it into the standard
and INTERPRET doesn't.
(WORD and FIND hints at implementation internal words, that
probably are not used in modern implementation.
INTERPRET OTOH is far from outdated.)
none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
This confirms my suspicion that LOCAL is the root of all evil ;-)
You'll love closures then. :-)
"minf...@arcor.de" <minf...@arcor.de> writes:
none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
This confirms my suspicion that LOCAL is the root of all evil ;-)
You'll love closures then. :-)Gforth now also has closures that don't involve locals. E.g., you can
define +FIELD and FCONSTANT as:
: +field ( n "name" -- )
[n:d + ;] alias ;
5 +field x
7 x . \ prints 12
What's happening here is that when +FIELD is running, the closure
consumes one data stack item (n); this is used to build a closure,
with the needed space allocated in the dictionary. The xt of the
closure is left on the stack, and the ALIAS creates a word X with that
xt as its execution semantics. When X is run, n (i.e., 5) is pushed
on the stack, and the "+" adds it to the 7.
So the closure mechanism transfers one data stack item from closure
creation time to closure execution time (and transferring data from
closure creation time to closure execution time is the functional
essence of closures, no locals needed for that). We also have
variants for one double ("[d:d") and one float ("[f:d"), and for
allocating the closure on the locals stack ("[n:l") and on the heap
("[n:h"), and all nine combinations. We don't have variants for more
stack items; you can use the closures that involve locals if you need
that.
"minf...@arcor.de" <minforth@arcor.de> writes:
none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
This confirms my suspicion that LOCAL is the root of all evil ;-)
You'll love closures then. :-)
Gforth now also has closures that don't involve locals. E.g., you can
define +FIELD and FCONSTANT as:
: +field ( n "name" -- )
[n:d + ;] alias ;
5 +field x
7 x . \ prints 12
What's happening here is that when +FIELD is running, the closure
consumes one data stack item (n); this is used to build a closure,
with the needed space allocated in the dictionary. The xt of the
closure is left on the stack, and the ALIAS creates a word X with that
xt as its execution semantics. When X is run, n (i.e., 5) is pushed
on the stack, and the "+" adds it to the 7.
So the closure mechanism transfers one data stack item from closure
creation time to closure execution time (and transferring data from
closure creation time to closure execution time is the functional
essence of closures, no locals needed for that). We also have
variants for one double ("[d:d") and one float ("[f:d"), and for
allocating the closure on the locals stack ("[n:l") and on the heap
("[n:h"), and all nine combinations. We don't have variants for more
stack items; you can use the closures that involve locals if you need
that.
- anton
In article <2022Apr1...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
Probably not, because EXIT has no interpretation semantics. The EXITA standard program according ISO can not use EXIT in interpretation
and INTERPRET implementations on some systems may work to achieve the >effects you have in mind (although I doubt that it works for INCLUDED
and friends on many systems, because INCLUDED is one level out from
the processing that EVALUATE and LOAD perform).
state. That is not a dogma, but a design decision.
In my implementation EXIT performs a return, i.e. pops a
continuation address for the program counter, and jumps there.
If I remove the ?EXEC (that serves to forbid EXIT in compilation
state), suddenly it performs the useful function of ending INTERPRET.
Making Forth better by removing a line, isn't that the tao of
Forth?
Anton Ertl schrieb am Mittwoch, 20. April 2022 um 17:51:10 UTC+2:
"minf...@arcor.de" <minf...@arcor.de> writes:
none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:Gforth now also has closures that don't involve locals. E.g., you can
This confirms my suspicion that LOCAL is the root of all evil ;-)
You'll love closures then. :-)
define +FIELD and FCONSTANT as:
: +field ( n "name" -- )
[n:d + ;] alias ;
5 +field x
7 x . \ prints 12
What's happening here is that when +FIELD is running, the closure
consumes one data stack item (n); this is used to build a closure,
with the needed space allocated in the dictionary. The xt of the
closure is left on the stack, and the ALIAS creates a word X with that
xt as its execution semantics. When X is run, n (i.e., 5) is pushed
on the stack, and the "+" adds it to the 7.
So the closure mechanism transfers one data stack item from closure
creation time to closure execution time (and transferring data from
closure creation time to closure execution time is the functional
essence of closures, no locals needed for that). We also have
variants for one double ("[d:d") and one float ("[f:d"), and for
allocating the closure on the locals stack ("[n:l") and on the heap
("[n:h"), and all nine combinations. We don't have variants for more
stack items; you can use the closures that involve locals if you need
that.
Thanks for that gforth example. IIUC it puts the burden of "lexical scoping" >on programmer's shoulders.
Second big step would be do this with named locals i.e. put the burden on >compiler's shoulders and let programmers enjoy more readable code.
Gforth now also has closures that don't involve locals. E.g., you can >>define +FIELD and FCONSTANT as:
: +field ( n "name" -- )
[n:d + ;] alias ;
5 +field x
7 x . \ prints 12
What's happening here is that when +FIELD is running, the closure
consumes one data stack item (n); this is used to build a closure,
with the needed space allocated in the dictionary. The xt of the
closure is left on the stack, and the ALIAS creates a word X with that
xt as its execution semantics. When X is run, n (i.e., 5) is pushed
on the stack, and the "+" adds it to the 7.
So the closure mechanism transfers one data stack item from closure >>creation time to closure execution time (and transferring data from
closure creation time to closure execution time is the functional
essence of closures, no locals needed for that). We also have
variants for one double ("[d:d") and one float ("[f:d"), and for
allocating the closure on the locals stack ("[n:l") and on the heap >>("[n:h"), and all nine combinations. We don't have variants for more
stack items; you can use the closures that involve locals if you need
that.
So it is similar to
: CONSTANT , DOES> @ ;
or defined by a class/oo mechanism :
_ class CONSTANT M: @ M; , endclass
What then is de big deal?
On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
In article <2022Apr1...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
Probably not, because EXIT has no interpretation semantics. The EXITA standard program according ISO can not use EXIT in interpretation
and INTERPRET implementations on some systems may work to achieve the
effects you have in mind (although I doubt that it works for INCLUDED
and friends on many systems, because INCLUDED is one level out from
the processing that EVALUATE and LOAD perform).
state. That is not a dogma, but a design decision.
In my implementation EXIT performs a return, i.e. pops a
continuation address for the program counter, and jumps there.
If I remove the ?EXEC (that serves to forbid EXIT in compilation
state), suddenly it performs the useful function of ending INTERPRET.
Making Forth better by removing a line, isn't that the tao of
Forth?
[Applause.]
On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
In article <2022Apr1...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
Probably not, because EXIT has no interpretation semantics. The EXITA standard program according ISO can not use EXIT in interpretation
and INTERPRET implementations on some systems may work to achieve the
effects you have in mind (although I doubt that it works for INCLUDED
and friends on many systems, because INCLUDED is one level out from
the processing that EVALUATE and LOAD perform).
state. That is not a dogma, but a design decision.
In my implementation EXIT performs a return, i.e. pops a
continuation address for the program counter, and jumps there.
If I remove the ?EXEC (that serves to forbid EXIT in compilation
state), suddenly it performs the useful function of ending INTERPRET.
Making Forth better by removing a line, isn't that the tao of
Forth?
[Applause.]
Except ANSForth isn't Forth. It's a federation (or confederation if one >believes it was a choice) of Forth implementers. EXIT in interpret state
is one of the many things it couldn't get agreement upon. Mistaking
ANSForth for a created language is what results in the 'I could have done
it better' complaints. Well yes, almost anyone could have created a better >Forth but that's not what was being offered.
albert@cherry.(none) (albert) writes:
Gforth now also has closures that don't involve locals. E.g., you can >>>define +FIELD and FCONSTANT as:
: +field ( n "name" -- )
[n:d + ;] alias ;
5 +field x
7 x . \ prints 12
What's happening here is that when +FIELD is running, the closure >>>consumes one data stack item (n); this is used to build a closure,
with the needed space allocated in the dictionary. The xt of the
closure is left on the stack, and the ALIAS creates a word X with that
xt as its execution semantics. When X is run, n (i.e., 5) is pushed
on the stack, and the "+" adds it to the 7.
So the closure mechanism transfers one data stack item from closure >>>creation time to closure execution time (and transferring data from >>>closure creation time to closure execution time is the functional
essence of closures, no locals needed for that). We also have
variants for one double ("[d:d") and one float ("[f:d"), and for >>>allocating the closure on the locals stack ("[n:l") and on the heap >>>("[n:h"), and all nine combinations. We don't have variants for more >>>stack items; you can use the closures that involve locals if you need >>>that.
So it is similar to
: CONSTANT , DOES> @ ;
or defined by a class/oo mechanism :
_ class CONSTANT M: @ M; , endclass
What then is de big deal?
Yes, I selected an example that Forth programmers may be more familiar
with than the numeric integration example that I used more heavily in
the paper and that has led to complaints that people unfamiliar with >numerical integration cannot follow the example.
So yes, you can implement this +FIELD with DOES>:
: +field ( n "name" -- )
create ,
does> @ + ;
(BTW, the stack effect of all +FIELD examples I gave in this thread is >non-standard, but that should not detract from the point of the
example (at least nobody has complained about it yet).
Here are some differences between closures and CREATE...DOES>:
* A closure is nameless (so the code above uses ALIAS to give it a
name); there is no standard way to make a nameless CREATEd word.
* A closure can be allocated in the dictionary (as done here), on the
heap, on the locals stack, or using a user-supplied allocation word.
With CREEATE..DOES>, you are limited to dictionary allocation (and
its lifetime).
* [N:D takes a cell off the stack at closre creation time, and pushes
it on closure execution time, without the programmer having to
manage the data in between (other than supplying an allocation
method). With CREATE..DOES>, the programmer has to store the data
to the dictionary with "," and get it from there with @.
* [N:D can manage the data in any way it sees fit, and the programmer
knows very little about that. As a result, the data is immutable
for the program, so the closure could be inlined, and the data could
be compiled as a literal (with a very sophisticated compiler). By
contrast, the user can change the data of a CREATE-+FIELD child with
BODY, so even a very sophisticated implementation has to compile afetch of that data.
Whether you consider these differences a big deal, is up to you.
- anton
In article <2022Apr23.191637@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
Here are some differences between closures and CREATE...DOES>:
* A closure is nameless (so the code above uses ALIAS to give it a
name); there is no standard way to make a nameless CREATEd word.
If you allow me to use the alternative oo-ish definition of constant
`` _ class CONSTANT M: get @ M; , endclass ''
gives me also a BUILD-CONSTANT that does exactly that,
...* [N:D can manage the data in any way it sees fit, and the programmer
knows very little about that. As a result, the data is immutable
for the program, so the closure could be inlined, and the data could
be compiled as a literal (with a very sophisticated compiler). By
contrast, the user can change the data of a CREATE-+FIELD child with
BODY, so even a very sophisticated implementation has to compile afetch of that data.
Rules that an optimiser can follow, are in this context maybe
simpler. I don't believe in the complicated things a compiler
can do if she is allowed to assume that the e.g. a c-program does
nothing "undefined". (As do you apparently.)
Whether you consider these differences a big deal, is up to you.
For the moment I will prefer simple additions to Forth to
achieve similar goals.
Implementing [N:D and friends is pretty simple. Currently closures.fs
has 227 lines (including comment lines and empty lines), but includes
a lot of extra functionality.
How big are your simple additions?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
albert@cherry.(none) (albert) writes:<SNIP>
Better get rid of ?EXEC and ?COMP everywhere. They only check STATE
at the time when the containing words are performed, which is not
appropriate for checking whether the interpretation semantics or the >compilation semantics of a word are performed.
It's fascinating that you used ?EXEC for EXIT. My guess is that this >happened the following way: You saw that EXIT has no interpretation >semantics, so you put in ?COMP. Of course this failed, probably on
the first exection of EXIT. So the ?COMP was obviously wrong. As a
remedy you thought you would put in ?EXEC, and it seemed to work (you
have no immediate words containing EXIT), so you left it in, but it's
just as wrong as ?COMP.
As for having EXIT with interpretation semantics, that's something we
wanted to support, as detailed in the grandparent posting. It's
certainly a good idea to add useful functionality beyond the standard,
but in the benefit was not worth the cost.
As for INTERPRET, if you want it standardized, make a proposal. You
may want to provide some usage statistics to support your case.
- antonGroetjes Albert
--
In article <t428i6$16k9$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
On 23/04/2022 23:22, luser droog wrote:
On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
In article <2022Apr1...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
Probably not, because EXIT has no interpretation semantics. The EXITA standard program according ISO can not use EXIT in interpretation
and INTERPRET implementations on some systems may work to achieve the >>>> >effects you have in mind (although I doubt that it works for INCLUDED >>>> >and friends on many systems, because INCLUDED is one level out from
the processing that EVALUATE and LOAD perform).
state. That is not a dogma, but a design decision.
In my implementation EXIT performs a return, i.e. pops a
continuation address for the program counter, and jumps there.
If I remove the ?EXEC (that serves to forbid EXIT in compilation
state), suddenly it performs the useful function of ending INTERPRET.
Making Forth better by removing a line, isn't that the tao of
Forth?
[Applause.]
Except ANSForth isn't Forth. It's a federation (or confederation if one >>believes it was a choice) of Forth implementers. EXIT in interpret state >>is one of the many things it couldn't get agreement upon. Mistaking >>ANSForth for a created language is what results in the 'I could have done >>it better' complaints. Well yes, almost anyone could have created a better >>Forth but that's not what was being offered.
You could not accuse me of not embracing ANSForth. Proposals in this way serve as incremental improvements of Forth.
Considering ANSForth as dogma, was that something Jeff Fox and Chuck Moore warned about?
Groetjes Albert
To have an idea of code I use woc (words of code),
the count doesn't differ between file source and block source.
The woc-count is 615 in total. The loc-count is not saying much
depending how generous one is regarding blank lines, or
the presence of the GPL2 copyright in full.
The woc count is also not sensitive to a horizontal or
vertical layout.
----------------------
#!/bin/sh
cat $1 |\
sed -e 's/\\ .*//' |\
sed -e 's/( [^)]*)//g' |\
sed -e '/\<DOC\>/,/\<ENDDOC\>/d'|\
sed -e 's/\\D .*//' |\
wc -w
exit
----------------------
On 23/04/2022 23:22, luser droog wrote:
On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
In article <2022Apr1...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
Probably not, because EXIT has no interpretation semantics. The EXITA standard program according ISO can not use EXIT in interpretation
and INTERPRET implementations on some systems may work to achieve the
effects you have in mind (although I doubt that it works for INCLUDED
and friends on many systems, because INCLUDED is one level out from
the processing that EVALUATE and LOAD perform).
state. That is not a dogma, but a design decision.
In my implementation EXIT performs a return, i.e. pops a
continuation address for the program counter, and jumps there.
If I remove the ?EXEC (that serves to forbid EXIT in compilation
state), suddenly it performs the useful function of ending INTERPRET.
Making Forth better by removing a line, isn't that the tao of
Forth?
[Applause.]Except ANSForth isn't Forth. It's a federation (or confederation if one believes it was a choice) of Forth implementers. EXIT in interpret state
is one of the many things it couldn't get agreement upon. Mistaking
ANSForth for a created language is what results in the 'I could have done
it better' complaints. Well yes, almost anyone could have created a better Forth but that's not what was being offered.
On Saturday, April 23, 2022 at 8:19:05 PM UTC-5, dxforth wrote:
On 23/04/2022 23:22, luser droog wrote:
On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:Except ANSForth isn't Forth. It's a federation (or confederation if one
In article <2022Apr1...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
Probably not, because EXIT has no interpretation semantics. The EXITA standard program according ISO can not use EXIT in interpretation
and INTERPRET implementations on some systems may work to achieve the
effects you have in mind (although I doubt that it works for INCLUDED
and friends on many systems, because INCLUDED is one level out from
the processing that EVALUATE and LOAD perform).
state. That is not a dogma, but a design decision.
In my implementation EXIT performs a return, i.e. pops a
continuation address for the program counter, and jumps there.
If I remove the ?EXEC (that serves to forbid EXIT in compilation
state), suddenly it performs the useful function of ending INTERPRET.
Making Forth better by removing a line, isn't that the tao of
Forth?
[Applause.]
believes it was a choice) of Forth implementers. EXIT in interpret state
is one of the many things it couldn't get agreement upon. Mistaking
ANSForth for a created language is what results in the 'I could have done
it better' complaints. Well yes, almost anyone could have created a better >> Forth but that's not what was being offered.
I don't know enough about the whole story to weigh in there,
just saying that Albert made a compelling point. So compelling
that the rest of the story kinda reads as just noise to me.
If I can figure out how to use it, my personal forth will do it this way.
And that's all I'm likely to use anyway.
Until I stumble across something better.
EXIT was a regular word in Forth-79/83 until someone decided they could 'improve' on it.
On Monday, April 25, 2022 at 4:16:53 AM UTC+2, dxforth wrote:
EXIT was a regular word in Forth-79/83 until someone decided they could
'improve' on it.
I agree. In 4tH, having Forth-79 roots, EXIT is still a very simple
word: get TORS,
put it in the instruction pointer and continue (Ok, some checks are made
- agreed).
It's not that much different from a RET instruction in Z80 - and why
should it? It's
just there as a counterpart for a CALL.
Of course, if you add several other services (like taking care of
locals) it will most
probably become a bit beefier. That's one of the reasons why I don't
like locals in
the first place.
Of course I love them in C - but C is not Forth.
And those who have a history with my ramblings here won't be too surprised to >hear that I don't like over-complicated Forths, which absolutely improve
in "ease of
use", but IMHO lose this "simple elegance" quality of Forth I fell in love with.
So dxforth, I concur with you on this point.
Hans Bezemer
So dxforth, I concur with you on this point.So do I, but it is possible to make life easier without compromising
the simplicity of the kernel Forth.
On Thursday, April 28, 2022 at 3:13:55 PM UTC+2, none albert wrote:
So dxforth, I concur with you on this point.So do I, but it is possible to make life easier without compromising
the simplicity of the kernel Forth.
True - in 4tH (with it's wildly different architecture) I see the same thing >happening. But due to the radical division between "compilation" and >"interpretation", I see it's not happening in the (inner) interpreter. It's >happening in the compiler - or even the tools on top of the compiler, like >the preprocessor.
The VM hasn't become much smarter at all. In 10 (!) years, that code has
seen only 15 changes - roughly a third of them C syntax related, a third of >them architecture related and the final third of them behavior related (incl. >new functionality).
The compiler has seen about fifty changes in the meanwhile - most them >behavior related.
Translated to the classical Forth architecture - primitives and inner >interpreter
have hardly changed.
I dunno how that works out for other Forths - I think it would be an interesting
question, though.
Hans Bezemer
Don't stop looking for simplications. I recently managed the central (FIND) word from 6 to 3 labels and eliminate a third of the underlyingI recently reprogrammed the inner Accept() word. I was hesitant to touch it since - although murky - it had worked absolutely fine for three decades.
~MATCH word.
The discotheque principle is useful. Nobody gets in, before somebody gets out. If you add a word, an other word has to get removed.I have this policy that 4tH has 106 reserved tokens. For every one added, one must disappear. That leaves someone who wants to expand on it a clean
This would be a useful principle for laws also.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 51:40:32 |
| Calls: | 6,712 |
| Calls today: | 5 |
| Files: | 12,243 |
| Messages: | 5,355,044 |
| Posted today: | 1 |