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

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

description of Forth-2012's `synonym`

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

Contents

  description of Forth-2012's `synonym` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-11-23 20:47 +0000
    Re: description of Forth-2012's `synonym` Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-23 22:55 +0100
      Re: description of Forth-2012's `synonym` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-11-23 22:20 +0000
        Re: description of Forth-2012's `synonym` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-24 05:12 +0000
      Re: description of Forth-2012's `synonym` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-11-24 17:29 +0000
        Re: description of Forth-2012's `synonym` Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-25 02:46 +0100
          Re: description of Forth-2012's `synonym` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-24 22:46 -0800
            Re: description of Forth-2012's `synonym` Mark Wills <markwills1970@gmail.com> - 2015-11-25 01:39 -0800
              Re: description of Forth-2012's `synonym` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 02:37 -0800
            Re: description of Forth-2012's `synonym` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-25 13:13 +0000
              Re: description of Forth-2012's `synonym` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 09:06 -0800
                Re: description of Forth-2012's `synonym` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-25 18:33 +0000
                  Re: description of Forth-2012's `synonym` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 23:01 -0800
                    Re: description of Forth-2012's `synonym` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 07:15 +0000
                      Re: description of Forth-2012's `synonym` Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-26 02:30 -0800
                        Re: description of Forth-2012's `synonym` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 13:44 +0000
              Re: description of Forth-2012's `synonym` Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-25 17:27 +0000
                Re: description of Forth-2012's `synonym` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 07:56 +0000
                  Re: description of Forth-2012's `synonym` Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-26 11:25 +0000
                  Re: description of Forth-2012's `synonym` Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 01:36 +0100
                    Re: description of Forth-2012's `synonym` Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-27 16:57 +0000
                      Re: description of Forth-2012's `synonym` Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-27 19:18 +0000
                        Re: description of Forth-2012's `synonym` Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-27 19:22 +0000
                          Re: description of Forth-2012's `synonym` Mark Wills <markwills1970@gmail.com> - 2015-11-27 11:48 -0800
                    Re: description of Forth-2012's `synonym` anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-28 11:07 +0000
                      Re: description of Forth-2012's `synonym` Matthias Trute <matthias.trute@gmail.com> - 2015-11-28 12:34 -0800
        Re: description of Forth-2012's `synonym` hughaguilar96@gmail.com - 2015-11-26 18:43 -0800
          Re: description of Forth-2012's `synonym` Marcos Cruz <use_the_contact_page@programandala.net> - 2015-12-05 03:35 +0000
      Re: description of Forth-2012's `synonym` hughaguilar96@gmail.com - 2015-11-26 14:39 -0800

Page 1 of 2  [1] 2  Next page →

#43682 — description of Forth-2012's `synonym`

I have a doubt about the description of `synonym`:

____

  when looking  up oldname, newname shall not be found.
____

Well, it will depend on the search order, unless `synonym` creates
_newname_ in the wordlist of _oldname_ (or hide _oldname_).  Is that
what `synonym` must do?  But the provided example implementation (even,
as the document says, imperfect and specific for VFX) doesn't change the
compilation word list or modifies _oldname_.

Or maybe the description implicitly means "when looking up oldname,
newname shall not be found, with the current search order"?

Anyway, I already adapted and improved the code for my system:

----
: synonym  ( "newname" "oldname" -- )
  create immediate
    hide ' , reveal
  does>  ( -- )
   ( pfa ) @ ( cfa ) dup >name dup ( cfa nfa nfa )
   compile-only? executing? and -14 ?throw
   immediate? executing? or
   if  execute  else  compile,  then  ;
----

May someone confirm this point? Thank you.

-- 
Marcos Cruz
http://programandala.net

[toc] | [next] | [standalone]

#43686

Marcos Cruz wrote:

