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

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

Re: String Constants

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-18 20:52 -0700
    Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-19 03:44 -0500
      Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-21 21:34 -0700
        Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-22 03:20 -0500
          Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-22 07:37 -0700
            Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-22 11:12 -0500
              Re: String Constants anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-22 17:36 +0000
                Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-22 13:05 -0500
                  Re: String Constants anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-22 18:17 +0000
                    Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 03:22 -0500
                      Re: String Constants anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-23 11:35 +0000
                        Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 11:37 -0500
                      Re: String Constants anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-23 12:07 +0000
                        Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 11:40 -0500
                  Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-22 12:22 -0700
              Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-22 12:13 -0700
                Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 03:30 -0500
                  Re: String Constants anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-23 11:44 +0000
                    Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-23 11:47 -0500
                      Re: String Constants anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-26 09:23 +0000
                        Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-26 06:49 -0500
                    Re: String Constants Paul Rubin <no.email@nospam.invalid> - 2011-04-25 00:50 -0700
                      Re: String Constants anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-26 10:08 +0000
                  Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-23 10:14 -0700
                    Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-24 03:15 -0500
                      Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-24 13:26 -0700
                        Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-24 17:03 -0500
                          Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-24 19:05 -0700
                            Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-25 03:08 -0500
                              Re: String Constants kenney@cix.compulink.co.uk - 2011-04-25 07:07 -0500
                                Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-25 08:00 -0700
                                Re: String Constants Elizabeth D Rather <erather@forth.com> - 2011-04-25 08:56 -1000
                              Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-25 07:45 -0700
                                Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-26 03:42 -0500
                                  Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-26 11:20 -0700
                  Re: String Constants Alex McDonald <blog@rivadpm.com> - 2011-04-26 11:02 -0700
                    Re: String Constants Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-26 21:59 +0200
                    Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-27 03:26 -0500
                      Re: String Constants Alex McDonald <blog@rivadpm.com> - 2011-04-27 09:12 -0700
                        Re: String Constants Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-27 11:28 -0500
                          Re: String Constants Alex McDonald <blog@rivadpm.com> - 2011-04-27 10:47 -0700
                      Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-27 10:20 -0700
              Re: String Constants BruceMcF <agila61@netscape.net> - 2011-04-22 12:37 -0700

Page 1 of 3  [1] 2 3  Next page →

#1301 — Re: String Constants

On Mar 27, 5:48 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Does it?  At best it's self contradictory.  It says that no system
> words use PAD, but ALLOT may move it or destroy its contents.  If you
> take the first as being the truth, then ALLOT may trash PAD.  If you
> take the second as ths truth, then it may not.

It never *gives* ALLOT permission to destroy PAD's contents, so when
it prohibits that trashing, there is no contradiction.

It says that use of PAD's contents "may become invalid after" ALLOT
and friends, and it says that that "no words defined in this Standard
place anything in the region", and it says that ALLOT , C, ALIGN and
CREATE (and by reference anything else added to 3.3.3.2 list by some
later section) are permitted to *change the address returned by PAD*.

The reading of "may become invalid after" as "is allowed to trash" is
(1) not the only way to read "may become invalid after", and (2)
contradicts the explicit prohibition from writing into the region
defined by PAD, _which also specifies *how* those words *may* render
the region invalid_ (that is, by changing the address that it refers
to).

[toc] | [next] | [standalone]

#1311

BruceMcF <agila61@netscape.net> wrote:
> On Mar 27, 5:48?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Does it? At best it's self contradictory. It says that no system
>> words use PAD, but ALLOT may move it or destroy its contents. If you
>> take the first as being the truth, then ALLOT may trash PAD. If you
>> take the second as ths truth, then it may not.
> 
> It never *gives* ALLOT permission to destroy PAD's contents,

Yes it does.  "become invalid" may mean "trashed".

> so when it prohibits that trashing, there is no contradiction.
>
> It says that use of PAD's contents "may become invalid after" ALLOT
> and friends, and it says that that "no words defined in this Standard
> place anything in the region", and it says that ALLOT , C, ALIGN and
> CREATE (and by reference anything else added to 3.3.3.2 list by some
> later section) are permitted to *change the address returned by PAD*.
> 
> The reading of "may become invalid after" as "is allowed to trash" is
> (1) not the only way to read "may become invalid after",

That's right, but it is the most pessimistic way of reading it, and
it's not inconsistent with what is written.

> and (2) contradicts the explicit prohibition from writing into the
> region defined by PAD, _which also specifies *how* those words *may*
> render the region invalid_ (that is, by changing the address that it
> refers to).

I think I've already explained what I think that means: a standard
program may use that region unmolested by standard words.  It's not a
get-out from ALLOT invalidating the contents of PAD.  The language is
explicit.

I am aware that I am reading the text in the most pessimistic way
possible.  That is the right way to read a specification, if you want
your programs to be robust.

Andrew.

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

#1400

On Apr 19, 4:44 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> BruceMcF <agil...@netscape.net> wrote:
> > On Mar 27, 5:48?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> > wrote:
> >> Does it? At best it's self contradictory. It says that no system
> >> words use PAD, but ALLOT may move it or destroy its contents. If you
> >> take the first as being the truth, then ALLOT may trash PAD. If you
> >> take the second as ths truth, then it may not.
>
> > It never *gives* ALLOT permission to destroy PAD's contents,
>
> Yes it does.  "become invalid" may mean "trashed".

