Can we have a convention for naming parsing words?
What is your considerations?
[1] Naming for parsing words https://github.com/ForthHub/discussion/discussions/112
Namely, I mean the words for which compilation semantics include >scanning/parsing the input stream, and, if interpretation semantics are >defined for the word, they include parsing too. Especially, when the
word parses one or several lexemes.
Can we have a convention for naming parsing words?
What is your considerations?
[1] Naming for parsing words >https://github.com/ForthHub/discussion/discussions/112
--
Ruvim
In my post [1] in ForthHub I compare the different variants for naming parsing words.
Namely, I mean the words for which compilation semantics include scanning/parsing the input stream, and, if interpretation semantics are defined for the word, they include parsing too. Especially, when the
word parses one or several lexemes.
Can we have a convention for naming parsing words?
What is your considerations?
[1] Naming for parsing words https://github.com/ForthHub/discussion/discussions/112
On 18/05/2022 02:23, Ruvim wrote:Well, I think you mean by parsing - cutting up the TIB. In that case,
In my post [1] in ForthHub I compare the different variants for naming parsing words.
Can we have a convention for naming parsing words?
What is your considerations?
On Tuesday, May 17, 2022 at 11:23:57 AM UTC-5, Ruvim wrote:
Can we have a convention for naming parsing words?
What is your considerations?
[1] Naming for parsing words
https://github.com/ForthHub/discussion/discussions/112
Bah, that a parsing word with immediate parameter is 'better readable' than
a postfix operator. Most definitions contain postfix words and mixing in parsing words is style conflict so I avoid parsing words.
May mean I miss some
peephole optimizing opportunities but that doesn't impact me. If I had
to have a parsing word I would choose the form 'foo( parm )' and I won't be confusing it as a comment.
Do you avoid the standard parsing words?
For example: "[']" "postpone" 's"' 'abort"'
And what about defining words?
I'm wondered why people continue to use parsing words if they dislike them.
Why not introduce new words like:
:def ( sd.name -- ) ( C: -- colon-sys )
does-created ( xt sd.name -- )
To use them as:
`foo :def 123 . ;
[: @ . ;] `bar does-created 123 ,
foo bar \ prints "123 123"
And after that, what to do with "[if]" and "[undefined]"?
123 constant( foo )
create( bar ) 456 ,
:( baz ) ( -- x ) foo postpone( foo bar ) ;
:( test-baz ) :( baz2 ) baz drop postpone( @ ; ) ;
t{ test-baz baz2 -> 123 456 }t
Hm.. why not.
Do you avoid the standard parsing words?
On 2022-05-17, S Jack wrote:
Bah, that a parsing word with immediate parameter is 'better readable' than >> a postfix operator. Most definitions contain postfix words and mixing in
parsing words is style conflict so I avoid parsing words.
Do you avoid the standard parsing words?
For example: "[']" "postpone" 's"' 'abort"'
And what about defining words?
I'm wondered why people continue to use parsing words if they dislike them.
On Tuesday, May 17, 2022 at 11:23:57 AM UTC-5, Ruvim wrote:
Can we have a convention for naming parsing words?
What is your considerations?
[1] Naming for parsing words
https://github.com/ForthHub/discussion/discussions/112
Bah, that a parsing word with immediate parameter is 'better readable' than >> a postfix operator. Most definitions contain postfix words and mixing in
parsing words is style conflict so I avoid parsing words.
Do you avoid the standard parsing words?
For example: "[']" "postpone" 's"' 'abort"'
And what about defining words?
I'm wondered why people continue to use parsing words if they dislike them.
Why not introduce new words like:
:def ( sd.name -- ) ( C: -- colon-sys )
does-created ( xt sd.name -- )
To use them as:
`foo :def 123 . ;
[: @ . ;] `bar does-created 123 ,
foo bar \ prints "123 123"
t{ test-baz baz2 -> 123 456 }t
Hm.. why not.
--
Ruvim
Do you avoid the standard parsing words?In my programming: no - they're just too handy. Imagine not having
For example: "[']" "postpone" 's"' 'abort"'
And what about defining words?
Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into interpretive code... which (like prefixed numbers) violate the rule "keep it simple", since
Instead of S" BLA", I write "BLA".
Instead of POSTPONE FOO, I write ]] FOO [[. Especially nice forI think that it's a beautiful solution - although due to 4tH's architecture,
multiple words.
I think this comes form a desire to "beautify the language" - may beWhy not introduce new words like:Why yes? And please explain the definition of TEST-BAZ and BAZ2.
On Wednesday, May 18, 2022 at 4:30:45 PM UTC+2, Ruvim wrote:
Do you avoid the standard parsing words?In my programming: no - they're just too handy. Imagine not having
For example: "[']" "postpone" 's"' 'abort"'
And what about defining words?
S" and having to poke in characters into a string one by one - no
matter what mechanism you throw at it. I even confiscated C"
for that reason in 4tH to avoid too many C, ;-)
But I can tell you they're a pain in 4tH without a preprocessor. In
that particular variant ALL parsing words have to be hardcoded.
And then there are those STANDARD "parsing words" that are so
braindead that the only way I WANT to support them is by only
supporting them in that preprocessor.
.. like ACTION-OF (needless: DEFER@ can do that);
.. like BEGIN-STRUCTURE (overly complex and VERY unForth-like
compared to "0 .. CONSTANT).
.. like SYNONYM (it's much easier to look up the behavior first and,
if that succeeds, make the proper dictionary entry - instead of
making a dictionary entry and then fail at the most crucial moment).
The latter could even have been better if they followed the ALIAS rule
' FOO ALIAS BAR
Because that is in essence what you're doing and IMHO clearer than
SYNONYM BAR FOO
4tH supports a parsing AKA which does EXACTLY that:
AKA FOO BAR
Although (also from readability), this is IMHO much clearer:
' FOO AKA BAR
But the former is found at least in SOME Forths, so almost COMUS. ;-)
Hans Bezemer--
DEFER BAR
'FOO IS BAR
is also an abomination.
This must be
'FOO 'BAR TRANSFER-EXECUTION-BEHAVIOUR
But I'm inasmuch a purist where I'd like to keep things simple and clear - >even a little bit less abstract.
E.g. I'd like the "three rule engine" intact, which says:
(1) If it's a word, execute it;
(2) If it's not a word, convert it to a number;
(3) If it's not a number either, it's an error.
"Simplicity" means "maintainability". "Maintainability" means "less bugs". >(See: "Does Software Decay").
DEFER BARYou're kidding, right? I desperately hope so. Because IS is just another
'FOO IS BAR
is also an abomination.
This must be
'FOO 'BAR TRANSFER-EXECUTION-BEHAVIOUR
Neither FOO nor BAR is executed, so their dea ("name tokens")
should be used.
On Friday, May 20, 2022 at 3:01:57 PM UTC+2, none albert wrote:
DEFER BAR
'FOO IS BAR
is also an abomination.
Hans Bezemer <the.bee...@gmail.com> writes:Compilation sets STATE and enters the compiler. ";" compiles EXIT,
No compilation?
The problem with the traditional interpreter is thatIMHO it should not even recognize doubles. I consider it to be an add-on.
* It does not recognize floats.
* Without number prefixes we get bugs in the code from using (sticky)Gee, never happened to me. Maybe a programmer discipline issue? IMHO
HEX.
* Without the tick-recognizer I get bugs from writing ' where ['] is appropriate and vice versa, and testing compiled code interpretivelyGee, never happened to me. Maybe a programmer discipline issue? IMHO
is cumbersome.
* Without the string-recognizer, we need to use S\" (or S"), andNever had that problem. Could be an architecture issue - idunno:
implementing these words properly is apparently too complex for most
Forth systems.
On Friday, May 20, 2022 at 6:05:05 PM UTC+2, Anton Ertl wrote:
* It does not recognize floats.IMHO it should not even recognize doubles. I consider it to be an add-on.
I know it's a quite radical idea and most certainly would break a LOT
of code, I consider it to be architectural more solid. You may have
another opinion.
Gee, never happened to me. Maybe a programmer discipline issue?[...]
Gee, never happened to me. Maybe a programmer discipline issue?
* Without the string-recognizer, we need to use S\" (or S"), andNever had that problem. Could be an architecture issue - idunno:
implementing these words properly is apparently too complex for most
Forth systems.
The reason I'm posting this is: I can't comment on the rationale
others peoples implementations. I can - however - comment on
mine.
You can burden the programmers with some tasks, claim that you have aTry Java. You'll find it impressive. It's built EXACTLY from that perspective. Dijkstra LOVED it.
simple system that supposedly reduces bugs, and dismiss all bugs
arising from that as prgrammer discipline issues (which does not make
them go away).
I prefer to avoid such issues by giving the programmers less
burdensome ways to express the programs, e.g., number prefixes and the tick-recognizer.
...
Concerning VALUEs, GForth does not allow ADDR for them, so you have to
use IS to change them. And that's good, because it means that @ and !
don't access the value.
On 21/05/2022 20:26, Anton Ertl wrote:
...
Concerning VALUEs, GForth does not allow ADDR for them, so you have to
use IS to change them. And that's good, because it means that @ and !
don't access the value.
So assembler routines can't access VALUEs ?
On Saturday, May 21, 2022 at 8:11:49 PM UTC+2, Anton Ertl wrote:
I prefer to avoid such issues by giving the programmers lessTry Java. You'll find it impressive. It's built EXACTLY from that perspective.
burdensome ways to express the programs, e.g., number prefixes and the
tick-recognizer.
Dijkstra LOVED it.
Hans Bezemer <the.bee...@gmail.com> writes:
On Saturday, May 21, 2022 at 8:11:49 PM UTC+2, Anton Ertl wrote:In my experience Java is quite burdensome.
I prefer to avoid such issues by giving the programmers lessTry Java. You'll find it impressive. It's built EXACTLY from that perspective.
burdensome ways to express the programs, e.g., number prefixes and the
tick-recognizer.
Dijkstra LOVED it.
I actually tool the effort to check your claim, and what I found
indicates that it is a blatant lie: <https://www.cs.utexas.edu/users/EWD/transcriptions/OtherDocs/Haskell.html>
Some quotes from this letter by Dijkstra:
|their undergraduate curriculum has not recovered from the transition
|from Pascal to something like C++ or Java.
|Haskell, though not perfect, is of a quality that is several orders of |magnitude higher than Java, which is a mess
- 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
|Haskell, though not perfect, is of a quality that is several orders of |magnitude higher than Java, which is a mess
dxforth <dxforth@gmail.com> writes:
On 21/05/2022 20:26, Anton Ertl wrote:
...
Concerning VALUEs, GForth does not allow ADDR for them, so you have to
use IS to change them. And that's good, because it means that @ and !
don't access the value.
So assembler routines can't access VALUEs ?
If they know where to find them, they can. The value might be in a
register, however; it also might be in a register in some parts of the
code, and in memory in other parts.
On 22/05/2022 17:16, Anton Ertl wrote:
So assembler routines can't access VALUEs ?
If they know where to find them, they can. The value might be in a
register, however; it also might be in a register in some parts of the
code, and in memory in other parts.
The choice whether a VALUE or a VARIABLE is used should have nothing to do >with whether one is using high-level or assembler.
dxforth <dxforth@gmail.com> writes:
On 22/05/2022 17:16, Anton Ertl wrote:
So assembler routines can't access VALUEs ?
If they know where to find them, they can. The value might be in a
register, however; it also might be in a register in some parts of the
code, and in memory in other parts.
The choice whether a VALUE or a VARIABLE is used should have nothing to do >>with whether one is using high-level or assembler.
If you feel this way, you as a system designer can devise the
interface between Forth and assembly language accordingly; or as a
user of a third-party Forth system, you can choose a Forth system that satisfies your requirement.
Gforth seems to be the 'odd man out' here. A user may well ask why has
it made access to VALUEs so difficult.
dxforth <dxforth@gmail.com> writes:
Gforth seems to be the 'odd man out' here. A user may well ask why has
it made access to VALUEs so difficult.
Difficult? Let's phrase the question in a less loaded way:
Q: Why does Gforth not support ADDR on value-flavoured words?
A: E.g., because without ADDR a future version of Gforth can keep the
value V in a register in the loop
?do ... v ... @ ... to v ... loop
wheras with ADDR V that's not generally possible, and those cases that
are possible require a lot of compiler complexity.
Q: But I want to port code that uses ADDR V to Gforth?
A: Either define V as a VARUE (like a VALUE, but supports ADDR), or
just prepend the code with
: VALUE VARUE ;
On 23/05/2022 21:23, Anton Ertl wrote:
Q: Why does Gforth not support ADDR on value-flavoured words?
A: E.g., because without ADDR a future version of Gforth can keep the
value V in a register in the loop
?do ... v ... @ ... to v ... loop
wheras with ADDR V that's not generally possible, and those cases that
are possible require a lot of compiler complexity.
Keeping things in registers usually refers to constants or locals.
My understanding of VALUEs is that they're read far more often than
written and, as such, your use above would appear to be something of
an anomaly.
FWIW I don't expect ADDR to be used much either
When a value is both read and written in a loop, allocating
it in a register is particularly beneficial. Here's an example:
: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
0 value x
: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
[/tmp:130361] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo1 bye"
[/tmp:130362] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo2 bye"
On a Skylake this produces:
cycles instructions
1012951207 4010090522 foo1
5060982449 6010156213 foo2
So allocating x in a register (what lxf does for stack items) is 5
times faster than allocating it in memory (what lxf does for values).
FWIW I don't expect ADDR to be used much either
Exactly. But the possible future use of ADDR on a value means that it
always has to be kept in memory. So if you support ADDR on a value,
you have to pay for it even if you don't use it (on that value, or at
all).
And that's why Gforth does not support ADDR on values. If you want to
use ADDR on a word, you can define this particular word with VARUE.
- 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
And just to show that it's not as bad for read-only or write-only
memory accesses:
: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
0 value x
0 value y
: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
: foo3 to y 0 begin y over u> while 1+ repeat drop ;
: foo4 0 begin 2dup u> while 1+ dup to y repeat 2drop ;
cycles instructions vfxlin 4.72
1012848419 4009410376 foo1 registers
5060035003 6010211435 foo2 read+write
1900018814 4009598660 foo3 read-only
1012666250 5009454583 foo4 write-only
dxforth <dxforth@gmail.com> writes:
...
Keeping things in registers usually refers to constants or locals.
Sure, if you support ADDR, you cannot keep values in registers in many situations (and the remaining situations are probably so few that you
just keep them in memory all the time).
But there are also those who advocate not using locals, and to use
variables or values instead. Aren't you one of them? Anyway, for
those usages, among others, it would be beneficial to keep values in registers.
My understanding of VALUEs is that they're read far more often than
written and, as such, your use above would appear to be something of
an anomaly.
Possibly. When a value is both read and written in a loop, allocating
it in a register is particularly beneficial. Here's an example:
: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
0 value x
: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
On Tuesday, May 24, 2022 at 6:53:55 PM UTC+2, Anton Ertl wrote:
[..]
And just to show that it's not as bad for read-only or write-only
memory accesses:
: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
0 value x
0 value y
: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
: foo3 to y 0 begin y over u> while 1+ repeat drop ;
: foo4 0 begin 2dup u> while 1+ dup to y repeat 2drop ;
cycles instructions vfxlin 4.72
1012848419 4009410376 foo1 registers
5060035003 6010211435 foo2 read+write
1900018814 4009598660 foo3 read-only
1012666250 5009454583 foo4 write-only
Hmm, weird. On iForth it is permutated:
FORTH> #1000000000 TO #times TEST
foo1 0.212 seconds elapsed.
foo2 0.221 seconds elapsed.
foo3 0.213 seconds elapsed.
foo4 0.425 seconds elapsed. ok
On 24/05/2022 20:48, Anton Ertl wrote:
: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
0 value x
: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
That's where I would use a VARIABLE
which optimizing compilers can
can keep in a register if they wish.
The example code I previously
posted has one VALUE referenced once and two VARIABLEs each referenced
twice. If I were going to prioritize anything for register use, it
would be VARIABLEs as they're used more often.
dxforth <dxforth@gmail.com> writes:
On 24/05/2022 20:48, Anton Ertl wrote:
: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
0 value x
: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
That's where I would use a VARIABLE
I certainly used to think that variables are the Forth way, and that
one should use values only for almost-constants that are not changed
in compiled code.
But values (without ADDR) have a nice property, as
discussed in this thread.
which optimizing compilers can
can keep in a register if they wish.
Forget it. This optimization is as hard for variables as for varues.
It is easy for values. A Forth meme is that you should not burden the compiler with jobs that the programmer can perform. And as it
happens, values make the compiler's job easier than varues or
variables, so if you want this optimization, use values!
My guess is that's because you are running it on a Zen3
CPU, where the hardware has special optimizations for avoiding the
memory dependence latency we see on the Skylake.
Here's the cycles/iteration that I see on more recent CPUs than the
Skylake (using lxf):
foo1 foo2 foo3 foo4
1 8 1 1 Zen2 (Ryzen 3900X)
1 1 1 1 Zen3 (Ryzen 5800X)
1 1.8 1 1 Rocket Lake (Xeon W1370P)
So Rocket Lake obviously optimizes this case, too, but apparently
there is some residue.
That's where I would use a VARIABLE - which optimizing compilers can
can keep in a register if they wish. The example code I previously
posted has one VALUE referenced once and two VARIABLEs each referenced
twice. If I were going to prioritize anything for register use, it
would be VARIABLEs as they're used more often.
VALUEs in forth were conceived as self-fetching VARIABLEs. Which was
fine until one had to write to them. They're in CORE-EXT because they
didn't replace anything nor add anything. Syntactic sugar with pros
and cons is how I view them. I'll use them - but not when VARIABLEs
are the better choice.
...
And I find that I tend to do VALUEs often when I can initialize a VARIABLE - like VARIABLE in Forth-79.
On 26/05/2022 06:23, Hans Bezemer wrote:
...
And I find that I tend to do VALUEs often when I can initialize a VARIABLE - >> like VARIABLE in Forth-79.
Given VALUEs will change (else one would use CONSTANT) it might have been >better to omit the initial value.
In the app below every VALUE was defined with a dummy.
\ Program constants
0 value #TERMS \ number of terminals in DTA file
\ Storage areas allocated at run-time
here value IN-BASE ( -- a ) \ in-file
here value DTA-BASE ( -- a ) \ dta-file
here value TBUF ( -- a ) \ temp terminal buffer
here value SBUF ( -- a ) \ swap/work buffer
here value IBUF ( -- a ) \ console input
here value XBUF ( -- a ) \ terminal index
dxforth <dxforth@gmail.com> writes:
On 26/05/2022 06:23, Hans Bezemer wrote:
...
And I find that I tend to do VALUEs often when I can initialize a VARIABLE -
like VARIABLE in Forth-79.
From Forth-79:
|VARIABLE 227
| A defining word executed in the form:
| VARIABLE <name>
| to create a dictionary entry for <name> and allot two bytes
| for storage in the parameter field. The application must
| initialize the stored value.
In fig-Forth VARIABLE took the initial value from the stack. I miss
it every time I use VARIABLE.
Given VALUEs will change (else one would use CONSTANT) it might have been >>better to omit the initial value.
No. You need to initialize a variable (or value) before reading its
value. So the way to ensure this is to initialize it right after
definition:
variable where-index -1 where-index !
This is much more cumbersome than fig-Forth's
-1 variable where-index
At least they got it right for VALUE.
In the app below every VALUE was defined with a dummy.
A defined dummy helps avoid Heisenbugs, and can help find bugs.
\ Program constants
0 value #TERMS \ number of terminals in DTA file
You have more than 0 terminals at the start?
\ Storage areas allocated at run-time
here value IN-BASE ( -- a ) \ in-file
here value DTA-BASE ( -- a ) \ dta-file
here value TBUF ( -- a ) \ temp terminal buffer
here value SBUF ( -- a ) \ swap/work buffer
here value IBUF ( -- a ) \ console input
here value XBUF ( -- a ) \ terminal index
I work on systems where accessing memory near 0 produces an exception,
so initializing addresses as 0 helps find bugs quickly where the
allocation has not happened before the first read. Without
initialization, the bug might go unnoticed for longer, making it
harder to find.
Defining x VALUE FOO is misleading as it suggests FOO will be x
whenever the program is run.
dxforth <dxf...@gmail.com> writes:
On 23/05/2022 21:23, Anton Ertl wrote:
Q: Why does Gforth not support ADDR on value-flavoured words?
A: E.g., because without ADDR a future version of Gforth can keep the
value V in a register in the loop
?do ... v ... @ ... to v ... loop
wheras with ADDR V that's not generally possible, and those cases that
are possible require a lot of compiler complexity.
Keeping things in registers usually refers to constants or locals.Sure, if you support ADDR, you cannot keep values in registers in many situations (and the remaining situations are probably so few that you
just keep them in memory all the time).
But there are also those who advocate not using locals, and to use
variables or values instead. Aren't you one of them? Anyway, for
those usages, among others, it would be beneficial to keep values in registers.
My understanding of VALUEs is that they're read far more often than >written and, as such, your use above would appear to be something ofPossibly. When a value is both read and written in a loop, allocating
an anomaly.
it in a register is particularly beneficial. Here's an example:
: foo1 0 begin 2dup u> while 1+ repeat 2drop ;
0 value x
: foo2 0 to x begin dup x u> while x 1+ to x repeat drop ;
[/tmp:130361] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo1 bye"
[/tmp:130362] perf stat -e cycles -e instructions vfxlin "include xxx.fs 1000000000 foo2 bye"
On a Skylake this produces:
cycles instructions
1012951207 4010090522 foo1
5060982449 6010156213 foo2
So allocating x in a register (what lxf does for stack items) is 5
times faster than allocating it in memory (what lxf does for values).
FWIW I don't expect ADDR to be used much eitherExactly. But the possible future use of ADDR on a value means that it
always has to be kept in memory. So if you support ADDR on a value,
you have to pay for it even if you don't use it (on that value, or at
all).
And that's why Gforth does not support ADDR on values. If you want to
use ADDR on a word, you can define this particular word with VARUE.
- 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 26/05/2022 06:23, Hans Bezemer wrote:
...
And I find that I tend to do VALUEs often when I can initialize a VARIABLE -
like VARIABLE in Forth-79.
From Forth-79:
|VARIABLE 227
| A defining word executed in the form:
| VARIABLE <name>
| to create a dictionary entry for <name> and allot two bytes
| for storage in the parameter field. The application must
| initialize the stored value.
In fig-Forth VARIABLE took the initial value from the stack. I miss
it every time I use VARIABLE.
dxforth <dxforth@gmail.com> writes:
Defining x VALUE FOO is misleading as it suggests FOO will be x
whenever the program is run.
It only suggests that FOO is x until it gets updated. FOO should (if possible) have a legitimate and meaningful value at all times, rather
than a dummy value.
It only suggests that FOO is x until it gets updated. FOO should (if possible) have a legitimate and meaningful value at all times, rather
than a dummy value.
Paul Rubin <no.email@nospam.invalid> writes:
It only suggests that FOO is x until it gets updated. FOO should (if
possible) have a legitimate and meaningful value at all times, rather
than a dummy value.
Indeed, thus almost every language has initializers for things which can subsequently have their value changed.
Ruvim <ruvim.pinka@gmail.com> writes:
Do you avoid the standard parsing words?
For example: "[']" "postpone" 's"' 'abort"'
I avoid these unless there is some reason not to. In particular:
Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into interpretive code.
To use them as:
`foo :def 123 . ;
Why `FOO, not "FOO"?
Ruvim <ruvim.pinka@gmail.com> writes:
Do you avoid the standard parsing words?
For example: "[']" "postpone" 's"' 'abort"'
I avoid these unless there is some reason not to. In particular:
Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into interpretive code.
Instead of POSTPONE FOO, I write ]] FOO [[. Especially nice for
multiple words.
Instead of S" BLA", I write "BLA".
I don't use ABORT", not the least because I always have to look up the directiom of the flag.
Instead, I use THROW. If I need a new ball, I
create it with
"new ball" exception constant new-ball
And what about defining words?
I tend to use these. They have default compilation semantics and one
rarely wants to copy-paste them between compiled and interpreted code.
Of course, in those rare cases (i.e., when debugging a defining word),
I wish that they took their name argument from the stack.
I'm wondered why people continue to use parsing words if they dislike them.
In the four cases above, I do it when writing code that should work on
Forth systems that do not understand the better idioms, or when
demonstating something to an audience that may not be familiar with
the better idioms, and these idioms would distract from the point I am
trying to demonstrate.
Why not introduce new words like:
:def ( sd.name -- ) ( C: -- colon-sys )
does-created ( xt sd.name -- )
The question is if the benefit is worth the cost in these cases.
Cost: additional words (because we don't want to destandardize all
existing code). Benefit: rare, as mentioned above.
And after that, what to do with "[if]" and "[undefined]"?
And \ and (.
Ruvim <ruvim.pinka@gmail.com> writes:
123 constant( foo )
create( bar ) 456 ,
:( baz ) ( -- x ) foo postpone( foo bar ) ;
:( test-baz ) :( baz2 ) baz drop postpone( @ ; ) ;
t{ test-baz baz2 -> 123 456 }t
And please explain the definition of TEST-BAZ and BAZ2.
On Wednesday, May 18, 2022 at 9:30:45 AM UTC-5, Ruvim wrote:
Do you avoid the standard parsing words?
No. For new words where the choice is to make it parsing or postfix I choose postfix. I've re-defined some existing parsing words to be postifx such as FORGET and SEE:
' foo FORGET
' foo SEE
But I don't go for purity which usually leads to abominations. Note in
above tick is acceptable. It's a matter of using exceptions sparingly and where most effective. That's the art and of course not everyone is going
to agree on the choices.
But back to your original what should be standard convention for parsing
word syntax, my view:
General choices
1) foo bar bat
No syntax
One must know what foo bar and bat are.
2) foo: bar bat
Syntax indicates foo: a parsing word with bar as immediate parameter
but bat is undetermined, could be a second parameter to foo or an
operator.
3) foo( bar bat )
Syntax indicates foo( is parsing word and has two immediate parameters
bar and bat.
Choice (1) should be preferable to the Forth purist (DX, the.Bee).
Don't waste time worrying over syntax schemes.
Choice (2) proposed by Albert which works for me is a simple syntax for parsing words, sufficient since our use of parsing words will be limited.
Choice (3) is total explicit and should fit well in a more formal Forth which is standard Forth.
I think choice (3) is best for the standard. I'll probably be using choice (2) but that doesn't mean I'm changing ' to ': .
On 2022-05-19 18:47, Anton Ertl wrote:
Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into
interpretive code.
To quoting a word I prefer the form 'FOO (i.e. Tick vs Backtick) for the >following reasons:
- it is closer to "[']" and "'" (so it's already connotated with
quoting a word in Forth);
- it is also used for quoting in some other languages (e.g., in Lisp,
to quote a list).
Possible disadvantage of this choice are as follows.
- Sometimes Tick is an actual part of a name. But those who use names
starting with a Tick probably will not use recognizers, but parsing words.
- Tick is used for character literals in Gforth. But is was a
suboptimal choice, I think.
I think we should find some conventions for these forms (and maybe some >other), and give them names. After that, to avoid conflicts, a Forth
source code file (or code block) that relies on a convention, should
start with a declaration that mentions the convention's name.
The format of such a declaration probably should be standardized.
As an example, JavaScript uses "use strict" string literal as the first
item of a code block to declare strict mode.
We could use a list of recognizer names in the declaration. The scope of
this declaration (where this recognizers are in effect) should be
limited in obvious way.
Can we have a convention for naming parsing words?
From thees three variants, (3) looks better for me too.
But applying this rule to Colon seems not so pretty:
:( foo ) ... ;
For ` I have yet to
see someone write a word that starts with that.
In article <t62vui$1mi$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
On 2022-05-17, S Jack wrote:
On Tuesday, May 17, 2022 at 11:23:57 AM UTC-5, Ruvim wrote:
Can we have a convention for naming parsing words?
What is your considerations?
[1] Naming for parsing words
https://github.com/ForthHub/discussion/discussions/112
Bah, that a parsing word with immediate parameter is 'better readable' than >>> a postfix operator. Most definitions contain postfix words and mixing in >>> parsing words is style conflict so I avoid parsing words.
Do you avoid the standard parsing words?
For example: "[']" "postpone" 's"' 'abort"'
And what about defining words?
I'm wondered why people continue to use parsing words if they dislike them. >>
Why not introduce new words like:
:def ( sd.name -- ) ( C: -- colon-sys )
does-created ( xt sd.name -- )
To use them as:
`foo :def 123 . ;
[: @ . ;] `bar does-created 123 ,
foo bar \ prints "123 123"
Then I would prefer:
[: "hello world" TYPE ;] : hello
or even c++/java/.. compatible:
{ "hello world" TYPE } : hello
<SNIP>
t{ test-baz baz2 -> 123 456 }t
Test words benefit from 2 separate code sequences plugged in.
I use
REGRESS test-baz baz2 S: 123 456 <EOL>
On Saturday, May 28, 2022 at 4:32:30 PM UTC+2, Anton Ertl wrote:...
[..]
For ` I have yet to
see someone write a word that starts with that.
: ` &' PARSE \ #<string of server commands>#
On 19/05/2022 00:30, Ruvim wrote:
On 2022-05-17, S Jack wrote:
Bah, that a parsing word with immediate parameter is 'better readable' than >>> a postfix operator. Most definitions contain postfix words and mixing in >>> parsing words is style conflict so I avoid parsing words.
Do you avoid the standard parsing words?
For example: "[']" "postpone" 's"' 'abort"'
And what about defining words?
I'm wondered why people continue to use parsing words if they dislike them.
But do they [beyond the few that already exist]?
A few may enjoy creating
new parsing words (like the few that enjoy creating macros) but I wouldn't say either was intrinsic to Forth, or even popular. If creating new parsing words were popular, wouldn't there already be a convention for it?
https://pastebin.com/qpZLFc6h
In article <t60i6r$7m0$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
In my post [1] in ForthHub I compare the different variants for naming
parsing words.
Namely, I mean the words for which compilation semantics include
scanning/parsing the input stream, and, if interpretation semantics are
defined for the word, they include parsing too. Especially, when the
word parses one or several lexemes.
Can we have a convention for naming parsing words?
What is your considerations?
I am a proponent of outlawing parsing words, with an exception for denotations, say constants.
E.g 'DROP or "AAP" are parsed by ' and " and generate a constant,
independant of interpretation of compilation mode.
That made it possible to restrict the inspection of STATE to
where a word is interpreted or compiled.
The compilation STATE decides whether to compile it,
adding LIT or FLIT, or leave it on the stack.
Don't get upset, I don't propose it to the standard.
Parsing words can be handy in special purpose languages,
to honour expectations from users. That is a different matter.
A simple convention to end the parsing words with ':'.
FROM floating-point IMPORT: F* F** FLOG PI
In my post [1] in ForthHub I compare the different variants for naming parsing words.
Namely, I mean the words for which compilation semantics include scanning/parsing the input stream, and, if interpretation semantics are defined for the word, they include parsing too. Especially, when the
word parses one or several lexemes.
Can we have a convention for naming parsing words?
What is your considerations?
[1] Naming for parsing words https://github.com/ForthHub/discussion/discussions/112
On 2022-05-20 09:14, dxforth wrote:
On 19/05/2022 00:30, Ruvim wrote:
On 2022-05-17, S Jack wrote:
Bah, that a parsing word with immediate parameter is 'better readable' than
a postfix operator. Most definitions contain postfix words and mixing in >>> parsing words is style conflict so I avoid parsing words.
Do you avoid the standard parsing words?
For example: "[']" "postpone" 's"' 'abort"'
And what about defining words?
I'm wondered why people continue to use parsing words if they dislike them.
But do they [beyond the few that already exist]?
Yes, they/we do. For example, see use of "parse-name" in Forth code on
GitHub [1]. There are many cases of standard words definitions, but also
many cases of user defined parsing word.
Obviously, in the set of distinct parsing words, the user defined words
is a major part.
A few may enjoy creating
new parsing words (like the few that enjoy creating macros) but I wouldn't say either was intrinsic to Forth, or even popular. If creating new parsing words were popular, wouldn't there already be a convention for it?
https://pastebin.com/qpZLFc6h
The old convention was: don't use any special naming convention for
porcelain parsing word, they should look just like ordinary words.
For example: "[COMPILE]" and ASCII in Forth-79, POSTPONE in Forth-94
[1] Search results in GitHub for "language:forth parse-name' https://github.com/search?q=language%3Aforth+parse-name&type=code
--
Ruvim
On Saturday, 28 May 2022 at 18:41:48 UTC+2, Ruvim wrote:
On 2022-05-20 09:14, dxforth wrote:
A few may enjoy creating
new parsing words (like the few that enjoy creating macros) but I wouldn't >>> say either was intrinsic to Forth, or even popular. If creating new parsing >>> words were popular, wouldn't there already be a convention for it?
https://pastebin.com/qpZLFc6h
The old convention was: don't use any special naming convention for
porcelain parsing word, they should look just like ordinary words.
For example: "[COMPILE]" and ASCII in Forth-79, POSTPONE in Forth-94
One of the first things that struck me when I learned about the forth language
was the complete freedom to name words whatever you wanted.
I do not want to change that!
What you have presented might be very logical but it looks ugly and does not read well.
you can do recommendations but no standardization please!
: ip-in-subnet >r and r> = ;
: ip-in-subnet ['] and dip = ;
: ip-in-subnet 'and dip = ; \ Tick is for quoting a word
: ip-in-subnet `and dip = ; \ Backtick is for quoting a word
: ip-in-subnet dip' and = ;
: ip-in-subnet dip:and = ;
: ip-in-subnet dip( and ) = ;
: ip-in-subnet dip{ and } = ;
Ruvim <ruvim.pinka@gmail.com> writes:
Do you avoid the standard parsing words?
For example: "[']" "postpone" 's"' 'abort"'
I avoid these unless there is some reason not to. In particular:
Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into
interpretive code.
To quoting a word I prefer the form 'FOO (i.e. Tick vs Backtick) for the >following reasons:
- it is closer to "[']" and "'" (so it's already connotated with
quoting a word in Forth);
- it is also used for quoting in some other languages (e.g., in Lisp,
to quote a list).
Possible disadvantage of this choice are as follows.
- Sometimes Tick is an actual part of a name. But those who use names
starting with a Tick probably will not use recognizers, but parsing words.
- Tick is used for character literals in Gforth. But is was a
suboptimal choice, I think.
----
Ruvim
On Saturday, May 28, 2022 at 4:32:30 PM UTC+2, Anton Ertl wrote:
[..]
For ` I have yet to
see someone write a word that starts with that.
\ Try to talk to the Forth inside the server (If it's not C).
ALSO ENVIR
SERVER >UPC 'N'
<> [IF]
: ` &' PARSE \ #<string of server commands>#
{{
IFORTH!
DUP BOOTLINK @ CHANNEL-!
BOOTLINK @ CHANNEL-SEND
}} ;
[ELSE] : ` CR ." Cannot execute: ``" &' PARSE TYPE ." ''" ; [THEN]
PREVIOUS
-marcel
Can you share some more information on how you plan to implement it?
I can see some problems in that you can have more values defined then
you have registers available. In lxf I have 5 registers available for the c= >ode
generator, the rest are used by the system (stackpointers etc). Even if I o= >nly=20
use 1 register for values it will hurt the code generator. And what VALUE >would I dedicate that register to!
On a CPU with many register like ARM64 I could think of something like
1234 REGISTER-VALUE R1 test
to make test a value stored in register R1. This could be very useful
in some cases.
And after that, what to do with "[if]" and "[undefined]"?
And \ and (.
If they are with us in any case, we should not avoid them, but properly >(safely and readable) use them.
----
Ruvim
On Wednesday, May 18, 2022 at 9:30:45 AM UTC-5, Ruvim wrote:
Do you avoid the standard parsing words?
No. For new words where the choice is to make it parsing or postfix I choose >> postfix. I've re-defined some existing parsing words to be postifx such as >> FORGET and SEE:
' foo FORGET
' foo SEE
But I don't go for purity which usually leads to abominations. Note in
above tick is acceptable. It's a matter of using exceptions sparingly and
where most effective. That's the art and of course not everyone is going
to agree on the choices.
My choice is a recognizer for Tick, e.g. 'foo
And I think, we can avoid exceptions in some scopes.
But back to your original what should be standard convention for parsing
word syntax, my view:
General choices
1) foo bar bat
No syntax
One must know what foo bar and bat are.
2) foo: bar bat
Syntax indicates foo: a parsing word with bar as immediate parameter
but bat is undetermined, could be a second parameter to foo or an
operator.
--3) foo( bar bat )--
Syntax indicates foo( is parsing word and has two immediate parameters >> bar and bat.
Choice (1) should be preferable to the Forth purist (DX, the.Bee).
Don't waste time worrying over syntax schemes.
Choice (2) proposed by Albert which works for me is a simple syntax for
parsing words, sufficient since our use of parsing words will be limited.
Choice (3) is total explicit and should fit well in a more formal Forth which
is standard Forth.
I think choice (3) is best for the standard. I'll probably be using choice >> (2) but that doesn't mean I'm changing ' to ': .
Ruvim
No it isn't. If the namespace/vocabulary word is pushing itIn article <t60i6r$7m0$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
In my post [1] in ForthHub I compare the different variants for naming
parsing words.
Namely, I mean the words for which compilation semantics include
scanning/parsing the input stream, and, if interpretation semantics are
defined for the word, they include parsing too. Especially, when the
word parses one or several lexemes.
Can we have a convention for naming parsing words?
What is your considerations?
I am a proponent of outlawing parsing words, with an exception for
denotations, say constants.
E.g 'DROP or "AAP" are parsed by ' and " and generate a constant,
independant of interpretation of compilation mode.
That made it possible to restrict the inspection of STATE to
where a word is interpreted or compiled.
The compilation STATE decides whether to compile it,
adding LIT or FLIT, or leave it on the stack.
Don't get upset, I don't propose it to the standard.
Parsing words can be handy in special purpose languages,
to honour expectations from users. That is a different matter.
A simple convention to end the parsing words with ':'.
FROM floating-point IMPORT: F* F** FLOG PI
It seems, "FROM" is also a parsing word, then why is a trailing ':'
missed in the name?
And what do you think in regards to "constant", "variable", ":", andThat is the normal use case for getting a name from the input
other defining words? Would you like to outlaw them?
My position is that the parsed part (the immediate arguments), if any,
should be explicitly marked and easy readable, without reading manuals.
And if a porcelain parsing word is allowed to be used in compilation
state and in interpretation state, it should accept immediate arguments
in both cases (or explicitly show that an argument is passed via the
stack instead).
--
Ruvim
On 2022-05-29 00:34, P Falth wrote:
On Saturday, 28 May 2022 at 18:41:48 UTC+2, Ruvim wrote:
On 2022-05-20 09:14, dxforth wrote:
A few may enjoy creating
new parsing words (like the few that enjoy creating macros) but I wouldn't
say either was intrinsic to Forth, or even popular. If creating new parsing
words were popular, wouldn't there already be a convention for it?
https://pastebin.com/qpZLFc6h
The old convention was: don't use any special naming convention for
porcelain parsing word, they should look just like ordinary words.
For example: "[COMPILE]" and ASCII in Forth-79, POSTPONE in Forth-94
One of the first things that struck me when I learned about the forth languageOK. Could you please order by ugliness (from higher to lower) the
was the complete freedom to name words whatever you wanted.
I do not want to change that!
What you have presented might be very logical but it looks ugly and does not
read well.
following definitions for the word "ip-in-subnet ( x.ip x.ip-mask
x.ip-net -- flag )":
: ip-in-subnet >r and r> = ;
: ip-in-subnet ['] and dip = ;
: ip-in-subnet 'and dip = ; \ Tick is for quoting a word
: ip-in-subnet `and dip = ; \ Backtick is for quoting a word
: ip-in-subnet dip' and = ;
: ip-in-subnet dip:and = ;
: ip-in-subnet dip( and ) = ;
: ip-in-subnet dip{ and } = ;
See definitions for "dip", etc at https://github.com/ForthHub/discussion/discussions/112
you can do recommendations but no standardization please!Yes, naming conventions it not about standardization at all.
--
Ruvim
On Saturday, May 28, 2022 at 11:25:06 PM UTC+2, Ruvim wrote:
This is Forth
: ip-in-subnet >r and r> = ;
Entering Factor territory here
: ip-in-subnet ['] and dip = ;
This is Anton Forth
: ip-in-subnet 'and dip = ; \ Tick is for quoting a word
: ip-in-subnet `and dip = ; \ Backtick is for quoting a word
Night of the Living Dead
: ip-in-subnet dip' and = ;
Texas Chainsaw Massacre
: ip-in-subnet dip:and = ;
Cannibal Holocaust
: ip-in-subnet dip( and ) = ;
A Serbian Film
: ip-in-subnet dip{ and } = ;
Hans Bezemer
On Saturday, May 28, 2022 at 11:25:06 PM UTC+2, Ruvim wrote:
This is Forth
: ip-in-subnet >r and r> = ;
Hear, hear. Simplify and add lightness.
Do you still use the recognizer/prefix & ?
We were there first in 1993/2001 with that prefix.
I would love to see 0X1A for hex
instead of $1A , freeing
$HOME for environment variables.
That would be a beneficial c-compatibility.
Ruvim <ruvim.pinka@gmail.com> writes:
On 2022-05-19 18:47, Anton Ertl wrote:
Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into
interpretive code.
To quoting a word I prefer the form 'FOO (i.e. Tick vs Backtick) for the
following reasons:
- it is closer to "[']" and "'" (so it's already connotated with
quoting a word in Forth);
- it is also used for quoting in some other languages (e.g., in Lisp,
to quote a list).
Possible disadvantage of this choice are as follows.
- Sometimes Tick is an actual part of a name. But those who use names
starting with a Tick probably will not use recognizers, but parsing words.
Gforth currently has the following words starting with ':
'-error ' 'quit 'cold 'image 'clean-maintask
and Gforth has recognizers. Also, I have seen several programs that
define words with names starting with ' (and often paired with a word
with a name without ', such as 'QUIT and QUIT). For ` I have yet to
see someone write a word that starts with that. As soon as someone
loads that program in a system with a '-recognizer, there are the
following potential problems:
* The user may be unaware of the existence of 'QUIT, and writes 'QUIT
with the intention of getting the xt of QUIT, but gets something
else because the word-recognizer precedes the '-recognizer.
* If, OTOH, the '-recognizer preceded the word-recognizer, you get the
converse problem: If you want to get at the word 'QUIT, you get the
xt of QUIT instead.
We also would have preferred to use 'FOO for the xt of FOO, but to[...]
avoid these problems, we chose `.
In any case, while some problems are less serious than others, all of
these problems are avoided by using ` in the tick-recognizer, which is
why we are using that.
I think we should find some conventions for these forms (and maybe some
other), and give them names. After that, to avoid conflicts, a Forth
source code file (or code block) that relies on a convention, should
start with a declaration that mentions the convention's name.
The format of such a declaration probably should be standardized.
As an example, JavaScript uses "use strict" string literal as the first
item of a code block to declare strict mode.
We could use a list of recognizer names in the declaration. The scope of
this declaration (where this recognizers are in effect) should be
limited in obvious way.
I think that, on the contrary, we should use one common set of words
and syntax instead of introducing ways to declare idiosyncracy.
E.g., do I think that the alignment handling in struct.fs is superior
to the Forth-2012 field words? Yes. Still, when writing new code, I
use the Forth-2012 words. And that's despite the fact that struct.fs
is a standard program, so you can use the struct.fs words fully
portably. It's just that the cost of idiosyncrasy outweighs the
benefits of the superior alignment handling.
We have also had ways to specify which wordset a program uses: wordset queries with ENVIRONMENT?. A number of systems did not support that
in a useful way, few programs used it, and eventually we decided to
make them obsolescent (and refer only to Forth-94 while they are still there). So I expect that a new way to specify which dialect a program
uses will also receive little love.
That being said, once we have standardized configurable recognizers,
nothing prevents you from adding a recognizer that uses ' for xt
literals and another recognizer that uses ` for string. So your
convention might be something like
require ruvim.4th ruvim-convention{
... \ code that uses ruvim-convention stuff
}ruvim-convention
I just hope that, like I do for field words, you will use the
(hopefully standardized) string syntax "string" (which already has a
lot of mindshare), and that we reach a consensus for a syntax for xt literals, and all use that then.
I hate [UNDEFINED].I don't care for its length but at least [UNDEFINED] is unambiguous.
Were shortness paramount I'd have chosen LACK. But hey, we need to
keep Forth respectable and starched shirts sell better.
In article <t6t9mi$buj$2@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
On 2022-05-19 18:47, Anton Ertl wrote:
And after that, what to do with "[if]" and "[undefined]"?
And \ and (.
If they are with us in any case, we should not avoid them, but properly >>(safely and readable) use them.
I hate [UNDEFINED].
"socket-server" [UNDEFINED] [IF]
\ You really mean you can insert a portable definition of `socket-server?
\ Even if you succeed, you uglifies you code beyond redemption.
[THEN]
has to be replaced by
WANT socket-server
On 29/05/2022 17:56, albert wrote:
In article <t6t9mi$buj$2@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
On 2022-05-19 18:47, Anton Ertl wrote:
And after that, what to do with "[if]" and "[undefined]"?
And \ and (.
If they are with us in any case, we should not avoid them, but properly
(safely and readable) use them.
I hate [UNDEFINED].
"socket-server" [UNDEFINED] [IF]
\ You really mean you can insert a portable definition of `socket-server?
\ Even if you succeed, you uglifies you code beyond redemption.
[THEN]
has to be replaced by
WANT socket-server
I don't care for its length but at least [UNDEFINED] is unambiguous.
Were shortness paramount I'd have chosen LACK. But hey, we need to
keep Forth respectable and starched shirts sell better.
On Sunday, May 29, 2022 at 6:18:12 PM UTC+2, dxforth wrote:
I hate [UNDEFINED].I don't care for its length but at least [UNDEFINED] is unambiguous.
Were shortness paramount I'd have chosen LACK. But hey, we need to
keep Forth respectable and starched shirts sell better.
I love [UNDEFINED] for the same reason I like
VARIABLE x
VALUE y
CONSTANT z
: a
CHAR b
You parse the thing, look it up in the symboltable and leave a 1 or a 0 - which [IF]
can pick up easily. Ok, you can discuss the name as far as I'm concerned, but that's
it.
I'd hate to see:
S" x" VARIABLE
20 S" y" VALUE
10 S" x" CONSTANT
S" a" DEF{ }
S" b" CHAR
On Saturday, 28 May 2022 at 23:25:06 UTC+2, Ruvim wrote:
On 2022-05-29 00:34, P Falth wrote:
On Saturday, 28 May 2022 at 18:41:48 UTC+2, Ruvim wrote:OK. Could you please order by ugliness (from higher to lower) the
On 2022-05-20 09:14, dxforth wrote:
A few may enjoy creating
new parsing words (like the few that enjoy creating macros) but I wouldn't
say either was intrinsic to Forth, or even popular. If creating new parsing
words were popular, wouldn't there already be a convention for it?
https://pastebin.com/qpZLFc6h
The old convention was: don't use any special naming convention for
porcelain parsing word, they should look just like ordinary words.
For example: "[COMPILE]" and ASCII in Forth-79, POSTPONE in Forth-94
One of the first things that struck me when I learned about the forth language
was the complete freedom to name words whatever you wanted.
I do not want to change that!
What you have presented might be very logical but it looks ugly and does not
read well.
following definitions for the word "ip-in-subnet ( x.ip x.ip-mask
x.ip-net -- flag )":
This is how I would write it
: ip-in-subnet >r and r> = ;
This I can understand after looking up what dip does
: ip-in-subnet ['] and dip = ;
The rest are just ugly and difficult to read. ' ´ ` all look the same for me at a quick view
: ip-in-subnet 'and dip = ; \ Tick is for quoting a word
: ip-in-subnet `and dip = ; \ Backtick is for quoting a word
: ip-in-subnet dip' and = ;
: ip-in-subnet dip:and = ;
: ip-in-subnet dip( and ) = ;
: ip-in-subnet dip{ and } = ;
What I do not understand is this drive to pass an XT as argument.
For sure it can be powerful in certain cases,
but you do not need to rewrite everything in that style.
In article <t6tldc$2k1$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
And if a porcelain parsing word is allowed to be used in compilation
state and in interpretation state, it should accept immediate arguments
in both cases (or explicitly show that an argument is passed via the
stack instead).
A user of my reverse engineering assembler would use "porcelain"
words only. These are a layer separated from reality, and can
be used only via meticulous documentation.
You are spreading an illusion of git-people, that porcelain words
are intuitive. That makes git all but unusable for the casual
user.
On 2022-05-29 12:57, P Falth wrote:
On Saturday, 28 May 2022 at 23:25:06 UTC+2, Ruvim wrote:
On 2022-05-29 00:34, P Falth wrote:
On Saturday, 28 May 2022 at 18:41:48 UTC+2, Ruvim wrote:OK. Could you please order by ugliness (from higher to lower) the
On 2022-05-20 09:14, dxforth wrote:
One of the first things that struck me when I learned about the forth languageA few may enjoy creating
new parsing words (like the few that enjoy creating macros) but I wouldn't
say either was intrinsic to Forth, or even popular. If creating new parsing
words were popular, wouldn't there already be a convention for it? >>>>>
https://pastebin.com/qpZLFc6h
The old convention was: don't use any special naming convention for >>>> porcelain parsing word, they should look just like ordinary words.
For example: "[COMPILE]" and ASCII in Forth-79, POSTPONE in Forth-94 >>>
was the complete freedom to name words whatever you wanted.
I do not want to change that!
What you have presented might be very logical but it looks ugly and does not
read well.
following definitions for the word "ip-in-subnet ( x.ip x.ip-mask
x.ip-net -- flag )":
This is how I would write itThis example is taken for simplicity. Instead, just take your real life
: ip-in-subnet >r and r> = ;
case when you pass an xt as an argument, or pass a word (or several) as
an immediate argument.
This I can understand after looking up what dip does
: ip-in-subnet ['] and dip = ;
The rest are just ugly and difficult to read. ' ´ ` all look the same for me at a quick view
: ip-in-subnet 'and dip = ; \ Tick is for quoting a word
: ip-in-subnet `and dip = ; \ Backtick is for quoting a word
: ip-in-subnet dip' and = ;
: ip-in-subnet dip:and = ;
: ip-in-subnet dip( and ) = ;
: ip-in-subnet dip{ and } = ;
What I do not understand is this drive to pass an XT as argument.No any xt is passed in the last four code examples.
For sure it can be powerful in certain cases,Actually, it's my position too.
but you do not need to rewrite everything in that style.
Have a look [1], I started from a combinator (a word that accepts an xt
on the stack), and then introduced an equivalent parsing word:
| Now let's consider a variant of the "dip" combinator
| that accepts a word to be executed as an immediate argument
| and generates a more efficient code. Also, this variant can
| be better readable when the word is known in advance.
I provided two reasons for that:
1. Potentially, more efficient code.
2. Potentially, better readability.
In general, I talk not only about passing xt, but passing any argument
(for example, a name string).
Accepting immediate arguments can be a good choice in many cases. But a common problem that authors don't mark these arguments in the source
code explicitly. And that worsens readability.
So for the words having immediate arguments — I want the boundaries of these arguments be easy visible. And in the same time I want to have the corresponding ("plumbing") words that accepts argument from the data
stack (or, reluctantly, a technique like "execute-parsing" at least).
[1] https://github.com/ForthHub/discussion/discussions/112
--
Ruvim
On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:[...]
So for the words having immediate arguments — I want the boundaries of
these arguments be easy visible. And in the same time I want to have the
corresponding ("plumbing") words that accepts argument from the data
stack (or, reluctantly, a technique like "execute-parsing" at least).
To make them visible I have a completely different solution.
I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
After I add parsing words to the right section they will color their arguments different
then ordinary text. It is a great help for readability.
Ruvim <ruvim.pinka@gmail.com> writes:
On 2022-05-19 18:47, Anton Ertl wrote:Gforth currently has the following words starting with ':
Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into
interpretive code.
To quoting a word I prefer the form 'FOO (i.e. Tick vs Backtick) for the >>> following reasons:
- it is closer to "[']" and "'" (so it's already connotated with
quoting a word in Forth);
- it is also used for quoting in some other languages (e.g., in Lisp, >>> to quote a list).
Possible disadvantage of this choice are as follows.
- Sometimes Tick is an actual part of a name. But those who use names >>> starting with a Tick probably will not use recognizers, but parsing words. >>
'-error ' 'quit 'cold 'image 'clean-maintask
and Gforth has recognizers. Also, I have seen several programs that
define words with names starting with ' (and often paired with a word
with a name without ', such as 'QUIT and QUIT). For ` I have yet to
see someone write a word that starts with that. As soon as someone
loads that program in a system with a '-recognizer, there are the
following potential problems:
* The user may be unaware of the existence of 'QUIT, and writes 'QUIT
with the intention of getting the xt of QUIT, but gets something
else because the word-recognizer precedes the '-recognizer.
* If, OTOH, the '-recognizer preceded the word-recognizer, you get the
converse problem: If you want to get at the word 'QUIT, you get the
xt of QUIT instead.
As a user, I would prefer the tick-recognizer precedes the
word-recognizer. Since I know that I always use a leading tick either to >quoting a word, or for a character literal (when the lexeme ends with a
tick and consists of 3 xchars), and don't use a tick in names at all.
--
Ruvim
In article <t6vvk4$bl7$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
On 2022-05-28 17:22, Anton Ertl wrote:
Ruvim <ruvim.pinka@gmail.com> writes:
On 2022-05-19 18:47, Anton Ertl wrote:Gforth currently has the following words starting with ':
Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into >>>>> interpretive code.
To quoting a word I prefer the form 'FOO (i.e. Tick vs Backtick) for the >>>> following reasons:
- it is closer to "[']" and "'" (so it's already connotated with
quoting a word in Forth);
- it is also used for quoting in some other languages (e.g., in Lisp, >>>> to quote a list).
Possible disadvantage of this choice are as follows.
- Sometimes Tick is an actual part of a name. But those who use names >>>> starting with a Tick probably will not use recognizers, but parsing words. >>>
'-error ' 'quit 'cold 'image 'clean-maintask
and Gforth has recognizers. Also, I have seen several programs that
define words with names starting with ' (and often paired with a word
with a name without ', such as 'QUIT and QUIT). For ` I have yet to
see someone write a word that starts with that. As soon as someone
loads that program in a system with a '-recognizer, there are the
following potential problems:
* The user may be unaware of the existence of 'QUIT, and writes 'QUIT
with the intention of getting the xt of QUIT, but gets something
else because the word-recognizer precedes the '-recognizer.
* If, OTOH, the '-recognizer preceded the word-recognizer, you get the
converse problem: If you want to get at the word 'QUIT, you get the
xt of QUIT instead.
As a user, I would prefer the tick-recognizer precedes the
word-recognizer. Since I know that I always use a leading tick either to >>quoting a word, or for a character literal (when the lexeme ends with a >>tick and consists of 3 xchars), and don't use a tick in names at all.
In ciforth the question is moot. Recognizers (prefixes) are present
in the dictionary in wordlists. Normal precedence rules apply.
If a recognizer is present in a VOCABULARY, you can switch it off
by not adding that vocabulary to the search order.
The exception position for numbers (and other denotations) was a
major design flaw in the original Forth.
Note that Moore himself moved away from that in colorforth.
I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
On 2022-05-30, P Falth wrote:
On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:[...]
So for the words having immediate arguments — I want the boundaries of >>> these arguments be easy visible. And in the same time I want to have the >>> corresponding ("plumbing") words that accepts argument from the data
stack (or, reluctantly, a technique like "execute-parsing" at least).
To make them visible I have a completely different solution.
I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
After I add parsing words to the right section they will color their arguments different
then ordinary text. It is a great help for readability.
I see. Probably, this solution is acceptable for individuals or very
small collectives.
But this solution is not scalable on the whole Forth ecosystem. It is
not suitable for shared code and distributed development.
Ruvim <ruvim...@gmail.com> writes:
On 2022-05-30, P Falth wrote:
On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:[...]
So for the words having immediate arguments — I want the boundaries of >>> these arguments be easy visible. And in the same time I want to have the >>> corresponding ("plumbing") words that accepts argument from the data
stack (or, reluctantly, a technique like "execute-parsing" at least).
To make them visible I have a completely different solution.
I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
After I add parsing words to the right section they will color their arguments different
then ordinary text. It is a great help for readability.
I see. Probably, this solution is acceptable for individuals or very
small collectives.
But this solution is not scalable on the whole Forth ecosystem. It isWhy not?
not suitable for shared code and distributed development.
Sure, you may need to add the parsing words to multiple editors, but
that's doable. And you don't add that many parsing words.
I guess that with the language server protocol you can add the parsing
words to several editors at once.
Of course, with a naming convention you would just add the convention
to the editor, no need to add every word separately, so a large
project might want to introduce such a convention.
One very general way would be to load the project into a Forth system,
and use the system's parsing and recognizing for coloring: If a piece
of source code is parsed with with something other than the text interpreter's PARSE-NAME or one of a list of pre-defined parsing words (e.g., S", (, \), you give the parsing-word-parsed colour to the piece
of source code. You colour stuff parsed by the text interpreter based
on the recognizer that recognizes it, and stuff parsed by S", (, \,
and maybe a few others separately. You have to find some way to
continue parsing after an error to make this approach usable.
- anton
--
Ruvim <ruvim.pinka@gmail.com> writes:
On 2022-05-30, P Falth wrote:
On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:[...]
So for the words having immediate arguments — I want the boundaries of >>>> these arguments be easy visible. And in the same time I want to have the >>>> corresponding ("plumbing") words that accepts argument from the data
stack (or, reluctantly, a technique like "execute-parsing" at least).
To make them visible I have a completely different solution.
I have written a context sensitive Forth colorizer for the text editor I am using (SciTe)
After I add parsing words to the right section they will color their arguments different
then ordinary text. It is a great help for readability.
I see. Probably, this solution is acceptable for individuals or very
small collectives.
But this solution is not scalable on the whole Forth ecosystem. It is
not suitable for shared code and distributed development.
Why not?
Sure, you may need to add the parsing words to multiple editors, but
that's doable. And you don't add that many parsing words.
I guess that with the language server protocol you can add the parsing
words to several editors at once.
Of course, with a naming convention you would just add the convention
to the editor, no need to add every word separately, so a large
project might want to introduce such a convention.
One very general way would be to load the project into a Forth system,
and use the system's parsing and recognizing for coloring: If a piece
of source code is parsed with with something other than the text interpreter's PARSE-NAME or one of a list of pre-defined parsing words
(e.g., S", (, \), you give the parsing-word-parsed colour to the piece
of source code. You colour stuff parsed by the text interpreter based
on the recognizer that recognizes it, and stuff parsed by S", (, \,
and maybe a few others separately. You have to find some way to
continue parsing after an error to make this approach usable.
On 2022-05-29 20:18, dxforth wrote:
I don't care for its length but at least [UNDEFINED] is unambiguous.
Were shortness paramount I'd have chosen LACK. But hey, we need to
keep Forth respectable and starched shirts sell better.
lack( foo ) [if]
...
[then]
Nice!
On 2022-05-28 17:22, Anton Ertl wrote:[...]
I just hope that, like I do for field words, you will use the
(hopefully standardized) string syntax "string" (which already has a
lot of mindshare), and that we reach a consensus for a syntax for xt
literals, and all use that then.
forth-2023 !perception{
... \ code that uses a standard set of recognizers
... \ including 'FOO `name wordlist1::wordlist2::name etc
... \ that precede the word-recognizer (!)
}
or
forth-2023 !perception// \ up to the end of file
(the naming is under construction)
On 2022-05-30, P Falth wrote:
On Sunday, 29 May 2022 at 21:23:44 UTC+2, Ruvim wrote:[...]
So for the words having immediate arguments — I want the boundaries of >>> these arguments be easy visible. And in the same time I want to have the >>> corresponding ("plumbing") words that accepts argument from the data
stack (or, reluctantly, a technique like "execute-parsing" at least).
To make them visible I have a completely different solution.
I have written a context sensitive Forth colorizer for the text editor I am >> using (SciTe)
After I add parsing words to the right section they will color their
arguments different
then ordinary text. It is a great help for readability.
I see. Probably, this solution is acceptable for individuals or very
small collectives.
But this solution is not scalable on the whole Forth ecosystem. It is
not suitable for shared code and distributed development.
Why not? Syntax colouring editors have been around for a long time.
On Monday, May 30, 2022 at 11:14:16 AM UTC-5, Stephen Pelc wrote:
Why not? Syntax colouring editors have been around for a long time.
Unsure if editor syntax coloring is robust enough. Forth has little syntax so each word will need to be listed. May be sufficient for the standard words but
when additional word-sets are loaded, the editor's syntax coloring will need to be updated. Is this a problem?
Color Forth wouldn't have this problem as
each word has embedded color information (I assume). But then will need some means of having the Forth interact with the editor display.
If Forth words
have a consistent syntax, then editor syntax coloring would have little problem.
One solution is to have syntax, even if no one likes it, and the editor displays the word without the syntax but in color based on the syntax
the editor sees. I do that now with comment tags where the pager (less) converts the tags to color escape codes. The comment text is shown in
color without the tag.
--
me
On 2022-05-29 20:18, dxforth wrote:
I don't care for its length but at least [UNDEFINED] is unambiguous.
Were shortness paramount I'd have chosen LACK. But hey, we need to
keep Forth respectable and starched shirts sell better.
lack( foo ) [if]
...
[then]
Nice!
Probably, readability of following
"foo" lack [if] ... [then]
is not worser.
--
Ruvim
But having shorter string literals it looks better:
"x" var
or
`x var
10 `x const
Anyway, what can you suggest if I need to create a definition (e.g. a constant) programmatically, and its name is passed as an argument?
Having "const" from the above it could look as:
: foo ( sd.name -- ) ... 10 -rot const ... ;
On Monday, May 30, 2022 at 11:14:16 AM UTC-5, Stephen Pelc wrote:
Why not? Syntax colouring editors have been around for a long time.
Unsure if editor syntax coloring is robust enough.
The word type is determined by its codeword and for defining word
offspring an additional address. As a Forth word's type can be
determined by codeword and an address, any Forth has information
that it can use for coloring.
NB: "Green words like if are compiled, but because they are in the macro wordlist and act like immediate words, they are executed at compile timeYeah - and at least two accessibility modes for the colorblind. I think that making "color" part of the syntax is one of the least well-considered ideas that
like words written explicitly in yellow." [1]
A definition
: foo ( flag -- ) if 123 . then ;
is written as
red:foo
white:(
white:flag
white:--
white:)
green:if
green:123
green:.
green:then
green:;
On Monday, May 30, 2022 at 9:08:27 PM UTC+2, Ruvim wrote:
NB: "Green words like if are compiled, but because they are in the macroYeah - and at least two accessibility modes for the colorblind. I think that making "color" part of the syntax is one of the least well-considered ideas that
wordlist and act like immediate words, they are executed at compile time
like words written explicitly in yellow." [1]
Moore has ever had.
On Monday, May 30, 2022 at 9:08:27 PM UTC+2, Ruvim wrote:
NB: "Green words like if are compiled, but because they are in the macroYeah - and at least two accessibility modes for the colorblind. I think that >making "color" part of the syntax is one of the least well-considered ideas that
wordlist and act like immediate words, they are executed at compile time
like words written explicitly in yellow." [1]
Moore has ever had.
The more since syntax coloring has been around for a long time and >particularly successful, I must say. I've created several such schemes myself.
However - I doubt very much that such exotic format would EVER be supported >by any major editor. Not to mention how to encode it in a plain-text format.
You know, something you can copy, paste, compile and it simply works.
Like the stuff I took from a ZX Spectrum to DOS, Windows and finally Linux.
Great invention - I recommend you try it once.
Hans Bezemer
On Sunday, May 29, 2022 at 8:30:33 PM UTC+2, Ruvim wrote:
But having shorter string literals it looks better:
"x" var
or
`x var
10 `x const
That is a very personal metric. I see strings - not declarations. And I think prefixed
words are b--t ugly.
Anyway, what can you suggest if I need to create a definition (e.g. a
constant) programmatically, and its name is passed as an argument?
Having "const" from the above it could look as:
: foo ( sd.name -- ) ... 10 -rot const ... ;
Try "CREATE". It has been there for a long time.
On 2022-05-30 23:14, Hans Bezemer wrote:
On Sunday, May 29, 2022 at 8:30:33 PM UTC+2, Ruvim wrote:
But having shorter string literals it looks better:
"x" var
or
`x var
10 `x const
That is a very personal metric. I see strings - not declarations. And I think prefixed
words are b--t ugly.
When you write:
10 constant foo
"constant " is a prefix for "foo".
When you write:
[char] A
"[char] " is a prefix for "A"
Such prefixes are ugly, since you don't have a general rule that tells
you whether some lexeme is a prefix or not.
Just for example, a convention about parentheses could be a rule that
shows such prefixes explicitly.
In Forth, when a word is used, you don't see (from the surrounding
context) how many arguments from the data stack it consumes. But if you
also don't see how many immediate arguments it consumes — it's far worse for readability.
Concerning string literals, it just less or more concise forms:
string" x"
s" x"
"x"
`x
In every of these variants the boundaries are obvious and good readable
due to special characters and well known conventions.
On 31/05/2022 18:36, Ruvim wrote:(1)
On 2022-05-30 23:14, Hans Bezemer wrote:
On Sunday, May 29, 2022 at 8:30:33 PM UTC+2, Ruvim wrote:
But having shorter string literals it looks better:
"x" var
or
`x var
10 `x const
That is a very personal metric. I see strings - not declarations. And I think prefixed
words are b--t ugly.
When you write:
10 constant foo
"constant " is a prefix for "foo".
When you write:
[char] A
"[char] " is a prefix for "A"
Such prefixes are ugly, since you don't have a general rule that tells
you whether some lexeme is a prefix or not.
Just for example, a convention about parentheses could be a rule that
shows such prefixes explicitly.
In Forth, when a word is used, you don't see (from the surrounding
context) how many arguments from the data stack it consumes. But if you
also don't see how many immediate arguments it consumes — it's far worse >> for readability.
Concerning string literals, it just less or more concise forms:
string" x"
s" x"
"x"
`x
In every of these variants the boundaries are obvious and good readable
due to special characters and well known conventions.
Thanks to 200x, folks today think $#%' et al is forth convention when it's actually imported convention.
On 2022-05-31 13:27, dxforth wrote:
On 31/05/2022 18:36, Ruvim wrote:(1)
...
In Forth, when a word is used, you don't see (from the surrounding
context) how many arguments from the data stack it consumes. But if you
also don't see how many immediate arguments it consumes — it's far worse >>> for readability.
Concerning string literals, it just less or more concise forms:
string" x"
s" x"
"x"
`x
In every of these variants the boundaries are obvious and good readable
due to special characters and well known conventions.
Thanks to 200x, folks today think $#%' et al is forth convention when it's >> actually imported convention.
It doesn't matter whether they are imported or not.
Anyway, what would you suggest instead that to solve the problem (1)?
Anyway, what would you suggest instead that to solve the problem (1)?
On Tuesday, May 31, 2022 at 5:24:54 AM UTC-5, Ruvim wrote:
Anyway, what would you suggest instead that to solve the problem (1)?10 constant \ un-named constant
$"bar" \ assign name to latest
42 constant $"bar"
On Tuesday, May 31, 2022 at 12:29:17 PM UTC-5, minf...@arcor.de wrote:Oops, stack effects should be: constant ( n -- xt )
Tweeked it a little:
:) frogd
ELF32X86_64 Frog Version 1.0d
"job" /go
: constant ( n -- ) docon , here swap , ;
: s: ( name xt -- ) defer cfa latest pfa dfa ! ;
42 constant s: bar
bar space . 42
-fin-
ok
--
me
In Forth, when a word is used, you don't see (from the surrounding
context) how many arguments from the data stack it consumes. But if you
also don't see how many immediate arguments it consumes — it's far worse >for readability.
"x"The only thing you need to remember is that " introduces a string.
--
Ruvim
On 30 May 2022 at 21:01:10 CEST, "S Jack" <sdwjack69@gmail.com> wrote:
The word type is determined by its codeword and for defining word
offspring an additional address. As a Forth word's type can be
determined by codeword and an address, any Forth has information
that it can use for coloring.
Does that apply to Native Code Compilers?
From my early school days:
https://www.teaching.com.au/product/EY302
those nuns knew how to punish
When you write:Well, your ontology sucks. And that's why your whole argument following
10 constant foo
"constant " is a prefix for "foo".
When you write:
[char] A
"[char] " is a prefix for "A"
Such prefixes are ugly, since you don't have a general rule that tellsNaming is everything. In my libs, I tend to use the rule that privates
you whether some lexeme is a prefix or not.
For what? For the odd occasion you do things like "function composition"?Try "CREATE". It has been there for a long time.How does it help to pass a name string via the data stack?
On Tuesday, May 31, 2022 at 5:59:22 AM UTC+2, dxforth wrote:
From my early school days:
https://www.teaching.com.au/product/EY302
those nuns knew how to punish
You weren't inventive enough - they gave you 72 rods to throw to their heads. That'll teach them about their didactic values.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 53:34:50 |
| Calls: | 6,712 |
| Files: | 12,243 |
| Messages: | 5,355,272 |