> I have a doubt about the description of `synonym`:
> 
> ____
> 
>   when looking  up oldname, newname shall not be found.
> ____
> 
> Well, it will depend on the search order, unless `synonym` creates
> _newname_ in the wordlist of _oldname_ (or hide _oldname_).  Is that
> what `synonym` must do?  But the provided example implementation (even,
> as the document says, imperfect and specific for VFX) doesn't change the
> compilation word list or modifies _oldname_.
> 
> Or maybe the description implicitly means "when looking up oldname,
> newname shall not be found, with the current search order"?
> 
> Anyway, I already adapted and improved the code for my system:
> 
> ----
> : synonym  ( "newname" "oldname" -- )
>   create immediate
>     hide ' , reveal
>   does>  ( -- )
>    ( pfa ) @ ( cfa ) dup >name dup ( cfa nfa nfa )
>    compile-only? executing? and -14 ?throw
>    immediate? executing? or
>    if  execute  else  compile,  then  ;
> ----
> 
> May someone confirm this point? Thank you.

Yes, that's the point, the sequence

hide ' , reveal

pretty much is what's required.

The more problematic part is that you are using create does> for it.  Just 
think what will happen with ' <newname> execute.  This word just can't be 
implemented using standard means, which is why we added it.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43687

En/Je/On 2015-11-23, Bernd Paysan <bernd.paysan@gmx.de>
escribió/skribis/wrote:

> Marcos Cruz wrote:

>> ____
>> 
>>   when looking  up oldname, newname shall not be found.
>> ____
>
> Yes, that's the point, the sequence
>
> hide ' , reveal
>
> pretty much is what's required.

I see I was misunderstanding the description: "when looking up oldname"
obviously refers the search for "oldname" done by `synonym` when both
names are equal, not the way `newname` will work.

-- 
Marcos Cruz
http://programandala.net

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

#43695

Marcos Cruz <use_the_contact_page@programandala.net> writes:
>I see I was misunderstanding the description: "when looking up oldname"
>obviously refers the search for "oldname" done by `synonym` when both
>names are equal, not the way `newname` will work.

Yes.  The use case for this is when you want a synonym for the old
name in a new wordlist with the same name; then you don't need to
remove the word list from the search order in order for this to work.

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

#43709

En/Je/On 2015-11-23, Bernd Paysan <bernd.paysan@gmx.de>
escribió/skribis/wrote:

>> ----
>> : synonym  ( "newname" "oldname" -- )
>>   create immediate
>>     hide ' , reveal
>>   does>  ( -- )
>>    ( pfa ) @ ( cfa ) dup >name dup ( cfa nfa nfa )
>>    compile-only? executing? and -14 ?throw
>>    immediate? executing? or
>>    if  execute  else  compile,  then  ;
>> ----

> The more problematic part is that you are using create does> for it.  Just 
> think what will happen with ' <newname> execute.

What do you mean? I've tried synonyms of `if`, `postpone`, `literal`,
non-immediate words..., and everything seems to work fine: the synonym
has the semantics of the original.

Example:

----
  synonym later postpone

  : non-imm ;
  here
  ' later execute non-imm
  dup    @ >name id.  \ "COMPILE"
  cell+  @ >name id.  \ "NON-IMM"

  : imm ; immediate
  here
  ' later execute imm
         @ >name id.  \ "IMM"

----
  
Am I missing something?

-- 
Marcos Cruz
http://programandala.net

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

#43716

Marcos Cruz wrote:

> En/Je/On 2015-11-23, Bernd Paysan <bernd.paysan@gmx.de>
> escribió/skribis/wrote:
> 
>>> ----
>>> : synonym  ( "newname" "oldname" -- )
>>>   create immediate
>>>     hide ' , reveal
>>>   does>  ( -- )
>>>    ( pfa ) @ ( cfa ) dup >name dup ( cfa nfa nfa )
>>>    compile-only? executing? and -14 ?throw
>>>    immediate? executing? or
>>>    if  execute  else  compile,  then  ;
>>> ----
> 
>> The more problematic part is that you are using create does> for it. 
>> Just think what will happen with ' <newname> execute.
> 
> What do you mean? I've tried synonyms of `if`, `postpone`, `literal`,
> non-immediate words..., and everything seems to work fine: the synonym
> has the semantics of the original.
> 
> Example:
> 
> ----
>   synonym later postpone
> 
>   : non-imm ;
>   here
>   ' later execute non-imm
>   dup    @ >name id.  \ "COMPILE"
>   cell+  @ >name id.  \ "NON-IMM"
> 
>   : imm ; immediate
>   here
>   ' later execute imm
>          @ >name id.  \ "IMM"
> 
> ----
>   
> Am I missing something?

