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

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

RfD v7: TRAVERSE-WORDLIST final

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

Contents

  RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-12 21:08 +0100
    Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-12 17:02 -0500
    Re: RfD v7: TRAVERSE-WORDLIST final anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-13 06:40 +0000
      Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-13 15:47 +0100
    Re: RfD v7: TRAVERSE-WORDLIST final stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-13 08:30 +0000
      Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-13 03:49 -0500
        Re: RfD v7: TRAVERSE-WORDLIST final stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-13 12:10 +0000
          Re: RfD v7: TRAVERSE-WORDLIST final graham <"s\" xyzgrahams@tectime.com\" 3 /string"> - 2013-08-14 11:51 +0100
          Re: RfD v7: TRAVERSE-WORDLIST final anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-14 11:11 +0000
            Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-14 07:08 -0500
              Re: RfD v7: TRAVERSE-WORDLIST final anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-14 13:22 +0000
                SYNONYM (was: RfD v7: TRAVERSE-WORDLIST final) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-14 13:34 +0000
                  Re: SYNONYM (was: RfD v7: TRAVERSE-WORDLIST final) stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-15 12:46 +0000
                    Re: SYNONYM (was: RfD v7: TRAVERSE-WORDLIST final) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-15 14:44 +0000
                      Re: SYNONYM (was: RfD v7: TRAVERSE-WORDLIST final) peter.m.falth@gmail.com - 2013-08-15 08:09 -0700
                Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-14 09:40 -0500
                  Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-14 16:39 +0100
                    Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-14 11:32 -0500
                      Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-14 18:26 +0100
                        Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-14 14:50 -0500
                          Re: RfD v7: TRAVERSE-WORDLIST final Elizabeth D Rather <erather@forth.com> - 2013-08-14 10:28 -1000
                            Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-15 12:04 +0100
                              Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-15 07:20 -0500
                          Re: RfD v7: TRAVERSE-WORDLIST final Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-08-15 08:23 +0100
                            Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-15 03:16 -0500
                          Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-15 12:32 +0100
                            Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-15 07:26 -0500
                              Re: RfD v7: TRAVERSE-WORDLIST final anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-15 12:50 +0000
                                Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-15 08:55 -0500
                                  SYNONYM (was: RfD v7: TRAVERSE-WORDLIST final) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-15 14:05 +0000
                                    Re: SYNONYM Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-15 09:16 -0500
                                      Re: SYNONYM "Alex McDonald" <blog@rivadpm.com> - 2013-08-15 16:07 +0100
                                Re: RfD v7: TRAVERSE-WORDLIST final Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-15 23:52 +0200
                                  Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-16 07:22 -0500
                                    Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-16 13:39 +0100
                                      Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-16 08:25 -0500
                                        Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-16 18:54 +0100
                                          Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-16 13:13 -0500
                                    Re: RfD v7: TRAVERSE-WORDLIST final anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-16 13:16 +0000
                                      Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-16 09:01 -0500
                                        Re: RfD v7: TRAVERSE-WORDLIST final anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-16 14:23 +0000
                                          Re: RfD v7: TRAVERSE-WORDLIST final Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-16 22:14 +0200
                                    Re: RfD v7: TRAVERSE-WORDLIST final Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-16 21:46 +0200
                                      Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-17 03:08 -0500
                                  Re: RfD v7: TRAVERSE-WORDLIST final anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-16 13:42 +0000
                                    Re: RfD v7: TRAVERSE-WORDLIST final Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-16 22:12 +0200
                                      Re: RfD v7: TRAVERSE-WORDLIST final anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-17 12:29 +0000
                            Re: RfD v7: TRAVERSE-WORDLIST final Graham Smith <"s\" xyzgrahams@tectime.com\" 3 /string"> - 2013-08-16 17:36 +0100
                              Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-16 12:00 -0500
                                Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-16 18:56 +0100
                                  Re: RfD v7: TRAVERSE-WORDLIST final Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-16 13:07 -0500
                                    Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-16 19:18 +0100
                                      Re: RfD v7: TRAVERSE-WORDLIST final Graham Smith <"s\" not@gray@forthman.plus.com\" 4 /string"> - 2013-08-16 20:22 +0100
            Re: RfD v7: TRAVERSE-WORDLIST final stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-14 14:42 +0000
        Re: RfD v7: TRAVERSE-WORDLIST final stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-14 12:40 +0000
          Re: RfD v7: TRAVERSE-WORDLIST final Alex McDonald <blog@rivadpm.com> - 2013-08-14 06:20 -0700
            Re: RfD v7: TRAVERSE-WORDLIST final Mark Wills <markrobertwills@yahoo.co.uk> - 2013-08-14 06:23 -0700
      Re: RfD v7: TRAVERSE-WORDLIST final "Alex McDonald" <blog@rivadpm.com> - 2013-08-13 15:47 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#25255

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Either will be fine.
>
>Really?  I'm not going to argue about compliance, but I would have
>thought that from a QOI point of view that to not show the SYNOYM
>would be a Bad Thing indeed,
>
>Which would you prefer as a developer?

