Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

When speculation has done its worst, two plus two still equals four. -- S. Johnson


devel / comp.lang.forth / Re: Simplicity and the text interpreter (was: Naming for parsing words)

SubjectAuthor
* Naming for parsing wordsRuvim
+* Re: Naming for parsing wordsS Jack
|`* Re: Naming for parsing wordsRuvim
| +* Re: Naming for parsing wordsAnton Ertl
| |+* Re: Naming for parsing wordsHans Bezemer
| ||`* Simplicity and the text interpreter (was: Naming for parsing words)Anton Ertl
| || `* Re: Simplicity and the text interpreter (was: Naming for parsing words)Hans Bezemer
| ||  `* Re: Simplicity and the text interpreter (was: Naming for parsing words)Anton Ertl
| ||   `* Re: Simplicity and the text interpreter (was: Naming for parsing words)Hans Bezemer
| ||    `* Re: Simplicity and the text interpreter (was: Naming for parsing words)Anton Ertl
| ||     +- Re: Simplicity and the text interpreter (was: Naming for parsing words)Hans Bezemer
| ||     `* Re: Simplicity and the text interpreterPaul Rubin
| ||      `- Re: Simplicity and the text interpreterHans Bezemer
| |+* Format to quoting a word (was: Naming for parsing words)Ruvim
| ||+* Re: Format to quoting a word (was: Naming for parsing words)Anton Ertl
| |||+* Re: Format to quoting a word (was: Naming for parsing words)Marcel Hendrix
| ||||+- Re: Format to quoting a word (was: Naming for parsing words)Anton Ertl
| ||||`* Re: Format to quoting a word (was: Naming for parsing words)none
| |||| `- Re: Format to quoting a word (was: Naming for parsing words)Anton Ertl
| |||`* Recognizers precedence (was: Format to quoting a word)Ruvim
| ||| +* Re: Recognizers precedence (was: Format to quoting a word)none
| ||| |`- Re: Recognizers precedence (was: Format to quoting a word)dxforth
| ||| `- Re: Recognizers precedence (was: Format to quoting a word)Ruvim
| ||`- Re: Format to quoting a word (was: Naming for parsing words)none
| |+- Re: Naming for parsing wordsRuvim
| |`* Re: Naming for parsing wordsRuvim
| | `* Re: Naming for parsing wordsnone
| |  `* Re: Naming for parsing wordsdxforth
| |   +* Re: Naming for parsing wordsHans Bezemer
| |   |`* Re: Naming for parsing wordsRuvim
| |   | `* Re: Naming for parsing wordsHans Bezemer
| |   |  `* Re: Naming for parsing wordsRuvim
| |   |   +* Re: Naming for parsing wordsdxforth
| |   |   |`* Re: Naming for parsing wordsRuvim
| |   |   | +- Re: Naming for parsing wordsdxforth
| |   |   | `* Re: Naming for parsing wordsS Jack
| |   |   |  `* Re: Naming for parsing wordsminf...@arcor.de
| |   |   |   `* Re: Naming for parsing wordsS Jack
| |   |   |    `* Re: Naming for parsing wordsS Jack
| |   |   |     `- Re: Naming for parsing wordsS Jack
| |   |   +- Re: Naming for parsing wordsnone
| |   |   `- Re: Naming for parsing wordsHans Bezemer
| |   `* Re: Naming for parsing wordsRuvim
| |    `* Re: Naming for parsing wordsRuvim
| |     `- Re: Naming for parsing wordsnone
| +* Re: Naming for parsing wordsS Jack
| |`* Re: Naming for parsing wordsRuvim
| | +- Re: Naming for parsing wordsS Jack
| | `- Re: Naming for parsing wordsnone
| +* Re: Naming for parsing wordsdxforth
| |`* Re: Naming for parsing wordsRuvim
| | `* Re: Naming for parsing wordsP Falth
| |  `* Re: Naming for parsing wordsRuvim
| |   +* Re: Naming for parsing wordsHans Bezemer
| |   |`* Re: Naming for parsing wordsStephen Pelc
| |   | `- Re: Naming for parsing wordsMarcel Hendrix
| |   `* Re: Naming for parsing wordsP Falth
| |    `* Re: Naming for parsing wordsRuvim
| |     `* Re: Naming for parsing wordsP Falth
| |      +* Re: Naming for parsing wordsRuvim
| |      |+* Re: Naming for parsing wordsAnton Ertl
| |      ||+- Re: Naming for parsing wordsminf...@arcor.de
| |      ||`- Re: Naming for parsing wordsRuvim
| |      |`* Re: Naming for parsing wordsStephen Pelc
| |      | `* Re: Naming for parsing wordsS Jack
| |      |  +* Re: Naming for parsing wordsS Jack
| |      |  |`* Re: Naming for parsing wordsStephen Pelc
| |      |  | `- Re: Naming for parsing wordsAnton Ertl
| |      |  +* Re: Naming for parsing wordsRuvim
| |      |  |+* Re: Naming for parsing wordsHans Bezemer
| |      |  ||+* Re: Naming for parsing wordsdxforth
| |      |  |||`* Re: Naming for parsing wordsHans Bezemer
| |      |  ||| `- Re: Naming for parsing wordsdxforth
| |      |  ||`- Re: Naming for parsing wordsnone
| |      |  |`- Re: Naming for parsing wordsS Jack
| |      |  `- Re: Naming for parsing wordsStephen Pelc
| |      `- Re: Naming for parsing wordsS Jack
| +* Re: Naming for parsing wordsnone
| |`- Re: Naming for parsing wordsRuvim
| `* Re: Naming for parsing wordsHans Bezemer
|  `* Re: Naming for parsing wordsnone
|   +- Re: Naming for parsing wordsAnton Ertl
|   `* Re: Naming for parsing wordsHans Bezemer
|    `* IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|     `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|      `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|       `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|        `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|         `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|          `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|           `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|            `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|             +* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|             |`* Re: IS vs. DEFER! (was: Naming for parsing words)Marcel Hendrix
|             | `* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|             |  `- memory dependencies (was: IS vs. DEFER! (was: Naming for parsing words))Anton Ertl
|             +* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|             |+* Re: IS vs. DEFER! (was: Naming for parsing words)Anton Ertl
|             ||`- Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|             |`* Re: IS vs. DEFER! (was: Naming for parsing words)Hans Bezemer
|             | `* Re: IS vs. DEFER! (was: Naming for parsing words)dxforth
|             `* Re: IS vs. DEFER! (was: Naming for parsing words)P Falth
+* Re: Naming for parsing wordsnone
+* Re: Naming for parsing wordsdxforth
+- Re: Naming for parsing wordsS Jack
`- Re: Naming for parsing wordsRuvim

