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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#25211

On 8/14/2013 9:50 AM, Andrew Haley wrote:
> Alex McDonald <blog@rivadpm.com> wrote:
>> on 14/08/2013 17:32:55, Andrew Haley wrote:
>>> Alex McDonald <blog@rivadpm.com> wrote:
>>>> on 14/08/2013 15:40:45, Andrew Haley wrote:
>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>> It was, but SYNONYM was described to us in a way that didn't suggest
>>>>>>> the interpretation people are placing on it.  The only reason, so we
>>>>>>> were told, that the older and better form
>>>>>>>
>>>>>>> ' foo AKA bar
>>>>>>>
>>>>>>> couldn't be used was that FOO might be immediate (or have other non-
>>>>>>> default compilation semantics) and we wanted BAR to inherit those.
>>>>>>
>>>>>> That's what's ended up in the specification.
>>>>>>
>>>>>>> There was certainly none of this "BAR has the same XT as FOO"
>>>>>>
>>>>>> I don't think anybody claimed that was a requirement
>>>>>
>>>>> Somebody seems to want to.
>>>>
>>>> If you mean me, then no; I was suggesting that an implementation that
>>>> didn't require major engineering and met a consistent specification of
>>>> SYNONYM could use the same XT. Many have done so.
>>>
>>> Sure.  No disagreement there.  Certainly many such systems exist.
>>>
>>> OK, so *nobody* believes that there is any requirement that aliases
>>> should have the same XT, or work with TO, or have the same body when
>>> ticked.  Good.
>>
>> No. Working with TO and having the same body make SYNONYM a
>> synonym. How you do that with a different XT is up to you. Anything
>> less that that isn't a synonym, and I'd agree with Stephen Pelc's
>> statement; "Where the standard is wrong, we should ignore and
>> correct it rather than jump through hoops to claim standards
>> compliance." I'm ignoring it as written, and implementing it as
>> intended.
>
> 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.

Sounds like the best solution is to reword SYNONYM to say what you mean. 
Limiting the kinds of things it can be used with would be reasonable 
(e.g. make TO "ambiguous").

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#25217

on 14/08/2013 21:28:13, Elizabeth D Rather wrote:
> On 8/14/2013 9:50 AM, Andrew Haley wrote:
>> Alex McDonald <blog@rivadpm.com> wrote:
>>> on 14/08/2013 17:32:55, Andrew Haley wrote:
>>>> Alex McDonald <blog@rivadpm.com> wrote:
>>>>> on 14/08/2013 15:40:45, Andrew Haley wrote:
>>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>>> It was, but SYNONYM was described to us in a way that didn't suggest
>>>>>>>> the interpretation people are placing on it.  The only reason, so we
>>>>>>>> were told, that the older and better form
>>>>>>>>
>>>>>>>> ' foo AKA bar
>>>>>>>>
>>>>>>>> couldn't be used was that FOO might be immediate (or have other non-
>>>>>>>> default compilation semantics) and we wanted BAR to inherit those.
>>>>>>>
>>>>>>> That's what's ended up in the specification.
>>>>>>>
>>>>>>>> There was certainly none of this "BAR has the same XT as FOO"
>>>>>>>
>>>>>>> I don't think anybody claimed that was a requirement
>>>>>>
>>>>>> Somebody seems to want to.
>>>>>
>>>>> If you mean me, then no; I was suggesting that an implementation that
>>>>> didn't require major engineering and met a consistent specification of
>>>>> SYNONYM could use the same XT. Many have done so.
>>>>
>>>> Sure.  No disagreement there.  Certainly many such systems exist.
>>>>
>>>> OK, so *nobody* believes that there is any requirement that aliases
>>>> should have the same XT, or work with TO, or have the same body when
>>>> ticked.  Good.
>>>
>>> No. Working with TO and having the same body make SYNONYM a
>>> synonym. How you do that with a different XT is up to you. Anything
>>> less that that isn't a synonym, and I'd agree with Stephen Pelc's
>>> statement; "Where the standard is wrong, we should ignore and
>>> correct it rather than jump through hoops to claim standards
>>> compliance." I'm ignoring it as written, and implementing it as
>>> intended.
>>
>> 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.
> 
> Sounds like the best solution is to reword SYNONYM to say what you
> mean. Limiting the kinds of things it can be used with would be
> reasonable (e.g. make TO "ambiguous").

