On 2022-05-19 18:47, Anton Ertl wrote:
> 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.

It's just a test case.
TEST-BAZ creates the word BAZ2, that is equivalent to the following
definition:

: baz2 [ baz drop postpone( @ ; ) ] [
⇔
: baz2 [ baz drop ] @ ;
⇔
: baz2 [ foo postpone( foo bar ) drop ] @ ;
⇔
: baz2 [ foo ] foo bar [ drop ] @ ;
⇔
: baz2 [ 123 ] foo bar [ drop ] @ ;
⇔
: baz2 [ 123 drop ] foo bar @ ;
⇔
: baz2 foo bar @ ;
⇔
: baz2 123 bar @ ;

Actually, the form
:( foo )
is not quite readable due to confused ":("

A variant:
def( foo )
looks slightly better. But then the block should end with "end-def".

Maybe:

:def( foo ) ... ;

Just for reference, an implementation for ':def(' is following.

\ Data type symbols:
\ "sd" is a pair ( c-addr u )
\ "t" is a tuple ( i*x )

\ The code relies on the "quoted-word-by-tick" recognizer

: noop ;
: tt-dual ( t xt.compil xt.interp -- t )
state @ if drop else nip then execute
;
: tt-slit ( sd -- sd | ) 'slit, 'noop tt-dual ;
: tt-xt ( t xt -- t ) 'compile, 'execute tt-dual ;
: def ( sd.name -- ) ( C: -- colon-sys ) ': execute-parsing ;

: :def( \ "ccc )"
')' parse [: ( -- sd.name )
parse-name parse-name nip abort" unexpected immediate argument"
;] execute-parsing ( sd.name | c-addr 0 )
dup if tt-slit else 2drop then 'def tt-xt
; immediate

It defines such a behavior that the following lines of code are equivalent:

:def( foo ) :def( bar ) ... ;
⇔
:def( foo ) "bar" :def( ) ... ;
⇔
: foo "bar" ': execute-parsing ... ;

Well, I dislike this variant too. Since the eclipsed fragment is not the
body of the "bar" definition.

--
Ruvim

On 2022-05-19 18:47, Anton Ertl wrote:
> 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

I use ABORT" for the examples that should be shot and standard
compliant. And I still have to use S" BLA", ['] and POSTPONE for
strictly standard compliant modules.

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

It's confusing that in one context they are followed by an immediate
argument, but in another context — are not.

: foo : bar ;

"foo" is an immediate argument of the first colon, but "bar" is not an
immediate argument of the second colon. It's very confusing. (1)

Actually, some such words cannot be avoided due to Forth reflection.
E.g. the phrase:
parse-name test type
produces different effects when it's interpreted and when it's executed
(after compilation to a word).

But "parse-name" is a “plumbing” word, and ":" is a “porcelain” word
(after Git's terminology). Puzzles are OK for plumbing.

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

I would like to get rid of the burden of that old idioms.

>> 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 I would like to avoid the problem (1) in some lexical scopes at least.

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

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

> - Tick is used for character literals in Gforth. But is was a
>suboptimal choice, I think.

The usage 'c' is standardized in Forth-2012. The usage 'c is legacy
in Gforth, and not the major reason why we decided against 'FOO,
although a user writing, e.g., '# might be unpleasantly surprised that
the result is the ASCII value of # instead of the xt of #.

There is a word I' in Gforth, so 'I' would be a conflict with
non-legacy syntax. I think that given the fact that Gforth by default
tries to recognize a character before an xt, most users who want the
xt of I' probably would see 'I' and immediately see the conflict.

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.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 2022-05-19 21:20, S Jack wrote:
> 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 ': .

From thees three variants, (3) looks better for me too.

But applying this rule to Colon seems not so pretty:

:( foo ) ... ;

(as I already mentioned that in a previous message).

If you want a Colon-like word that parses its body, how it can look like?

I mean something like:

def( foo ){ ... }def

I.e., the word should parse both the name and the whole definition body.
What a syntax can be for such a case?

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

On Saturday, May 28, 2022 at 9:41:21 AM UTC-5, Ruvim wrote:
>
> From thees three variants, (3) looks better for me too.
>
> But applying this rule to Colon seems not so pretty:
>
> :( foo ) ... ;
>

Like postscript make name assignment postfix:
: .... ; =( foo )

Colon is a :noname and "=(" assigns a name if wanted. ":NONAME" no longer needed.

Not going for purity one could do:
: .... ;\ foo

--
me

On 2022-05-20 11:48, albert wrote:
> 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

So this ":" is still a parsing word.

In the STOIC language [1,2] it's written as:

'hello : "hello world" type ;

123 'bar constant

Interestingly, it uses two forms of string literals [3] — blank
separated, and double-quoted:

Examples of strings are:

'ABC_DEF -- note termination by a space
(can use a tab also)

"This one has spaces in it as well as ^&*()"

But STOIC didn't avoid inconspicuous immediate arguments.
For example, the word DISPATCH
Compilation: ( "ccc" -- )
Run-time: ( x -- x | )

A usage example:

'C.F : % F-command, needs second character
CLI.GNB IF
CONVERT_TO_UPPER
DISPATCH 'I C.FI
DISPATCH 'O C.FO
THEN DROP ERR.INVCOM
;

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

There are actually two separate code sequences, they are just separated
not by "S:", but by "->".

In general, you can write:

t{ test-baz baz2 -> 123 dup 333 + }t

[1] STOIC, 1976, — it's very close to Forth
https://en.wikipedia.org/wiki/STOIC

[2] Sources and some applications
http://www.decuslib.com/decus/vax85c/saostoic/

[3] STOIC manual
http://www.decuslib.com/decus/vax85c/saostoic/gm/newstoic.mem

--
Ruvim

On Tuesday, May 17, 2022 at 11:23:57 AM UTC-5, Ruvim wrote:
>
> Can we have a convention for naming parsing words?

Not a suggestion but an intriguing thought:

Instead of naming conventions what if the standard specifies only behavior
with given id's and not names. Programs can map a set of names to the id's
when compiled thereby using names that fit the application. If one is looking
at someone else code and doesn't like the naming, he just maps it to the
name set he prefers and re-compiles.

In good old days of HTML before the prevalence of java script Firefox provided
a user default CSS. The user could disable a web page's CSS and use his
default to have a much improved view of the page.

--
me

Marcel Hendrix <mhx@iae.nl> writes:
>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>#

No problem, because the tick-recognizer does not recognize a solitary
"`".

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 2022-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 2022-05-17 23:47, albert wrote:
> 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

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", ":", and
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).

By "to be used" I mean to be encountered by the Forth text interpreter.

--
Ruvim

On 2022-05-17 20:23, Ruvim 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?
>
>
> [1] Naming for parsing words
> https://github.com/ForthHub/discussion/discussions/112

Concerning the defining words in Forth — I think, they do parsing just
for better readability.

For example, the code:

123 constant foo

: bar "hello world" type ;

probably is better readable than:

123 "foo" const

{ "hello world" type } "bar" def

or even

123 s" foo" const

But then, for better readability, why not to parse both arguments:

constant foo 123

The question is rhetorical. It's a compromise between readability and
ability to calculate or pass this argument from other words.

Let's have a look at the WebAssembly language [1]. It's a stack-based
language, and it employs s-expression in the source code by the
following rule [2]:

"(X ... )" is equivalent to "... X"

or, vice versa:

" ... X" is equivalent to "(X ... )"

Let the word "const ( x sd.name -- )" creates a constant by an x and
name string from the stack, and the word "def ( xt sd.name -- )" creates
a word by an xt and name string from the stack, and "{ ... }" is
equivalent to "[: ... ;]" that works in interpretation state too.

Using the above rule for s-expression, we will get:

123 "foo" const
⇔
123 (const "foo")
⇔
(const 123 "foo")
⇔
(const ("foo" 123))

And for a word definition:

{ "test passed" type } "foo" def
⇔
(def { "test passed" type } "foo" )
⇔
(def ("foo" { "test passed" type }))

NB: the words "def" and "const" don't parse anything by themselves.
In Forth it can be implemented as a recognizer for "(X" that returns "X"
and a translator that also parses input stream according to parenthesis.

This approach cannot be used when you need to analyze an immediate
argument in compile time. It only can provide a better readability in
some cases.

One more example:

\ !h ( fileid|0 -- )
\ h ( -- fileid|0 )

(open-file "path/to/file.txt" r/o) throw !h
(file-size h) throw
(reposition-file h) throw
(write-file (h "(test passed)" )) throw
(close-file h) throw 0 !h

Nice, isn't it?
We see the main command at the start of each line. And the explicit
arguments do not get in the way before the command. And the implicit
arguments on the stack also flow from command to command.

[1] WebAssembly in Wikipedia
https://en.wikipedia.org/wiki/WebAssembly
[2] Folded Instructions (specification)
https://webassembly.github.io/spec/core/text/instructions.html#folded-instructions

--
Ruvim

On Saturday, 28 May 2022 at 18:41:48 UTC+2, Ruvim wrote:
> 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

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!

BR
Peter
> [1] Search results in GitHub for "language:forth parse-name'
> https://github.com/search?q=language%3Aforth+parse-name&type=code
>
> --
> 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 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.

OK. Could you please order by ugliness (from higher to lower) the
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

In article <t6t189$k0b$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2022-05-19 18:47, Anton Ertl wrote:
>> 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.

I agree with this disadvantage. It is however no worse than
2SWAP, that at first glance seem to be an integer.
'DROP is a number (token/address) that is not to be found if 'DROP
is actually in the dictionary.
I'm using 'DROP instead of using `` ' DROP '' or `` ['] DROP ''
since 2001. My Forth doesn't get confused by an occasional
program by Marcel Hendrix who is fond of using ' to indicate
deferred execution.

<SNIP>

>--
>Ruvim
--
"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

P Falth <peter.m.falth@gmail.com> writes:
[Allocating VALUEs to registers]
>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!

I have no concrete plans, but the general idea is to allocate values
to registers locally, not globally. E.g., if you have a loop where V
is only read, load it into a register before the loop, and only use
the register in the loop. Or if it is read and written in the loop,
load it before the loop, keep it in the register during the loop, and
store it afterwards.

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

Something like that may be useful for dealing with things that are
used frequently in a lot of places, e.g., for implementing THIS in an
object-oriented extension. If you name the register, it becomes at
least machine-specific and probably also system-specific. The
approach used by early C compilers for the "register" storage class is
probably better: keep the first n register-values in registers, where
n is a machine- and system-specific number, and the rest is treated
like normal values.

- 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

In article <445b821c-4ee2-4655-b972-2f0b14d80cc9n@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:
>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

Do you still use the recognizer/prefix & ?
We were there first in 1993/2001 with that prefix.
I think &' is superior to ''' in view of ' and '' that also
exists.
I think &A is more Forth like, than a parser that not until
the second ' knows what 'A' is supposed to mean.

'A' is the worst c-compatibility.
I would love to see 0X1A for hex instead of $1A , freeing
$HOME for environment variables. That would be a beneficial
c-compatibility.

>
>-marcel

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

Groetjes Albert

>--
>Ruvim
--
"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 <t6tcae$ut7$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2022-05-19 21:20, S Jack wrote:
>> 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.

That is just solution 1, with a small code convention that
draw attention to parsing ahead.

>> 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
--
"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 <t6tldc$2k1$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2022-05-17 23:47, albert wrote:
>> 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
>
>It seems, "FROM" is also a parsing word, then why is a trailing ':'
>missed in the name?
No it isn't. If the namespace/vocabulary word is pushing it
is void, else ALSO.

>
>And what do you think in regards to "constant", "variable", ":", and
>other defining words? Would you like to outlaw them?
That is the normal use case for getting a name from the input
stream. That goes without saying.

>
>
>My position is that the parsed part (the immediate arguments), if any,
>should be explicitly marked and easy readable, without reading manuals.

You can study my programs ciasdis and tmanx. Both are user defined
languages and use parsing words freely, to mimic conventions used
in assembler and musical scores.
You can not use these powerful programs without reading manuals,
but most falls in place automatically.

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

>--
>Ruvim

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

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:
> >> 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.
> OK. Could you please order by ugliness (from higher to lower) the
> 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.

For this example "ip-in-subnet" I would probably just use it without a definition
x.ip x.ip-mask and x.ip-net =

BR
Peter
> 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 29 May 2022 at 00:28:55 CEST, "Hans Bezemer" <the.beez.speaks@gmail.com>
wrote:

> 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

Hear, hear. Simplify and add lightness.

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

On Sunday, May 29, 2022 at 11:33:36 AM UTC+2, Stephen Pelc wrote:
[..]
> > 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.

Yeah, like

: dip ( x quot -- x ) swap [ call ] dip ;

-marcel

On 2022-05-28 17:22, Anton Ertl wrote:
> 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.

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.

But another user, or the system implementer, who wants to use names
starting with tick (and probably doesn't use additional recognizers at
all), would prefer the word-recognizer precedes the tick-recognizer.

And only this latter option (where the word-recognizer is the most
precedence) is back compatible. The former option (where the
tick-recognizer precedes the word-recognizer) destandardizes some
standard programs, so it is not acceptable.

But with the backward-compatible option I cannot safely rely on the
tick-recognizer since I cannot be sure that 'QUIT always return xt of
QUIT. (1)

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

Using a backtick, you don't avoid the problem (1), but only reduce the
chance of encountering this problem. Eventually, you either effectively
destandardize names starting with a backtick (except this name itself),
or make the backtick-recognizer unsafe (and so unusable).

I cannot rely on the backtick-recognizer at all, if I have even a little
chance that it returns not what I expect.

At the same time, many people in the Forth community will fairly resist
to any new restrictions on names.

Nota bene — this problem is a general problem for recognizers.

For example, if the implementer of a standard system, or some third
party library, provides a word "'M'" in the FORTH-WORDLIST, the system
is still standard (even having the included library).

And a standard program that uses a character literal 'M' is still a
standard program. But this standard program will work incorrectly on
this standard system, since the system will interpret "'M'" as its word
name.

So I see a declaration of a recognizer (that is the perceptor) as the
only solution of this general problem, and the problem (1) particularly.
It can be actually specified as an ordered sequence of recognizers, or a
single name of a well known sequence of recognizers.

Then, if I declare the used recognizers in any case, and it affects only
my code, and doesn't affect third-party code, why give up on the
preferred tick-recognizer?

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

I don't interpret it as way to declare idiosyncrasy (although it can be
used for that). Otherwise any DSL, or even set of helping words that a
user includes into the search order would be declaration of idiosyncrasy.

I see it as a backward-compatible way to introduce a well-known set of
new features, that is connected with additional *restrictions* on
programs (that relies on these features).

I.e., for backward-compatibility, a handful of new words is better than
new *unconditional* restrictions on all word names.

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

I see. But now we are in the position as if the Forth-2012 field words
are not standardized yet. And we can choose a better set of words (and
their names).

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

Don't you think the solution is not well designed for the problem?

The "ENVIRONMENT?" word just doesn't fit the problem of including
external libraries (external definitions for a word set).

Using "ENVIRONMENT?" a program should choose what to do if a word set is
missed. Usually a program chooses just to not work (not load, abort,
throw an error, etc).

But then why to use "ENVIRONMENT?", and analyze it results, if the
program will be aborted in any case, if a word is not found.

So this example doesn't support your position, I think.

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

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)

--
Ruvim