Re: Fw: Re: Proposed patch to marker.fs for allowing custom clean up.

Bernd Paysan <[email protected]> Wed, 13 May 2026 11:51:16 +0200
Newsgroups gmane.comp.lang.forth.gforth
Message-ID <[email protected]>
--nextPartY6yTWGOJSDCBwlmURDRQ3A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Bernd Paysan <[email protected]>
To: anton-8NJIiSa5LzB3ZGU3T6kWFyEcasqEdqbRs2V0tQ3P5b8@public.gmane.org
Cc: "gforth-mXXj517/[email protected]" <gforth-mXXj517/[email protected]>, colossus <[email protected]>
Subject: Re: Fw: Re: Proposed patch to marker.fs for allowing custom clean up.
Date: Wed, 13 May 2026 11:51:16 +0200
Message-ID: <[email protected]>
In-Reply-To: <agQr+pBywkJiYkrc-eMTcDWn+JWX/RkxMZTRrOJdqbFPxfnh/@public.gmane.org>
MIME-Version: 1.0

Am Mittwoch, 13. Mai 2026, 09:44:58 Mitteleurop=C3=A4ische Sommerzeit schri=
eb Anton=20
Ertl:
> On Tue, May 12, 2026 at 03:47:52PM +0200, Bernd Paysan wrote:
> > The cognitive burden of adding something to MARKER, and MARKER! is like=
=20
this:
> > :is marker, ( -- )
> > :
> >   defers marker,
> >   my-value @ , ;
> > :
> > :is marker! ( addr1 -- addr2 )
> > :
> >   defers marker!
> >   @+ my-value ! ;
> >=20
> > That's it. Maybe we can make it even easier by providing :chain <defered
> > word> that does the defers as first step, too.
>=20
> In general I think that MARKER is not worth the effort we put into it
> (just finish the session and start it again), so I am not very
> sympathetic to the idea of adding more features to MARKER.
>=20
> The usage above poses the question: does :IS add info to the previous
> marker that resets the redefined word to its previous action?
> Consider the usage
>=20
> marker a
> marker b
> variable my-value \ why  is it called my-VALUE?
> 2 my-value !
>=20
> :is marker, ( -- )
>=20
>   defers marker,
>   my-value @ , ;
>=20
> :is marker! ( addr1 -- addr2 )
>=20
>   defers marker!
>   @+ my-value ! ;
> marker c
> 3 my-value !
> c
> b
> here 10000 erase
> a
>=20
> When C is called, everything works as designed.
>=20
> When B is called, unless :IS has an undoes action that happens first,
> the MARKER! action defined above is called, fetches a value that has
> not been stored, and stores into MY-VALUE which is just vanishing; it
> could be worse: the uninitialized value could be stored into some
> non-dead memory location.

:IS doesn't have that, but I added restoring the relevant vectors to the fi=
rst=20
part of MARKER!.

> When A is called, unless :IS has previously undone the change to
> MARKER!, A will try to execute a MARKER! definition that has probably
> been overwritten.
>=20
> We probably can find a way to get this right, but as mentioned, I
> think we have already spent more time on MARKER than it is worth.

That's likely true.  We don't use marker except in tt.fs, where it's also=20
superfluous.

=2D-=20
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o id: kQusJzA;7*?t=3Duy@X}1GWr!+0qqp_Cn176t4(dQ*
https://net2o.de/

--nextPartY6yTWGOJSDCBwlmURDRQ3A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEERJ1NDqPQRwYnwBjr9y2Uk5MtoGcFAmoESZQbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJEPctlJOTLaBnKZcP/16/RdTdEu811bOAmsic
mURQ7eErBGXoPbch8Xkkvp3syqtsJ9AZocGs2rhwJU7u/br1fx5HMHfFHxXCUqGr
Lt+h8K+u/tBLrol1nqHOsSCBdLoETyCWIRJh4EwhPhNIu62KZR7qPp1cUzsJMBpa
MKgAFZedNn3H2KyZy0EiSs+NGHutctx+xDV1mXwQkoFkmPXdELQFwe4+1OIVRpHj
cyR82RMzAmiYP376mYxE9Bo3dbEl5l0FbxW1kXzTsQRc97+K7X2jLaEANO6Sm+zD
kWW86l6pqGJ45cWMj9IesyRM2XUT/x0lScKo3c70KvEQbTUWGP+tr6iGmI9ZzMX9
QzHmUw+DaMfKQKJEKkVJyQiuvQACncvj/fBKKe9iUHtVgXuEDXEu3pdUB1lsLBgi
7hPYY5hQ7iG7LamsgnqkK9UHz9DmJtJ3jFZWqFdb0V8VL0RqMeA5gI+z1BgcffTd
pUJxiOj7oxVkpUqa0ViuPrT1/Bc7ce4wBgKHlc3ii3bqcFrdrpDg5Lu+lTOU141u
58TiZ+IwTD/oYF3DkULshgDWaCstWcduX7thslmEsNnxh/AQ/A/u1gEq7l0z5HVs
8qe7LVuZWzPLfIaBnaif6V/wtg4ShGXHRdrV6gh31FWGVrUyEJm2W22eVQnS8da2
uuX+anc53lrWWrv/Gl63Yyyf
=Fd+7
-----END PGP SIGNATURE-----

--nextPartY6yTWGOJSDCBwlmURDRQ3A--