And a whole class of other operations. In fact, the only safe thing to do
with a synonym as it currently stands is either to EXECUTE or COMPILE,
it.

The the stance by some is that <newname> is no different from a colon
definition that invokes <oldname>, regardless of the "type" of <oldname>.

I'd vote for its complete removal in that case.

> 
> Cheers,
> Elizabeth
> 

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

#25219

Alex McDonald <blog@rivadpm.com> wrote:
> 
> And a whole class of other operations. In fact, the only safe thing to do
> with a synonym as it currently stands is either to EXECUTE or COMPILE,
> it.

Right.

> The the stance by some is that <newname> is no different from a colon
> definition that invokes <oldname>, regardless of the "type" of <oldname>.

Not quite: if <oldname> is immediate (or has non-default compilation
semantics), so is <newname> .

Andrew.

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

#25214

On 14/08/2013 20:50, Andrew Haley wrote:
> Alex McDonald <blog@rivadpm.com> wrote:
>> on 14/08/2013 17:32:55, Andrew Haley wrote:
>>> Alex McDonald <blog@rivadpm.com> wrote:
>>>> on 14/08/2013 15:40:45, Andrew Haley wrote:
>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>> It was, but SYNONYM was described to us in a way that didn't suggest
>>>>>>> the interpretation people are placing on it.  The only reason, so we
>>>>>>> were told, that the older and better form
>>>>>>>
>>>>>>> ' foo AKA bar
>>>>>>>
>>>>>>> couldn't be used was that FOO might be immediate (or have other non-
>>>>>>> default compilation semantics) and we wanted BAR to inherit those.
>>>>>>
>>>>>> That's what's ended up in the specification.
>>>>>>
>>>>>>> There was certainly none of this "BAR has the same XT as FOO"
>>>>>>
>>>>>> I don't think anybody claimed that was a requirement
>>>>>
>>>>> Somebody seems to want to.
>>>>
>>>> If you mean me, then no; I was suggesting that an implementation that
>>>> didn't require major engineering and met a consistent specification of
>>>> SYNONYM could use the same XT. Many have done so.
>>>
>>> Sure.  No disagreement there.  Certainly many such systems exist.
>>>
>>> OK, so *nobody* believes that there is any requirement that aliases
>>> should have the same XT, or work with TO, or have the same body when
>>> ticked.  Good.
>>
>> No. Working with TO and having the same body make SYNONYM a
>> synonym. How you do that with a different XT is up to you. Anything
>> less that that isn't a synonym, and I'd agree with Stephen Pelc's
>> statement; "Where the standard is wrong, we should ignore and
>> correct it rather than jump through hoops to claim standards
>> compliance." I'm ignoring it as written, and implementing it as
>> intended.
>
> 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.

If such things were discussed at the time of the proposal, they should 
have been written into the specification for SYNONYM? What are users of 
the standard supposed to do - guess? I would have thought that a group 
of experienced software engineers/programmers would appreciate the need 
for a tightly written and complete specification for a new word.

As I (and Alex) wrote elsewhere the spec for SYNONYM requires a 
statement about what <newword> does and does not inherit from <oldword> 
as well as a complete list of what cannot be done to <newname>. In the 
absence of such statements you get what has happened here  - people 
making assumptions and others waffling about what was intended.

-- 
Gerry

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

#25215

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> On 14/08/2013 20:50, Andrew Haley wrote:
>> Alex McDonald <blog@rivadpm.com> wrote:
>>> No. Working with TO and having the same body make SYNONYM a
>>> synonym. How you do that with a different XT is up to you. Anything
>>> less that that isn't a synonym, and I'd agree with Stephen Pelc's
>>> statement; "Where the standard is wrong, we should ignore and
>>> correct it rather than jump through hoops to claim standards
>>> compliance." I'm ignoring it as written, and implementing it as
>>> intended.
>>
>> 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.
> 
> If such things were discussed at the time of the proposal,

