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

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

"comus" words

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

Contents

  "comus" words "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-18 20:55 -0500
    Re: "comus" words "Elizabeth D. Rather" <erather@forth.com> - 2012-11-18 16:28 -1000
    Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-19 20:14 +1100
      Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-19 07:20 -0800
        Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-20 16:30 +1100
          Re: "comus" words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-20 10:22 +0000
            Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-22 01:59 +1100
              Re: "comus" words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-21 09:34 -0600
              Re: "comus" words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-21 15:34 +0000
                Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-23 13:56 +1100
                  Re: "comus" words "Elizabeth D. Rather" <erather@forth.com> - 2012-11-22 19:21 -1000
                    Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-24 12:14 +1100
                      Re: "comus" words "Elizabeth D. Rather" <erather@forth.com> - 2012-11-23 17:21 -1000
                        Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-25 18:37 +1100
                          Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-25 02:38 -0800
                            Re: "comus" words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-25 05:11 -0600
                              Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-25 03:33 -0800
                                Re: "comus" words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-25 05:45 -0600
                                  Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-25 10:47 -0800
                                    Re: "comus" words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-25 16:05 -0600
                                      Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-26 04:06 -0800
                                      Re: "comus" words albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-26 15:12 +0000
                              Re: "comus" words "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-26 04:56 -0500
                                Re: "comus" words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-26 05:16 -0600
                                Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-26 03:51 -0800
                                  Re: "comus" words "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-27 07:29 -0500
                                    Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-27 11:05 -0800
                                      Re: "comus" words "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-28 07:09 -0500
                                        Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-28 10:13 -0800
                                          Re: "comus" words "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-29 06:09 -0500
                                            Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-29 03:22 -0800
                                        Re: "comus" words Peter Knaggs <pjk@bcs.org.uk> - 2012-11-29 21:32 +0000
                            Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-27 12:44 +1100
                              Re: "comus" words Coos Haak <chforth@hccnet.nl> - 2012-11-27 17:59 +0100
                                Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-29 12:53 +1100
                                  Re: "comus" words Coos Haak <chforth@hccnet.nl> - 2012-11-29 10:59 +0100
                                    Re: "comus" words Mark Wills <forthfreak@gmail.com> - 2012-11-29 02:22 -0800
                                      Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-29 02:58 -0800
                                      Re: "comus" words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-29 05:53 -0600
                                      Re: "comus" words "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 09:38 -1000
                                    Re: "comus" words Andy Valencia <vandys@vsta.org> - 2012-11-29 13:10 +0000
                                      Re: "comus" words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-29 13:52 +0000
                                      Re: "comus" words Mark Wills <forthfreak@gmail.com> - 2012-11-29 06:09 -0800
                                      Re: "comus" words Andy Valencia <vandys@vsta.org> - 2012-11-29 15:43 +0000
                                        Re: "comus" words Coos Haak <chforth@hccnet.nl> - 2012-11-29 21:01 +0100
                                        Re: "comus" words Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-29 23:17 +0100
                                        Re: "comus" words "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 17:01 -1000
                                    Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-30 08:30 +1100
                                      Re: "comus" words Coos Haak <chforth@hccnet.nl> - 2012-11-29 23:06 +0100
                                        Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-30 16:23 +1100
                                  Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-29 03:14 -0800
                                    Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-30 08:31 +1100
                                      Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-29 14:41 -0800
                                        Re: "comus" words "Ed" <invalid@nospam.com> - 2012-11-30 16:19 +1100
                                          Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-30 02:31 -0800
                                            Re: "comus" words "Ed" <invalid@nospam.com> - 2012-12-04 03:53 +1100
                                              Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-12-03 10:45 -0800
                                                Re: "comus" words "Ed" <invalid@nospam.com> - 2012-12-06 18:31 +1100
                                                  Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-12-06 01:37 -0800
                                                    Re: "comus" words albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-12-06 13:31 +0000
                                                      Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-12-06 07:07 -0800
                                    Re: "comus" words "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 17:04 -1000
                                      Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-30 02:29 -0800
    Re: "comus" words Mark Wills <forthfreak@gmail.com> - 2012-11-19 05:33 -0800
    Re: "comus" words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-19 14:45 +0000
    Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-19 07:43 -0800
      Re: "comus" words Alex McDonald <blog@rivadpm.com> - 2012-11-19 07:45 -0800
    Re: "comus" words oh2aun@gmail.com - 2012-11-22 21:10 -0800

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

#17568

On Nov 25, 10:05 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Alex McDonald <b...@rivadpm.com> wrote:
> > On Nov 25, 11:45?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> > wrote:
> >> Alex McDonald <b...@rivadpm.com> wrote:
> >> > On Nov 25, 11:11?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> >> > wrote:
> >> >> Alex McDonald <b...@rivadpm.com> wrote:
>
> >> >> > What is not clear from the Forth200x spec is the address of a null
> >> >> > string; is 0 0 allowed?
>
> >> >> Does it matter? ?Is there any standard program that might be affected
> >> >> in any way?
>
> >> > Yes; /STRING.
>
> >> I don't understand. ?Can you provide a standard program that might be
> >> affected?
>
> > s" A" 1 /string -1 /string should return s" A", but if 1 /string
> > returns 0 0...
>
> Why would it do that?

It doesn't, as I saw on re-reading the below.

>
> > Actually, on re-reading the spec, it would appear that / string
> > can't return 0 0 given the spec; "Adjust the character string at
> > c-addr1 by n characters. The resulting character string, specified
> > by c-addr2 u2, begins at c-addr1 plus n characters and is u1 minus n
> > characters long."
>
> Right.  I'm still guessing that no standard program would be affected
> if 0 were allowed as the address of a 0-length string.  I'm pretty
> sure that 0 is allowed as the address of any string.  IMO it shouldn't
> be, and lots of Forth programs use 0 to mean null, but strictly
> speaking that's an incorrect assumption.
>
> Andrew.

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

#17574

In article <ZuidnQv2SM_fCy_NnZ2dnUVZ8vWdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Alex McDonald <blog@rivadpm.com> wrote:
>> On Nov 25, 11:45?am, Andrew Haley <andre...@littlepinkcloud.invalid>
>> wrote:
>>> Alex McDonald <b...@rivadpm.com> wrote:
>>> > On Nov 25, 11:11?am, Andrew Haley <andre...@littlepinkcloud.invalid>
>>> > wrote:
>>> >> Alex McDonald <b...@rivadpm.com> wrote:
>>>
>>> >> > What is not clear from the Forth200x spec is the address of a null
>>> >> > string; is 0 0 allowed?
>>>
>>> >> Does it matter? ?Is there any standard program that might be affected
>>> >> in any way?
>>>
>>> > Yes; /STRING.
>>>
>>> I don't understand. ?Can you provide a standard program that might be
>>> affected?
>>
>> s" A" 1 /string -1 /string should return s" A", but if 1 /string
>> returns 0 0...
>
>Why would it do that?
>
>> Actually, on re-reading the spec, it would appear that / string
>> can't return 0 0 given the spec; "Adjust the character string at
>> c-addr1 by n characters. The resulting character string, specified
>> by c-addr2 u2, begins at c-addr1 plus n characters and is u1 minus n
>> characters long."
>
>Right.  I'm still guessing that no standard program would be affected
>if 0 were allowed as the address of a 0-length string.  I'm pretty
>sure that 0 is allowed as the address of any string.  IMO it shouldn't
>be, and lots of Forth programs use 0 to mean null, but strictly
>speaking that's an incorrect assumption.

I make good use of the distinction between addr,0 (an empty string)
and nil,xxx ( a null string) in $/ (string slash).
"BAB" &A $/
leaves two string "B"
"A" &A &/
leaves two strings ""
"A" &x &/
leaves a null string and "A"

>
>Andrew.

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

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

#17564

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:bO2dnZM42qd5YSzNnZ2dnUVZ8uydnZ2d@supernews.com...
> Alex McDonald <blog@rivadpm.com> wrote:
> > On Nov 25, 7:38?am, "Ed" <inva...@nospam.com> wrote:
> >>     Table 2.1 - Parsed text abbreviations
> >>
> >>     ccc          a parsed sequence of arbitrary characters, excluding
> >>                     the delimiter character
> >>
> >> As I read it S" is specified to parse and return ccc.  If ccc is
> >> absent and nothing but delimiter characters are present as in the
> >> case of S" " then the result is undefined.
> >
> > [Andrew snipped Alex]
>
> Why?  Are you saying that a parsed sequence cannot be zero-length?
> But 3.4.1, Parsing says " Unless otherwise noted, the number of
> characters parsed may be from zero to the implementation-defined
> maximum length of a counted string."  So that [cannot] be true.
>

