Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #45598

Re: 8th version of "create... does>"

Show all headers | View raw

Ron Aaron <rambamist@gmail.com> writes:
>On 16/02/2016 18:34, Anton Ertl wrote:
>> ... And we have an implementation where we have a special "current-word"
>> structure that can be changed up to the next definition and is then
>> frozen in order to share data between similar words (and then we have
>> thought about unfreezing words, changing them, and refreezing them);
>> so the fixup approach also causes problems for RAM-based systems;
>> maybe we could solve these problems by doing the setup first, and then
>> creating the word with a header that does not need further fixups;
>
>Well, "fixing up is hard to do", to badly misquote a song.  Moving bits
>of code around is apt to run into issues when some other code calls into
>the being-moved-around bits.  So, so far in 8th we don't reclaim any
>"forget"-ed words, nor any newly-unused anonymous words.  The amount of
>effort to do it without creating problems just doesn't seem like a good
>use of my time at present.  Or perhaps you were talking about something
>completely different?

Yes.  Gforth supports nested definitions (locals, quotations, and
generalizations thereof).  Gforth also supports changing the last
definition, e.g., with IMMEDIATE or DOES>, or SET-OPTIMIZER.

One could implement this stuff with a number of fields per word, but
currently the implementation factors some of the fields out and tries
to share them between words with the same values for the fields (e.g.,
children of the same CREATE..DOES> word) to reduce the memory
consumption (not sure if that optimization is really worth the
problems it causes); the way this is currently done is that we have a
"current header-fields thing", and when there is a new header, if the
current header-fields are the same as a pre-existing one, the current
header points to the pre-existing one, otherwise a new one is
allocated; in either case, changing the word should not happen
afterwards.

This does not work so well in the presence of nested definitions: When
we start nesting, we have to do something with the current
header-fields, and when we end it, we have to restore the current
header-fields.  Also, if we want to change a word later, we need to
create a new copy, do the change there, and maybe then try to reshare
it.

FORGETting/MARKERs also have a potential for problems, if we support

create foo create bar ... forget bar immediate

or somesuch.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

Back to comp.lang.forth | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

8th version of "create... does>" Ron Aaron <rambamist@gmail.com> - 2016-02-16 13:08 +0200
  Re: 8th version of "create... does>" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-16 08:33 -0600
    Re: 8th version of "create... does>" Ron Aaron <rambamist@gmail.com> - 2016-02-16 16:41 +0200
      Re: 8th version of "create... does>" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-02-16 08:44 -0600
      Re: 8th version of "create... does>" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-16 16:34 +0000
        Re: 8th version of "create... does>" Ron Aaron <rambamist@gmail.com> - 2016-02-16 19:31 +0200
          Re: 8th version of "create... does>" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-17 17:10 +0000

csiph-web