( New thread from "Show human-readable time" )

FORGET and MARKER work ok for out-of-flow data but out-of-flow :NONAME
can have problems. The out-of-flow noname was being used for quotation.
The problem with out-of-flow noname has to do with it's being in link
with other dicitionary words. The following uses un-linked anonymous
code in place of noname and as can be seen there is no problem with
FORGET. When FOO is forgotten, memory is reclaimed up to the last
linked word BAR. All out-of-flow data and code was in-between BAR and
FOO so they were also removed as desired.

Notes:
1. The headless value previous name XVAR was renamed VAL,
2. The compiling register %R1 and %R2 were replace with two
standard compliant words [PARM0] and [PARM1] and
standard values named PARM0 and PARM1. These new compliant
words perform the same as compiling registers.

The run (as echoed):

\ Couple of parameter holders for compiling
0 value PARM0 \ hold a parameter
0 value PARM1 \ hold a parameter
: [PARM0] PARM0 COMPILE, ; IMMEDIATE \ compile parameter
: [PARM1] PARM1 COMPILE, ; IMMEDIATE \ compile parameter

: bar ." BAR " ;

HERE ," Today's date is " VAL, to PARM0 \ string data
HERE ," date" VAL, to PARM1 \ string data
DOCOL , HERE ] [PARM1] TRY /SYS THROW EXIT [ to PARM1 \ code ~ quotation
: FOO SPACE [PARM0] COUNT TYPE [PARM1] ;

FOO Today's date is Fri 01 Oct 2021 12:06:30 PM CDT

' FOO forget
latest space id. bar
+echo

Recap:
The goal was to move data and quotation code out of program flow of
the parent word to avoid processor penalty.

By placing out-of-flow data and code before the parent word and leaving them
un-linked FORGET and MARKER (not shown here) are able to perform
without modification.
--
me

On Friday, October 1, 2021 at 1:04:56 PM UTC-5, S Jack wrote:

To make previous example a little clearer
1. defined the following to remove word clutter:
: {{ DOCOL , HERE ] ;
: }} POSTPONE EXIT POSTPONE [ ; IMMEDIATE

2. Moved the catch/throw to the parent word (note that a VAL,
was then added to the quotation)
Being able to catch un-named code phrase is probably
the main driver for having quotations in Forth.
(
I'm not promoting quotations; I'm just dealing with it.
Give a concept a name and people get goofy with it.
)
HERE ," Today's date is " VAL, to PARM0
HERE ," date" VAL, to PARM1
{{ [PARM1] /SYS }} VAL, to PARM1
: FOO SPACE [PARM0] COUNT TYPE [PARM1] CATCH THROW ;

FOO Today's date is Fri 01 Oct 2021 02:02:03 PM CDT

--
me

On 2021-10-01, S Jack <sdwjack69@gmail.com> wrote:
> ( New thread from "Show human-readable time" )
>
> 0 value PARM0 \ hold a parameter
> 0 value PARM1 \ hold a parameter
>: [PARM0] PARM0 COMPILE, ; IMMEDIATE \ compile parameter
>: [PARM1] PARM1 COMPILE, ; IMMEDIATE \ compile parameter
>
>: bar ." BAR " ;
>
> HERE ," Today's date is " VAL, to PARM0 \ string data
> HERE ," date" VAL, to PARM1 \ string data
> DOCOL , HERE ] [PARM1] TRY /SYS THROW EXIT [ to PARM1 \ code ~ quotation
>: FOO SPACE [PARM0] COUNT TYPE [PARM1] ;
>
> FOO Today's date is Fri 01 Oct 2021 12:06:30 PM CDT
>

You should provide definitions for non standard words, I don't have
extensions...
>
> ' FOO forget
> latest space id. bar
> +echo
>
> Recap:
> The goal was to move data and quotation code out of program flow of
> the parent word to avoid processor penalty.
>
> By placing out-of-flow data and code before the parent word and leaving them
> un-linked FORGET and MARKER (not shown here) are able to perform
> without modification.
> --
> me

--

7-77-777
Evil Sinner!

On Friday, October 1, 2021 at 2:37:43 PM UTC-5, Branimir Maksimovic wrote:
> You should provide definitions for non standard words, I don't have
> extensions...

I know very little about the standard especially anything beyond ANS.
But I'll try:

"' foo FORGET" is same as "FORGET foo" and FORGET is standard.
In my Forth the norm is to have parameters precede operator with
some exception such as TO and IS . But don't concern yourself
about that; it just my thing.

LATEST ID. is Fig Forth. Have no idea how standard handles that.
Ask a guru.

DOCOL is codeword for colon definition. In a standard compliant Forth
you should be able to get it by ticking some colon definition:
: FOO ; ' FOO CONSTANT DOCOL
Again, ask a guru if that is compliant.

TRY wasn't standard in ANS and may be now, not sure. It was commonly used
in a definition as "TRY FOO" to be the same as "['] FOO CATCH".

VAL, was my headless value. VAL, is a rename of XVAL which I defined in
the previous thread. I show the definition that works in my Forth, a
Fig Forth which PFA functions like the standard XT. Probably most Figgers
who make their FIG behave close to standard use CFA as their XT which I
did long back. But Fig is PFA centric so I went with that this round and
it has not been a problem. My goal is not to make my system compliant but
I usually make words behave the same as standard where I can. But
some words such as ['] and [CHAR] no. And I usually use shorten names
such as VAR for VARIABLE CONST for CONSTANT VAL for VALUE and etc.
Back to VAL, . Because the definition shows where the XT of VAL, comes
from (the PFA) then for sure it's not compliant. What it would take to
make a compliant VAL, ask a guru.

Bottom line. Anything I publish is Forth in general and has nothing to
do with suggesting what the standard should do. You have many people
here more than happy to do that.
--
me

Hi SJack,

I have 2 (and a half) questions concerning your code.

S Jack <sdwjack69@gmail.com> wrote:
>
> HERE ," Today's date is " VAL, to PARM0
> HERE ," date" VAL, to PARM1
> {{ [PARM1] /SYS }} VAL, to PARM1
>> FOO SPACE [PARM0] COUNT TYPE [PARM1] CATCH THROW ;
>
> FOO Today's date is Fri 01 Oct 2021 02:02:03 PM CDT
>

Is CATCH THROW. different from EXECUTE in your system?

After FORGET foo are the string and the unnamed definition still
allocated in the dictionary? If not, how are they released?

Greetings, Ulrich

On Saturday, October 2, 2021 at 12:47:30 AM UTC-5, Ulrich Hoffmann wrote:
> Is CATCH THROW. different from EXECUTE in your system?
Not sure what you're getting at but because I used PFA as XT and to be somewhat
like standard I renamed Fig EXECUTE to EXEC and created EXECUTE ( pfa -- )
thus: ' FOO EXECUTE behaves like standard instead of ' FOO CFA EXECUTE in Fig.
That I believe was the only renaming of a Fig word to accommodate the standard.
But in general I found I could hide the CFA in most new words like COMPILE, and IS :
' foo compile,
defer bar ' koo is bar
I retained the evil state smart tick so in a definition I have:
' bar CATCH and not ['] bar CATCH
and PPN ' to postpone it (which in past was named ['] :)
>
> After FORGET foo are the string and the unnamed definition still
> allocated in the dictionary? If not, how are they released?
>
Your are correct. My claim of reclaiming the memory was false.
See following post.
--
me