No, Ed just has a different interpretation.  I think his interpretation is a
valid interpretation.  I'm not saying I agree that it is correct for what
needs to be done in Forth sense.  But, ones understanding depends on your
understanding of English, inconjuction with the imprecise English in the
specification.  I can come to the same conclusion.  Let's take a look:

"
"Table 2.1 - Parsed text abbreviations
"ccc a parsed sequence of arbitrary characters, excluding
"the delimiter character
"

How do you like this interpretation?  If the size is zero, then ccc is not
"a parsed sequence of arbitrary characters, excluding the delimiter
character", since there are no "arbitrary characters", or any character for
that matter, present in a null string.  So, what is "ccc", if not undefined,
when the length is zero?

"
"The number of characters in ccc may be zero to the number of
"characters in the parse area.
"

Of course, some people interpret "may be zero to the number of ..." to mean
"between zero and the number of ...".  But, that's not what is actually
said.  It doesn't say "between" zero and "the number of characters in the
parse area".  It says "may be" zero.  Well, it "may be" non-zero too.  It
"may be" one to ...  "May be" is imprecise.  It allows for other meanings.
It doesn't say it's required to be zero through some value.  So, this
doesn't require zero to be returned as a valid length.  I.e., some
implementations may generate a minimum length of zero while others may not.
E.g., others may generate a minimum length of one "to the number of
characters in the parse area" and not ever generate a zero.

Do you see it now?  Do you see how the specification's English is open to
multiple interpretations?

To me, it seems that many of these issues are boundary related issues.
I.e., does it start at zero or one, where does it end or wrap, etc.  E.g.
while non-zero values can be ALLOTed since they are quantities, can ALLOT
allocate a quantity of zero when zero is not a quantity?  E.g., does a null
string qualify as "arbitrary characters" since no characters are present?

I recall a number of interpretations of mine that are entirely valid from
the imprecise English of the specification that everyone here disagreed
with.  This isn't a problem with intellect or understanding.  It's a problem
with the wording of the specification.  It can be understood to mean
multiple things.


Rod Pemberton

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

#17565

Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:bO2dnZM42qd5YSzNnZ2dnUVZ8uydnZ2d@supernews.com...
>> Alex McDonald <blog@rivadpm.com> wrote:
>> > On Nov 25, 7:38?am, "Ed" <inva...@nospam.com> wrote:
>> >>     Table 2.1 - Parsed text abbreviations
>> >>
>> >>     ccc          a parsed sequence of arbitrary characters, excluding
>> >>                     the delimiter character
>> >>
>> >> As I read it S" is specified to parse and return ccc.  If ccc is
>> >> absent and nothing but delimiter characters are present as in the
>> >> case of S" " then the result is undefined.
>> >
>> > [Andrew snipped Alex]
>>
>> Why?  Are you saying that a parsed sequence cannot be zero-length?
>> But 3.4.1, Parsing says " Unless otherwise noted, the number of
>> characters parsed may be from zero to the implementation-defined
>> maximum length of a counted string."  So that [cannot] be true.
> 
> No, Ed just has a different interpretation.  I think his interpretation is a
> valid interpretation.  I'm not saying I agree that it is correct for what
> needs to be done in Forth sense.  But, ones understanding depends on your
> understanding of English, inconjuction with the imprecise English in the
> specification.  I can come to the same conclusion.  Let's take a look:
> 
> "
> "Table 2.1 - Parsed text abbreviations
> "ccc a parsed sequence of arbitrary characters, excluding
> "the delimiter character
> "
> 
> How do you like this interpretation?  If the size is zero, then ccc is not
> "a parsed sequence of arbitrary characters, excluding the delimiter
> character", since there are no "arbitrary characters", or any character for
> that matter, present in a null string.

Yes it is, because the definition of "parsing" specifically includes
zero-length strings.

> So, what is "ccc", if not undefined, when the length is zero?

It's a zero-length string.

> "
> "The number of characters in ccc may be zero to the number of
> "characters in the parse area.
> "
> 
> Of course, some people interpret "may be zero to the number of ..."
> to mean "between zero and the number of ...". 

Well, yes.

> But, that's not what is actually said.  It doesn't say "between"
> zero and "the number of characters in the parse area".  It says "may
> be" zero. 

Yes.  A standard Forth program may contain zero-length strings to be
parsed.

> Well, it "may be" non-zero too. 

Indeed; that depends on the program.

> It "may be" one to ...  "May be" is imprecise.  It allows for other
> meanings.  It doesn't say it's required to be zero through some
> value.

It says that the string may be zero-length.

> So, this doesn't require zero to be returned as a valid length.

Yes it does.  That's where you're making a mistake.  The standard
provides the writer of a standard Forth program the permission to use
zero-length strings in ( ) .  It doesn't compel them to do so: that's
why the word "may" is used.

Anywhere the standard gives a programmer permission, a standard
implementation is required to behave in a conforming way.

> I.e., some implementations may generate a minimum length of zero
> while others may not.  E.g., others may generate a minimum length of
> one "to the number of characters in the parse area" and not ever
> generate a zero.

No, it doesn't mean this.  It specifically allows the programmer of a
Forth system to supply an implementation with a zero-length string, in
which case an implementation must handle it correctly.

> Do you see it now?  Do you see how the specification's English is
> open to multiple interpretations?

In this case, no, I don't.  In my view, this interpretation is only
possible if one reads the specification in an absurdly pedantic (and,
in this case, incorrect) way with the intention of interpreting it in
a way that is at odds with what was intended by the writers.  While we
(the TC) could go through the standard looking for all the places
where perverse individuals could misinterpret what is written, this
would be a waste of time because no matter how ingenious our wording,
people could find more things to misinterpret.

> To me, it seems that many of these issues are boundary related
> issues.  I.e., does it start at zero or one, where does it end or
> wrap, etc.  E.g.  while non-zero values can be ALLOTed since they
> are quantities, can ALLOT allocate a quantity of zero when zero is
> not a quantity?  E.g., does a null string qualify as "arbitrary
> characters" since no characters are present?
> 
> I recall a number of interpretations of mine that are entirely valid
> from the imprecise English of the specification that everyone here
> disagreed with.  This isn't a problem with intellect or
> understanding.  It's a problem with the wording of the
> specification.  It can be understood to mean multiple things.

In suspect that you were not reading the standard as a whole, but
instead focusing on one particular phrase.  You can't do that with a
programming language standard: it has to be read as a whole.  In this
case, the intention is clear: in a standard Forth program parsed
strings may be zero-length.

Andrew.

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

#17566