Pages:12345
Naming for parsing words

<t60i6r$7m0$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17884&group=comp.lang.forth#17884

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Naming for parsing words
Date: Tue, 17 May 2022 20:23:53 +0400
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <t60i6r$7m0$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 17 May 2022 16:23:55 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="807795a438bec98f39b43dc1a4b9c7f5";
logging-data="7872"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/mWQO4/sP5vc7l3yQcbP2M"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:YQk+yuWNXL3w0xUYwDcTwmkx/Co=
Content-Language: en-US
 by: Ruvim - Tue, 17 May 2022 16:23 UTC

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

--
Ruvim

Re: Naming for parsing words

<27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17885&group=comp.lang.forth#17885

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ad4:5a12:0:b0:456:3040:6b0 with SMTP id ei18-20020ad45a12000000b00456304006b0mr21566948qvb.68.1652811180200;
Tue, 17 May 2022 11:13:00 -0700 (PDT)
X-Received: by 2002:a05:620a:6c8:b0:69c:7adc:7370 with SMTP id
8-20020a05620a06c800b0069c7adc7370mr16928058qky.49.1652811179931; Tue, 17 May
2022 11:12:59 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Tue, 17 May 2022 11:12:59 -0700 (PDT)
In-Reply-To: <t60i6r$7m0$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=67.61.77.94; posting-account=V5nGoQoAAAC_P2U0qnxm2kC0s1jNJXJa
NNTP-Posting-Host: 67.61.77.94
References: <t60i6r$7m0$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
Subject: Re: Naming for parsing words
From: sdwjac...@gmail.com (S Jack)
Injection-Date: Tue, 17 May 2022 18:13:00 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1725
 by: S Jack - Tue, 17 May 2022 18:12 UTC

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

Re: Naming for parsing words

<nnd$587ee73c$4c21fe45@037f106620cc2af5>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17886&group=comp.lang.forth#17886

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <t60i6r$7m0$1@dont-email.me>
Subject: Re: Naming for parsing words
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$587ee73c$4c21fe45@037f106620cc2af5>
Organization: KPN B.V.
Date: Tue, 17 May 2022 21:47:29 +0200
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe004.abavia.com!abp001.abavia.com!news.kpn.nl!not-for-mail
Lines: 43
Injection-Date: Tue, 17 May 2022 21:47:29 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
X-Received-Bytes: 2232
 by: none - Tue, 17 May 2022 19:47 UTC

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

>
>[1] Naming for parsing words
>https://github.com/ForthHub/discussion/discussions/112
>
>--
>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

Re: Naming for parsing words

<t61nfm$1rge$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17890&group=comp.lang.forth#17890

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Naming for parsing words
Date: Wed, 18 May 2022 13:00:06 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t61nfm$1rge$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="60942"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Wed, 18 May 2022 03:00 UTC

On 18/05/2022 02: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

I've tended to use /xxx to mean 'extract' e.g. /STRING /SIGN

Any confusion with file path is just the nature of forth and the former
should be in quotes anyway.

Re: Naming for parsing words

<a184f419-cc55-4868-ae1c-3fb42b27f206n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17898&group=comp.lang.forth#17898

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:620a:10a8:b0:69f:8b8b:36d9 with SMTP id h8-20020a05620a10a800b0069f8b8b36d9mr19753639qkk.93.1652873929137;
Wed, 18 May 2022 04:38:49 -0700 (PDT)
X-Received: by 2002:a0c:f78b:0:b0:461:e30c:fafb with SMTP id
s11-20020a0cf78b000000b00461e30cfafbmr5238185qvn.48.1652873928964; Wed, 18
May 2022 04:38:48 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 18 May 2022 04:38:48 -0700 (PDT)
In-Reply-To: <t61nfm$1rge$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <t60i6r$7m0$1@dont-email.me> <t61nfm$1rge$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a184f419-cc55-4868-ae1c-3fb42b27f206n@googlegroups.com>
Subject: Re: Naming for parsing words
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Wed, 18 May 2022 11:38:49 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1777
 by: Hans Bezemer - Wed, 18 May 2022 11:38 UTC

