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