On Nov 26, 9:52 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Andrew Haley" <andre...@littlepinkcloud.invalid> wrote in message
>
> news:bO2dnZM42qd5YSzNnZ2dnUVZ8uydnZ2d@supernews.com...
>
>
>
>
>
>
>
>
>
> > Alex McDonald <b...@rivadpm.com> wrote:
> > > On Nov 25, 7:38?am, "Ed" <inva...@nospam.com> wrote:
> > >>     Table 2.1 - Parsed text abbreviations
>
> > >>     ccc          a parsed sequence of arbitrary characters, excluding
> > >>                     the delimiter character
>
> > >> As I read it S" is specified to parse and return ccc.  If ccc is
> > >> absent and nothing but delimiter characters are present as in the
> > >> case of S" " then the result is undefined.
>
> > > [Andrew snipped Alex]
>
> > Why?  Are you saying that a parsed sequence cannot be zero-length?
> > But 3.4.1, Parsing says " Unless otherwise noted, the number of
> > characters parsed may be from zero to the implementation-defined
> > maximum length of a counted string."  So that [cannot] be true.
>
> No, Ed just has a different interpretation.  I think his interpretation is a
> valid interpretation.  I'm not saying I agree that it is correct for what
> needs to be done in Forth sense.  But, ones understanding depends on your
> understanding of English, inconjuction with the imprecise English in the
> specification.  I can come to the same conclusion.  Let's take a look:
>
> "
> "Table 2.1 - Parsed text abbreviations
> "ccc a parsed sequence of arbitrary characters, excluding
> "the delimiter character
> "
>
> How do you like this interpretation?  If the size is zero, then ccc is not
> "a parsed sequence of arbitrary characters, excluding the delimiter
> character", since there are no "arbitrary characters", or any character for
> that matter, present in a null string.  So, what is "ccc", if not undefined,
> when the length is zero?
>
> "
> "The number of characters in ccc may be zero to the number of
> "characters in the parse area.
> "
>
> Of course, some people interpret "may be zero to the number of ..." to mean
> "between zero and the number of ...".  But, that's not what is actually
> said.  It doesn't say "between" zero and "the number of characters in the
> parse area".  It says "may be" zero.  Well, it "may be" non-zero too.  It
> "may be" one to ...  "May be" is imprecise.  It allows for other meanings.
> It doesn't say it's required to be zero through some value.  So, this
> doesn't require zero to be returned as a valid length.  I.e., some
> implementations may generate a minimum length of zero while others may not.
> E.g., others may generate a minimum length of one "to the number of
> characters in the parse area" and not ever generate a zero.

In which case you would not include a negative length with that
interpretation?

>
> Do you see it now?  Do you see how the specification's English is open to
> multiple interpretations?

Yes, but all specifications have these problems to one degree or
another, since they are written for humans and not machines.
Translation requires an understanding of the intent too; Ed and you
see the intent as excluding null strings, and if this had been raised
during the spec writing process, it would no doubt have resulted in
any of: (a) an explanation in a non-normative annex (b) a rejection on
the basis that the words were clear and understood by the vast
majority to exclude your interpretation (c) a re-write of the
normative words in tighter language (see below).

>
> To me, it seems that many of these issues are boundary related issues.
> I.e., does it start at zero or one, where does it end or wrap, etc.  E.g.
> while non-zero values can be ALLOTed since they are quantities, can ALLOT
> allocate a quantity of zero when zero is not a quantity?  E.g., does a null
> string qualify as "arbitrary characters" since no characters are present?

Zero has been a quantity since the 8th century. It is distinct from a
null or nothingness -- although many programming languages, like
Forth, cannot represent it and use zero. For those languages, we
compromise and represent null by convention as a zero quantity of some
type. In Forth by definition a string is two numbers taken to be an
address and a non-negative length; an empty or null string (note --
not a true null) is represented with a length of zero. Since 0 is a
quantity, 0 ALLOT is acceptable; the zero refers to a quantity of
address units, not "nothingness".

Shorter form; in Forth, nothing of something is represented by 0 of
something, and a true null or nothingness can't be represented.


>
> I recall a number of interpretations of mine that are entirely valid from
> the imprecise English of the specification that everyone here disagreed
> with.  This isn't a problem with intellect or understanding.  It's a problem
> with the wording of the specification.  It can be understood to mean
> multiple things.
>
> Rod Pemberton

In terms of RFC2119 (which postdates the Forth ANSI spec, so the
ambiguity in that spec is forgivable) "MAY" is tightly defined, as is
"SHALL". To use the language in that RFC to rewrite; "The number of
characters in ccc shall be zero to the number of characters in the
parse area".

Not that this is a good description, or properly placed in the spec.
There are a number of areas where reading of several scattered parts
is required to make sense of a single question, as in this case.

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

#17600

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:48482d40-448c-4692-acc0-bdca6fa59050@y6g2000vbb.googlegroups.com...
> On Nov 26, 9:52 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
> wrote:
...

> > Do you see it now? Do you see how the specification's English
> > is open to multiple interpretations?
>
> Yes, but all specifications have these problems to one degree or
> another, since they are written for humans and not machines.
> Translation requires an understanding of the intent too;

Correct.  And where should that intent be correctly specified?  It should
be specified in the language of the specification, of course.  If not, the
specification is worthless, as I just demonstrated ...  The sample
interpretation used standard Computer Science definitions and common
English to come to a conclusion almost no one here agrees with.

> Ed and you see the intent as excluding null strings, [...]

No, I don't.  As stated, that was for example only.  I'm not sure why both
you and Andrew always ignore that examples clearly stated as examples
are only examples.

I can come to either interpretation, but the "correct" interpretation
according to everyone posting in this thread is not what is *actually*
stated in the specification, i.e., the intent was lost due to rather poor
wording.  It seems that only those who already know the intent in advance
can "correctly" understand the specification.  I.e., the specification is
worthless except to those who don't need it.  Isn't the specification
supposed to define the intent for those who are unaware of it?  If not,
what's the point?

> > To me, it seems that many of these issues are boundary related issues.
> > I.e., does it start at zero or one, where does it end or wrap, etc. E.g.
> > while non-zero values can be ALLOTed since they are quantities, can
> > ALLOT allocate a quantity of zero when zero is not a quantity? E.g.,
> > does a null string qualify as "arbitrary characters" since no characters
> > are present?
>
> Zero has been a quantity since the 8th century.

Zero has been a number for a long time, but it's never been a quantity.

> [Zero] is distinct from a null or nothingness -- [...]

Are you sure about that?  E.g.,

"Zero is a number which quantifies a count or an amount of null size."
http://en.wikipedia.org/wiki/Zero

AIR, the definition of null or nothingness has three different standard
meanings, but only one is used by programmers.  Unfortunately, I've been
unable to locate that article for some years now...

> [...] although many programming languages, like
> Forth, cannot represent [null or nothingness] and use zero. For those
> languages, we compromise and represent null by convention as a zero
> quantity of some type.

Null is frequently represented as a syntactical "zero".  However, 1) a
syntactical "zero" isn't required to be the number zero, and 2) a
syntactical "zero" can be any number including a non-quantity number
such as zero.

E.g., for C, a null pointer is any value which doesn't point to or within a
valid C object.  On many systems, it's set to zero since code can't be
placed at address zero on many systems.  However, null can be non-zero in C
for systems that place code at address zero.  Null must just not compare as
equal to any valid C pointer or object, or point into a valid C object, or
point one past the end of a C string ...

E.g., D.A. Gwyn (ANSI C) example of non-zero null in C:
http://groups.google.com/group/comp.std.c/msg/a755c07e5c78df26

> In Forth by definition a string is two numbers
> taken to be an address and a non-negative length; [...]

You know full well that Forth also has counted strings too, where a string
only needs an address for to be fully specified.

> In Forth by definition a string is two numbers
> taken to be an address and a non-negative length; an empty or null string
> (note -- not a true null) is represented with a length of zero.

I don't disagree with that.

The issue was whether the specification accurately states that a string of
length zero is required to be returned for parsing of 'ccc'.  It doesn't.
Someone can understand it to mean that some systems do return null strings
of length zero while others don't, i.e., "may".

> Since 0 is a quantity, 0 ALLOT is acceptable; the zero
> refers to a quantity of address units, not "nothingness".

Zero isn't a quantity.  Please give me zero apples.  Once you've done so, I
expect to have some apples, not none.  Where are my apples?  With zero, I
won't have any apples.  I'd have none.  I.e., zero isn't a quantity.  It's a
number.

> In terms of RFC2119 (which postdates the Forth ANSI spec, so the
> ambiguity in that spec is forgivable) "MAY" is tightly defined, as is
> "SHALL". To use the language in that RFC to rewrite; "The number of
> characters in ccc shall be zero to the number of characters in the
> parse area".

RFC2119 is utterly irrelevant in regards to Forth ANSI specification.

Even so, I don't see where you could arrive at the conclusion that
RFC2119 conflates or equates "MAY" with "SHALL".

RFC2119's definition of "MAY":

"5. MAY   This word, or the adjective 'OPTIONAL', mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)"

RFC2119's definition of "SHALL":

"1. MUST   This word, or the terms 'REQUIRED' or 'SHALL', mean that the
   definition is an absolute requirement of the specification."


The definition of "MAY" above corresponds to how I used it for the example.
As Ed noted else-thread, Forth 94 defines "may" correctly too, i.e., not as
"shall" ...