On Saturday, October 2, 2021 at 12:47:30 AM UTC-5, Ulrich Hoffmann wrote:
> After FORGET foo are the string and the unnamed definition still
> allocated in the dictionary? If not, how are they released?

1. Replace scratch values with a parameter block; looks cleaner.
2. Found I didn't reclaim memory.
ELF32X86_64 Frog Version 1.0d

"wrk" job

\ VAL, ( x -- xt ) Headless value
\ Execution only.
\ Compile a headless value holding value x
\ and return the xt of the headless value
\ {{ ( -- xt ) Begin headless anonymous colon code
\ Execution only, not-nested.
\ }} ( C: xt -- ) Immediate ( -- XT )
\ End headless anonymous code
\ []! ( x n a -- ) Store x in nth cell of memory block
\ at address a
\ /SYS ( s -- ) Pass counted string s to system ( Frog Forth )
\ FORGET ( xt -- ) Non-parsing FORGET ( Frog Forth )

WRK DEFINITIONS
CREATE PARMBLK 16 CELLS ALLOT \ parameter block
: [PARM0] \ compile first parmeter
PARMBLK @ COMPILE, ; IMMEDIATE
: [PARM1] \ compile second parameter
PARMBLK CELL+ @ COMPILE, ; IMMEDIATE