On Wednesday, May 18, 2022 at 5:00:14 AM UTC+2, dxforth wrote:
> On 18/05/2022 02:23, Ruvim wrote:
> > 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?
Well, I think you mean by parsing - cutting up the TIB. In that case,
we already have PARSE, PARSE-NAME (and 4tH has got its own "PARSE-WORD").

So, when designing this lib I took that into account:
https://sourceforge.net/p/forth-4th/code/HEAD/tree/trunk/4th.src/lib/parsing.4th

BTW, if you try to compile it - it's 4tH, not Forth, so your mileage may vary.

Hans Bezemer

Re: Naming for parsing words

<t62vui$1mi$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17904&group=comp.lang.forth#17904

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: Naming for parsing words
Date: Wed, 18 May 2022 18:30:39 +0400
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <t62vui$1mi$1@dont-email.me>
References: <t60i6r$7m0$1@dont-email.me>
<27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 18 May 2022 14:30:42 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="92555cf9bb6086aa2f0a414ebbf48b6e";
logging-data="1746"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18scQ9FSj4bNdTaQnNFn06Y"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:507DGPcQCD0C0rKXsrT38cu84lQ=
In-Reply-To: <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
Content-Language: en-US
 by: Ruvim - Wed, 18 May 2022 14:30 UTC

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"

And after that, what to do with "[if]" and "[undefined]"?

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

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.

--
Ruvim

Re: Naming for parsing words

<2022May19.164709@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17922&group=comp.lang.forth#17922

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Naming for parsing words
Date: Thu, 19 May 2022 14:47:09 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 79
Message-ID: <2022May19.164709@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me>
Injection-Info: reader02.eternal-september.org; posting-host="6f7ef30ae0f966f306955afb045a748f";
logging-data="11212"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+DW1FWot+dcphksPwa7CaH"
Cancel-Lock: sha1:ZHE9hH+gKXolg2NHKVDKhCjzorI=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Thu, 19 May 2022 14:47 UTC

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.

>To use them as:
>
> `foo :def 123 . ;
>
> [: @ . ;] `bar does-created 123 ,
>
> foo bar \ prints "123 123"

Why `FOO, not "FOO"?

>And after that, what to do with "[if]" and "[undefined]"?

And \ and (.

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

Why yes? And please explain the definition of TEST-BAZ and BAZ2.

- 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

Re: Naming for parsing words

<5074be33-6409-46f1-bd7b-fb171d3dabc5n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17923&group=comp.lang.forth#17923

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a37:2d44:0:b0:6a3:2bf1:a6b3 with SMTP id t65-20020a372d44000000b006a32bf1a6b3mr3657021qkh.293.1652980858768;
Thu, 19 May 2022 10:20:58 -0700 (PDT)
X-Received: by 2002:a05:6214:2426:b0:45a:32f9:362b with SMTP id
gy6-20020a056214242600b0045a32f9362bmr4990117qvb.127.1652980858573; Thu, 19
May 2022 10:20:58 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Thu, 19 May 2022 10:20:58 -0700 (PDT)
In-Reply-To: <t62vui$1mi$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=67.61.77.94; posting-account=V5nGoQoAAAC_P2U0qnxm2kC0s1jNJXJa
NNTP-Posting-Host: 67.61.77.94
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5074be33-6409-46f1-bd7b-fb171d3dabc5n@googlegroups.com>
Subject: Re: Naming for parsing words
From: sdwjac...@gmail.com (S Jack)
Injection-Date: Thu, 19 May 2022 17:20:58 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2683
 by: S Jack - Thu, 19 May 2022 17:20 UTC

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 ': .
--
me

Re: Naming for parsing words

<t67838$12n4$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17925&group=comp.lang.forth#17925

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Naming for parsing words
Date: Fri, 20 May 2022 15:14:15 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t67838$12n4$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me>
<27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="35556"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Fri, 20 May 2022 05:14 UTC

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

Re: Naming for parsing words

<nnd$14d13a55$38f3b2cc@2d634e70c09e3a23>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17926&group=comp.lang.forth#17926

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me>
Subject: Re: Naming for parsing words
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$14d13a55$38f3b2cc@2d634e70c09e3a23>
Organization: KPN B.V.
Date: Fri, 20 May 2022 09:48:43 +0200
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!feeder.usenetexpress.com!tr2.eu1.usenetexpress.com!94.232.112.246.MISMATCH!abe006.abavia.com!abp001.abavia.com!news.kpn.nl!not-for-mail
Lines: 61
Injection-Date: Fri, 20 May 2022 09:48:43 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
 by: none - Fri, 20 May 2022 07:48 UTC

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>
>
>
>Hm.. why not.
>
>--
>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

Re: Naming for parsing words

<fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17927&group=comp.lang.forth#17927

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:620a:102d:b0:6a3:3c42:423f with SMTP id a13-20020a05620a102d00b006a33c42423fmr3827718qkk.274.1653045778517;
Fri, 20 May 2022 04:22:58 -0700 (PDT)
X-Received: by 2002:a05:6214:2aa1:b0:45a:f491:34c3 with SMTP id
js1-20020a0562142aa100b0045af49134c3mr7423742qvb.83.1653045778315; Fri, 20
May 2022 04:22:58 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Fri, 20 May 2022 04:22:58 -0700 (PDT)
In-Reply-To: <2022May19.164709@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me> <2022May19.164709@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com>
Subject: Re: Naming for parsing words
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Fri, 20 May 2022 11:22:58 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3875
 by: Hans Bezemer - Fri, 20 May 2022 11:22 UTC

On Thursday, May 19, 2022 at 5:23:39 PM UTC+2, Anton Ertl wrote:

Nice to see that "S Jack" puts me in the realm of "Forth purists", where
4tH cannot be classified as "pure" by any measure - including the words
it supports - which are in part just there to facilitate the particular 4tH
architecture, but also stuff like ">ZERO" ( n -- 0), "STOW" ( n1 n2 -- n1 n1 n2),
"EXCEPT" (like: 0= WHILE), "UNLESS" (like: 0= IF) and ";THEN" (like: EXIT THEN).

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.

> Instead of ['] FOO, I write `FOO. The latter can be copy-pasted into
> interpretive code.
> Instead of S" BLA", I write "BLA".
... which (like prefixed numbers) violate the rule "keep it simple", since
it requires me to evaluate what I've parsed before I pull the trigger.