Rod Pemberton

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

#17614

On Nov 27, 12:24 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Alex McDonald" <b...@rivadpm.com> wrote in message
>
> news:48482d40-448c-4692-acc0-bdca6fa59050@y6g2000vbb.googlegroups.com...> On Nov 26, 9:52 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
> > wrote:
>
> ...
>
> > > Do you see it now? Do you see how the specification's English
> > > is open to multiple interpretations?
>
> > Yes, but all specifications have these problems to one degree or
> > another, since they are written for humans and not machines.
> > Translation requires an understanding of the intent too;
>
> Correct.  And where should that intent be correctly specified?  It should
> be specified in the language of the specification, of course.  If not, the
> specification is worthless, as I just demonstrated ...  The sample
> interpretation used standard Computer Science definitions and common
> English to come to a conclusion almost no one here agrees with.

The almost no-one is you and Ed. Everyone else believes that it
clearly states that S" " is allowed, and represents the empty string;
for instance, all Forth compiler writers, since there isn't a Forth
compiler that doesn't implement it.

>
> > Ed and you see the intent as excluding null strings, [...]
>
> No, I don't.  As stated, that was for example only.  I'm not sure why both
> you and Andrew always ignore that examples clearly stated as examples
> are only examples.

You said " I can come to the same conclusion [as Ed who stated it
wasn't allowed]" in the bit you snipped. What am I to make of that? If
I were to read your statement the way you and Ed read specs, I'd say
that it wasn't an example; you really think it's wrong, and you argued
for such.

>
> I can come to either interpretation, but the "correct" interpretation
> according to everyone posting in this thread is not what is *actually*
> stated in the specification, i.e., the intent was lost due to rather poor
> wording.  It seems that only those who already know the intent in advance
> can "correctly" understand the specification.  I.e., the specification is
> worthless except to those who don't need it.  Isn't the specification
> supposed to define the intent for those who are unaware of it?  If not,
> what's the point?

I'm with Andrew on this one. Being absurdly perverse and pedantic
might lead you to that conclusion.

>
> > > To me, it seems that many of these issues are boundary related issues.
> > > I.e., does it start at zero or one, where does it end or wrap, etc. E.g.
> > > while non-zero values can be ALLOTed since they are quantities, can
> > > ALLOT allocate a quantity of zero when zero is not a quantity? E.g.,
> > > does a null string qualify as "arbitrary characters" since no characters
> > > are present?
>
> > Zero has been a quantity since the 8th century.
>
> Zero has been a number for a long time, but it's never been a quantity.
>
> > [Zero] is distinct from a null or nothingness -- [...]
>
> Are you sure about that?  E.g.,
>
> "Zero is a number which quantifies a count or an amount of null size."http://en.wikipedia.org/wiki/Zero

Ah, so zero according to Pemberton has never been a quantity but is a
number, but wikipedia uses the word "quantifies" and "count". I see...
Did you read the bit you posted from wikipedia? Seriously, re-read it
and then try and persuade me that you're not on drugs.

>
> AIR, the definition of null or nothingness has three different standard
> meanings, but only one is used by programmers.

Bollocks. I say that wholeheartedly as someone who has written in
languages that support a variety of nulls; nulls of the type null,
null strings, null values, null objects; and empty strings, zero
values, uninitialised objects; and "missing" strings, values and
objects.

> Unfortunately, I've been
> unable to locate that article for some years now...
>
> > [...] although many programming languages, like
> > Forth, cannot represent [null or nothingness] and use zero. For those
> > languages, we compromise and represent null by convention as a zero
> > quantity of some type.
>

[ C digression snipped]

>
> > In Forth by definition a string is two numbers
> > taken to be an address and a non-negative length; [...]
>
> You know full well that Forth also has counted strings too, where a string
> only needs an address for to be fully specified.

Double bollocks, and now you're swimming around in diversionary
nonsense. A counted string has a (duh) count. It just happens to be in
the first address unit.

>
> > In Forth by definition a string is two numbers
> > taken to be an address and a non-negative length; an empty or null string
> > (note -- not a true null) is represented with a length of zero.
>
> I don't disagree with that.
>
> The issue was whether the specification accurately states that a string of
> length zero is required to be returned for parsing of 'ccc'.  It doesn't.
> Someone can understand it to mean that some systems do return null strings
> of length zero while others don't, i.e., "may".

Drugs again?

>
> > Since 0 is a quantity, 0 ALLOT is acceptable; the zero
> > refers to a quantity of address units, not "nothingness".
>
> Zero isn't a quantity.  Please give me zero apples.  Once you've done so, I
> expect to have some apples, not none.  Where are my apples?  With zero, I
> won't have any apples.  I'd have none.  I.e., zero isn't a quantity.  It's a
> number.

Contradicting your wikipedia sourced support.

>
> > In terms of RFC2119 (which postdates the Forth ANSI spec, so the
> > ambiguity in that spec is forgivable) "MAY" is tightly defined, as is
> > "SHALL". To use the language in that RFC to rewrite; "The number of
> > characters in ccc shall be zero to the number of characters in the
> > parse area".
>
> RFC2119 is utterly irrelevant in regards to Forth ANSI specification.

As are you.


[snipped]

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

#17628

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:670efa3a-4772-49c0-bfb9-90ac40de429a@g6g2000vbk.googlegroups.com...
> On Nov 27, 12:24 pm, "Rod Pemberton"
<do_not_h...@notemailnotz.cnm>
> wrote:
...

> > No, I don't. As stated, that was for example only. I'm not
> > sure why both you and Andrew always ignore that examples
> > clearly stated as examples are only examples.
>
> You said " I can come to the same conclusion [as Ed who stated
> it wasn't allowed]" in the bit you snipped. What am I to make of
> that?

I also said: "I'm not saying I agree that it is correct for what
needs to be done in Forth sense." as well as other disclaimers.

> If I were to read your statement the way you and Ed read specs,
> I'd say that it wasn't an example; you really think it's wrong,
> and you argued for such.

No, I just demonstrated (or attempted to, apparently I failed ...)
that what the specification says can be validly understood in a
manner different from what you or others think or keep stating is
correct.

> > I can come to either interpretation, but the "correct"
> > interpretation according to everyone posting in this thread
> > is not what is *actually* stated in the specification, i.e.,
> > the intent was lost due to rather poor wording. It seems that
> > only those who already know the intent in advance
> > can "correctly" understand the specification. I.e., the
> > specification is worthless except to those who don't need it.
> > Isn't the specification supposed to define the intent for
> > those who are unaware of it?  If not, what's the point?
>
> I'm with Andrew on this one. Being absurdly perverse and
> pedantic might lead you to that conclusion.
>

I don't need to understand Forth to understand fig-Forth or
Forth-83.  So, why does one need to understand Forth to understand
the ANS Forth specification?  That's the core of the issue.  So,
sorry, I don't see the issue as being perverse, pedantic, or
contrived.  I see the issue as a rather poorly worded
specification.

> > > > To me, it seems that many of these issues are boundary
> > > > related issues.  I.e., does it start at zero or one, where
> > > > does it end or wrap, etc. E.g. while non-zero values
> > > > can be ALLOTed since they are quantities, can
> > > > ALLOT allocate a quantity of zero when zero is not a
> > > > quantity? E.g., does a null string qualify as "arbitrary
> > > > characters" since no characters are present?
>
> > > Zero has been a quantity since the 8th century.
>
> > Zero has been a number for a long time, but it's never been
> > a quantity.
>
> > > [Zero] is distinct from a null or nothingness -- [...]
>
> > Are you sure about that? E.g.,
>
> > "Zero is a number which quantifies a count or an amount of
> > null size.
>
> Ah, so zero according to Pemberton has never been a quantity but
> is a number, but wikipedia uses the word "quantifies" and
> "count".  I see...

The fact that McDonald conflates "quantity" and "quantifies" and
take "count" out of context to support his position seems to be
an issue ...

Also, the fact they're lacking in accuracy, need a thesaurus, or
don't have more precise mathematical terms, is not my problem.
It's clear they wanted a definition anyone could understand.  As
far as I know, a child could've posted that definition ...

