On Tuesday, October 5, 2021 at 2:53:41 AM UTC-5, minf...@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:
> 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.

I use markers all the time (in the form of ANEW). MARKERS present no problems.
It's use in the compliant example misses the point. It was FORGET that needed
to be dealt with.

l often use FORGET in development to rework a word as oppose to just redefining it.
Feel better having the memory cleared with nothing hidden left over that may come
into play.
--
me

On 5/10/2021 20:42, Branimir Maksimovic wrote:
> 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

Exceptions aren't the problem - rather the belief one should be able to
beat them and the extraordinary lengths taken to that end. Meanwhile
the application suffers as a result of these interventions which nobody
knows for sure will even work.

On 2021-10-06, dxforth <dxforth@gmail.com> wrote:
> On 5/10/2021 20:42, Branimir Maksimovic wrote:
>> 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
>
> Exceptions aren't the problem - rather the belief one should be able to
> beat them and the extraordinary lengths taken to that end. Meanwhile
> the application suffers as a result of these interventions which nobody
> knows for sure will even work.
Well, in 1999 I gave up on C++ exceptions, too much unreliable...
discriminated unions are future :P

--

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

dxforth <dxforth@gmail.com> writes:
> Exceptions aren't the problem - rather the belief one should be able
> to beat them and the extraordinary lengths taken to that end.

What does it mean to beat an exception?

Regarding discriminated unions (Branimir Maksimovic), see this:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0709r0.pdf

On 6/10/2021 18:49, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> Exceptions aren't the problem - rather the belief one should be able
>> to beat them and the extraordinary lengths taken to that end.
>
> What does it mean to beat an exception?

Take FORGET|MARKER|EMPTY. Today it represents a level of exception
handling one would balk at duplicating were it an application. In
Forth we've decided no amount of expense is too much.

dxforth <dxforth@gmail.com> writes:
>> What does it mean to beat an exception?
> Take FORGET|MARKER|EMPTY. Today it represents a level of exception
> handling one would balk at duplicating were it an application. In
> Forth we've decided no amount of expense is too much.

I still don't see what you're getting at. I hadn't thought of FORGET
and MARKER as being related to exceptions. They just reset HERE, I
thought. I don't know what EMPTY does and can't find it in the Forth
docs I've looked at, but it sounds similar. Exceptions involve
remembering handlers on the control stack and (when an exception is
thrown) unwinding back to where the handler is found.

On 7/10/2021 04:52, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>>> What does it mean to beat an exception?
>> Take FORGET|MARKER|EMPTY. Today it represents a level of exception
>> handling one would balk at duplicating were it an application. In
>> Forth we've decided no amount of expense is too much.
>
> I still don't see what you're getting at. I hadn't thought of FORGET
> and MARKER as being related to exceptions. They just reset HERE, I
> thought. I don't know what EMPTY does and can't find it in the Forth
> docs I've looked at, but it sounds similar. Exceptions involve
> remembering handlers on the control stack and (when an exception is
> thrown) unwinding back to where the handler is found.
>

A compile error is an exception. The 'handler' that resets HERE in a
modern forth is a non-trivial process involving unwinding the dictionary
word by word and restoring anything that may otherwise affect the system
e.g. altered DEFERed words. EMPTY does the same removing all user
additions to the dictionary.

Point being while this is all very clever it's hard to justify when one
can simply reboot the compiler - as one does for other languages.
Similar argument can be made for applications. At what point is recovery
not worth the effort.

dxforth <dxforth@gmail.com> writes:
> A compile error is an exception. The 'handler' that resets HERE in a
> modern forth is a non-trivial process involving unwinding the dictionary
> word by word and restoring anything that may otherwise affect the system
> e.g. altered DEFERed words.

Yucch, is that implemented through exception handlers and compile
errors? I had no idea. I thought FORGET or a MARKER xt simply reset
HERE, and if that broke stuff like DEFERred words, then too bad.
Similarly, there could have been VARIABLEs containing pointers or xt's
into the now-clobbered dictionary, etc. If it's as messy as you
describe instead, it doesn't seem worth it.

> Point being while this is all very clever it's hard to justify when
> one can simply reboot the compiler - as one does for other languages.