CREATE BAR \ HERE at this point
HERE ," Today's date is " VAL, PARMBLK !
HERE ," date" VAL, 1 PARMBLK []!
{{ [PARM1] /SYS }} VAL, 1 PARMBLK []!
: FOO SPACE [PARM0] COUNT TYPE [PARM1] CATCH THROW ;

CR FOO \ text and date shown
Today's date is Сб окт 2 09:42:02 CDT 2021

WORDS
CURRENT and CONTEXT are WRK
FOO BAR [PARM1] [PARM0] PARMBLK
' FOO FORGET \ Forget FOO
WORDS
CURRENT and CONTEXT are WRK
BAR [PARM1] [PARM0] PARMBLK
( Confirmed BAR is now last word in context BUT...)
BAR HERE - 0= SPACE . \ TRUE if Memory reclaimed upto BAR -> 0
( (oops!) memory not reclaimed. )

+echo ok
--
me

On Saturday, October 2, 2021 at 10:18:46 AM UTC-5, S Jack wrote:

> \ {{ ( -- xt ) Begin headless anonymous colon code
> \ Execution only, not-nested.

Bah! Of course it's nested.

--
me

On 3/10/2021 01:13, S Jack wrote:
> On Saturday, October 2, 2021 at 12:47:30 AM UTC-5, Ulrich Hoffmann wrote:
>>
>> After FORGET foo are the string and the unnamed definition still
>> allocated in the dictionary? If not, how are they released?
>>
> Your are correct. My claim of reclaiming the memory was false.
> See following post.

It's not an uncommon situation e.g.

: BAR ... ;

:NONAME ... ; DROP

: FOO ... ;

FORGET FOO

won't recover the space consumed by the :NONAME. Few would lose sleep
over it but should an exact restore point be wanted, create a dummy word
and FORGET that.

On Saturday, October 2, 2021 at 11:21:02 AM UTC-5, dxforth wrote:
> On 3/10/2021 01:13, S Jack wrote:

Can't let it go.

VAL, ( x -- xt ) Headless value
\ Execution only.
\ Compile a headless value holding value x
\ and return the xt of the headless value
\ {{ ( -- xt ) Begin headless anonymous colon code
\ Execution only, not-nested.
\ }} ( C: xt -- ) Immediate ( -- XT )
\ End headless anonymous code
\ []! ( x n a -- ) Store x in nth cell of memory block
\ at address a
\ /SYS ( s -- ) Pass counted string s to system ( Frog Forth )
\ FORGET ( xt -- ) Non-parsing FORGET ( Frog Forth )
\ VDOES Vector latest to here ( Frog Forth )

WRK DEFINITIONS
CREATE PARMBLK 16 CELLS ALLOT \ parameter block
: [PARM0] \ compile first parmeter
PARMBLK @ COMPILE, ; IMMEDIATE
: [PARM1] \ compile second parameter
PARMBLK CELL+ @ COMPILE, ; IMMEDIATE

CREATE BAR \ HERE at this point
: FOO ;
HERE ," Today's date is " VAL, PARMBLK !
HERE ," date" VAL, 1 PARMBLK []!
{{ [PARM1] /SYS }} VAL, 1 PARMBLK []!
VDOES SPACE [PARM0] COUNT TYPE [PARM1] CATCH THROW ;

CR FOO \ text and date shown
Today's date is Сб окт 2 13:52:21 CDT 2021

WORDS
CURRENT and CONTEXT are WRK
FOO BAR [PARM1] [PARM0] PARMBLK
' FOO DUP FORGET \ Forget FOO
WORDS
CURRENT and CONTEXT are WRK
BAR [PARM1] [PARM0] PARMBLK
BAR HERE - 0= SPACE . \ TRUE if Memory reclaimed upto BAR -> -1

+echo ok
--
me

On 2021-10-02, S Jack <sdwjack69@gmail.com> wrote:
> On Saturday, October 2, 2021 at 12:47:30 AM UTC-5, Ulrich Hoffmann wrote:
>> After FORGET foo are the string and the unnamed definition still
>> allocated in the dictionary? If not, how are they released?
>
> 1. Replace scratch values with a parameter block; looks cleaner.
> 2. Found I didn't reclaim memory.
> ELF32X86_64 Frog Version 1.0d
>
> "wrk" job
>
> \ VAL, ( x -- xt ) Headless value
> \ Execution only.
> \ Compile a headless value holding value x
> \ and return the xt of the headless value
> \ {{ ( -- xt ) Begin headless anonymous colon code
> \ Execution only, not-nested.
> \ }} ( C: xt -- ) Immediate ( -- XT )
> \ End headless anonymous code
> \ []! ( x n a -- ) Store x in nth cell of memory block
> \ at address a
> \ /SYS ( s -- ) Pass counted string s to system ( Frog Forth )
> \ FORGET ( xt -- ) Non-parsing FORGET ( Frog Forth )
>
> WRK DEFINITIONS
> CREATE PARMBLK 16 CELLS ALLOT \ parameter block
>: [PARM0] \ compile first parmeter
> PARMBLK @ COMPILE, ; IMMEDIATE
>: [PARM1] \ compile second parameter
> PARMBLK CELL+ @ COMPILE, ; IMMEDIATE
>
> CREATE BAR \ HERE at this point
> HERE ," Today's date is " VAL, PARMBLK !
Is it : HERE @ ! ;
? What is PARAM0 ?
> --
> me

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

On 2021-10-02, S Jack <sdwjack69@gmail.com> wrote:
> On Saturday, October 2, 2021 at 11:21:02 AM UTC-5, dxforth wrote:
>> On 3/10/2021 01:13, S Jack wrote:
>
> Can't let it go.
>
> VAL, ( x -- xt ) Headless value
> \ Execution only.
> \ Compile a headless value holding value x
> \ and return the xt of the headless value
> \ {{ ( -- xt ) Begin headless anonymous colon code
> \ Execution only, not-nested.
> \ }} ( C: xt -- ) Immediate ( -- XT )
> \ End headless anonymous code
> \ []! ( x n a -- ) Store x in nth cell of memory block
> \ at address a
> \ /SYS ( s -- ) Pass counted string s to system ( Frog Forth )
> \ FORGET ( xt -- ) Non-parsing FORGET ( Frog Forth )
> \ VDOES Vector latest to here ( Frog Forth )
>
> WRK DEFINITIONS
> CREATE PARMBLK 16 CELLS ALLOT \ parameter block
>: [PARM0] \ compile first parmeter
> PARMBLK @ COMPILE, ; IMMEDIATE
>: [PARM1] \ compile second parameter
> PARMBLK CELL+ @ COMPILE, ; IMMEDIATE
>
> CREATE BAR \ HERE at this point
>: FOO ;
> HERE ," Today's date is " VAL, PARMBLK !
> HERE ," date" VAL, 1 PARMBLK []!
> {{ [PARM1] /SYS }} VAL, 1 PARMBLK []!
> VDOES SPACE [PARM0] COUNT TYPE [PARM1] CATCH THROW ;
>
> CR FOO \ text and date shown
> Today's date is Сб окт 2 13:52:21 CDT 2021
>
>
> WORDS
> CURRENT and CONTEXT are WRK
> FOO BAR [PARM1] [PARM0] PARMBLK
> ' FOO DUP FORGET \ Forget FOO
> WORDS
> CURRENT and CONTEXT are WRK
> BAR [PARM1] [PARM0] PARMBLK
> BAR HERE - 0= SPACE . \ TRUE if Memory reclaimed upto BAR -> -1
>

A thanks!

> +echo ok
> --
> me

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

On 3/10/2021 05:54, S Jack wrote:
> On Saturday, October 2, 2021 at 11:21:02 AM UTC-5, dxforth wrote:
>> On 3/10/2021 01:13, S Jack wrote:
>
> Can't let it go.

Just give it some time :)

On Saturday, October 2, 2021 at 8:25:48 PM UTC-5, dxforth wrote:
> On 3/10/2021 05:54, S Jack wrote:
> > On Saturday, October 2, 2021 at 11:21:02 AM UTC-5, dxforth wrote:
> >> On 3/10/2021 01:13, S Jack wrote:
> >
> > Can't let it go.
> Just give it some time :)
Don't need to. Last post shows it working.
--
me