The question is whether it implies trashed. Whether that is the most
pessimistic way to ready it consistent with the standard, or *more*
pessimistic than the way to read it consistent with the standard
hinges on the second.

> > so when it prohibits that trashing, there is no contradiction.

> > It says that use of PAD's contents "may become invalid after" ALLOT
> > and friends, and it says that that "no words defined in this Standard
> > place anything in the region", and it says that ALLOT , C, ALIGN and
> > CREATE (and by reference anything else added to 3.3.3.2 list by some
> > later section) are permitted to *change the address returned by PAD*.

> > The reading of "may become invalid after" as "is allowed to trash" is
> > (1) not the only way to read "may become invalid after",

> That's right, but it is the most pessimistic way of reading it, and
> it's not inconsistent with what is written.

That depends on (2).

> > and (2) contradicts the explicit prohibition from writing into the
> > region defined by PAD, _which also specifies *how* those words *may*
> > render the region invalid_ (that is, by changing the address that it
> > refers to).

> I think I've already explained what I think that means: a standard
> program may use that region unmolested by standard words.  It's not a
> get-out from ALLOT invalidating the contents of PAD.  The language is
> explicit.

See, I am not going by what I think it *means*, I am going by what it
*specifies*. Skipping what it explicitly says to draw the
specification from what it is presumed to mean does not strike me as a
sound first resort.

> I am aware that I am reading the text in the most pessimistic way
> possible.  That is the right way to read a specification, if you want
> your programs to be robust.

The most pessimistic possible reading is that everything explicitly
said is subject to tacit modification because of some common
understanding that what it actually says is not what it really means.

When the standard puts the "may render invalid" net over that set of
words, then singles out one of the set and says that no system word
may touch its contents, however a set of words may change the location
at which it is addressed, it is for that specific word also specifying
the manner in which that set of words may render it invalid.

Luckily, what it specifies is also what generally seems to have been
intended ~ to exclude the contents of PAD from being subject to what
would otherwise be the most pessimistic allowed reading of "may render
invalid". It could well be that the specific intent is to avoid , C,
and CREATE from trashing PAD, without actually imagining that someone
would zero out memory being ALLOTted, but the effect is to rule out
*any* of those words trashing the content of PAD.

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

#1406

BruceMcF <agila61@netscape.net> wrote:
> On Apr 19, 4:44?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> BruceMcF <agil...@netscape.net> wrote:
>> > On Mar 27, 5:48?am, Andrew Haley <andre...@littlepinkcloud.invalid>
>> > wrote:
>> >> Does it? At best it's self contradictory. It says that no system
>> >> words use PAD, but ALLOT may move it or destroy its contents. If you
>> >> take the first as being the truth, then ALLOT may trash PAD. If you
>> >> take the second as ths truth, then it may not.
>>
>> > It never *gives* ALLOT permission to destroy PAD's contents,
>>
>> Yes it does. ?"become invalid" may mean "trashed".
> 
> The question is whether it implies trashed. Whether that is the most
> pessimistic way to ready it consistent with the standard, or *more*
> pessimistic than the way to read it consistent with the standard
> hinges on the second.

The question is whether a reasonable implementor of Forth might read
it that way.  

>> > so when it prohibits that trashing, there is no contradiction.
> 
>> > It says that use of PAD's contents "may become invalid after" ALLOT
>> > and friends, and it says that that "no words defined in this Standard
>> > place anything in the region", and it says that ALLOT , C, ALIGN and
>> > CREATE (and by reference anything else added to 3.3.3.2 list by some
>> > later section) are permitted to *change the address returned by PAD*.
> 
>> > The reading of "may become invalid after" as "is allowed to trash" is
>> > (1) not the only way to read "may become invalid after",
> 
>> That's right, but it is the most pessimistic way of reading it, and
>> it's not inconsistent with what is written.
> 
> That depends on (2).

>> > and (2) contradicts the explicit prohibition from writing into the
>> > region defined by PAD, _which also specifies *how* those words *may*
>> > render the region invalid_ (that is, by changing the address that it
>> > refers to).
> 
>> I think I've already explained what I think that means: a standard
>> program may use that region unmolested by standard words. ?It's not a
>> get-out from ALLOT invalidating the contents of PAD. ?The language is
>> explicit.
> 
> See, I am not going by what I think it *means*, I am going by what it
> *specifies*.

Me too.  "May become invalid."

> Skipping what it explicitly says to draw the specification from what
> it is presumed to mean does not strike me as a sound first resort.

>> I am aware that I am reading the text in the most pessimistic way
>> possible. ?That is the right way to read a specification, if you want
>> your programs to be robust.
> 
> The most pessimistic possible reading is that everything explicitly
> said is subject to tacit modification because of some common
> understanding that what it actually says is not what it really means.

Perhaps, but that would be unsound reasoning.  Let's try to stick to
reasoning that only relies on the text itself, without regard to
anything else.

> When the standard puts the "may render invalid" net over that set of
> words, then singles out one of the set and says that no system word
> may touch its contents, however a set of words may change the location
> at which it is addressed, it is for that specific word also specifying
> the manner in which that set of words may render it invalid.