Of course you lose any state you've built up in the session before
rebooting the compiler. I think nowadays, that's not too big a problem,
since you can edit on a system with isolated processes so your editing
window stays around while you restart Forth. I've sometimes wondered
how people did it in the old days.

Paul Rubin <no.email@nospam.invalid> writes:
>dxforth <dxforth@gmail.com> writes:
>>> What does it mean to beat an exception?
>> Take FORGET|MARKER|EMPTY. Today it represents a level of exception
>> handling one would balk at duplicating were it an application. In
>> Forth we've decided no amount of expense is too much.
>
>I still don't see what you're getting at. I hadn't thought of FORGET
>and MARKER as being related to exceptions.

They are not. That's why they are not in the EXCEPTION wordset and do
not depend on it. Forth systems have had FORGET long before the
exception wordset arrived, and conversely, no word of the exception
wordset performs any functionality that FORGET (or MARKER) perform.
They just have nothing to do with each other.

Sometimes I get the impression that dxforth just replies to anything,
and if he has nothing substantive to write (the usual case), he just
writes something which makes little to no sense, like "Exceptions
aren't the problem - rather the belief one should be able to beat them
and the extraordinary lengths taken to that end." or "In Forth we've
decided no amount of expense is too much."; basically what Eliza does
when it does not find any word in the user's text that it can hook
onto. Your responses show that this strategy still works:-).

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

On 7/10/2021 15:58, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> A compile error is an exception. The 'handler' that resets HERE in a
>> modern forth is a non-trivial process involving unwinding the dictionary
>> word by word and restoring anything that may otherwise affect the system
>> e.g. altered DEFERed words.
>
> Yucch, is that implemented through exception handlers and compile
> errors? I had no idea.

By 'exception handler' you mean automatic response to an exception?
I don't see that's necessary for the words being discussed since
one can put EMPTY as the first word in an application and it executes
when the source is loaded.

> I thought FORGET or a MARKER xt simply reset
> HERE, and if that broke stuff like DEFERred words, then too bad.
> Similarly, there could have been VARIABLEs containing pointers or xt's
> into the now-clobbered dictionary, etc. If it's as messy as you
> describe instead, it doesn't seem worth it.

Standard MARKER guarantees very little. ANS would have been aware a
practical implementation would need mechanisms for restoring DEFERs
etc but elected not to specify them.

>
>> Point being while this is all very clever it's hard to justify when
>> one can simply reboot the compiler - as one does for other languages.
>
> Of course you lose any state you've built up in the session before
> rebooting the compiler. I think nowadays, that's not too big a problem,
> since you can edit on a system with isolated processes so your editing
> window stays around while you restart Forth. I've sometimes wondered
> how people did it in the old days.

FORGET was a convenience from the days when the editor was resident
and remained in standards in one form or another.

On 7/10/2021 18:17, Anton Ertl wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>>dxforth <dxforth@gmail.com> writes:
>>>> What does it mean to beat an exception?
>>> Take FORGET|MARKER|EMPTY. Today it represents a level of exception
>>> handling one would balk at duplicating were it an application. In
>>> Forth we've decided no amount of expense is too much.
>>
>>I still don't see what you're getting at. I hadn't thought of FORGET
>>and MARKER as being related to exceptions.
>
> They are not. That's why they are not in the EXCEPTION wordset and do
> not depend on it. Forth systems have had FORGET long before the
> exception wordset arrived, and conversely, no word of the exception
> wordset performs any functionality that FORGET (or MARKER) perform.
> They just have nothing to do with each other.
>
> Sometimes I get the impression that dxforth just replies to anything,
> and if he has nothing substantive to write (the usual case), he just
> writes something which makes little to no sense, like "Exceptions
> aren't the problem - rather the belief one should be able to beat them
> and the extraordinary lengths taken to that end." or "In Forth we've
> decided no amount of expense is too much."; basically what Eliza does
> when it does not find any word in the user's text that it can hook
> onto. Your responses show that this strategy still works:-).

A strange statement considering your CMOVE fast block propagate all but
fits the description - a long-winded solution to a problem nobody had.
Never mind it would be easier to implement and use outside CMOVE were
someone to request such a thing.