On Saturday, October 2, 2021 at 8:28:13 PM UTC-5, S Jack wrote:
> On Saturday, October 2, 2021 at 8:25:48 PM UTC-5, dxforth wrote:
> > On 3/10/2021 05:54, S Jack wrote:
> > > On Saturday, October 2, 2021 at 11:21:02 AM UTC-5, dxforth wrote:
> > >> On 3/10/2021 01:13, S Jack wrote:
> > >
> > > Can't let it go.
> > Just give it some time :)
> Don't need to. Last post shows it working.
> --
> me
The fix to reclaim data involved constructing a compound Forth word, one that
has both a data area and a main code area. Started a new thread for the construct
of compound Forth words.
--
me

Hi SJack,

> Not sure what you're getting at but because I used
> PFA as XT and to be somewhat like standard I renamed Fig
> EXECUTE to EXEC and created EXECUTE ( pfa -- )

I see - I only wanted to remark that in

> : FOO SPACE [PARM0] COUNT TYPE [PARM1] CATCH THROW ;

if CATCH THROW is like EXECUTE then there is no need to CATCH
any error and then reTHROW it. Just EXECUTING will throw the same
errors anyway. So you could write

: FOO SPACE [PARM0] COUNT TYPE [PARM1] EXECUTE ;

I like the idea of having phrases that are considered equivalent such as