They weren't.

> they should have been written into the specification for SYNONYM?
> What are users of the standard supposed to do - guess? I would have
> thought that a group of experienced software engineers/programmers
> would appreciate the need for a tightly written and complete
> specification for a new word.

It's still a work in progress.

> As I (and Alex) wrote elsewhere the spec for SYNONYM requires a
> statement about what <newword> does and does not inherit from
> <oldword> as well as a complete list of what cannot be done to
> <newname>. In the absence of such statements you get what has
> happened here - people making assumptions and others waffling about
> what was intended.

Indeed.  We need to discuss this at the next meeting.

Andrew.

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

#25218

on 14/08/2013 20:50:38, Andrew Haley wrote:
> Alex McDonald <blog@rivadpm.com> wrote:
>> on 14/08/2013 17:32:55, Andrew Haley wrote:
>>> Alex McDonald <blog@rivadpm.com> wrote:
>>>> on 14/08/2013 15:40:45, Andrew Haley wrote:
>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>>It was, but SYNONYM was described to us in a way that didn't suggest
>>>>>>>the interpretation people are placing on it.  The only reason, so we
>>>>>>>were told, that the older and better form
>>>>>>>
>>>>>>> ' foo AKA bar
>>>>>>>
>>>>>>>couldn't be used was that FOO might be immediate (or have other non-
>>>>>>>default compilation semantics) and we wanted BAR to inherit those.
>>>>>>
>>>>>> That's what's ended up in the specification.
>>>>>>
>>>>>>>There was certainly none of this "BAR has the same XT as FOO"
>>>>>>
>>>>>> I don't think anybody claimed that was a requirement
>>>>>
>>>>> Somebody seems to want to.
>>>>
>>>> If you mean me, then no; I was suggesting that an implementation that
>>>> didn't require major engineering and met a consistent specification of
>>>> SYNONYM could use the same XT. Many have done so.
>>>
>>> Sure.  No disagreement there.  Certainly many such systems exist.
>>>
>>> OK, so *nobody* believes that there is any requirement that aliases
>>> should have the same XT, or work with TO, or have the same body when
>>> ticked.  Good.
>>
>> No. Working with TO and having the same body make SYNONYM a
>> synonym. How you do that with a different XT is up to you. Anything
>> less that that isn't a synonym, and I'd agree with Stephen Pelc's
>> statement; "Where the standard is wrong, we should ignore and
>> correct it rather than jump through hoops to claim standards
>> compliance." I'm ignoring it as written, and implementing it as
>> intended.
> 
> 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.

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

#25220

Alex McDonald <blog@rivadpm.com> wrote:
> on 14/08/2013 20:50:38, Andrew Haley wrote:
>> Alex McDonald <blog@rivadpm.com> wrote:
>>>
>>> No. Working with TO and having the same body make SYNONYM a
>>> synonym. How you do that with a different XT is up to you. Anything
>>> less that that isn't a synonym, and I'd agree with Stephen Pelc's
>>> statement; "Where the standard is wrong, we should ignore and
>>> correct it rather than jump through hoops to claim standards
>>> compliance." I'm ignoring it as written, and implementing it as
>>> intended.
>> 
>> 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.
> 
> 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."

Maybe they should.

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

I'm not falling for that: a child of SYNONYM behaves identicially when
executed and when comma'd.  There was no other intention, or we would
have had to discuss all the ramifications of making it work with, say,
IS .

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

Not at all: you can still execute and comma VALUEs, DEFERs, and CREATEs.

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

A proposal cannot have any intent because a proposal is not sentient.
We already know what the intent of the proposer was, and it was not
what you say.

Andrew.

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

#25222

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.

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

#25223

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> My guess, though, is that he did not think about >BODY, TO, IS etc.,
> just like I did not.

Exactly.  So that can't have been our intention, since we didn't think
about it.  The proposal seemed harmless at the time, and now we're
driven to thinking about a SYNONYM-smart ' .  Argh!  Just say no!  We
need more baggage like this in Forth like we need a hole in the head.