Probably depends on the situation.  But in any case, if I

see foo

and I get a decompilation of a word called BAR, it's pretty obvious
that an alias/SYNONYM is involved.  For less experienced users, one
can compare the name of the SEE parameter and the name of the found
word, and preprend

synonym foo bar

to the output if they differ.

- 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 2013: http://www.euroforth.org/ef13/

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

#25269

Anton Ertl wrote:

> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> Either will be fine.
>>
>>Really?  I'm not going to argue about compliance, but I would have
>>thought that from a QOI point of view that to not show the SYNOYM
>>would be a Bad Thing indeed,
>>
>>Which would you prefer as a developer?
> 
> Probably depends on the situation.  But in any case, if I
> 
> see foo
> 
> and I get a decompilation of a word called BAR, it's pretty obvious
> that an alias/SYNONYM is involved.  For less experienced users, one
> can compare the name of the SEE parameter and the name of the found
> word, and preprend
> 
> synonym foo bar
> 
> to the output if they differ.

I did add a small check for synonyms/aliases and the current git-head Gforth 
now prints that out, too.  No big deal.  It's useful information.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#25266

Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> 
>> The proposal is frank and says that newname and oldname have identical
>> effects, it is implementable, and if you have questions about how to
>> implement it properly, I can certainly assist.
>> 
>> Essentially, all you have to do is to change your NAME> or whatever you
>> call it to get from the NFA to the XT so that it recognizes synonyms and
>> does a @
>> of the xt (or maybe nt, if an xt is not enough) stored there.  It
>> requires to add one word and change one other word, it is *not* a big
>> deal.
> 
> Hmmmm, maybe, but not so fast.  What should SEEing a SYNOYM do?  I
> think it should see the SYNOYM, not the thing of which it is suppose
> to be a synonym.

As Alex already explained, SEE can first check the name token, and tell you 
that bar is a synonym to foo.  Yes, this means you need a third place to 
change if you want to have a perfect SEE.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#25277

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> 
>>> The proposal is frank and says that newname and oldname have
>>> identical effects, it is implementable, and if you have questions
>>> about how to implement it properly, I can certainly assist.
>>> 
>>> Essentially, all you have to do is to change your NAME> or
>>> whatever you call it to get from the NFA to the XT so that it
>>> recognizes synonyms and does a @ of the xt (or maybe nt, if an xt
>>> is not enough) stored there.  It requires to add one word and
>>> change one other word, it is *not* a big deal.
>> 
>> Hmmmm, maybe, but not so fast.  What should SEEing a SYNOYM do?  I
>> think it should see the SYNOYM, not the thing of which it is suppose
>> to be a synonym.
> 
> As Alex already explained, SEE can first check the name token, and
> tell you that bar is a synonym to foo.  Yes, this means you need a
> third place to change if you want to have a perfect SEE.

So far as we know at the moment.

It's a case of a frequently-observed phenomenon: a change that
initially looks reasonable and quite simple turns out to have wider
ramifications.

Andrew.

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

#25254

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>We already know what the intent of the proposer was, and it was not
>>>what you say.
>> 
>> But the question is what the intent of the committee was.  The
>> requirement for SYNONYM stated in the CfV is
>> 
>> |<newname> will behave identically to <oldname>
>> 
>> without mentioning any exceptions.
>> 
>> If the proposer did not intend that, it was he who did a
>> bait-and-switch trick.  My guess, though, is that he did not think
>> about >BODY, TO, IS etc., just like I did not.
...
>Maybe Anton didn't think about all the corner cases, but the thing I 
>implemented in Gforth as SYNONYM does work perfectly on all that stuff.  The 
>implementation in bigForth works perfectly, too.  And we have identified at 
>least three other Forth systems that do work perfectly, as well, so I'm not 
>the only one capable of doing this right.