I literally try to find the word. FAIL: I literally convert it. FAIL: I throw
an exception. I don't have to go looking for prefixed ', ", #, $ or whatever.
"Simplicity" means "maintainability". "Maintainability" means "less bugs".
(See: "Does Software Decay").
> Instead of POSTPONE FOO, I write ]] FOO [[. Especially nice for
> multiple words.
I think that it's a beautiful solution - although due to 4tH's architecture,
it does carry very little significance to that particular project.

> >Why not introduce new words like:
> Why yes? And please explain the definition of TEST-BAZ and BAZ2.
I think this comes form a desire to "beautify the language" - may be
by even looking at other "beautiful languages", without really appreciating
Forth's inherent philosophy. And that's KISS. And IMHO every generally
accepted proposition HAS to adhere to that philosophy.

I have nothing against coming up with new stuff that make the language
more useful or readable - but the starting point must always be:
- What problem am I exactly solving here;
- How do I express (implement) it in a Forth-like way ;
- How does this actual solution improve the way we're reading and writing
Forth programs.

Starting with (a ripped off) idea about "syntactic sugar" and then try to
squeeze it brute force in the most horrible Forth code, is IMHO the very
worst starting point - even from a engineering point of view.

P.S. I know I'm reacting here to different messages from different persons.
But I'm not addressing particular persons here, but particular ideas.

Hans Bezemer

Re: Naming for parsing words

<8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17928&group=comp.lang.forth#17928

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:5e11:0:b0:2f9:ef3:38c0 with SMTP id h17-20020ac85e11000000b002f90ef338c0mr7137104qtx.537.1653047221726;
Fri, 20 May 2022 04:47:01 -0700 (PDT)
X-Received: by 2002:a05:6214:411c:b0:45a:d240:afb9 with SMTP id
kc28-20020a056214411c00b0045ad240afb9mr7384586qvb.122.1653047221573; Fri, 20
May 2022 04:47:01 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Fri, 20 May 2022 04:47:01 -0700 (PDT)
In-Reply-To: <t62vui$1mi$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
Subject: Re: Naming for parsing words
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Fri, 20 May 2022 11:47:01 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2681
 by: Hans Bezemer - Fri, 20 May 2022 11:47 UTC

On Wednesday, May 18, 2022 at 4:30:45 PM UTC+2, Ruvim wrote:
> Do you avoid the standard parsing words?
> For example: "[']" "postpone" 's"' 'abort"'
> And what about defining words?
In my programming: no - they're just too handy. Imagine not having
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

Re: Naming for parsing words

<nnd$47dde30e$196d686f@6e5070a1f8d96c61>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17930&group=comp.lang.forth#17930

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
Subject: Re: Naming for parsing words
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$47dde30e$196d686f@6e5070a1f8d96c61>
Organization: KPN B.V.
Date: Fri, 20 May 2022 15:01:49 +0200
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe004.abavia.com!abp002.abavia.com!news.kpn.nl!not-for-mail
Lines: 90
Injection-Date: Fri, 20 May 2022 15:01:49 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
X-Received-Bytes: 3978
 by: none - Fri, 20 May 2022 13:01 UTC

In article <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>On Wednesday, May 18, 2022 at 4:30:45 PM UTC+2, Ruvim wrote:
>> Do you avoid the standard parsing words?
>> For example: "[']" "postpone" 's"' 'abort"'
>> And what about defining words?
>In my programming: no - they're just too handy. Imagine not having
>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

Totally agreed. But in my book:
'FOO ALIAS BAR
' is a normal word, but it has the prefix flag.
'FOO is the same constant in compilation and interpretation mode.
In this way there is no exception with numbers,
1 is the prefix that understands all numbers starting with 1,
2 with 2 etc.
(I invented this when I refused to add $ in my kernel, and
I wanted to load Marcel Hendrix programs. The solution is to
make $ a loadable extension, and the PREFIX idea was born.).
Interestingly the lookup of words in the dictionary is shorter.
Formerly (adr len adr1 len1 ) COMPARE
Now (pp adr len ) CORA (simpler compare)
Who cares what the lenght of the word is, the comparision fails
anyway, normally.

Every word say
DROP 1178 $189 'FOO "We gaan naar rome"
is found in the dictionary. No exceptions.

(I have demonstrated that with adding a few characters to
terminators, not only space and tab, you can parse Pascal.)

>
>Because that is in essence what you're doing and IMHO clearer than
>
>SYNONYM BAR FOO

I hate that too

>
>4tH supports a parsing AKA which does EXACTLY that:
>
>AKA FOO BAR
>
>Although (also from readability), this is IMHO much clearer:
>
>' FOO AKA BAR

The rule is that you add a word (BAR) to the dictionary, the
preceeding word (AKA) does the action, consuming some data.

DEFER BAR
'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.

>
>But the former is found at least in SOME Forths, so almost COMUS. ;-)

>
>Hans Bezemer
--
"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

Re: Naming for parsing words

<2022May20.165102@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17931&group=comp.lang.forth#17931

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Naming for parsing words
Date: Fri, 20 May 2022 14:51:02 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 17
Message-ID: <2022May20.165102@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com> <nnd$47dde30e$196d686f@6e5070a1f8d96c61>
Injection-Info: reader02.eternal-september.org; posting-host="2c951e407f74007c0342cdc4431af617";
logging-data="6281"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+KG6Dtv5tjCfuSNXBsgtfC"
Cancel-Lock: sha1:iqhHzW3yZWp/z7zBC27P9Mc+No0=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Fri, 20 May 2022 14:51 UTC

albert@cherry.(none) (albert) writes:
>DEFER BAR
>'FOO IS BAR
>is also an abomination.
>This must be
>'FOO 'BAR TRANSFER-EXECUTION-BEHAVIOUR

A standard variant of this code:

' foo ' bar defer!

- 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

Simplicity and the text interpreter (was: Naming for parsing words)

<2022May20.165835@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17933&group=comp.lang.forth#17933

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Simplicity and the text interpreter (was: Naming for parsing words)
Date: Fri, 20 May 2022 14:58:35 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 129
Message-ID: <2022May20.165835@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me> <2022May19.164709@mips.complang.tuwien.ac.at> <fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="2c951e407f74007c0342cdc4431af617";
logging-data="6846"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+NG0EjTxRB2YkyCqC2V7Ql"
Cancel-Lock: sha1:kTxw4LyYJgXfnQbxJsSs9vdsTbA=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Fri, 20 May 2022 14:58 UTC

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>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;

No compilation?

>(2) If it's not a word, convert it to a number;

No compilation?

>(3) If it's not a number either, it's an error.

I guess you want a traditional text interpreter rather than the
interpret-only text interpreter you outlined above. let's take a look
at a very tradtitional one: This is taken from Ting's System's Guide
to fig-Forth:

: INTERPRET
BEGIN
-FIND
IF
STATE @ <
IF CFA ,
ELSE
CFA
EXECUTE
ENDIF
?STACK
ELSE
HERE
NUMBER
DPL @ 1+
IF
[COMPILE]
DLITERAL
ELSE
DROP
[COMPILE]
LITERAL
ENDIF
?STACK
ENDIF
AGAIN
;

Hmm, triple-nested control structure, 1 BEGIN, 3 IFs, and 3 ELSEs, not
the paragon of simplicity. Interestingly, I don't find your (3) in
there. It must be hidden im NUMBER (checking, it is). It's also not
obvious how INTERPRET terminates; that's performed with the X trick,
but I don't discuss this here further.

How about simplifying it?

1) Eliminating doubles would get rid of one IF.

