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

Groups > comp.lang.forth > #45567 > unrolled thread

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

Back to article view | Back to comp.lang.forth

Contents

  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

#45567 — 8th version of "create... does>"

Until now, there was no create... does> in 8th.  After having people ask
for it, I decided to make an implementation.

http://8th-dev.com/forum/index.php/topic,809.0.html

Note that the syntax is quite different from ANS Forth.  Instead of

  : something
    create  ...
    does> ... ;

you do

  x ' does-word ' create-word c/does something

where "x" is the initial data type (could be overwritten later) and
"does-word" is invoked at run-time while "create-word" is invoked at
creation time (of the run-time word).

A different approach, but very easy to code up.

[toc] | [next] | [standalone]

#45575

Ron Aaron <rambamist@gmail.com> wrote:
> Until now, there was no create... does> in 8th.  After having people ask
> for it, I decided to make an implementation.
> 
> http://8th-dev.com/forum/index.php/topic,809.0.html
> 
> Note that the syntax is quite different from ANS Forth.  Instead of
> 
>  : something
>    create  ...
>    does> ... ;
> 
> you do
> 
>  x ' does-word ' create-word c/does something
> 
> where "x" is the initial data type (could be overwritten later) and
> "does-word" is invoked at run-time while "create-word" is invoked at
> creation time (of the run-time word).
> 
> A different approach, but very easy to code up.

That's not wildly different from polyFORTH II, which had USE:

    CREATE FOO  ... blah ...   <address> USE

USE takes the address of some runtime code and patches it into the
code field of the most recent definition.  I think that syntax is a
little more pleasant than your above.

Andrew.

[toc] | [prev] | [next] | [standalone]

#45576

On 16/02/2016 16:33, Andrew Haley wrote:

> That's not wildly different from polyFORTH II, which had USE:
> 
>     CREATE FOO  ... blah ...   <address> USE
> 
> USE takes the address of some runtime code and patches it into the
> code field of the most recent definition.  I think that syntax is a
> little more pleasant than your above.

Yes, the syntax is a bit nicer. On the other hand, I strongly want to
avoid "fixing up" code as much as possible.  Such things can be too
easily used to subvert code, which is counter to 8th's design goals.
(almost wrote "gaols", which some might think more appropriate)

[toc] | [prev] | [next] | [standalone]

#45577

Ron Aaron <rambamist@gmail.com> wrote:
> 
> Yes, the syntax is a bit nicer. On the other hand, I strongly want
> to avoid "fixing up" code as much as possible.  Such things can be
> too easily used to subvert code, which is counter to 8th's design
> goals.  (almost wrote "gaols", which some might think more
> appropriate)

Fair enough.  Forth always was about convenience and pragmatism over
purity and (ahem) "security".

Andrew.

[toc] | [prev] | [next] | [standalone]

#45582

Ron Aaron <rambamist@gmail.com> writes:
>
>
>On 16/02/2016 16:33, Andrew Haley wrote:
>
>> That's not wildly different from polyFORTH II, which had USE:
>> 
>>     CREATE FOO  ... blah ...   <address> USE
>> 
>> USE takes the address of some runtime code and patches it into the
>> code field of the most recent definition.  I think that syntax is a
>> little more pleasant than your above.

The Gforth development version has SET-DOES>, which is similar to the
USE above.  E.g.:

: constant ( n "name" -- ) 
  create , ['] @ set-does> ;

>Yes, the syntax is a bit nicer. On the other hand, I strongly want to
>avoid "fixing up" code as much as possible.  Such things can be too
>easily used to subvert code, which is counter to 8th's design goals.

Moreover, the fixing up is hard to implement in Forth systems that
directly compile to flash.  In
<http://www.complang.tuwien.ac.at/anton/euroforth/ef15/papers/ertl.pdf>
I suggest a word DOES-CREATE that does both at once.  The example
above would become

: const ( n "name" -- )
  ['] @ does-create , ;

Thinking about it again, I am wondering, though.  We also have
SET-OPTIMIZER (which changes what COMPILE, does), and this is also
used as a fixup; e.g.:

: constant ( n "name" -- )
  \ you must not change the body of "name"
  create ,
  ['] @ set-does>
  [: >body @ postpone literal ;] set-optimizer ;

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;
maybe something like:

: constant ( n "name" -- )
  \ you must not change the body of "name"
  ['] @ next-does>
  [: >body @ postpone literal ;] next-optimizer
  create , ;

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

[toc] | [prev] | [next] | [standalone]

#45583

On 16/02/2016 18:34, Anton Ertl wrote:

> The Gforth development version has SET-DOES>, which is similar to the
> USE above.  E.g.:
> 
> : constant ( n "name" -- ) 
>   create , ['] @ set-does> ;

OK.

> Moreover, the fixing up is hard to implement in Forth systems that
> directly compile to flash.

That's actually very interesting, I hadn't considered that.  Though as a
matter of fact in 8th we do need to use "mprotect()" or its equivalent
system calls in order to work properly on mobile devices.  So I guess
we're already compiling directly to flash memory in any event.

> In <http://www.complang.tuwien.ac.at/anton/euroforth/ef15/papers/ertl.pdf>
> I suggest a word DOES-CREATE that does both at once.  The example
> above would become
> 
> : const ( n "name" -- )
>   ['] @ does-create , ;

I'll try to take a look at that, thanks for the information.

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

[toc] | [prev] | [next] | [standalone]

#45598

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/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web