This is merely to restate your previous opinion.  I'll restate mine:
it might mean that, or not.

> Luckily, what it specifies is also what generally seems to have been
> intended ~ to exclude the contents of PAD from being subject to what
> would otherwise be the most pessimistic allowed reading of "may render
> invalid". It could well be that the specific intent is to avoid , C,
> and CREATE from trashing PAD, without actually imagining that someone
> would zero out memory being ALLOTted, but the effect is to rule out
> *any* of those words trashing the content of PAD.

You're saying that by careful reasoning it's possible to determine
that two apparently contradictory passages are, in fact, not
contradictory if read together in a certain way.  You propose to write
application programs that rely on your interpretation.  You believe
that you will be safe because every implementor will, you hope, read
those passages in the same way that you do.

Andrew.

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

#1414

On Apr 22, 4:20 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> > The question is whether it implies trashed. Whether that is the most
> > pessimistic way to ready it consistent with the standard, or *more*
> > pessimistic than the way to read it consistent with the standard
> > hinges on the second.

> The question is whether a reasonable implementor of Forth might read
> it that way.  

Yes, that is the problem with the specification: not that it fails to
specify that, but that it specifies it in a way that someone applying
a specific stereotype may misinterpret.

> > When the standard puts the "may render invalid" net over that set of
> > words, then singles out one of the set and says that no system word
> > may touch its contents, however a set of words may change the location
> > at which it is addressed, it is for that specific word also specifying
> > the manner in which that set of words may render it invalid.

> This is merely to restate your previous opinion.  I'll restate mine:
> it might mean that, or not.

> You're saying that by careful reasoning it's possible to determine
> that two apparently contradictory passages are, in fact, not
> contradictory if read together in a certain way.

No, I am saying that by careful *reading*, its possible to determine
what the two passages mean, when taken together. The entire "seeming
contradiction" comes from reading one part of a single section and
interpreting it in a way that would indeed seem valid unless detailed
more completely elsewhere ... and skipping the fact that its detailed
more completely for one specific region two paragraphs later in the
same section.

It may be my opinion, but its my opinion about what the text *says*,
not my opinion about what the text implies.

The apparent contradiction only occurs due to careless reading, but
that in itself is a problem with the way the specification is stated.

> You propose to write
> application programs that rely on your interpretation.  You believe
> that you will be safe because every implementor will, you hope, read
> those passages in the same way that you do.

I am willing to believe that multiple implementers will misread that
section. However, if an implementer is so aggressive in trying to
limit the freedom of action of the user in that section ...

Well, compare the two interpretations:
"It says that no system word can touch the contents of PAD, but can
move the location of pad, so I'll be sure none of my system words
touch the contents of PAD."

"It *says* no system word can touch the contents of PAD, but can move
the location of PAD, but if my system word moves the location first,
then, *aha*, I can touch the contents of the *former* pad later on in
that word!"

... if the implementer is looking that aggressively for loopholes that
allow them to take away freedom of action from the user, it seems
highly likely that the implementation has taken away my freedom of
action in other ways.

For big systems, if SwiftForth, VFX, gforth, bigforth, and Win32Forth
respect it, and for small systems if hForth and CamelForth respect it,
and for retro fun if hForth for CP/M and VolksForth64 respect it ...
I'm not too worried by the systems that fail to respect it. They're
likely to be abusive to the user in other ways as well.

And in this case, as opposed to the "the memory after ALLOT might not
exist yet" case, it also requires adding extra cruft to ALLOT, and if
the implementer is adding extra cruft to ALLOT, they are likely adding
extra cruft to other system words as well.

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

#1417

BruceMcF <agila61@netscape.net> wrote:
> On Apr 22, 4:20?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> > The question is whether it implies trashed. Whether that is the most
>> > pessimistic way to ready it consistent with the standard, or *more*
>> > pessimistic than the way to read it consistent with the standard
>> > hinges on the second.
> 
>> The question is whether a reasonable implementor of Forth might read
>> it that way. 
> 
> Yes, that is the problem with the specification: not that it fails
> to specify that, but that it specifies it in a way that someone
> applying a specific stereotype may misinterpret.

That's the problem I'm pointing to.  Most Forth implementors just
"know" how it should be done.  I wonder what would happen if someone
not steeped in Forth tradition implemented the langauge from the
standard; I wonder how many supposedly standard programs would cease
to work.
 
>> > When the standard puts the "may render invalid" net over that set of
>> > words, then singles out one of the set and says that no system word
>> > may touch its contents, however a set of words may change the location
>> > at which it is addressed, it is for that specific word also specifying
>> > the manner in which that set of words may render it invalid.
> 
>> This is merely to restate your previous opinion. I'll restate mine:
>> it might mean that, or not.
> 
>> You're saying that by careful reasoning it's possible to determine
>> that two apparently contradictory passages are, in fact, not
>> contradictory if read together in a certain way.
> 
> No, I am saying that by careful *reading*, its possible to determine
> what the two passages mean, when taken together.

What's the difference?  You have to interpret a text in order to read
it.