CATCH THROW == EXECUTE

LITERAL EXECUTE == COMPILE,

Here is a standard version of your code:

: pass ( x <name> -- x ) >r ' execute r> ; immediate

Marker empty

here u. ( 250360 )

here ," date" pass :noname ( -- addr ) Literal ;

pass :noname ( -- )
[ compile, ] /sys ; pass :noname ( -- addr ) Literal ;

here ," Today's date is " pass :noname ( -- addr ) Literal ;

pass pass : spam ( -- )
space [ compile, ] count type [ compile, ] execute ;

spam ( Today's date is Mo 4 Okt 2021 11:01:19 CEST )

empty

here u. ( 250360 )

PASS is an invention of Michael Gassenenko and passes a single value
inside a definition. (pass pass transfers two values).

EMPTY as a marker will revert the dictionary to its original
state thus also eliminating ALLOTed space and unnamed definitions.
HERE is the same as before.

A simplified version would be:

: pass ( x <name> -- x ) >r ' execute r> ; immediate

Marker empty

here u. ( 250360 )

here ," date"
pass :noname ( -- ) Literal /sys ;
here ," Today's date is "

pass pass : spam ( -- ) space Literal count type [ compile, ] ;

spam ( Today's date is Mo 4 Okt 2021 11:01:19 CEST )

empty

here u. ( 250360 )

Note this is all discussed in the context of avoiding to branch
around strings or quotations because of branch prediction penalties
in native code systems. Yes this can be made explicit as seen above
and the code is ugly. The gforth idea of using sections in the
implementation for this does it implicitly and keeps the normal syntax:

: spam ( -- ) space ." Today's date is " c" date" /sys ;

Greetings,

Ulrich

Am 02.10.21 um 17:13 schrieb S Jack:
> On Saturday, October 2, 2021 at 12:47:30 AM UTC-5, Ulrich Hoffmann wrote:
>> Is CATCH THROW. different from EXECUTE in your system?
> Not sure what you're getting at but because I used PFA as XT and to
be somewhat
> like standard I renamed Fig EXECUTE to EXEC and created EXECUTE ( pfa
-- )
> thus: ' FOO EXECUTE behaves like standard instead of ' FOO CFA
EXECUTE in Fig.
> That I believe was the only renaming of a Fig word to accommodate
the standard.
> But in general I found I could hide the CFA in most new words like
COMPILE, and IS :
> ' foo compile,
> defer bar ' koo is bar
> I retained the evil state smart tick so in a definition I have:
> ' bar CATCH and not ['] bar CATCH
> and PPN ' to postpone it (which in past was named [']
>>
>> After FORGET foo are the string and the unnamed definition still
>> allocated in the dictionary? If not, how are they released?
>>
> Your are correct. My claim of reclaiming the memory was false.
> See following post.
> --
> me
>

On 2021-10-04 12:59, Ulrich Hoffmann wrote:

> > : FOO SPACE [PARM0] COUNT TYPE [PARM1] CATCH THROW ;
>
> if CATCH THROW is like EXECUTE then there is no need to CATCH
> any error and then reTHROW it. Just EXECUTING will throw the same
> errors anyway. So you could write
>
> : FOO SPACE [PARM0] COUNT TYPE [PARM1] EXECUTE ;
>
>
> I like the idea of having phrases that are considered equivalent such as
>
> CATCH THROW  ==  EXECUTE
>
> LITERAL EXECUTE  ==  COMPILE,

A small correction:

LITERAL EXECUTE == [ COMPILE, ]

POSTPONE LITERAL POSTPONE EXECUTE == COMPILE,

Also, for an ordinary word X

['] X EXECUTE == X == [ ' X COMPILE, ]

Concerning "COMPILE," in brackets -- such use has small conflict with
the letter of the standard, but it's conceptually correct.

--
Ruvim

On Monday, October 4, 2021 at 4:59:06 AM UTC-5, Ulrich Hoffmann wrote:
> if CATCH THROW is like EXECUTE then there is no need to CATCH
> any error and then reTHROW it. Just EXECUTING will throw the same
> errors anyway. So you could write

Indeed, the example catch/throw isn't necessary but I wanted to show
referenced code being caught. Unnamed code phrase apart from and
referenced by parent code is my limited understanding of what a
Quotation is. I figured its interest to Forth programmers is having a
fragment of code complied in the middle of a definition that provides
the main code an XT that could be caught. Unnamed code in the data
area referenced by the main code to my understanding performs the
same service as Quotations.

Code fragments preceding and passed to main code, has some appeal to
me. All the fragments are exposed, nothing hidden, the parent code
is more concise, and the ugly references is like underlining where the
fragments apply (similar to folding or accordion text in text editor).
Not trying to sell it, don't expect many to embrace it, but it's workable.

Passing parameters by parameter block is one of several ways, PASS and
OUTSIDE being typical alternatives. I wanted to pass the parameters on
stack and access them via Fig CSP (disregarding compliance). But
parameters on stack to be consumed can require stack maneuvers for
the right order and duplicates. Without stack maneuvers and consumption
drops after (or in) definitions are needed. Parameter block passing
involved less clutter.

Glad you've given me an compliant example. I'll be looking at it.
Thank-you.

On Monday, October 4, 2021 at 4:59:06 AM UTC-5, Ulrich Hoffmann wrote:
> Hi SJack,
MARKER , used in anticipation of deletion, was not my concern. MARKER
deleting all after allotted memory is a tautology. The case in point
was how could FORGET reclaim allotted memory when no deletion was
anticipated and no preparation for deletion, such a dummy word, were
made. Found that FORGET can reclaim memory for word constructed
compound with data and code spaces.

I do recognize that reclaiming all data memory is not a high priority.
Delete a word and if some data memory is left over, it's just taking
up space but not causing any harm otherwise (in most cases). I don't
want to dwell on if left over memory is harmful or not. For me it's
get rid of it if can be reasonably done or else not worry about it.
Of course what's "reasonable" is subjective. I can live with compound
words and I sure many can't.

Branch prediction penalties I can live with (have been) but if I can
find a convenient way to avoid them I would thus willing to explore
the subject in particular that dealing with string data and quotations
as Anton suggests. I also included work around LITERAL replacing
literals with values which was the purpose of "VAL,", a headless value
to use in place of LIT .

For removing branching around string data and quotation it's a matter
of separation of strings and quotations from the main code flow. The
separating doesn't appear to be a big deal; of course to do it
elegantly most likely is.

I'm a bit surprised that sections is getting so much attentions as if
it's a key to this affair. Is there any real advantage of data in
sections over data in an allocated block of dictionary memory?
(hardware concern may dictate use of sections but that's an
independent subject)
--
me

On 5/10/2021 08:49, S Jack wrote:
>
> I do recognize that reclaiming all data memory is not a high priority.
> Delete a word and if some data memory is left over, it's just taking
> up space but not causing any harm otherwise (in most cases). I don't
> want to dwell on if left over memory is harmful or not. For me it's
> get rid of it if can be reasonably done or else not worry about it.
> Of course what's "reasonable" is subjective. I can live with compound
> words and I sure many can't.

Have you lived with it? It may be a passing fancy such as quotations.
The latter having been tagged and bagged, the search is on for the next
perceived dragon to slay.