This is all rather reminiscent of the fallout from the poor way that
IS and its friends were defined.  Let's not have any more such things.

Andrew.

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

#25225 — SYNONYM (was: RfD v7: TRAVERSE-WORDLIST final)

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> My guess, though, is that he did not think about >BODY, TO, IS etc.,
>> just like I did not.
>
>Exactly.  So that can't have been our intention, since we didn't think
>about it.

My intention certainly was written down in the proposal: 

|<newname> will behave identically to <oldname>

We did not think of all the corner cases, so this requirement is not
fully reflected in the specification, but that does not mean it was
not intended.

>The proposal seemed harmless at the time, and now we're
>driven to thinking about a SYNONYM-smart ' .  Argh!  Just say no!  We
>need more baggage like this in Forth like we need a hole in the head.

I am awaiting your RfD for removing 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]

#25226 — Re: SYNONYM

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> My guess, though, is that he did not think about >BODY, TO, IS etc.,
>>> just like I did not.
>>
>>Exactly.  So that can't have been our intention, since we didn't think
>>about it.
> 
> My intention certainly was written down in the proposal: 
> 
> |<newname> will behave identically to <oldname>
> 
> We did not think of all the corner cases, so this requirement is not
> fully reflected in the specification, but that does not mean it was
> not intended.

Hmm.  It doesn't mean that it *was* intended either, and I believe
that if someone had pointed out that this proposal might, as written,
require more extensive changes to some systems than just adding a
word, the proposal probably would not have passed.

>>The proposal seemed harmless at the time, and now we're
>>driven to thinking about a SYNONYM-smart ' .  Argh!  Just say no!  We
>>need more baggage like this in Forth like we need a hole in the head.
> 
> I am awaiting your RfD for removing SYNONYM.

I thought it was a good proposal, as described to us.  I still do.
The only thing that is bad about it is your interpretation; we need to
clean up the language.

Andrew.

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

#25228 — Re: SYNONYM

on 15/08/2013 15:16:33, Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> My guess, though, is that he did not think about >BODY, TO, IS etc.,
>>>> just like I did not.
>>>
>>>Exactly.  So that can't have been our intention, since we didn't think
>>>about it.
>>
>> My intention certainly was written down in the proposal:
>>
>> |<newname> will behave identically to <oldname>
>>
>> We did not think of all the corner cases, so this requirement is not
>> fully reflected in the specification, but that does not mean it was
>> not intended.
> 
> Hmm.  It doesn't mean that it *was* intended either, and I believe
> that if someone had pointed out that this proposal might, as written,
> require more extensive changes to some systems than just adding a
> word, the proposal probably would not have passed.
> 
>>>The proposal seemed harmless at the time, and now we're
>>>driven to thinking about a SYNONYM-smart ' .  Argh!  Just say no!  We
>>>need more baggage like this in Forth like we need a hole in the head.
>>
>> I am awaiting your RfD for removing SYNONYM.
> 
> I thought it was a good proposal, as described to us.  I still do.
> The only thing that is bad about it is your interpretation; we need to
> clean up the language.
> 
> Andrew.

The easiest way to do that is to declare SYNONYMs as read only. In other
words, all words that change any aspect of <newname> are ambiguous.

That kind of reduces the value (pun intended) of SYNONYM considerably.
Who wants a portable SYNONYM

3 value x
synonym y x

where Y is read only? Even Stephen's VFX supports TO on synonyms.

Again, let's remove SYNONYM. It doesn't stop systems from providing such
a word; but at least there won't then be the illusion of portability that
the CfV promised and the spec failed to deliver. 

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

#25233

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.

The proposal mentions ALIAS, which takes an xt, and we have about 30 years 
of experience with it.  The problem with ALIAS is addressed by the proposal: 
it takes an xt, which is not sufficient, because you don't know about 
immediacy, and the standard even allows weird things like dual-xts words and 
such things, where a single xt simply can't do what's necessary.