> The entire "seeming contradiction" comes from reading one part of a
> single section and interpreting it in a way that would indeed seem
> valid unless detailed more completely elsewhere ... and skipping the
> fact that its detailed more completely for one specific region two
> paragraphs later in the same section.  It may be my opinion, but its
> my opinion about what the text *says*, not my opinion about what the
> text implies.

No disagreement there.

> The apparent contradiction only occurs due to careless reading, but
> that in itself is a problem with the way the specification is stated.

OK, so we at least agree that some clarification is required.

>> You propose to write application programs that rely on your
>> interpretation. You believe that you will be safe because every
>> implementor will, you hope, read those passages in the same way
>> that you do.
> 
> I am willing to believe that multiple implementers will misread that
> section. However, if an implementer is so aggressive in trying to
> limit the freedom of action of the user in that section ...
> Well, compare the two interpretations:
> "It says that no system word can touch the contents of PAD, but can
> move the location of pad, so I'll be sure none of my system words
> touch the contents of PAD."
> "It *says* no system word can touch the contents of PAD, but can move
> the location of PAD, but if my system word moves the location first,
> then, *aha*, I can touch the contents of the *former* pad later on in
> that word!"
>
> ... if the implementer is looking that aggressively for loopholes that
> allow them to take away freedom of action from the user, it seems
> highly likely that the implementation has taken away my freedom of
> action in other ways.

Such as?

> For big systems, if SwiftForth, VFX, gforth, bigforth, and Win32Forth
> respect it, and for small systems if hForth and CamelForth respect it,
> and for retro fun if hForth for CP/M and VolksForth64 respect it ...

Well, that's a very different question.  There's a tradition of Forth
implementations going back decades, and many Forth programmers are
used to coding to that tradition, not the standard.  Which is, I
think, what you're doing.

Andrew.

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

#1424

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>BruceMcF <agila61@netscape.net> wrote:
>> Yes, that is the problem with the specification: not that it fails
>> to specify that, but that it specifies it in a way that someone
>> applying a specific stereotype may misinterpret.
>
>That's the problem I'm pointing to.  Most Forth implementors just
>"know" how it should be done.

That's common practice then.  That's what the standard is supposed to
codify.

>I wonder what would happen if someone
>not steeped in Forth tradition implemented the langauge from the
>standard; I wonder how many supposedly standard programs would cease
>to work.

It's not the programs that would not work, it's the system.

>> For big systems, if SwiftForth, VFX, gforth, bigforth, and Win32Forth
>> respect it, and for small systems if hForth and CamelForth respect it,
>> and for retro fun if hForth for CP/M and VolksForth64 respect it ...
>
>Well, that's a very different question.  There's a tradition of Forth
>implementations going back decades, and many Forth programmers are
>used to coding to that tradition, not the standard.