All the corner cases Anton mentions in his "why state smart is evil" paper.

http://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43725

> 
> All the corner cases Anton mentions in his "why state smart is evil" paper.
> 
> http://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf
> 

If you have a clean system where every word has an xt and it is either immediate 
or non-immediate, there is  no "evil".

My system has the same "problem" with your (Anton's) paper: it just works. 
And I use state smart words everywhere.

You and Anton just don't want to admit that. That people happen to have
simple and clean systems that don't have problems with your corner cases...

Is it my problem (or Chris's) that there are obfuscated systems that special
cased a lot of words (like IF) and then they have "problems"? I always
wondered how is it possible that IF to not be immediate? Yes it is possible,
but then it should be just a special cased piece of code in the kernel that
does what IF has to do... IF is not immediate but it is not non-immediate
also... It is not a regular forth word anymore! And for the sake of the
standard it is presented like to be a word ...
In those systems yes, there may be "evil" in many parts of the system.
But there are still a lot of systems with no problem at all.

Don't generalize.

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

#43746

On Wednesday, 25 November 2015 06:46:22 UTC, Raimond Dragomir  wrote:
> > 
> > All the corner cases Anton mentions in his "why state smart is evil" paper.
> > 
> > http://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf
> > 
> 
> If you have a clean system where every word has an xt and it is either immediate 
> or non-immediate, there is  no "evil".
> 
> My system has the same "problem" with your (Anton's) paper: it just works. 
> And I use state smart words everywhere.
> 
> You and Anton just don't want to admit that. That people happen to have
> simple and clean systems that don't have problems with your corner cases...
> 
> Is it my problem (or Chris's) that there are obfuscated systems that special
> cased a lot of words (like IF) and then they have "problems"? I always
> wondered how is it possible that IF to not be immediate? Yes it is possible,
> but then it should be just a special cased piece of code in the kernel that
> does what IF has to do... IF is not immediate but it is not non-immediate
> also... It is not a regular forth word anymore! And for the sake of the
> standard it is presented like to be a word ...
> In those systems yes, there may be "evil" in many parts of the system.
> But there are still a lot of systems with no problem at all.
> 
> Don't generalize.

I'm inclined to agree. I think the "problem" with state-smart words,
whilst it is a problem, is somewhat over-blown.

For example, S" is a (generally) state-smart word, so, yes, you can
run into problems if you compile it in the sense that when executed
it might not do what you want. However, if S" is correctly factored,
you can get at the guts of word and compile them individually.

S" should be nothing more than a macro. A convenience:

: S"   state @ if do_this else do_that then ; immediate

That's *all* S" is. A mere convenience for the user. It's a macro.

When you're dealing explicitly with the compilation of strings, you
just need to man up and know what you're doing. In the example
above you either want do_this or do_that. It's that simple. Of course,
it relies on an appropriate level of documentation from the system
author to point this out. The manual should state that S" is state 
smart, and should explain the issues, and which words to compile in
order to get the actual required behaviour.

I think it helps a lot if we adopt the nomenclature of "macro" for
state-smart words. Then we simply adopt the idiom "don't compile
macros, for there be dragons".

We could even adopt a new word called macro:

: S"   state @ if do_this else do_that then ; macro

Such that the system could warn us if we try to compile one.

Simple.

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

#43749

miercuri, 25 noiembrie 2015, 11:39:14 UTC+2, Mark Wills a scris:
> On Wednesday, 25 November 2015 06:46:22 UTC, Raimond Dragomir  wrote:
> > > 
> > > All the corner cases Anton mentions in his "why state smart is evil" paper.
> > > 
> > > http://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf
> > > 
> > 
> > If you have a clean system where every word has an xt and it is either immediate 
> > or non-immediate, there is  no "evil".
> > 
> > My system has the same "problem" with your (Anton's) paper: it just works. 
> > And I use state smart words everywhere.
> > 
> > You and Anton just don't want to admit that. That people happen to have
> > simple and clean systems that don't have problems with your corner cases...
> > 
> > Is it my problem (or Chris's) that there are obfuscated systems that special
> > cased a lot of words (like IF) and then they have "problems"? I always
> > wondered how is it possible that IF to not be immediate? Yes it is possible,
> > but then it should be just a special cased piece of code in the kernel that
> > does what IF has to do... IF is not immediate but it is not non-immediate
> > also... It is not a regular forth word anymore! And for the sake of the
> > standard it is presented like to be a word ...
> > In those systems yes, there may be "evil" in many parts of the system.
> > But there are still a lot of systems with no problem at all.
> > 
> > Don't generalize.
> 
> I'm inclined to agree. I think the "problem" with state-smart words,
> whilst it is a problem, is somewhat over-blown.
> 
> For example, S" is a (generally) state-smart word, so, yes, you can
> run into problems if you compile it in the sense that when executed
> it might not do what you want. However, if S" is correctly factored,
> you can get at the guts of word and compile them individually.
> 
> S" should be nothing more than a macro. A convenience:
> 
> : S"   state @ if do_this else do_that then ; immediate
> 
> That's *all* S" is. A mere convenience for the user. It's a macro.
> 
> When you're dealing explicitly with the compilation of strings, you
> just need to man up and know what you're doing. In the example
> above you either want do_this or do_that. It's that simple. Of course,
> it relies on an appropriate level of documentation from the system
> author to point this out. The manual should state that S" is state 
> smart, and should explain the issues, and which words to compile in
> order to get the actual required behaviour.
> 
> I think it helps a lot if we adopt the nomenclature of "macro" for
> state-smart words. Then we simply adopt the idiom "don't compile
> macros, for there be dragons".
> 
> We could even adopt a new word called macro:
> 
> : S"   state @ if do_this else do_that then ; macro
> 
> Such that the system could warn us if we try to compile one.
> 
> Simple.

You are right, the system has to be documented properly if a user
will ever wants to compile such words and to define state smart
words that work both in compilation and interpretation mode.

I have a very usefull word:

: 'eval \ xt --
  state @ if compile, else execute then ;

that I use all the time. For example:

\ "ccc<quote>" -- , display string
i: ."
  compile s"
  ' type 'eval ;

\ "ccc<quote>" -- , display string, throws an 100
i: abort"
  compile ."
  100 ' throw 'eval ; \ 100 doesn't have a printed message on its own

These definitions look simple but in fact you have to know very well
what you are doing. This kind of programming is not for everyone.

Sometimes I have a feeling that the ANS standard's goal of making
the compiler/compilation standardized and easy "for everyone" is too bold.
It is a forth's problem because the compiler is exposed to the user
but standardizing the compilation seems harder and harder as the systems
evoluated and are too diverse.

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

#43755

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> 
>> All the corner cases Anton mentions in his "why state smart is evil" paper.
>> 
>> http://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf
>> 
>
>If you have a clean system where every word has an xt and it is either immediate 
>or non-immediate, there is  no "evil".
>
>My system has the same "problem" with your (Anton's) paper: it just works. 
>And I use state smart words everywhere.
>
>You and Anton just don't want to admit that. That people happen to have
>simple and clean systems that don't have problems with your corner cases...

Let's look at a relatively clean system that has state-smart words not
everywhere, but has implemented S" in a state-smart way; here are some
corner cases where this S" does not work as specified in the standard:

\ for you with [COMPILE] :-)
: ]execute[ ] execute [compile] [ ;
' s" ]execute[ bla" cr type \ should output "bla"
: [s]" [compile] s" ;
: foo [ [s]" bla" ] type ; cr .s \ stack should be empty
0 cr foo drop \ should print "bla"

Here's what happens on this system with the state-smart S":

SwiftForth i386-Linux 3.4.4 31-Jul-2012 
\ for you with [COMPILE] :-)  ok
: ]execute[ ] execute [compile] [ ;  ok
' s" ]execute[ bla" cr type \ should output "bla" 
Stack underflow
: [s]" [compile] s" ;  ok
: foo [ [s]" bla" ] type ; cr .s \ stack should be empty 

134589581 3 <-Top  ok
0 cr foo drop \ should print "bla" 

Some people say that these are only corner cases, and that in practice
these corner cases don't occur, but your claim that such
implementations have no problems even when confronted with corner
cases is new (and wrong).

>I always
>wondered how is it possible that IF to not be immediate?

In the sense of the section 2.1 of the standard, IF is not specified
as immediate word, because no execution semantics is specified for IF,
and the compilation semantics of IF are specified directly without
reference to execution semantics.

In the sense of what FIND returns for IF, a standard system has to
return 1 (immediate) for IF, or one cannot implement a user-defined
text interpreter with this system.  VFX returns -1 (non-immediate),
but allows to implement a user-defined text interpreter by providing a
non-standard COMPILE, (VFX's COMPILE, does not have the stack effect
( xt -- ) for all xts).

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

#43762

> Let's look at a relatively clean system that has state-smart words not
> everywhere, but has implemented S" in a state-smart way; here are some
> corner cases where this S" does not work as specified in the standard:
> 
> \ for you with [COMPILE] :-)
> : ]execute[ ] execute [compile] [ ;
> ' s" ]execute[ bla" cr type \ should output "bla"
> : [s]" [compile] s" ;
> : foo [ [s]" bla" ] type ; cr .s \ stack should be empty
> 0 cr foo drop \ should print "bla"
> 

Sorry but my system is so clean that it doesn't have [ ] :)
I didn't implement [ ] because they make a system completely open
and unpredictable. If you have such a system you will never be sure
what happens and when.
The other reason that I didn't implement [ ] is because my system
is based on nested quotations and the compilation level is tightly
controlled. Opening it with [ ] is just crazy.

I only need something like [ ] twice, in a cross-compiler application.
I resolved the issue cleanly with two immediate words which did the job.

My personal opinion about [ ] is more than that above. I consider [ ]
an artifact of the past when optimizing compilers were just unaffordable
to the systems at the time, and the [ ] LITERAL sequence was used 
as a primitive way of literal optimization. They should have been obsoleted
and eradicated long time ago.

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

#43771

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> Let's look at a relatively clean system that has state-smart words not
>> everywhere, but has implemented S" in a state-smart way; here are some
>> corner cases where this S" does not work as specified in the standard:
>> 
>> \ for you with [COMPILE] :-)
>> : ]execute[ ] execute [compile] [ ;
>> ' s" ]execute[ bla" cr type \ should output "bla"
>> : [s]" [compile] s" ;
>> : foo [ [s]" bla" ] type ; cr .s \ stack should be empty
>> 0 cr foo drop \ should print "bla"
>> 
>
>Sorry but my system is so clean that it doesn't have [ ] :)

That's insufficient to get rid of the corner cases:

' s" constant s"-xt
: foo" s"-xt execute type ; immediate
cr : bar foo" bla" ; \ should print "bla"

Here's what the STATE-smart S" in SwiftForth produces:

' s" constant s"-xt  ok
: foo" s"-xt execute type ; immediate  ok
cr : bar foo" bla" ; \ should print "bla" 
Stack underflow

>The other reason that I didn't implement [ ] is because my system
>is based on nested quotations and the compilation level is tightly
>controlled. Opening it with [ ] is just crazy.

We have nested quotations in Gforth, and [ ] do not pose a particular
problem.

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

#43802

miercuri, 25 noiembrie 2015, 20:40:09 UTC+2, Anton Ertl a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >> Let's look at a relatively clean system that has state-smart words not
> >> everywhere, but has implemented S" in a state-smart way; here are some
> >> corner cases where this S" does not work as specified in the standard:
> >> 
> >> \ for you with [COMPILE] :-)
> >> : ]execute[ ] execute [compile] [ ;
> >> ' s" ]execute[ bla" cr type \ should output "bla"
> >> : [s]" [compile] s" ;
> >> : foo [ [s]" bla" ] type ; cr .s \ stack should be empty
> >> 0 cr foo drop \ should print "bla"
> >> 
> >
> >Sorry but my system is so clean that it doesn't have [ ] :)
> 
> That's insufficient to get rid of the corner cases:
> 
> ' s" constant s"-xt
> : foo" s"-xt execute type ; immediate
> cr : bar foo" bla" ; \ should print "bla"
> 
> Here's what the STATE-smart S" in SwiftForth produces:
> 
> ' s" constant s"-xt  ok
> : foo" s"-xt execute type ; immediate  ok
> cr : bar foo" bla" ; \ should print "bla" 
> Stack underflow
> 
I have the same message.
The problem is that you want to use S" for something it is not designed for.
You can't use S" just like that and expect what you expect. 
S" in a definition compiles the string into the body. 
It is designed to do that. Trying to use it in another way is not a corner 
case. It is just a mistake.

If you want to print something at compile time (like the .( "comment and print" ) you need some other word.

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

#43805

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> ' s" constant s"-xt
>> : foo" s"-xt execute type ; immediate
>> cr : bar foo" bla" ; \ should print "bla"
...
>The problem is that you want to use S" for something it is not designed for.
>You can't use S" just like that and expect what you expect. 

Sure I can, and I can even get what I expect, with the appropriate
implementation:

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
' s" constant s"-xt  ok
: foo" s"-xt execute type ; immediate  ok
cr : bar foo" bla" ; \ should print "bla" 
bla ok

>S" in a definition compiles the string into the body. 
>It is designed to do that. Trying to use it in another way is not a corner 
>case. It is just a mistake.

Not according to the standard.  We actually considered removing the
allowance for ticking, POSTPONEing and [COMPILE]ing S" from Forth-2012
in order to make STATE-smart implementations standard, but obviously
forgot to actually do it.

Anyway, my point is that contrary to what you claim, a STATE-smart
implementation of S" is anything but clean.  And after having
discussed this for 19 years, I now think that the best solution is to
get rid of words like S".

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

#43825

joi, 26 noiembrie 2015, 09:22:39 UTC+2, Anton Ertl a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >> ' s" constant s"-xt
> >> : foo" s"-xt execute type ; immediate
> >> cr : bar foo" bla" ; \ should print "bla"
> ...
> >The problem is that you want to use S" for something it is not designed for.
> >You can't use S" just like that and expect what you expect. 
> 
> Sure I can, and I can even get what I expect, with the appropriate
> implementation:
> 
> Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
> Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
> Type `bye' to exit
> ' s" constant s"-xt  ok
> : foo" s"-xt execute type ; immediate  ok
> cr : bar foo" bla" ; \ should print "bla" 
> bla ok
> 
> >S" in a definition compiles the string into the body. 
> >It is designed to do that. Trying to use it in another way is not a corner 
> >case. It is just a mistake.
> 
> Not according to the standard.  We actually considered removing the
> allowance for ticking, POSTPONEing and [COMPILE]ing S" from Forth-2012
> in order to make STATE-smart implementations standard, but obviously
> forgot to actually do it.
> 
> Anyway, my point is that contrary to what you claim, a STATE-smart
> implementation of S" is anything but clean.  And after having
> discussed this for 19 years, I now think that the best solution is to
> get rid of words like S".
> 
> - 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/

And what is your solution? According to the standard, there is no way
to have a string at interpret time, isn't it? S" and C" can be used only
in compilation mode. That's simpler of course. What is your solution for
interpretation mode?

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

#43828

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>joi, 26 noiembrie 2015, 09:22:39 UTC+2, Anton Ertl a scris:
>> Anyway, my point is that contrary to what you claim, a STATE-smart
>> implementation of S" is anything but clean.  And after having
>> discussed this for 19 years, I now think that the best solution is to
>> get rid of words like S".
...
>And what is your solution?

Recognizers.  For numbers, we have a number recognizer (or one for
integers and one for FP values) hard-coded into the text interpreter,
and there is no STATE-smartness problem there.  For strings, add
string recognizers.  In general, allow user-defined recognizers.

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

#43763

On 25/11/2015 13:13, Anton Ertl wrote:
> In the sense of what FIND returns for IF, a standard system has to
> return 1 (immediate) for IF, or one cannot implement a user-defined
> text interpreter with this system.

Does the standard actually state that a standard system has to permit 
the definition of a user-defined text interpreter. I know in practice 
you would want to be able to do that, I'm just asking about the letter 
of the standard.

FIND IF returning 1 seems to contradict the specification for IF that 
does not state that IF is immediate so that a system with an immediate 
IF is non-standard.

Incidentally the specification for FIND permits it to return different 
values when compiling or interpreting. But SEARCH-WORDLIST doesn't. That 
seems inconsistent.

-- 
Gerry

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

#43814

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 25/11/2015 13:13, Anton Ertl wrote:
>> In the sense of what FIND returns for IF, a standard system has to
>> return 1 (immediate) for IF, or one cannot implement a user-defined
>> text interpreter with this system.
>
>Does the standard actually state that a standard system has to permit 
>the definition of a user-defined text interpreter.

Not in the normative part.  The informative part makes it clear that
that was the intention, though (e.g., look in the rationale for
COMPILE,).

Anyway, that's why I phrased the sentence in the way above.  Another
way to phrase it is: "If a system wants to be standard and wants the
classical user-defined text interpreter to work, it has to return 1
(immediate) for IF."

>FIND IF returning 1 seems to contradict the specification for IF that 
>does not state that IF is immediate so that a system with an immediate 
>IF is non-standard.

The standard does not specify immediacy or non-immediacy for most
words, with the idea that this is an implementation decision.

The idea was to allow cmForth, where all primitives (e.g., +) return 1
and the xt of a word that generates the code for an addition in
compile state.

The other direction, returning -1 for traditionally immediate word is
implemented in VFX, but for words like IF where the compilation
semantics have a stack effect other than ( -- ), results in COMPILE,
having a non-standard stack effect.

>Incidentally the specification for FIND permits it to return different 
>values when compiling or interpreting. But SEARCH-WORDLIST doesn't. That 
>seems inconsistent.

Yes.  Apparently FIND was intended to be used in user-defined text
interpreters, but SEARCH-WORDLIST was not.  Gforth implements that
difference, and it rarely led to complaints (one complaint from Bernd
Paysan this year, the previous one from Jonah Thomas in 2007).  For a
longer discussion of the difference, read
<2015Jul4.155835@mips.complang.tuwien.ac.at>.

I think the solution is to have FIND-NAME ( c-addr u -- nt | 0 ) and
something like Gforth's (SEARCH-WORDLIST) ( c-addr u wid -- nt | 0 )
(but with a better name).

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

#43826

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

<SNIP>

>I think the solution is to have FIND-NAME ( c-addr u -- nt | 0 ) and

That one is called FOUND in my book ( sc -- dea).
I hate having NAME in there. Before long dea's will be *the* token,
no need to make a distinction between name-tokens and execution-tokens.

>something like Gforth's (SEARCH-WORDLIST) ( c-addr u wid -- nt | 0 )
>(but with a better name).

I have (FIND)
Because it is always used repetitively the stack effect is choosen to be
(sc wid -- sc dea)

Thinking about it (FOUND) may be better.

This is in concert with words like INCLUDED to set them apart from
words that parse ahead like INCLUDE.

>- anton
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#43853

Anton Ertl wrote:

> I think the solution is to have FIND-NAME ( c-addr u -- nt | 0 ) and
> something like Gforth's (SEARCH-WORDLIST) ( c-addr u wid -- nt | 0 )
> (but with a better name).

I'm suggesting

FIND-NAME-IN ( c-addr u wid -- nt | 0 )

as in "find name in <wordlist>".  (search-wordlist) is too ugly and way too 
useful to stay that ugly ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web