The reference implementation was said to be inappropriate, because the 
problem with SYNONYM is exactly that: It's not possible to implement it with 
standard words.  I'm sure I've pointed out that the reference implementation 
is bogus and won't work, but the quick defense was that this is the 
particular reason why it needs to go into the standard, because it requires 
carnal knowledge to do it right.

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.  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, and the 
current implementation uses something that wouldn't be possible in 0.7.x).

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.  You can 
recognize synonyms by the DOES> code if you like so; no special header flag 
bit required.

Please, people, calm down.  And don't panic!

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

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

#25246

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.

Andrew.

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

#25247

on 16/08/2013 13:22:22, 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.
> 
> Andrew.
> 

You'll be wanting a name token next.

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

#25249

Alex McDonald <blog@rivadpm.com> wrote:
> on 16/08/2013 13:22:22, 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.
> 
> You'll be wanting a name token next.

I guess this is supposed to be humourous, but -- in all seriousness :-) --
I don't get it.

Andrew.

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

#25259

on 16/08/2013 14:25:52, Andrew Haley wrote:
> Alex McDonald <blog@rivadpm.com> wrote:
>> on 16/08/2013 13:22:22, 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.
>>
>> You'll be wanting a name token next.
> 
> I guess this is supposed to be humourous, but -- in all seriousness
> :-) -- I don't get it.
> 
> Andrew.

Sort of both humourous and serious. What you're asking for is the name
token (to get the defined name) when SEEing a SYNONYM; not the xt.
Otherwise your requirement could disenfranchise those implemenations that
have the same xt for both names.

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

#25262

Alex McDonald <blog@rivadpm.com> wrote:
> on 16/08/2013 14:25:52, Andrew Haley wrote:
>> Alex McDonald <blog@rivadpm.com> wrote:
>>> on 16/08/2013 13:22:22, 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.
>>>
>>> You'll be wanting a name token next.
>> 
>> I guess this is supposed to be humourous, but -- in all seriousness
>> :-) -- I don't get it.
> 
> Sort of both humourous and serious. What you're asking for is the
> name token (to get the defined name) when SEEing a SYNONYM; not the
> xt.  Otherwise your requirement could disenfranchise those
> implemenations that have the same xt for both names.

Hmm.  I don't think that was really my intention.

AFAIK every Forth system has something like a name token (or, more
likely, the address of a name) and it's reasonable to use it for some
things.  The question in my mind is not where such a thing should be
used -- that's up to the implementer -- but whether it should be
exposed by the standard.

Andrew.

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

#25251

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>What should SEEing a SYNOYM do?

|15.6.1.2194 SEE
|... The source of the representation (object-code decompilation,
|source block, etc.) and the particular form of the display is
|implementation defined. ...

Given that, a system has a large freedom in what SEE does.  E.g., I
doubt that VFX's output for

: foo dup + ; see foo

which is

FOO 
( 080BF2E0    03DB )                  ADD       EBX, EBX
( 080BF2E2    C3 )                    NEXT,
( 3 bytes, 2 instructions )

has produced many complaints.

>I
>think it should see the SYNOYM, not the thing of which it is suppose
>to be a synonym.

Either will be fine.  In Gforth ALIAS and SEE have worked together as
follows for two decades:

: foo ; 
' foo alias bar
see bar

produces the following output:

: foo  ;

There have been no complaints about that.  I think there was one
complaint about

... r@ ...

decompiling to

... i ...

but I consider that within acceptable bounds.

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

#25253

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>What should SEEing a SYNOYM do?
> 
> |15.6.1.2194 SEE
> |... The source of the representation (object-code decompilation,
> |source block, etc.) and the particular form of the display is
> |implementation defined. ...
> 
> Given that, a system has a large freedom in what SEE does.  E.g., I
> doubt that VFX's output for
> 
> : foo dup + ; see foo
> 
> which is
> 
> FOO 
> ( 080BF2E0    03DB )                  ADD       EBX, EBX
> ( 080BF2E2    C3 )                    NEXT,
> ( 3 bytes, 2 instructions )
> 
> has produced many complaints.
> 
>>I
>>think it should see the SYNOYM, not the thing of which it is suppose
>>to be a synonym.
> 
> 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?

Andrew.

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

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

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

csiph-web