2) Eliminating numbers would get rid of another IF (you now have to
hide the error handling in -FIND).

3) Eliminating compile state would eliminate the third IF.

The result would be much simpler and especially clearer (well, apart
from the error-hiding and X tricks):

: INTERPRET
BEGIN
-FIND
CFA
EXECUTE
?STACK
AGAIN
;

>"Simplicity" means "maintainability". "Maintainability" means "less bugs".
>(See: "Does Software Decay").

Then you should be delighted by this new INTERPRET.

However, there is a cost to this implementation simplicity. Where in
fig-Forth you write

: star 42 emit ;

you now have to write something like

: star num 42 literal [compile] emit ;

but that's a sacrifice you love to make in the name of "simplicity",
clarity, "maintainability" and "less bugs", no?

If not, please explain why you find the compexity of the traditional
INTERPRET to be acceptable, but not

: INTERPRET
BEGIN
PARSE-NAME DUP
WHILE
FORTH-RECOGNIZER RECOGNIZE
STATE @ IF RECTYPE>COMP ELSE RECTYPE>INT THEN
EXECUTE
?STACK \ simple housekeeping
REPEAT 2DROP
;

(from <https://forth-standard.org/proposals/recognizer#contribution-142>)

The problem with the traditional interpreter is that

* It does not recognize floats.

* Without number prefixes we get bugs in the code from using (sticky)
HEX.

* Without the tick-recognizer I get bugs from writing ' where ['] is
appropriate and vice versa, and testing compiled code interpretively
is cumbersome.

* Without the string-recognizer, we need to use S\" (or S"), and
implementing these words properly is apparently too complex for most
Forth systems.

- 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

Re: Naming for parsing words

<27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17939&group=comp.lang.forth#17939

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ad4:596c:0:b0:45d:b08f:830f with SMTP id eq12-20020ad4596c000000b0045db08f830fmr10925426qvb.86.1653127648002;
Sat, 21 May 2022 03:07:28 -0700 (PDT)
X-Received: by 2002:ac8:5cca:0:b0:2f9:ca3:f35e with SMTP id
s10-20020ac85cca000000b002f90ca3f35emr10810506qta.432.1653127647831; Sat, 21
May 2022 03:07:27 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sat, 21 May 2022 03:07:27 -0700 (PDT)
In-Reply-To: <nnd$47dde30e$196d686f@6e5070a1f8d96c61>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
<nnd$47dde30e$196d686f@6e5070a1f8d96c61>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
Subject: Re: Naming for parsing words
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Sat, 21 May 2022 10:07:27 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Hans Bezemer - Sat, 21 May 2022 10:07 UTC