S Jack <sdwjack69@gmail.com> writes:
>For removing branching around string data and quotation it's a matter
>of separation of strings and quotations from the main code flow. The
>separating doesn't appear to be a big deal; of course to do it
>elegantly most likely is.
>
>I'm a bit surprised that sections is getting so much attentions as if
>it's a key to this affair. Is there any real advantage of data in
>sections over data in an allocated block of dictionary memory?

Do you mean an ALLOCATEd block of memory? The disadvantage of
ALLOCATEd memory in Gforth and most other Forth systems is that it is
not saved in an image. So you would have

: foo s" bla" ;

and after putting this into an image and restoring it, foo would
produce a "string", where the address points to some place that
probably does not contain "bla", and has a good chance of being
unmapped (i.e., trying to access it produces a segmentation
violation). One could implement an image saver that can save
ALLOCATEd memory, but sections are easier to implement. For
quotations ALLOCATE is also inconvenient because you have to know the
size in advance.

Or do you mean an ALLOTed block of dictionary memory? That's the
first step towards sections: At the very least you now have to save
the dictionary pointer (DP) of the original dictionary and each of
these blocks. If you leave it at that, UNUSED will not tell you how
much of your block you have left, and more importantly, the system
cannot inform you when you have used up that block and are overwriting
parts of the dictionary not belonging to the block. You can now add a
dictionary-end pointer per block to address these things, and are
already pretty far in sections land. What you still have is that
saving the image will save all the unused data in these blocks, and
you cannot resize these blocks on image loading, but the advantage is
that image saving and loading is quite a bit simpler than if you have
resizable and (by necessity) relocatable sections.

>(hardware concern may dictate use of sections but that's an
>independent subject)

I am unaware of such hardware concerns.

- 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

S Jack schrieb am Montag, 4. Oktober 2021 um 23:49:21 UTC+2:
> On Monday, October 4, 2021 at 4:59:06 AM UTC-5, Ulrich Hoffmann wrote:
> > Hi SJack,
> MARKER , used in anticipation of deletion, was not my concern. MARKER
> deleting all after allotted memory is a tautology. The case in point
> was how could FORGET reclaim allotted memory when no deletion was
> anticipated and no preparation for deletion, such a dummy word, were
> made. Found that FORGET can reclaim memory for word constructed
> compound with data and code spaces.
Use case here:
If an exception occurs while loading a library (Forth source) or an overlay
(binary) all ponters and allotted/allocated memories are automaticall freed
in the exception handler to avoid garbage accumulation.

On 2021-10-05, minf...@arcor.de <minforth@arcor.de> wrote:
> S Jack schrieb am Montag, 4. Oktober 2021 um 23:49:21 UTC+2:
>> On Monday, October 4, 2021 at 4:59:06 AM UTC-5, Ulrich Hoffmann wrote:
>> > Hi SJack,
>> MARKER , used in anticipation of deletion, was not my concern. MARKER
>> deleting all after allotted memory is a tautology. The case in point
>> was how could FORGET reclaim allotted memory when no deletion was
>> anticipated and no preparation for deletion, such a dummy word, were
>> made. Found that FORGET can reclaim memory for word constructed
>> compound with data and code spaces.
>
> Use case here:
> If an exception occurs while loading a library (Forth source) or an overlay
> (binary) all ponters and allotted/allocated memories are automaticall freed
> in the exception handler to avoid garbage accumulation.
So that library is practically useless... Exceptions are most evil ever
invented:P

--

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

On Monday, October 4, 2021 at 10:22:08 PM UTC-5, dxforth wrote:
> Have you lived with it?
Of course not but it got my interest. I like the idea of having all the
data close at hand with the word that using it. As in this case it
allows FORGET to deal with it.

> It may be a passing fancy such as quotations.
Most likely. I'm not rewriting any existing code but am exploring with it. I often
use constants for numbers. Could put a number or two not being shared in a
data area where they could be nameless.
--
me

On Tuesday, October 5, 2021 at 1:47:13 AM UTC-5, Anton Ertl wrote:
> S Jack <sdwj...@gmail.com> writes:
> Do you mean an ALLOCATEd block of memory? The disadvantage of
No for said reason.

> Or do you mean an ALLOTed block of dictionary memory? That's the
Yes.
The feeling was the use of sections may be convenient for some given scheme
but a mandated use of sections seems too much.

> I am unaware of such hardware concerns.
Sections give memory blocks access attributes which may apply because of type
of memory used in some address range.

--
me