So you claim that the standard does not codify common practice in this
area.  Then maybe you should make a proposeal that fixes this mistake
(if it is one), or at least makes things clearer.  But what you
suggested in <76-dnQbZoI8CPhDQnZ2dnUVZ_radnZ2d@supernews.com> is the
exact opposite of that (I'll comment on that posting separately).

- 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 2010: http://www.euroforth.org/ef10/

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

#1426

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>BruceMcF <agila61@netscape.net> wrote:
>>> Yes, that is the problem with the specification: not that it fails
>>> to specify that, but that it specifies it in a way that someone
>>> applying a specific stereotype may misinterpret.
>>
>>That's the problem I'm pointing to.  Most Forth implementors just
>>"know" how it should be done.
> 
> That's common practice then.  That's what the standard is supposed to
> codify.
> 
>>I wonder what would happen if someone not steeped in Forth tradition
>>implemented the langauge from the standard; I wonder how many
>>supposedly standard programs would cease to work.
> 
> It's not the programs that would not work, it's the system.

I don't understand why you say that.  It doesn't seem to make any
sense.  Could you explain a little more?

>>> For big systems, if SwiftForth, VFX, gforth, bigforth, and Win32Forth
>>> respect it, and for small systems if hForth and CamelForth respect it,
>>> and for retro fun if hForth for CP/M and VolksForth64 respect it ...
>>
>>Well, that's a very different question.  There's a tradition of Forth
>>implementations going back decades, and many Forth programmers are
>>used to coding to that tradition, not the standard.
> 
> So you claim that the standard does not codify common practice in
> this area.

No, it doesn't, and deliberately so.  A major goal of ANS Forth, if
not the most important goal, was to liberate the language from
implementation-based specifications such as fig-FORTH.  This is a
feature, not a bug.

> Then maybe you should make a proposeal that fixes this mistake
> (if it is one), or at least makes things clearer.  But what you
> suggested in <76-dnQbZoI8CPhDQnZ2dnUVZ_radnZ2d@supernews.com> is the
> exact opposite of that (I'll comment on that posting separately).

Is there any way to persuade you to provide URLs for messages you
reference?

Andrew.

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

#1431

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>I wonder what would happen if someone not steeped in Forth tradition
>>>implemented the langauge from the standard; I wonder how many
>>>supposedly standard programs would cease to work.
>> 
>> It's not the programs that would not work, it's the system.
>
>I don't understand why you say that.  It doesn't seem to make any
>sense.  Could you explain a little more?

If a system does not follow common practice and breaks programs that
follow common practice, the system is broken, not the programs.

>> So you claim that the standard does not codify common practice in
>> this area.
>
>No, it doesn't, and deliberately so.  A major goal of ANS Forth, if
>not the most important goal, was to liberate the language from
>implementation-based specifications such as fig-FORTH.  This is a
>feature, not a bug.

In those cases where Forth-94 removed guarantees to programs, there
was typically a good reason and a benefit associated with it; e.g., it
removed the guarantee that the cell size is 16 bits in order to
include 32-bit (and later 64-bit systems) in the standard systems,
which in turn allows a wider set of programs.

For the change you suggest, there is no good reason and no benefit;
you had to contrive a hypothetical system (that no one has any reason
to implement) to have an example of a system that would break the
common-practice code.

If you want something cleanear than the somewhat
implementation-oriented approach I suggest in
<news:2011Apr22.194458@mips.complang.tuwien.ac.at>, the way to go
would be to remove the restrictions to programs, i.e., something like:

|Standard programs can store to and fetch from UNUSED aus after HERE.

That would force changing many current systems (they would have to
move these buffers elsewhere), so it may be hard to convince system
implementors to agree with this extension.

<nit-pick>fig-Forth is an implementation, not a specification.</>

>> Then maybe you should make a proposeal that fixes this mistake
>> (if it is one), or at least makes things clearer.  But what you
>> suggested in <76-dnQbZoI8CPhDQnZ2dnUVZ_radnZ2d@supernews.com> is the
>> exact opposite of that (I'll comment on that posting separately).
>
>Is there any way to persuade you to provide URLs for messages you
>reference?

Sure, here it is:
<news:76-dnQbZoI8CPhDQnZ2dnUVZ_radnZ2d@supernews.com> 

(But it may be that your browser is no longer capable of dealing with
the "news:" scheme or that the message has expired on your news server
(or that the browser accesses the wrong news server), so you might
want to fall back to the Google Groups web-based Message-Id seearch.
Here's one way to access it:

http://www.complang.tuwien.ac.at/anton/search.html

Use the second field.

- 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 2010: http://www.euroforth.org/ef10/

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

#1449

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>I wonder what would happen if someone not steeped in Forth tradition
>>>>implemented the langauge from the standard; I wonder how many
>>>>supposedly standard programs would cease to work.
>>> 
>>> It's not the programs that would not work, it's the system.
>>
>>I don't understand why you say that.  It doesn't seem to make any
>>sense.  Could you explain a little more?
> 
> If a system does not follow common practice and breaks programs that
> follow common practice, the system is broken, not the programs.

That's just a restatement, not an explanation.  I don't know why you
believe that.

>>> So you claim that the standard does not codify common practice in
>>> this area.
>>
>>No, it doesn't, and deliberately so.  A major goal of ANS Forth, if
>>not the most important goal, was to liberate the language from
>>implementation-based specifications such as fig-FORTH.  This is a
>>feature, not a bug.
> 
> In those cases where Forth-94 removed guarantees to programs, there
> was typically a good reason and a benefit associated with it; e.g., it
> removed the guarantee that the cell size is 16 bits in order to
> include 32-bit (and later 64-bit systems) in the standard systems,
> which in turn allows a wider set of programs.

Right, and it removed the entitlement to do weird things with the
return stack, which allows more opportunity for implementation
techniques.

> For the change you suggest,

I certainly am not suggesting any change in the programming language,
just saying that what we have in the standard is not clear.

> there is no good reason and no benefit; you had to contrive a
> hypothetical system (that no one has any reason to implement) to
> have an example of a system that would break the common-practice
> code.

Indeed, yes.

> If you want something cleanear than the somewhat
> implementation-oriented approach I suggest in
> <news:2011Apr22.194458@mips.complang.tuwien.ac.at>, the way to go
> would be to remove the restrictions to programs, i.e., something like:
> 
> |Standard programs can store to and fetch from UNUSED aus after HERE.
> 
> That would force changing many current systems (they would have to
> move these buffers elsewhere), so it may be hard to convince system
> implementors to agree with this extension.

That would be bad.

>>Is there any way to persuade you to provide URLs for messages you
>>reference?
> 
> Sure, here it is:
> <news:76-dnQbZoI8CPhDQnZ2dnUVZ_radnZ2d@supernews.com> 
> 
> (But it may be that your browser is no longer capable of dealing with
> the "news:" scheme or that the message has expired on your news server
> (or that the browser accesses the wrong news server), so you might
> want to fall back to the Google Groups web-based Message-Id seearch.
> Here's one way to access it:
> 
> http://www.complang.tuwien.ac.at/anton/search.html
> 
> Use the second field.

I'll take that as a "no", then.

Andrew.

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

#1460

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>I wonder what would happen if someone not steeped in Forth tradition
>>>>>implemented the langauge from the standard; I wonder how many
>>>>>supposedly standard programs would cease to work.
>>>> 
>>>> It's not the programs that would not work, it's the system.
>>>
>>>I don't understand why you say that.  It doesn't seem to make any
>>>sense.  Could you explain a little more?
>> 
>> If a system does not follow common practice and breaks programs that
>> follow common practice, the system is broken, not the programs.
>
>That's just a restatement, not an explanation.  I don't know why you
>believe that.

I don't understand the question.  Could you explain it a little more?

>> In those cases where Forth-94 removed guarantees to programs, there
>> was typically a good reason and a benefit associated with it; e.g., it
>> removed the guarantee that the cell size is 16 bits in order to
>> include 32-bit (and later 64-bit systems) in the standard systems,
>> which in turn allows a wider set of programs.
>
>Right, and it removed the entitlement to do weird things with the
>return stack, which allows more opportunity for implementation
>techniques.

Yes, and already before Forth-94 there were systems that did not
support these "weird things" (at least not portably), even very
popular ones like F-PC (with two-cell return addresses) and reportedly
8051 Forths (where AFAIUI return addresses were not on the
user-visible return stack or something).  I.e., not common practice
(but maybe borderline).

>>>Is there any way to persuade you to provide URLs for messages you
>>>reference?
>> 
>> Sure, here it is:
>> <news:76-dnQbZoI8CPhDQnZ2dnUVZ_radnZ2d@supernews.com> 
>> 
>> (But it may be that your browser is no longer capable of dealing with
>> the "news:" scheme or that the message has expired on your news server
>> (or that the browser accesses the wrong news server), so you might
>> want to fall back to the Google Groups web-based Message-Id seearch.
>> Here's one way to access it:
>> 
>> http://www.complang.tuwien.ac.at/anton/search.html
>> 
>> Use the second field.
>
>I'll take that as a "no", then.

You asked for a URL, I gave you one.  If you want something else, be
more specific.

- 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 2010: http://www.euroforth.org/ef10/

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

#1463

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>I wonder what would happen if someone not steeped in Forth tradition
>>>>>>implemented the langauge from the standard; I wonder how many
>>>>>>supposedly standard programs would cease to work.
>>>>> 
>>>>> It's not the programs that would not work, it's the system.
>>>>
>>>>I don't understand why you say that.  It doesn't seem to make any
>>>>sense.  Could you explain a little more?
>>> 
>>> If a system does not follow common practice and breaks programs that
>>> follow common practice, the system is broken, not the programs.
>>
>>That's just a restatement, not an explanation.  I don't know why you
>>believe that.
> 
> I don't understand the question.  Could you explain it a little more?

Why do you believe that if an ANS Forth system does not follow common
practice and breaks programs that follow common practice, there is
something wrong with the system?

>>>>Is there any way to persuade you to provide URLs for messages you
>>>>reference?
>>> 
>>> Sure, here it is:
>>> <news:76-dnQbZoI8CPhDQnZ2dnUVZ_radnZ2d@supernews.com> 
>>> 
>>> (But it may be that your browser is no longer capable of dealing with
>>> the "news:" scheme or that the message has expired on your news server
>>> (or that the browser accesses the wrong news server), so you might
>>> want to fall back to the Google Groups web-based Message-Id seearch.
>>> Here's one way to access it:
>>> 
>>> http://www.complang.tuwien.ac.at/anton/search.html
>>> 
>>> Use the second field.
>>
>>I'll take that as a "no", then.
> 
> You asked for a URL, I gave you one.  If you want something else, be
> more specific.

Ah, yeah.  :-)  A URL that a browser, say Firefox, can handle.  Here is
a good example of a useful URL for the news: URL above:

https://groups.google.com/group/comp.lang.forth/msg/29b49804b9d8e8f0

Andrew.

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

#1462

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> For the change you suggest,
>
>I certainly am not suggesting any change in the programming language,
>just saying that what we have in the standard is not clear.

You suggested <news:76-dnQbZoI8CPhDQnZ2dnUVZ_radnZ2d@supernews.com>:

|I'd simply make it clear that using HERE before it was allotted was
|nonstandard

- 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 2010: http://www.euroforth.org/ef10/

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

#1464

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> For the change you suggest,
>>
>>I certainly am not suggesting any change in the programming language,
>>just saying that what we have in the standard is not clear.
> 
> You suggested <news:76-dnQbZoI8CPhDQnZ2dnUVZ_radnZ2d@supernews.com>:
> 
> |I'd simply make it clear that using HERE before it was allotted was
> |nonstandard

That was intended to be a clarification rather than a substantive
change.  It is not my intention to restrict an ANS programmer in any
way that they are not already restricted, and I am sorry that my words
may have been read in that way.

Andrew.

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

#1436

On Apr 22, 2:05 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

> > So you claim that the standard does not codify common practice in
> > this area.

> No, it doesn't, and deliberately so.  A major goal of ANS Forth, if
> not the most important goal, was to liberate the language from
> implementation-based specifications such as fig-FORTH.  This is a
> feature, not a bug.

But the misreading is a bug due to reading the standard as if it were
an implementation standard.

That is, "when it says that system words cannot touch the content of
PAD, but can change the location, it doesn't mean that as a *result*
of executing the system word, it means that when you are *writing* the
system word, you have to change the location *first*, and then later
on in the system word you are free to change the contents".

That's only the *implementation of* the system word that has that
sequence of actions: *the behavior that it implements* is to modify
the contents of PAD, which is forbidden by the standard.

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

#1434

On Apr 22, 12:12 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> > The entire "seeming contradiction" comes from reading one part of a
> > single section and interpreting it in a way that would indeed seem
> > valid unless detailed more completely elsewhere ... and skipping the
> > fact that its detailed more completely for one specific region two
> > paragraphs later in the same section.  It may be my opinion, but its
> > my opinion about what the text *says*, not my opinion about what the
> > text implies.

> No disagreement there.

> > The apparent contradiction only occurs due to careless reading, but
> > that in itself is a problem with the way the specification is stated.

> OK, so we at least agree that some clarification is required.

I think that clarification would be useful, on the basis of the
misreading presented in this discussion.

Since I do not see any argument based on the *text* of the standard
that this would be a substantial change, but rather arguments that
bypass the specifics of what the text says to infer implications from
incomplete portions of sections ... I don't *know* that its required.

> > ... if the implementer is looking that aggressively for loopholes that
> > allow them to take away freedom of action from the user, it seems
> > highly likely that the implementation has taken away my freedom of
> > action in other ways.

> Such as?

I'd expect them to bite me in the behind when I least expected it,
which is why I'd rather not use an implementation where the
implementer is playing the game of "what strained reading of the
standard can I make to break as much existing code as possible".

> > For big systems, if SwiftForth, VFX, gforth, bigforth, and Win32Forth
> > respect it, and for small systems if hForth and CamelForth respect it,
> > and for retro fun if hForth for CP/M and VolksForth64 respect it ...

> Well, that's a very different question.  There's a tradition of Forth
> implementations going back decades, and many Forth programmers are
> used to coding to that tradition, not the standard.  Which is, I
> think, what you're doing.

Of course, wherever possible that is what the standard was trying to
codify. In this case they succeeded in substance, by ruling out system
words modifying the contents of PAD, but they may have done so in a
way that is prone to misinterpretation in the hands of an implementer
eager to take the maximum freedom from the user allowed by the
standard.

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

#1450

BruceMcF <agila61@netscape.net> wrote:
> On Apr 22, 12:12?pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> > The entire "seeming contradiction" comes from reading one part of a
>> > single section and interpreting it in a way that would indeed seem
>> > valid unless detailed more completely elsewhere ... and skipping the
>> > fact that its detailed more completely for one specific region two
>> > paragraphs later in the same section. ?It may be my opinion, but its
>> > my opinion about what the text *says*, not my opinion about what the
>> > text implies.
> 
>> No disagreement there.
> 
>> > The apparent contradiction only occurs due to careless reading, but
>> > that in itself is a problem with the way the specification is stated.
> 
>> OK, so we at least agree that some clarification is required.
> 
> I think that clarification would be useful, on the basis of the
> misreading presented in this discussion.
> 
> Since I do not see any argument based on the *text* of the standard
> that this would be a substantial change, but rather arguments that
> bypass the specifics of what the text says to infer implications from
> incomplete portions of sections ... I don't *know* that its required.

Explicit permission to do what you want to do, much as Elizabeth has
written, would do it.

>> > ... if the implementer is looking that aggressively for loopholes that
>> > allow them to take away freedom of action from the user, it seems
>> > highly likely that the implementation has taken away my freedom of
>> > action in other ways.
> 
>> Such as?
> 
> I'd expect them to bite me in the behind when I least expected it,
> which is why I'd rather not use an implementation where the
> implementer is playing the game of "what strained reading of the
> standard can I make to break as much existing code as possible".

And neither would I, but when writing portable programs that will run
on systems you've never seen and may not yet exist, it makes sense to
apply Postel's principle:

Be conservative in what you send; be liberal in what you accept.

Which, in this case, means that if you program for "the devil's
implementation" of Forth, one that satisfies the letter of the law,
but is as perversely written as possible, your program will be robust
even in the presence of occasional foibles of implementation.

>> > For big systems, if SwiftForth, VFX, gforth, bigforth, and Win32Forth
>> > respect it, and for small systems if hForth and CamelForth respect it,
>> > and for retro fun if hForth for CP/M and VolksForth64 respect it ...
> 
>> Well, that's a very different question. ?There's a tradition of Forth
>> implementations going back decades, and many Forth programmers are
>> used to coding to that tradition, not the standard. ?Which is, I
>> think, what you're doing.
> 
> Of course, wherever possible that is what the standard was trying to
> codify. In this case they succeeded in substance, by ruling out system
> words modifying the contents of PAD, but they may have done so in a
> way that is prone to misinterpretation in the hands of an implementer
> eager to take the maximum freedom from the user allowed by the
> standard.

OK.  Now we're getting somewhere.

Andrew.

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

#1461

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>BruceMcF <agila61@netscape.net> wrote:
>And neither would I, but when writing portable programs that will run
>on systems you've never seen and may not yet exist, it makes sense to
>apply Postel's principle:
>
>Be conservative in what you send; be liberal in what you accept.

Maybe so, but that's not a good basis for designing standards.

>Which, in this case, means that if you program for "the devil's
>implementation" of Forth, one that satisfies the letter of the law,
>but is as perversely written as possible, your program will be robust
>even in the presence of occasional foibles of implementation.

Sure, that may be heaven for language lawyers, but in practice most
programmers write programs such that they work on the real systems
they expect their program to be used with.  And that's the sane
approach, because there is no test whether a program will work on a
"devil's implementation".  E.g., As a result, most portable Forth code
assumes 1 chars=1, because all maintained systems implement that, we
cannot test code that tries to cater for the "devil's system" in this
area.

If you change the standard in the way you suggested ("I'd simply make
it clear that using HERE before it was allotted was nonstandard"),
there would be no way for programmers to test whether their program
violates this restriction.  So this suggested change would make
standard Forth more of a language for language lawyers than for
programmers than it is now.  Not a good direction to take.

- 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 2010: http://www.euroforth.org/ef10/

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

#1466

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>BruceMcF <agila61@netscape.net> wrote:
>>And neither would I, but when writing portable programs that will run
>>on systems you've never seen and may not yet exist, it makes sense to
>>apply Postel's principle:
>>
>>Be conservative in what you send; be liberal in what you accept.
> 
> Maybe so, but that's not a good basis for designing standards.

No, but it's a really, really good way to write portable programs.

>>Which, in this case, means that if you program for "the devil's
>>implementation" of Forth, one that satisfies the letter of the law,
>>but is as perversely written as possible, your program will be robust
>>even in the presence of occasional foibles of implementation.
> 
> Sure, that may be heaven for language lawyers, but in practice most
> programmers write programs such that they work on the real systems
> they expect their program to be used with. 

This has nothing to do with language lawyers, but about writing robust
portable programs.

> And that's the sane approach, because there is no test whether a
> program will work on a "devil's implementation".  E.g., As a result,
> most portable Forth code assumes 1 chars=1, because all maintained
> systems implement that, we cannot test code that tries to cater for
> the "devil's system" in this area.

That's good practice: it makes sense to program for a somewhat
modified standard, with 1 chars=1.

> If you change the standard in the way you suggested ("I'd simply make
> it clear that using HERE before it was allotted was nonstandard"),
> there would be no way for programmers to test whether their program
> violates this restriction.

You can't test for portability on a single system anyway, so this is a
complete red herring.

> So this suggested change would make standard Forth more of a
> language for language lawyers than for programmers than it is now.
> Not a good direction to take.

As above: I don't think this has anything to do with language
lawyering.

Andrew.

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

#1544

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>BruceMcF <agila61@netscape.net> wrote:
>>>And neither would I, but when writing portable programs that will run
>>>on systems you've never seen and may not yet exist, it makes sense to
>>>apply Postel's principle:
>>>
>>>Be conservative in what you send; be liberal in what you accept.
>> 
>> Maybe so, but that's not a good basis for designing standards.
>
>No, but it's a really, really good way to write portable programs.

Maybe.  But writing programs to comply with an interpretation of a
standard that cannot be tested without implementing a new system (the
"devil's system") is not practical and therefore not a good way; it
also does not increase the real-world portability in any way.

>>>Which, in this case, means that if you program for "the devil's
>>>implementation" of Forth, one that satisfies the letter of the law,
>>>but is as perversely written as possible, your program will be robust
>>>even in the presence of occasional foibles of implementation.
>> 
>> Sure, that may be heaven for language lawyers, but in practice most
>> programmers write programs such that they work on the real systems
>> they expect their program to be used with. 
>
>This has nothing to do with language lawyers, but about writing robust
>portable programs.

"Letter of the law" has everything to do with language lawyers.

It also has nothing to do with writing robust portable programs.  As
an example, in classical C,

n<n-1

is an efficient test for checking whether x was the smallest number of
its type (and that's even true for ones-complement and sign-magnitude
arithmetic).  In ANSI C, this is only guaranteed for unsigned numbers,
and gcc -O, the devil's implementation, goes ahead and "optimizes"
this to "0".  Now a language lawyer told me that I could write

n < (long)(((unsigned long)n)-1)

instead to get the C compiler to produce the code I want while
"satisfying the letter of the law".  So I try this with the devil's
implementation and find: gcc 2.95, 3.3 and 3.4 all produce 0 with -O
for both code variants and produce the intended code (apart from quite
a bit of inefficiency) without -O for both variants of the code.  Only
gcc 4.1 (among the gcc versions I tested) works as the language lawyer
promised.

In conclusion, I did not get a robust and portable program by
satisfying the letter of the law.

>> And that's the sane approach, because there is no test whether a
>> program will work on a "devil's implementation".  E.g., As a result,
>> most portable Forth code assumes 1 chars=1, because all maintained
>> systems implement that, we cannot test code that tries to cater for
>> the "devil's system" in this area.
>
>That's good practice: it makes sense to program for a somewhat
>modified standard, with 1 chars=1.

And in all maintained systems UNUSED bytes after here are accessible,
so anything else cannot be tested.

>> If you change the standard in the way you suggested ("I'd simply make
>> it clear that using HERE before it was allotted was nonstandard"),
>> there would be no way for programmers to test whether their program
>> violates this restriction.
>
>You can't test for portability on a single system anyway, so this is a
>complete red herring.

I am not sure why you bring up a red herring only to denounce it as
such.  To be clear: Nobody but you has talked about testing on a
single system.

- 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 2010: http://www.euroforth.org/ef10/

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web