On Friday, May 20, 2022 at 3:01:57 PM UTC+2, none albert wrote:
> DEFER BAR
> '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.
You're kidding, right? I desperately hope so. Because IS is just another
TO. By seriously promoting this, you say:

23 ' FOO !

I don't think this helps readability - on the contrary.

Hans Bezemer

Re: Simplicity and the text interpreter (was: Naming for parsing words)

<42d94edf-e450-4c54-baa7-4f715faf367cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17940&group=comp.lang.forth#17940

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:622a:1210:b0:2f3:da26:3778 with SMTP id y16-20020a05622a121000b002f3da263778mr10683319qtx.173.1653129234464;
Sat, 21 May 2022 03:33:54 -0700 (PDT)
X-Received: by 2002:ac8:58c3:0:b0:2f9:2356:d21f with SMTP id
u3-20020ac858c3000000b002f92356d21fmr3607724qta.265.1653129234312; Sat, 21
May 2022 03:33:54 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sat, 21 May 2022 03:33:54 -0700 (PDT)
In-Reply-To: <2022May20.165835@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me> <2022May19.164709@mips.complang.tuwien.ac.at>
<fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com> <2022May20.165835@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <42d94edf-e450-4c54-baa7-4f715faf367cn@googlegroups.com>
Subject: Re: Simplicity and the text interpreter (was: Naming for parsing words)
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Sat, 21 May 2022 10:33:54 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 4107
 by: Hans Bezemer - Sat, 21 May 2022 10:33 UTC

On Friday, May 20, 2022 at 6:05:05 PM UTC+2, Anton Ertl wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
> No compilation?
Compilation sets STATE and enters the compiler. ";" compiles EXIT,
SMUDGEs the latest definition and reenters the interpreter.

> The problem with the traditional interpreter is that
> * 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.

> * Without number prefixes we get bugs in the code from using (sticky)
> HEX.
Gee, never happened to me. Maybe a programmer discipline issue? IMHO
that enables people to write Forth at all - since they don't deplete or overflow
the stack with every IF or BEGIN..REPEAT.

Neat antidote:

: base&exec base @ >r base ! execute r> base ! ;

Which allows for cool code like:

r@ [char] u = if u>d ['] (.number) 10 base&exec then
r@ [char] o = if u>d ['] (.number) 8 base&exec then
r@ [char] x = if u>d ['] (.number) 16 base&exec then

You know - Factor has got some cool idea's!

> * Without the tick-recognizer I get bugs from writing ' where ['] is
> appropriate and vice versa, and testing compiled code interpretively
> is cumbersome.
Gee, never happened to me. Maybe a programmer discipline issue? IMHO
that enables people to write Forth at all - since they don't deplete or overflow
the stack with every IF or BEGIN..REPEAT.

> * Without the string-recognizer, we need to use S\" (or S"), and
> implementing these words properly is apparently too complex for most
> Forth systems.
Never had that problem. Could be an architecture issue - idunno:

/*
This function compiles '."'.
*/

#ifndef ARCHAIC
static void DoDotQuote (void)
#else
static void DoDotQuote ()
#endif

{
CompileString (PRINT);
}

/*
This function compiles a ,".
*/

#ifndef ARCHAIC
static void DoCommaQuote (void)
#else
static void DoCommaQuote ()
#endif

{
CompileString (STRINGD);
}

/*
This function compiles a S".
*/

#ifndef ARCHAIC
static void DoSQuote (void)
#else
static void DoSQuote ()
#endif

{
CompileString (SQUOTE);
}

The reason I'm posting this is: I can't comment on the rationale
others peoples implementations. I can - however - comment on
mine. If I'd done Tings compiler, I'd probably done it differently.

E.g. I'd implemented a HIDE, so after implementing IF, I could
discard helper words from the search chain . Gee, I even think
I implemented such a thing in 4tH, I'm not sure. But I vaguely
remember it..

Hans Bezemer

IS vs. DEFER! (was: Naming for parsing words)

<2022May21.122618@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17941&group=comp.lang.forth#17941

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: IS vs. DEFER! (was: Naming for parsing words)
Date: Sat, 21 May 2022 10:26:18 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 27
Message-ID: <2022May21.122618@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com> <nnd$47dde30e$196d686f@6e5070a1f8d96c61> <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="635e1e13de3db738801291169031cff5";
logging-data="12223"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/GyJAzy4QxkGyny397pUZU"
Cancel-Lock: sha1:d4A/QzkYhG1uQmA52oeP17ssGt0=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 21 May 2022 10:26 UTC

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>On Friday, May 20, 2022 at 3:01:57 PM UTC+2, none albert wrote:
>> DEFER BAR
>> 'FOO IS BAR
>> is also an abomination.

When I made the DEFER proposal, I proposed IS because of common
practice, DEFER! as a non-parsing alternative, and DEFER@ in order to
get the current contents of the deferred word. Stephen Pelc suggested
a parsing alternative to DEFER@, and it became ACTION-OF.

I used to think that ACTION-OF and IS are unnecessary with DEFER@ and
DEFER!, but a few years ago we introduced defer-flavoured locals, and
with locals the idioms "['] foo defer@" and "( xt ) ['] foo defer!"
don't work, so ACTION-OF and IS are actually necessary in this
context.

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.

- 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

Re: Simplicity and the text interpreter (was: Naming for parsing words)

<2022May21.194316@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17944&group=comp.lang.forth#17944

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Simplicity and the text interpreter (was: Naming for parsing words)
Date: Sat, 21 May 2022 17:43:16 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 60
Message-ID: <2022May21.194316@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me> <2022May19.164709@mips.complang.tuwien.ac.at> <fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com> <2022May20.165835@mips.complang.tuwien.ac.at> <42d94edf-e450-4c54-baa7-4f715faf367cn@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="635e1e13de3db738801291169031cff5";
logging-data="29229"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Q520ddMl6k/hiec4CAWtr"
Cancel-Lock: sha1:TpdKpjHzDXREX2qYsV+pWYlUsoM=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 21 May 2022 17:43 UTC

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>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.

But your three rule engine had no place for add-ons.

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

No, it actually is the direction I prefer: have an extensible text
interpreter. And once you have that, you can make your rule (1) and
(2) extensions, too.

>Gee, never happened to me. Maybe a programmer discipline issue?
[...]
>Gee, never happened to me. Maybe a programmer discipline issue?

You can burden the programmers with some tasks, claim that you have a
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.

>> * Without the string-recognizer, we need to use S\" (or S"), and
>> implementing these words properly is apparently too complex for most
>> Forth systems.
>Never had that problem. Could be an architecture issue - idunno:

[C code skipped]

What do you want to tell me by showing some C fragments?

>The reason I'm posting this is: I can't comment on the rationale
>others peoples implementations. I can - however - comment on
>mine.

But you posted the C fragments without any comment relevant to the
discussion at hand.

And if you studied other implementations, you could

1) learn from them.

2) comment on them.

Your comments leave the impression that you are convinced that your
implementation is the greatest, or at least close to it, but you
actually don't know other implementations.

- 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

Re: Simplicity and the text interpreter (was: Naming for parsing words)

<0c04229d-21f0-47ac-af3a-393388c4e767n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17946&group=comp.lang.forth#17946

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a37:a4c2:0:b0:6a3:4299:ba69 with SMTP id n185-20020a37a4c2000000b006a34299ba69mr7844654qke.493.1653168821895;
Sat, 21 May 2022 14:33:41 -0700 (PDT)
X-Received: by 2002:ac8:58c3:0:b0:2f9:2356:d21f with SMTP id
u3-20020ac858c3000000b002f92356d21fmr5120304qta.265.1653168821742; Sat, 21
May 2022 14:33:41 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sat, 21 May 2022 14:33:41 -0700 (PDT)
In-Reply-To: <2022May21.194316@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me> <2022May19.164709@mips.complang.tuwien.ac.at>
<fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com> <2022May20.165835@mips.complang.tuwien.ac.at>
<42d94edf-e450-4c54-baa7-4f715faf367cn@googlegroups.com> <2022May21.194316@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0c04229d-21f0-47ac-af3a-393388c4e767n@googlegroups.com>
Subject: Re: Simplicity and the text interpreter (was: Naming for parsing words)
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Sat, 21 May 2022 21:33:41 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2054
 by: Hans Bezemer - Sat, 21 May 2022 21:33 UTC

On Saturday, May 21, 2022 at 8:11:49 PM UTC+2, Anton Ertl wrote:
> You can burden the programmers with some tasks, claim that you have a
> 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.
Try Java. You'll find it impressive. It's built EXACTLY from that perspective.
Dijkstra LOVED it.

Hans Bezemer

Re: IS vs. DEFER! (was: Naming for parsing words)

<t6cm0j$1ar7$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17947&group=comp.lang.forth#17947

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Sun, 22 May 2022 16:42:26 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t6cm0j$1ar7$1@gioia.aioe.org>
References: <t60i6r$7m0$1@dont-email.me>
<27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me>
<8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com>
<nnd$47dde30e$196d686f@6e5070a1f8d96c61>
<27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com>
<2022May21.122618@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="43879"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Sun, 22 May 2022 06:42 UTC

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 ?

#512 value #OUTBUF \ buffer size

code WRITECHAR ( char -- )
addr #outbuf ) ax mov outsiz ) ax cmp 1 $ jnz
c: (flushwrite) 4 ?ferror ;c
1 $: ax pop outptr ) di mov al 0 [di] mov
outptr ) inc outsiz ) inc next end-code

Re: IS vs. DEFER! (was: Naming for parsing words)

<2022May22.091643@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17948&group=comp.lang.forth#17948

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: IS vs. DEFER! (was: Naming for parsing words)
Date: Sun, 22 May 2022 07:16:43 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 19
Message-ID: <2022May22.091643@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me> <8e02adcd-d183-4d15-977f-d08541c340acn@googlegroups.com> <nnd$47dde30e$196d686f@6e5070a1f8d96c61> <27a2ca80-3c2f-40f5-8e03-edaf50cae252n@googlegroups.com> <2022May21.122618@mips.complang.tuwien.ac.at> <t6cm0j$1ar7$1@gioia.aioe.org>
Injection-Info: reader02.eternal-september.org; posting-host="8241a6e5816418ac47af082a8fb0d782";
logging-data="940"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+kXw8bo7OP36tx24lZNKNn"
Cancel-Lock: sha1:jt0jI/UD58J0JofI13asPTRxIBY=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sun, 22 May 2022 07:16 UTC

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.

- 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

Re: Simplicity and the text interpreter (was: Naming for parsing words)

