Sujet : Re: portable or not? Volatile strings
De : dxforth (at) *nospam* gmail.com (dxf)
Groupes : comp.lang.forthDate : 24. Aug 2024, 03:58:26
Autres entêtes
Organisation : Ausics - https://newsgroups.ausics.net
Message-ID : <66c94c52$1@news.ausics.net>
References : 1 2 3 4 5
User-Agent : Mozilla Thunderbird
On 22/08/2024 8:59 pm,
albert@spenarnc.xs4all.nl wrote:
In article <nnd$274f6c32$10db022f@ea48fe6bf4bc59ed>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On 13-08-2024 06:07, dxf wrote:
On 13/08/2024 5:34 am, albert@spenarnc.xs4all.nl wrote:
...
In my book the code should be
>
" "
"###### "
" ## "
" "
DEF-BRICK BRICK1
>
Instead of
>
DEF-BRICK BRICK1 S" "
S" ###### "
S" ## "
S" "
>
The code (untested) could be
: DEF-BRICK CREATE
2>R 2>R 2>R 2>R
2R> ,, 2R> ,, 2R> ,, 2R> ,,
DOES> ... ;
>
OTOH it's no less difficult to write...
>
: M" [CHAR] " PARSE HERE OVER ALLOT SWAP MOVE ;
>
: DEF-BRICK CREATE DOES> ROT 4 * ROT + 2* CHARS + ;
>
DEF-BRICK BRICK1 M" "
M" ###### "
M" ## "
M" "
>
>
In 4tH, the easiest solution would be:
>
: BRICK@ ROT + @C SWAP 2* CHARS + ;
>
CREATE BRICK1
," "
," ###### "
," ## "
," "
DOES> BRICK@ ;
I dislike the use of parsing here by ," . It happens to work
because ," doesn't destroy the concatenation of HERE.
So you couldn't check the solution without digging into the 4TH
documentation.
In these case parsing is more or less advantageous because it allows
easier represent the bricks. The introduction of an auxiliary word M"
that is easily understood and checked is far superior using ," .
...
For the general case that's true. OTOH 4tH is free to exploit what it has.
The original ANS-Forth version tried using S" but it got complicated due
to the dual-action word. If standard compliance is the goal then options
are limited. OTOH a Gforth user not caring about compliance could exploit
what he had and define things more succinctly:
: M" \"-parse mem, ;
(assuming he knew these words existed)