Sure, if you take the right implementation approach, you get it right
for the corner cases without thinking about them.

What I was referring to was the specification, which specifies only
interpretation and compilation semantics.  None of us thought about
specifying that the synonym behaves like the original (as stated in
the requirements) for >BODY TO, and the words for accessing DEFERred
words.

What I learned from this:

Wrt specification: Name, interpretation semantics and compilation
semantics are not the only properties of a word.

Wrt implementation: a proper SYNONYM/ALIAS pretty much needs a kind of
name indirection mechanism at some level.  Attempts to tack SYNONYM on
a system that does not have such a mechanism without implementing such
a mechanism are likely to be complicated and miss corner cases.  OTOH,
adding such an indirection mechanism is not that complicated.

>  Anton didn't think about the 
>corner cases, but he thought about implementability, and it is indeed 
>implementable in Gforth (though it didn't get into Gforth 0.7.x

Gforth 0.7.0 was released in 2008, and SYNONYM was voted on in 2010.

- 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 2013: http://www.euroforth.org/ef13/

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

#25268

Anton Ertl wrote:

>>Maybe Anton didn't think about all the corner cases, but the thing I
>>implemented in Gforth as SYNONYM does work perfectly on all that stuff. 
>>The
>>implementation in bigForth works perfectly, too.  And we have identified
>>at least three other Forth systems that do work perfectly, as well, so I'm
>>not the only one capable of doing this right.
> 
> Sure, if you take the right implementation approach, you get it right
> for the corner cases without thinking about them.

The corner cases of ALIAS have been thought through about 30 years ago, when 
it was introduced.

> What I was referring to was the specification, which specifies only
> interpretation and compilation semantics.  None of us thought about
> specifying that the synonym behaves like the original (as stated in
> the requirements) for >BODY TO, and the words for accessing DEFERred
> words.
> 
> What I learned from this:
> 
> Wrt specification: Name, interpretation semantics and compilation
> semantics are not the only properties of a word.

Yes.  It also has an xt, it has a body (if child of CREATE), and it has a 
TO-semantics; something we already specify to avoid redefining TO each time 
we add a new class of words with TO semantics.

> Wrt implementation: a proper SYNONYM/ALIAS pretty much needs a kind of
> name indirection mechanism at some level.  Attempts to tack SYNONYM on
> a system that does not have such a mechanism without implementing such
> a mechanism are likely to be complicated and miss corner cases.  OTOH,
> adding such an indirection mechanism is not that complicated.

Indeed.

>>  Anton didn't think about the
>>corner cases, but he thought about implementability, and it is indeed
>>implementable in Gforth (though it didn't get into Gforth 0.7.x
> 
> Gforth 0.7.0 was released in 2008, and SYNONYM was voted on in 2010.

What I meant is that I didn't add SYNONYM before I completly rewrote 
Gforth's headers.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#25281

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> What I learned from this:
>> 
>> Wrt specification: Name, interpretation semantics and compilation
>> semantics are not the only properties of a word.
>
>Yes.  It also has an xt

That follows from having interpretation semantics.

>it has a body (if child of CREATE)

Yes.  So "child-of-CREATE" is another property.

>and it has a 
>TO-semantics; something we already specify to avoid redefining TO each time 
>we add a new class of words with TO semantics.

Yes.  That rewording gains event more usefulness in connection with
SYNONYM.

- 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 2013: http://www.euroforth.org/ef13/

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

#25257

On 15/08/2013 12:32, Alex McDonald wrote:
> on 14/08/2013 20:50:38, Andrew Haley wrote:
>> But we know that's not as intended: Stephen Pelc, the originator, has
>> said so.  I was there when he proposed it, and there was certainly no
>> stated intention that a SYNONYM should work with TO and have the same
>> body.  If there had been, I wouldn't have voted for the proposal.  To
>> claim that we did vote for such a thing, or that it is what the
>> proposer itended, is an attempt at a bait and switch con.  I'm not
>> falling for it.
>>
>> Andrew.
>
> No bait & switch is required. I don't know what you voted "yes" on, but
> it couldn't have been this CfV.
>
> The CfV http://www.forth200x.org/synonym.html clearly said;
>
> "Maybe some extra ambiguous conditions must be defined."
>
> They weren't, and you obviously didn't ask for others to be considered.
> Only IMMEDIATE got a mention.
>
> "...where <newname> will behave identically to <oldname>"
>
> You are proposing, in hindsight, that it doesn't behave identically, but
> you accepted the proposal as written and voted in support of it.
>
> "This required when porting code and when generating application
> wordlists that contain a reference to an existing word, e.g. when
> providing limited access to Forth system kernel words."
>
> Except for VALUEs, DEFERs, CREATEs and a bunch of others, of course.
>
> As I said to Elizabeth, if the intention of the CfV wasn't carried out -
> and I contend that it hasn't been - then SYNONYM as defined in the spec
> should be removed; or corrected to *not* exclude TO , >BODY and so on.
> Anything else is unacceptable, as the spec as written doesn't meet the
> intent of the proposal.
>

Surely, all this confusion about what SYNONYM is and what it does can 
easily be rectified by renaming it SIMILE.


-- 
Graham Smith

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

#25258

Graham Smith <"s\" xyzgrahams@tectime.com\" 3 /string"> wrote:
> 
> Surely, all this confusion about what SYNONYM is and what it does can 
> easily be rectified by renaming it SIMILE.

Excellent, good point!  I wish I'd thought of that.

Andrew.

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

#25260

on 16/08/2013 18:00:51, Andrew Haley wrote:
> Graham Smith <"s\" xyzgrahams@tectime.com\" 3 /string"> wrote:
>>
>> Surely, all this confusion about what SYNONYM is and what it does can
>> easily be rectified by renaming it SIMILE.
> 
> Excellent, good point!  I wish I'd thought of that.
> 
> Andrew.

How does this fix SYNONYM? It doesn't make the issue go away, it just
gives us a crippled SIMILE.

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

#25261

Alex McDonald <blog@rivadpm.com> wrote:
> on 16/08/2013 18:00:51, Andrew Haley wrote:
>> Graham Smith <"s\" xyzgrahams@tectime.com\" 3 /string"> wrote:
>>>
>>> Surely, all this confusion about what SYNONYM is and what it does can
>>> easily be rectified by renaming it SIMILE.
>> 
>> Excellent, good point!  I wish I'd thought of that.
> 
> How does this fix SYNONYM? It doesn't make the issue go away, it just
> gives us a crippled SIMILE.

I think it might -- just might -- be your turn not to get the joke!

Andrew.

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

#25263

on 16/08/2013 19:07:58, Andrew Haley wrote:
> Alex McDonald <blog@rivadpm.com> wrote:
>> on 16/08/2013 18:00:51, Andrew Haley wrote:
>>> Graham Smith <"s\" xyzgrahams@tectime.com\" 3 /string"> wrote:
>>>>
>>>> Surely, all this confusion about what SYNONYM is and what it does can
>>>> easily be rectified by renaming it SIMILE.
>>>
>>> Excellent, good point!  I wish I'd thought of that.
>>
>> How does this fix SYNONYM? It doesn't make the issue go away, it just
>> gives us a crippled SIMILE.
> 
> I think it might -- just might -- be your turn not to get the joke!
> 
> Andrew.

O lord. I normally get these...

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

#25264

On 16/08/13 19:18, Alex McDonald wrote:
> on 16/08/2013 19:07:58, Andrew Haley wrote:
>> Alex McDonald <blog@rivadpm.com> wrote:
>>> on 16/08/2013 18:00:51, Andrew Haley wrote:
>>>> Graham Smith <"s\" xyzgrahams@tectime.com\" 3 /string"> wrote:
>>>>>
>>>>> Surely, all this confusion about what SYNONYM is and what it does can
>>>>> easily be rectified by renaming it SIMILE.
>>>>
>>>> Excellent, good point!  I wish I'd thought of that.
>>>
>>> How does this fix SYNONYM? It doesn't make the issue go away, it just
>>> gives us a crippled SIMILE.
>>
>> I think it might -- just might -- be your turn not to get the joke!
>>
>> Andrew.
>
> O lord. I normally get these...
>

Yes, you rather surprised me.

-- 
Regards,

Graham Smith

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

#25198

On Wed, 14 Aug 2013 11:11:23 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>stephenXXX@mpeforth.com (Stephen Pelc) writes:
>>20 years after ANS we are beginning to discover what ANS wrought.

That was a general comment about the ANS and Forth2012 standards
to indicate that it'll take another decade or more to find the
faults in the Forth2012 standard.

>>Some of it is leading to a level of complexity that "just ain't
>>Forth".

Until recently, we have tended to regard standards compliance 
as a valid end in itself. After reading parts of the ANS standard
about compilation, I find myself baffled. If the standard is
incomprehensible, two possible reasons are that the standard
is badly written or that there's a bad design decision somewhere.
Or both.

Where the standard is wrong, we should ignore and correct it
rather than jump through hoops to claim standards compliance.

>SYNONYM is not in Forth-94 and is not 20 years old, and it was
>proposed by you.

Yes, and I'm beginning to regret it. To me, Forth is a 
conceptually simple and pragmatic programming language.
It should stay that way.

SYNONYM is a portable and simple way to provide aliases. That
it doesn't work on all corner cases on all implementations is
just the way the world works. But it's better than what we 
had before. The question for any implementer about any
extension is whether the system is improved by the extension
being present. 

>What do you have in mind here?

That discussion will have to wait until after the Forth2012
snapshot is finally released. Then we'll have the time to do
the job well.

One example is that if state-smart words are evil, then the
permission or implementation of FIND as a state-smart word is
also evil. I'm not posing a question for now, I'm suggesting
the topic as an example of how positions have changed since
the ANS standard was written.

For another example, if you read the standard too many times
you can convince yourself that COMPILE, should EXECUTE any
IMMEDIATE words. Fortunately, this requirement is ignored
by the vast majority of systems. The definitions of "compilation
semantics" and "execution semantics" could do with a rethink.

I have answered your question, but will not participate in
discussion about this on c.l.f until after EuroForth. I
reserve the right to change my mind.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#25185

On Tue, 13 Aug 2013 03:49:26 -0500, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>> For reasons 1 and 2 above, I withdraw my objection to name tokens.
>
>OK.  I don't think I can do this on my own.

You can always try to persuade me to object to nts again.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#25193

On Wednesday, 14 August 2013 13:40:07 UTC+1, Stephen Pelc  wrote:

> 
> You can always try to persuade me to object to nts again.
> 

At this point, I'm forced to mention that I have compromising photographs of you in Cambridge. In a punt. Handling a pole. 

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

#25194

On Wednesday, August 14, 2013 2:20:49 PM UTC+1, Alex McDonald wrote:
> At this point, I'm forced to mention that I have compromising photographs of you in Cambridge. In a punt. Handling a pole.

Leave the Poles out of this. They're good people!

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

#25158

on 13/08/2013 09:30:23,  wrote:
> On Mon, 12 Aug 2013 21:08:16 +0100, "Alex McDonald" <blog@rivadpm.com>
> wrote:
> 
>>Because TRAVERSE-WORDLIST is returning name tokens, it is perfectly
>>possible that the nt shares an xt with some other word. Consider:
> 
>>SYNONYM NEW OLD
> 
>>If NEW and OLD are both defined in wordlist wid, then nts for NEW and
>>OLD will be returned by TRAVERSE-WORLDLIST, and NAME>INTERPRET and
>>NAME>COMPILE will return the same corresponding xt for both NEW and
>>OLD.
> 
> Whoah! I don't believe that TRAVERSE-WORDLIST should impose on
> SYNONYM. Recognising that an n:1 name to xt relationship can
> exist in systems is very different from requiring it.

Correction; that should read "may" rather than "will".

If NEW and OLD are both defined in wordlist wid, then nts for NEW and OLD
will be returned by TRAVERSE-WORLDLIST, and NAME>INTERPRET and
NAME>COMPILE may return the same corresponding xt for both NEW and OLD.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web