> Did you read the bit you posted from wikipedia? Seriously,
> re-read it and then try and persuade me that you're not
> [insult].

Since you've now accepted Wikipedia's flaky definition as valid,
apparently, you re-read it and seriously try to persuade me "zero
is distinct from a null" as you've claimed.  As you said to me,
please stop diverting.  ;-)

(Personally, I'm surprised you didn't argue against their layman's
definition...  I would've.  It sucks.  I don't think that's a very
good definition at all.)

> > AIR, the definition of null or nothingness has three different
> > standard meanings, but only one is used by programmers.
>
> Bollocks.

Bullshit?  Really?  I think your insults may apply to you...

> I say that wholeheartedly as someone who has written
> in languages that support a variety of nulls; nulls of the type
> null, null strings, null values, null objects; and empty
> strings, zero values, uninitialised objects; and "missing"
> strings, values and objects.

As stated previously, null's are not necessarily zero values.
Sometimes null's are just syntax for non-zero values or other
special cases.

Most languages represent objects as pointers or addresses.  So,
saying "uninitialised objects" or "null objects" is different from
"null values" is utterly meaningless.

In actuality, there are only two different _implementations_ of
null listed by you above.  They both have the same *meaning* or
definition: "empty" or "not valid".

> > > In Forth by definition a string is two numbers
> > > taken to be an address and a non-negative length; [...]
>
> > You know full well that Forth also has counted strings too,
> > where a string only needs an address for [it] to be
> > fully specified.
>
> Double bollocks, and now you're swimming around in
> diversionary nonsense.

So, your insults and foul language aren't diversionary nonsense?

> A counted string has a (duh) count. It just happens to
> be in the first address unit.

Yes, a counted string has a count (duh), but a count doesn't need
to be passed around or maintained in a table in order to describe
the string.  The count is a component of the string.  I.e., only
an address is needed to represent a counted string.  COUNT obtains
the count - from the string - when needed.

> > > In Forth by definition a string is two numbers taken to be
> > > an address and a non-negative length; an empty or null
> > > string (note -- not a true null) is represented with a
> > > length of zero.
> >
> > I don't disagree with that.
>
> > The issue was whether the specification accurately states that
> > a string of length zero is required to be returned for parsing
> > of 'ccc'. It doesn't.  Someone can understand it to mean that
> > some systems do return null strings of length zero while
> > others don't, i.e., "may".
>
> [insult]

No, I just speak and comprehend American English.

> > > Since 0 is a quantity, 0 ALLOT is acceptable; the zero
> > > refers to a quantity of address units, not "nothingness".
>
> > Zero isn't a quantity. Please give me zero apples. Once you've
> > done so, I expect to have some apples, not none. Where are my
> > apples? With zero, I won't have any apples. I'd have none.
> > I.e., zero isn't a quantity. It's a number.
>
> Contradicting your wikipedia sourced support.

Not true.

> > > In terms of RFC2119 (which postdates the Forth ANSI spec, so
> > > the ambiguity in that spec is forgivable) "MAY" is tightly
> > > defined, as is "SHALL". To use the language in that RFC to
> > > rewrite; "The number of characters in ccc shall be zero to
> > > the number of characters in the parse area".
>
> > RFC2119 is utterly irrelevant in regards to Forth ANSI
> > specification.
>
> [insult]

Despite the incorrect unsnipped statement above, RFC2119 supports
my position ...  If you knew that, why did you bring it up?


Rod Pemberton
BTW, I don't think I insulted you any ... food for thought.

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

#17644

On Nov 28, 12:09 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:
> "Alex McDonald" <b...@rivadpm.com> wrote in message
>
> news:670efa3a-4772-49c0-bfb9-90ac40de429a@g6g2000vbk.googlegroups.com...> On Nov 27, 12:24 pm, "Rod Pemberton"
>
> <do_not_h...@notemailnotz.cnm>> wrote:
[snip]
>
> > > I can come to either interpretation, but the "correct"
> > > interpretation according to everyone posting in this thread
> > > is not what is *actually* stated in the specification, i.e.,
> > > the intent was lost due to rather poor wording. It seems that
> > > only those who already know the intent in advance
> > > can "correctly" understand the specification. I.e., the
> > > specification is worthless except to those who don't need it.
> > > Isn't the specification supposed to define the intent for
> > > those who are unaware of it?  If not, what's the point?
>
> > I'm with Andrew on this one. Being absurdly perverse and
> > pedantic might lead you to that conclusion.
>
> I don't need to understand Forth to understand fig-Forth or
> Forth-83.  So, why does one need to understand Forth to understand
> the ANS Forth specification?  That's the core of the issue.  So,
> sorry, I don't see the issue as being perverse, pedantic, or
> contrived.  I see the issue as a rather poorly worded
> specification.

One simply needs to understand that "the car may crash" indicates that
a crashed car is possible. "The number of characters in ccc may be
zero to the number of characters in the parse area" indicates that
zero characters is possible and valid. How hard is that?

[snip]

>
> Since you've now accepted Wikipedia's flaky definition as valid,
> apparently, you re-read it and seriously try to persuade me "zero
> is distinct from a null" as you've claimed.  As you said to me,
> please stop diverting.  ;-)
>
> (Personally, I'm surprised you didn't argue against their layman's
> definition...  I would've.  It sucks.  I don't think that's a very
> good definition at all.)


Then please stop quoting material in which you have no faith in
support of your argument.


>
> > > AIR, the definition of null or nothingness has three different
> > > standard meanings, but only one is used by programmers.
>
> > Bollocks.
>
> Bullshit?  Really?  I think your insults may apply to you...

The word is not considered rude where I come from. Translate it into
American as "nuts". http://www.heraldscotland.com/never-mind-the-sex-pistols-here-s-to-30-years-of-bollocks-1.830856

> > I say that wholeheartedly as someone who has written
> > in languages that support a variety of nulls; nulls of the type
> > null, null strings, null values, null objects; and empty
> > strings, zero values, uninitialised objects; and "missing"
> > strings, values and objects.
>
> As stated previously, null's are not necessarily zero values.
> Sometimes null's are just syntax for non-zero values or other
> special cases.
>
> Most languages represent objects as pointers or addresses.  So,
> saying "uninitialised objects" or "null objects" is different from
> "null values" is utterly meaningless.

See below.

>
> In actuality, there are only two different _implementations_ of
> null listed by you above.  They both have the same *meaning* or
> definition: "empty" or "not valid".

There are languages that support several types of "nulls". Assume X
and Y;

print(x)         <-- exception thrown as the value is a null

x=null
print(x)         <-- exception thrown as x is still a null
print(typeof(x)) <-- prints "null"
y=x              <-- exception thrown as the value of x is null

x=""             <-- set x to the empty string
print(x)         <-- doesn't print anything, since it's a null string
print(typeof(x)) <-- prints "string"
y=x+"abc"        <-- y is the string "abc"

y=y+.            <-- sets y to missing since missing propagates
print (y)        <-- prints . to represent missing
print(typeof(y)) <-- prints "missing"

x=10             <-- value x is 10
print(x)         <-- prints 10
print(typeof(x)) <-- prints "number"
y=x+y            <-- sets y to missing since missing propagates

and so on.

These are useful for the kind of programming where you wish to
identify the difference between ("this value is null so that if it is
used by accident where null is not allowed, the program will report an
error") or ("this value is missing and I wish to propagate the missing
value in any operations that include the value") or the bog standard
("this value is valid and can be used as specified").

[snip]

>
> > [insult]
>
> No, I just speak and comprehend American English.

Nuts in that case.

>
> > > > Since 0 is a quantity, 0 ALLOT is acceptable; the zero
> > > > refers to a quantity of address units, not "nothingness".
>
> > > Zero isn't a quantity. Please give me zero apples. Once you've
> > > done so, I expect to have some apples, not none. Where are my
> > > apples? With zero, I won't have any apples. I'd have none.
> > > I.e., zero isn't a quantity. It's a number.
>
> > Contradicting your wikipedia sourced support.
>
> Not true.

I have a bag. In that bag there is one nut. I remove one nut. What
quantity of nuts do I have in the bag?

I honestly can't believe how difficult you are making this.

>
> > > > In terms of RFC2119 (which postdates the Forth ANSI spec, so
> > > > the ambiguity in that spec is forgivable) "MAY" is tightly
> > > > defined, as is "SHALL". To use the language in that RFC to
> > > > rewrite; "The number of characters in ccc shall be zero to
> > > > the number of characters in the parse area".
>
> > > RFC2119 is utterly irrelevant in regards to Forth ANSI
> > > specification.
>
> > [insult]
>
> Despite the incorrect unsnipped statement above, RFC2119 supports
> my position ...  If you knew that, why did you bring it up?
>

Either its irrelevant (your first statement) or it's relevant and it
supports your position (second statement). Which is it?

I prefer SHALL; but the ANS spec predates the RFC, and it is what it
is.

> Rod Pemberton
> BTW, I don't think I insulted you any ... food for thought.

Me neither. Consider your vocabulary increased by one word.

To get back to the point; S" " is a null string. It has an address and
length; the length is zero to indicate that there are no characters in
the string. C" " is a null counted string. It has an address, and when
COUNTed produces a null string. The spec says so.

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

#17682

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:ec27bf9b-4983-4cc0-8297-930ab99835aa@l12g2000vbj.googlegroups.com...
> On Nov 28, 12:09 pm, "Rod Pemberton"
<do_not_h...@notemailnotz.cnm>
> wrote:
> > "Alex McDonald" <b...@rivadpm.com> wrote in message
>
news:670efa3a-4772-49c0-bfb9-90ac40de429a@g6g2000vbk.googlegroups.com...
> > > On Nov 27, 12:24 pm, "Rod Pemberton"
> > >  <do_not_h...@notemailnotz.cnm>> wrote:

[snip]

> > [ understanding of "may"]
>
> One simply needs to understand that "the car may crash"
> indicates that a crashed car is possible.

It also indicates that a never crashed car is a possible outcome
too.  I.e., there are two outcomes, not one, when one uses "may".

> "The number of characters in ccc may be zero to the number of
> characters in the parse area" indicates that zero characters is
> possible and valid. How hard is that?

That's not hard.  That's understood.  But, it also indicates that
an outcome where zero characters is never possible is valid too.
I.e., you're accepting one outcome of when "may" is used but
rejecting the other outcome.

> > Since you've now accepted Wikipedia's flaky definition as
> > valid, apparently, you re-read it and seriously try to
> > persuade me "zero is distinct from a null" as you've claimed.
> > As you said to me, please stop diverting. ;-)
> >
> > (Personally, I'm surprised you didn't argue against their
> > layman's definition... I would've. It sucks. I don't think
> > that's a very good definition at all.)
>
> Then please stop quoting material in which you have no faith
> in support of your argument.

First, this isn't about faith.

Second, I just asked if you were sure and cited something that
contradicted you.  Why you accepted that I agreed with what
someone else stated simply because it was cited by me is beyond
me...  It's not ludicrous to believe that someone can cite another
person, who has been proven false by history, without that
citation being a representation of that person's beliefs.  E.g.,
if you stated the world was round, I could cite Homer who thought
the world was flat, and ask if you're sure the world is round.  In
no way does that mean I believe the world is flat.

> > > > AIR, the definition of null or nothingness has three
> > > > different standard meanings, but only one is used
> > > > by programmers.
>
> > > Bollocks.
>
> > Bullshit? Really? I think your insults may apply to you...
>
> The word is not considered rude where I come from.

Ok.

> Translate it into American as "nuts". [link]

Then, improve this article.
http://en.wikipedia.org/wiki/Bollocks

> > In actuality, there are only two different _implementations_
> > of null listed by you above. They both have the same *meaning*
> > or definition: "empty" or "not valid".
>
> There are languages that support several types of "nulls".
> Assume X and Y;
>
> [snip]

All examples confuse implementation of null with a meaning for
null.  All cited demonstrate one meaning.  You'd have to check
some other industry or art, perhaps philosophy or religion instead
of programming, for the other meanings of null.

> > > > > Since 0 is a quantity, 0 ALLOT is acceptable; the zero
> > > > > refers to a quantity of address units, not
> > > > > "nothingness".
>
> > > > Zero isn't a quantity. Please give me zero apples. Once
> > > > you've done so, I expect to have some apples, not none.
> > > > Where are my apples? With zero, I won't have any apples.
> > > > I'd have none.  I.e., zero isn't a quantity. It's a
> > > > number.
>
> > > Contradicting your wikipedia sourced support.
>
> > Not true.
>
> I have a bag. In that bag there is one nut. I remove one nut.
> What quantity of nuts do I have in the bag?

There is no quantity of nuts in the bag ...

> I honestly can't believe how difficult you are making this.

See above.  It's in plain English.  So, ditto.

> > > > > In terms of RFC2119 (which postdates the Forth ANSI
> > > > > spec, so the ambiguity in that spec is forgivable) "MAY"
> > > > > is tightly defined, as is "SHALL". To use the language
> > > > > in that RFC to rewrite; "The number of characters in
> > > > > ccc shall be zero to the number of characters in the
> > > > > parse area".
>
> > > > RFC2119 is utterly irrelevant in regards to Forth ANSI
> > > > specification.
>
> > > [insult]
>
> > Despite the incorrect unsnipped statement above, RFC2119
> > supports my position ... If you knew that, why did you bring
> > it up?
>
> Either its irrelevant (your first statement) or it's relevant
> and it supports your position (second statement). Which
> is it?

Untrue.  It's both.  You've ignored the context of why it's both
irrelevant and supports my position.  It's irrelevant to ANS
specification since it has nothing whatsoever to do with it (first
statement).  It supports my position on what "may" means (second
statement).

> I prefer SHALL; but the ANS spec predates the RFC,
> and it is what it is.

Irrelevant.  Ed cited the ANS specification on "may".  It said the
same thing, albeit far more tersely.

> To get back to the point; S" " is a null string.

Is it a "null string"?  Please cite ANS as I don't see any
definition for a "null string".  FYI, "null" is only used four
times and none in regards to a string...  ANS Forth uses the term
"empty".  At best, ANS mentions a string of zero length, without
naming what it is...

> [S" "] has an address and length;

It's true that S" returns an address and length for valid
strings...

> the length is zero to indicate that there are no
> characters in the string.

Debatable, but it's definately good for safety and useability.

> C" " is a null counted string.

Is it a "null counted string"?  Please cite ANS as I don't see any
definition for a "null counted string" either.  FYI, "null" is
only used four times and none in regards to a string ...  ANS
Forth uses the term "empty".  At best, ANS mentions a string of
zero length, without naming what it is...


"counted string: A data structure consisting of one character
containing a length followed by zero or more contiguous data
characters. Normally, counted strings contain text."

As anyone can understand, the this definition allows for null
counted strings but doesn't require them.


3.1.3.4 Counted strings

"... between zero and the implementation-defined maximum
length for a counted string."

It's not clarified as to whether "between" as used here is
inclusive (very rare) of zero, or exclusive (common usage) of
zero.  The common exclusive meaning again supports the idea Forth
has no null strings.

> It has an address, and when
> COUNTed produces a null string. The spec says so.

That's not stated in 6.2.0855 for C".  It says to "parse".

"parse: To select and exclude a character string from the parse
area using a specified set of delimiting characters, called
delimiters."

"character string: Data space that is associated with a sequence
of consecutive character-aligned addresses.  Character strings
usually contain text.  Unless otherwise indicated, the term
"string" means "character string"."


As anyone can understand, the latter definition allows for null
strings but doesn't require them.


Of course 3.4.1 for Parsing of the text interpreter, says "may
be", which has two outcomes, i.e., one with null strings and one
without.

Elsewhere, in many places, the specification uses "zero or more".
Again, it allows for null strings, but doesn't require.

There is other "evidence" that null strings aren't supported in
ANS Forth such as TYPE conditionally emitting strings that aren't
null strings.  There is no need for conditionally emitting null
strings unless they don't exist in Forth.


For ANS Forth, WORD and PARSE and the optional
PARSE-WORD seem to be the only situations where
a string with zero length is required to be returned.


So, what you have is a specification where null strings - a term
which is never used nor defined - are optional at best everywhere,
has definitions which indicate that null strings aren't supported
by a number of words, and only has three Forth words that are
citable exceptions to that, since they require strings of zero
length, and even one of them is optional.


Rod Pemberton

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

#17684

On Nov 29, 11:09 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm>
wrote:

[snip]
>
> So, what you have is a specification where null strings - a term
> which is never used nor defined - are optional at best everywhere,
> has definitions which indicate that null strings aren't supported
> by a number of words, and only has three Forth words that are
> citable exceptions to that, since they require strings of zero
> length, and even one of them is optional.
>
> Rod Pemberton

Clinton would be proud of you.

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

#17726

"Rod Pemberton" <do_not_have@notemailnotz.cnm> wrote:
> "Alex McDonald" <blog@rivadpm.com> wrote in message
> news:670efa3a-4772-49c0-bfb9-90ac40de429a@g6g2000vbk.googlegroups.com...
>> On Nov 27, 12:24 pm, "Rod Pemberton"
> <do_not_h...@notemailnotz.cnm>
>> wrote:
>>>> In terms of RFC2119 (which postdates the Forth ANSI spec, so
>>>> the ambiguity in that spec is forgivable) "MAY" is tightly
>>>> defined, as is "SHALL". To use the language in that RFC to
>>>> rewrite; "The number of characters in ccc shall be zero to
>>>> the number of characters in the parse area".
>> 
>>> RFC2119 is utterly irrelevant in regards to Forth ANSI
>>> specification.

If we where publishing an RFC this might be worth consideration, but we are
not.  We are adhering to the ANSI standards for documentation.

--
Peter Knaggs

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

#17585

Alex McDonald wrote:
> On Nov 25, 7:38 am, "Ed" <inva...@nospam.com> wrote:
> > Elizabeth D. Rather wrote:
> > > On 11/23/12 3:14 PM, Ed wrote:
> > > > Elizabeth D. Rather wrote:
> > > >> On 11/22/12 4:56 PM, Ed wrote:
> > > >>> Anton Ertl wrote:
> > > >> ...
> > > >>>>>> There is no need to "seek to exclude implementations from using WORD"
> > > >>>>>> when implementing S". WORD is so limited that it excludes itself, at
> > > >>>>>> least from sensible and correct implementations. E.g.,
> >
> > > >>>>>> S" " . DROP
> >
> > > >>>>>> is a standard program and should print 0.
> >
> > > >>>>> I would say the result is ambiguous and therefore not a '94 portable
> > > >>>>> program.
> >
> > > >>>> There is no such ambiguous condition in the specification of S".
> >
> > > >>> Neither do S" or ." specify strings need to be preceded with a space.
> >
> > > >>> Do you really need a Forth Standard to tell you that generating null
> > > >>> strings with S" or ." is unnecessary?
> >
> > > >> The point is not that S" or ." specify strings which need to be preceded
> > > >> by a space, but that the standard Forth interpreter delimiter is a
> > > >> space, so that S" and ." need to be *followed* by a space in order to be
> > > >> recognized as Forth words.
> >
> > > > Indeed it was the point. It was intended to show how one may elicit
> > > > characteristics, possibly never intended, simply by reading a specification
> > > > in isolation.
> >
> > > >> ..
> > > >>> Chuck considered *practical* needs when he designed Forth. It didn't
> > > >>> concern him in the least that character and string literals in Forth didn't
> > > >>> appear, or behave like, those in other languages. He had better things
> > > >>> to do.
> >
> > > >> In fact, many people have coped with this requirement for a delimiting
> > > >> space for many years, and survived the ordeal with remarkably little trauma.
> >
> > > > The delimiting space is one aspect of Forth quoted strings. The empty string
> > > > case is another. Do you agree with Anton that Forth-94 S" ." .( ( etc is only
> > > > not permitted to return an empty string but is required to do so?
> >
> > > > I note someone has already declared the answer here:
> > > >http://rosettacode.org/wiki/Empty_string
> >
> > > Considering S" " as the test case.
> >
> > > From Forth94 3.4.1 Parsing:
> >
> > > "If delimiter characters are present in the parse area after the
> > > beginning of the selected string, the string continues up to and
> > > including the character just before the first such delimiter, and the
> > > number in >IN is changed to index immediately past that delimiter, thus
> > > removing the parsed characters and the delimiter from the parse area."
> >
> > > If you focus on the parsing of S" itself (rather than the subsequent
> > > parse looking for "), the text interpreter is parsing with space as a
> > > delimiter. It finds a space following the S" command, and thus >IN is
> > > positioned immediately *past* that space. At this point, a " delimiter
> > > is found immediately. The issue, therefore, is correctly framed as being
> > > whether or not parsing should "skip leading delimiters" of which, at
> > > this point " is one. And, of course, WORD skips leading delimiters while
> > > PARSE does not. Forth94 *does not* specify; in the prevailing usage at
> > > the time, WORD was the standard parsing operator; Open Firmware was
> > > strongly behind PARSE, and Mitch Bradley was an influential proponent of
> > > PARSE instead of WORD, and today many others are as well.
> >
> > > I have tried (and failed) to download current drafts of Forth200x.
> > > However, Forth94 does *not* specify how leading delimiters are to be
> > > treated for these words, so in my opinion the issue remains ambiguous.
> >
> > The TC was certainly aware of WORD's use in parsing strings
> > (A.6.2.2008 PARSE). Perhaps because everyone might not accept
> > the justifications given for including PARSE that it was left optional (?)
> >
> > I can understand some users having an *expectation* that S" " should
> > work and produce certain results but that is not the same as saying
> > Forth needs it. To that end my interpretation of the S" spec is as follows:
> >
> > 6.1.2165 S"
> > s-quote CORE
> >
> > Compilation: ( "ccc<quote>" -- )
> >
> > Parse ccc delimited by " (double-quote). Append the run-time semantics
> > given below to the current definition ...
> >
> > where "ccc" is defined as:
> >
> > Table 2.1 - Parsed text abbreviations
> >
> > ccc a parsed sequence of arbitrary characters, excluding
> > the delimiter character
> >
> > As I read it S" is specified to parse and return ccc. If ccc is absent
> > and nothing but delimiter characters are present as in the case of S" "
> > then the result is undefined. I apply a similar rationale to the specs for
> > ." .( .
> >
> > I note Forth-94 ( explicitly states the number of characters in ccc may
> > be zero which would break implementations using WORD. Make of it
> > what you will.
> >
> > 6.1.0080
> >
> > Execution: ( "ccc<paren>" -- )
> >
> > The number of characters in ccc may be zero to the number of
> > characters in the parse area.
>
> 3.4.1 Parsing
>
> Unless otherwise noted, the number of characters parsed may be from
> zero to the implementation-defined maximum length of a counted string.

    "may"

    2. Terms, notation, and references
    ...
    In this Standard, "shall" states a requirement on a system or program;
    conversely, "shall not" is a prohibition; "need not" means "is not required to";
    "should" describes a recommendation of the Standard; and "may",
    depending on context, means "is allowed to" or "might happen".

"parsing" characters does not necessarily mean returning them e.g. '('
Placing  '(' at the end of a parse area will result in the parsing of zero
characters - including implementations which use WORD.

I'll give Forth-94 the benefit of the doubt that it hasn't tried to be sneaky
and worded itself in such a manner that gives users little option but to
implement PARSE and S" " .

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

#17607

Op Tue, 27 Nov 2012 12:44:19 +1100 schreef Ed:

> "parsing" characters does not necessarily mean returning them e.g. '('
> Placing  '(' at the end of a parse area will result in the parsing of zero
> characters - including implementations which use WORD.
> 
What if someone places s" at the end of the input line.
I would be very surprised if the stack did not contain an address (or in
this special case perhaps zero) and a zero on top of it.
I would not trust a Forth that would not return the zero or even return
nothing, as I think you imply.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#17654

Coos Haak wrote:
> Op Tue, 27 Nov 2012 12:44:19 +1100 schreef Ed:
>
> > "parsing" characters does not necessarily mean returning them e.g. '('
> > Placing  '(' at the end of a parse area will result in the parsing of zero
> > characters - including implementations which use WORD.
> >
> What if someone places s" at the end of the input line.
> I would be very surprised if the stack did not contain an address (or in
> this special case perhaps zero) and a zero on top of it.
> I would not trust a Forth that would not return the zero or even return
> nothing, as I think you imply.

Perhaps that's why the definitions of  .(  ."  S"  do not specify:

    "The number of characters in ccc may be zero to the number of
    characters in the parse area."

Only  (  has it.

It's not Forth implementations that are at issue here but what folks are
attempting to elicit from the Standard.  We know that classically ." "  ( )
did not work and were not expected to.  I'm unaware of anyone even
presenting a case as to why Forth needs these and S" " to work.

If I were to believe 200x then floats on the data stack would be banned
despite decades of use.  The ability to parse empty strings and statements
like  S" world!".( Hello )TYPE  however would be mandatory.

Not long ago Elizabeth said Forth was for "intelligent programmers".
They certainly need to be to sort out the nonsense that the Standards
are imposing on them.

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

#17677

Op Thu, 29 Nov 2012 12:53:04 +1100 schreef Ed:

> Coos Haak wrote:
>> Op Tue, 27 Nov 2012 12:44:19 +1100 schreef Ed:
>>
>>> "parsing" characters does not necessarily mean returning them e.g. '('
>>> Placing  '(' at the end of a parse area will result in the parsing of zero
>>> characters - including implementations which use WORD.
>>>
>> What if someone places s" at the end of the input line.
>> I would be very surprised if the stack did not contain an address (or in
>> this special case perhaps zero) and a zero on top of it.
>> I would not trust a Forth that would not return the zero or even return
>> nothing, as I think you imply.
> 
> Perhaps that's why the definitions of  .(  ."  S"  do not specify:
> 
>     "The number of characters in ccc may be zero to the number of
>     characters in the parse area."
> 
> Only  (  has it.
> 
> It's not Forth implementations that are at issue here but what folks are
> attempting to elicit from the Standard.  We know that classically ." "  ( )
> did not work and were not expected to.  I'm unaware of anyone even
> presenting a case as to why Forth needs these and S" " to work.
> 
> If I were to believe 200x then floats on the data stack would be banned
> despite decades of use.  The ability to parse empty strings and statements
> like  S" world!".( Hello )TYPE  however would be mandatory.
> 
> Not long ago Elizabeth said Forth was for "intelligent programmers".
> They certainly need to be to sort out the nonsense that the Standards
> are imposing on them.

The only thing I asked is what happens when you type S" at the end of the 
line. Does it (as I would expect) leave an address and a zero or does the 
system crash? Can you answer that?

S" world!".( Hello )TYPE
Works in every Forth implementation I have examined. If Figforth had S" it
would work too.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#17678

On Nov 29, 9:59 am, Coos Haak <chfo...@hccnet.nl> wrote:
>
> The only thing I asked is what happens when you type S" at the end of the
> line. Does it (as I would expect) leave an address and a zero or does the
> system crash? Can you answer that?
>

It depends, I guess:

1) If loading from a block, then nothing, because a block is one long
line
1a) If placed at the end of a block, then it could crash/read beyond
the end of the block

2) If loading from a file, then I would expect it to crash/read beyond
the end of the buffered line

However: I guess it depends on how it was internally implemented: If
implemented with WORD (or the modern ANS version of WORD (is it
PARSE)) then it would probably be fine, since WORD would cause the
input buffer to be re-filled when out of input.

So, as this newbie sees it, there is *no* specific answer. It's
implementation dependant.

I see this is a demonstrable drawback of specifications that do not
offer any implementation guidance. I realise that the general opinion
here is that it is not the job of a language specification to offer
implementation guidance. That has the unfortunate side-effect of
making the specification next to useless to anyone wanting to
implement a system from its specification. It gives her no clues
whatsoever about how to go about it, and leads to endless arguments
over whos implementation is correct, and whos is not. It also leads to
a myriad of "compliant" systems that do not run "compliant" code, due
the ambiguities inherent within the standard and the differing
opinions/ego/pride of the implementors.

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

#17680

On Nov 29, 10:22 am, Mark Wills <forthfr...@gmail.com> wrote:
> On Nov 29, 9:59 am, Coos Haak <chfo...@hccnet.nl> wrote:
>
>
>
> > The only thing I asked is what happens when you type S" at the end of the
> > line. Does it (as I would expect) leave an address and a zero or does the
> > system crash? Can you answer that?
>
> It depends, I guess:
>
> 1) If loading from a block, then nothing, because a block is one long
> line
> 1a) If placed at the end of a block, then it could crash/read beyond
> the end of the block

No.

>
> 2) If loading from a file, then I would expect it to crash/read beyond
> the end of the buffered line

No.

>
> However: I guess it depends on how it was internally implemented: If
> implemented with WORD (or the modern ANS version of WORD (is it
> PARSE)) then it would probably be fine, since WORD would cause the
> input buffer to be re-filled when out of input.
>
> So, as this newbie sees it, there is *no* specific answer. It's
> implementation dependant.

Yet on every implementation Coos tried, it worked. That demonstrates
that all these systems interpreted the specification in the same way,
and the ANS specification is very clear on parsing. It's not
implementation dependent; it's clearly specified.

>
> I see this is a demonstrable drawback of specifications that do not
> offer any implementation guidance. I realise that the general opinion
> here is that it is not the job of a language specification to offer
> implementation guidance. That has the unfortunate side-effect of
> making the specification next to useless to anyone wanting to
> implement a system from its specification. It gives her no clues
> whatsoever about how to go about it, and leads to endless arguments
> over whos implementation is correct, and whos is not. It also leads to
> a myriad of "compliant" systems that do not run "compliant" code, due
> the ambiguities inherent within the standard and the differing
> opinions/ego/pride of the implementors.

Compliance testing has been the bugbear of many standards, yet in this
case all implementations correctly parse...

S"<nl>

(where <nl> is a newline character) and return a null string.

Why? They must. The spec clearly states this should happen, section
3.4.1 Parsing. I repeat; "If the parse area is empty, i.e., when the
number in >IN is equal to the length of the input buffer, or contains
no characters other than delimiters, the selected string is empty."
Read the rest of that section for the full discussion on delimiters.

Those with "opinion/ego/pride" that think otherwise are wrong.

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

#17685

Mark Wills <forthfreak@gmail.com> wrote:
> However: I guess it depends on how it was internally implemented: If
> implemented with WORD (or the modern ANS version of WORD (is it
> PARSE)) then it would probably be fine, since WORD would cause the
> input buffer to be re-filled when out of input.

No.  WORD doesn't refill buffers.

> I see this is a demonstrable drawback of specifications that do not
> offer any implementation guidance. I realise that the general
> opinion here is that it is not the job of a language specification
> to offer implementation guidance. That has the unfortunate
> side-effect of making the specification next to useless to anyone
> wanting to implement a system from its specification. It gives her
> no clues whatsoever about how to go about it, and leads to endless
> arguments over whos implementation is correct, and whos is not.

There is no lack of implementation guidance here.  There is a surplus
of idiots who argue with the experts who really know how to do it.

> It also leads to a myriad of "compliant" systems that do not run
> "compliant" code, due the ambiguities inherent within the standard
> and the differing opinions/ego/pride of the implementors.

Not really.  There are some (IMO) fairly minor disagreements about
things like whether S" can be state-smart, but that's it.

Andrew.

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

#17715

On 11/29/12 12:22 AM, Mark Wills wrote:
> On Nov 29, 9:59 am, Coos Haak <chfo...@hccnet.nl> wrote:
>>
>> The only thing I asked is what happens when you type S" at the end of the
>> line. Does it (as I would expect) leave an address and a zero or does the
>> system crash? Can you answer that?
>>
>
> It depends, I guess:
>
> 1) If loading from a block, then nothing, because a block is one long
> line
> 1a) If placed at the end of a block, then it could crash/read beyond
> the end of the block
>
> 2) If loading from a file, then I would expect it to crash/read beyond
> the end of the buffered line
>

I don't have time to research it right now, but I believe most 
discussions of parsing include the phrase "...or the end of the input 
stream is reached" or equivalent. In any case, reaching the end of the 
input stream (block, line, or file) is a normal occurrence, and any 
system that crashed in that case is incompetently written.

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]

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

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

csiph-web