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

Groups > comp.lang.forth > #17600

Re: "comus" words

Show all headers | View raw

"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

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

"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

csiph-web