<2022May22.101658@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17949&group=comp.lang.forth#17949

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Simplicity and the text interpreter (was: Naming for parsing words)
Date: Sun, 22 May 2022 08:16:58 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 29
Message-ID: <2022May22.101658@mips.complang.tuwien.ac.at>
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com> <t62vui$1mi$1@dont-email.me> <2022May19.164709@mips.complang.tuwien.ac.at> <fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com> <2022May20.165835@mips.complang.tuwien.ac.at> <42d94edf-e450-4c54-baa7-4f715faf367cn@googlegroups.com> <2022May21.194316@mips.complang.tuwien.ac.at> <0c04229d-21f0-47ac-af3a-393388c4e767n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="8241a6e5816418ac47af082a8fb0d782";
logging-data="1504"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PrdVcNfTON/dyFcW6RUFB"
Cancel-Lock: sha1:WZhZLyI8fAhl+pEnxgX8WfOBsiA=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sun, 22 May 2022 08:16 UTC

Hans Bezemer <the.beez.speaks@gmail.com> writes:
>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 less
>> burdensome ways to express the programs, e.g., number prefixes and the
>> tick-recognizer.
>Try Java. You'll find it impressive. It's built EXACTLY from that perspective.

In my experience Java is quite burdensome.

>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

Re: Simplicity and the text interpreter (was: Naming for parsing words)

<e0d091cb-addd-474a-8a3e-5fba578c8692n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17951&group=comp.lang.forth#17951

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:6214:208:b0:461:d511:c170 with SMTP id i8-20020a056214020800b00461d511c170mr13899449qvt.44.1653224795947;
Sun, 22 May 2022 06:06:35 -0700 (PDT)
X-Received: by 2002:ac8:5cca:0:b0:2f9:ca3:f35e with SMTP id
s10-20020ac85cca000000b002f90ca3f35emr13881630qta.432.1653224795728; Sun, 22
May 2022 06:06:35 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sun, 22 May 2022 06:06:35 -0700 (PDT)
In-Reply-To: <2022May22.101658@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <t60i6r$7m0$1@dont-email.me> <27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me> <2022May19.164709@mips.complang.tuwien.ac.at>
<fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com> <2022May20.165835@mips.complang.tuwien.ac.at>
<42d94edf-e450-4c54-baa7-4f715faf367cn@googlegroups.com> <2022May21.194316@mips.complang.tuwien.ac.at>
<0c04229d-21f0-47ac-af3a-393388c4e767n@googlegroups.com> <2022May22.101658@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <e0d091cb-addd-474a-8a3e-5fba578c8692n@googlegroups.com>
Subject: Re: Simplicity and the text interpreter (was: Naming for parsing words)
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Sun, 22 May 2022 13:06:35 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2997
 by: Hans Bezemer - Sun, 22 May 2022 13:06 UTC

On Sunday, May 22, 2022 at 10:42:16 AM UTC+2, Anton Ertl wrote:
> Hans Bezemer <the.bee...@gmail.com> writes:
> >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 less
> >> burdensome ways to express the programs, e.g., number prefixes and the
> >> tick-recognizer.
> >Try Java. You'll find it impressive. It's built EXACTLY from that perspective.
> In my experience Java is quite burdensome.
>
> >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.

Understanding sarcasm is a skill, I suppose. If you'd read his writings about e.g. Ada, you would have understood it was sarcasm.

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

Re: Simplicity and the text interpreter

<871qwlwc6o.fsf@nightsong.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=17963&group=comp.lang.forth#17963

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: no.em...@nospam.invalid (Paul Rubin)
Newsgroups: comp.lang.forth
Subject: Re: Simplicity and the text interpreter
Date: Sun, 22 May 2022 13:21:35 -0700
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <871qwlwc6o.fsf@nightsong.com>
References: <t60i6r$7m0$1@dont-email.me>
<27ad099d-5b39-4e07-9fc6-7afa4a5556aen@googlegroups.com>
<t62vui$1mi$1@dont-email.me>
<2022May19.164709@mips.complang.tuwien.ac.at>
<fdec8868-106e-4f77-95c4-019b28162711n@googlegroups.com>
<2022May20.165835@mips.complang.tuwien.ac.at>
<42d94edf-e450-4c54-baa7-4f715faf367cn@googlegroups.com>
<2022May21.194316@mips.complang.tuwien.ac.at>
<0c04229d-21f0-47ac-af3a-393388c4e767n@googlegroups.com>
<2022May22.101658@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="67ffa9353d8fefc17cc1a06ae438ec58";
logging-data="28987"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18LEYewtB/9yf/tkWd+yR+a"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:bdt2HXmOtgAXTuRH1rx+fOYoHbk=
sha1:MR7qrhhuSzhu5C6UF+fN1Zon1kM=
 by: Paul Rubin - Sun, 22 May 2022 20:21 UTC

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> |Haskell, though not perfect, is of a quality that is several orders of
> |magnitude higher than Java, which is a mess

From Dijkstra's 1972 Turing Award lecture:

With a few very basic principles at its foundation, it [LISP] has
shown a remarkable stability. Besides that, LISP has been the
carrier for a considerable number of in a sense our most
sophisticated computer applications. LISP has jokingly been
described as “the most intelligent way to misuse a computer”. I
think that description a great compliment because it transmits the
full flavour of liberation: it has assisted a number of our most
gifted fellow humans in thinking previously impossible
thoughts.

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor