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

#17368 — "comus" words

The "comus" words are mentioned on occasion, this time recently by Stephen
Pelc in another thread.
http://forth.sourceforge.net/mirror/comus/index.html

The mirrored webpage above is dated 1999.  I.e., isn't it a bit out of date?

I don't see a point to implementing all of them, especially if they aren't
used much anymore.  Which, if any, of the 'comus' definitions are generally
recommended to be implemented - today?

I've implement a few of them.  Very infrequently, I've seen these used in
code:

-ROT
BOUNDS
DEFER
IS
FOR
[DEFINED]
[UNDEFINED]
FOR ... NEXT

I haven't seen the others used in code, although I did see UNDER+
somewhere ...  likely Koopman or perhaps Knaggs webpage.

I haven't seen C@+ used much either, nor COUNT as C@+.

The words: APPEND SKIP SCAN PLACE and STRING, seem
useful as they are similar to some of C's string functions, but
how commonly are they actually used in Forth?

Also, should STRING, have an ALIGNED before the ALLOT ?  If not, why not?

Also, is there any valid reason that an ANS Forth word like S" be
implemented in terms of of words like PLACE and STRING, instead
of ANS only words (as I did)?


Rod Pemberton

[toc] | [next] | [standalone]

#17369

On 11/18/12 3:55 PM, Rod Pemberton wrote:
> The "comus" words are mentioned on occasion, this time recently by Stephen
> Pelc in another thread.
> http://forth.sourceforge.net/mirror/comus/index.html
>
> The mirrored webpage above is dated 1999.  I.e., isn't it a bit out of date?
>
> I don't see a point to implementing all of them, especially if they aren't
> used much anymore.  Which, if any, of the 'comus' definitions are generally
> recommended to be implemented - today?

Implement the ones you need to use, ideally when you discover you need 
them. Your system is for your use, yes?

> I've implement a few of them.  Very infrequently, I've seen these used in
> code:
>
> -ROT
> BOUNDS
> DEFER
> IS
> FOR
> [DEFINED]
> [UNDEFINED]
> FOR ... NEXT

In my experience, the most useful ones in this list are DEFER and IS 
(which work together). [DEFINED] and [UNDEFINED] are sometimes useful, 
as are -ROT and BOUNDS. FOR ... NEXT is Chuck's replacement for all the 
DO ... LOOP family of words, but it hasn't really caught on.

> I haven't seen the others used in code, although I did see UNDER+
> somewhere ...  likely Koopman or perhaps Knaggs webpage.
>
> I haven't seen C@+ used much either, nor COUNT as C@+.

That's occasionally a very useful thing to do. Whether you want to call 
it COUNT or C@+ is up to you.

> The words: APPEND SKIP SCAN PLACE and STRING, seem
> useful as they are similar to some of C's string functions, but
> how commonly are they actually used in Forth?

Depends on whether your application does a lot of string manipulation.

> Also, should STRING, have an ALIGNED before the ALLOT ?  If not, why not?

Depends on what goes before. CREATE guarantees that the data space 
pointer will be aligned, so the sequence CREATE ALLOT doesn't need it.

> Also, is there any valid reason that an ANS Forth word like S" be
> implemented in terms of of words like PLACE and STRING, instead
> of ANS only words (as I did)?

Nobody cares how you implement anything so long as it has the correct 
semantics (behavior).

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]

#17373

Rod Pemberton wrote:
> ...
> Also, is there any valid reason that an ANS Forth word like S" be
> implemented in terms of of words like PLACE and STRING, instead
> of ANS only words (as I did)?

You forgot WORD.

WORD is CORE and has traditionally been used to implement S"
type words.  This results in compromise in portable programs such
as using WORD and S" concurrently; not permitting entry of null
strings etc.

Standards are not about what you can do - rather what you shall
allow others to do :)

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

#17377

On Nov 19, 9:15 am, "Ed" <inva...@nospam.com> wrote:
> Rod Pemberton wrote:
> > ...
> > Also, is there any valid reason that an ANS Forth word like S" be
> > implemented in terms of of words like PLACE and STRING, instead
> > of ANS only words (as I did)?
>
> You forgot WORD.
>
> WORD is CORE and has traditionally been used to implement S"
> type words.  This results in compromise in portable programs such
> as using WORD and S" concurrently; not permitting entry of null
> strings etc.

Then the implementation is broken, not the standard.

>
> Standards are not about what you can do - rather what you shall
> allow others to do :)

A good standard says nothing about implementation, but it is my
experience that poor implementors blame standards to justify their
failure to understand or inability to implement as specified. They
rarely, if ever, assist in making standards less ambiguous or better
specified, since coining aphorisms is a cheaper and less
intellectually challenging task.

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

#17418

Alex McDonald wrote:
> On Nov 19, 9:15 am, "Ed" <inva...@nospam.com> wrote:
> > Rod Pemberton wrote:
> > > ...
> > > Also, is there any valid reason that an ANS Forth word like S" be
> > > implemented in terms of of words like PLACE and STRING, instead
> > > of ANS only words (as I did)?
> >
> > You forgot WORD.
> >
> > WORD is CORE and has traditionally been used to implement S"
> > type words. This results in compromise in portable programs such
> > as using WORD and S" concurrently; not permitting entry of null
> > strings etc.
>
> Then the implementation is broken, not the standard.

I didn't say the Standard was broken (though it may be) - rather that it
came with conditions and compromises to which its users are bound.

> > Standards are not about what you can do - rather what you shall
> > allow others to do :)
>
> A good standard says nothing about implementation,

That's because it wanted to accommodate as many implementations
and programs, past and present, as was feasible.  To effect this they
instead specified the *limits* to which functions could be used in a
Standard setting.

> but it is my
> experience that poor implementors blame standards to justify their
> failure to understand or inability to implement as specified. They
> rarely, if ever, assist in making standards less ambiguous or better
> specified, since coining aphorisms is a cheaper and less
> intellectually challenging task.

I'm surprised you still read my posts having previously expressed
an intention to bin them! :)

I don't recall what conditions '94 has placed on the use of S" in
a Standard Program but I'd be amazed if it sought to exclude
implementations from using WORD - which had been Forth's
standard string parser from earliest times.

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

#17425

"Ed" <invalid@nospam.com> writes:
>I don't recall what conditions '94 has placed on the use of S" in
>a Standard Program but I'd be amazed if it sought to exclude
>implementations from using WORD - which had been Forth's
>standard string parser from earliest times.

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.  A straightforward
implementation of S" based on WORD will not work correctly for that
program.  There is a reason why we have PARSE.  And just because a
word is old does not mean it is more generally useful than a young
word.  TIB is also old and is now obsolete.

- 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 2012: http://www.euroforth.org/ef12/

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

#17464

Anton Ertl wrote:
> "Ed" <invalid@nospam.com> writes:
> >I don't recall what conditions '94 has placed on the use of S" in
> >a Standard Program but I'd be amazed if it sought to exclude
> >implementations from using WORD - which had been Forth's
> >standard string parser from earliest times.
>
> 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.

Should I ever need a '94 program to generate a zero length string
then I'll use something that I know will work e.g.  HERE 0

> A straightforward
> implementation of S" based on WORD will not work correctly for that
> program.  There is a reason why we have PARSE.  And just because a
> word is old does not mean it is more generally useful than a young
> word.

WORD and S" are required in '94.  PARSE is not.

It would be absurd to require S" be able to generate empty strings when
PARSE was not available.  Even moreso when there exist easier ways
of achieving the same effect.

> TIB is also old and is now obsolete.

WORD is not obsolete in '94.  Nor did PARSE replace it.

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

#17466

Ed <invalid@nospam.com> wrote:
> Anton Ertl wrote:
>> "Ed" <invalid@nospam.com> writes:
>> >I don't recall what conditions '94 has placed on the use of S" in
>> >a Standard Program but I'd be amazed if it sought to exclude
>> >implementations from using WORD - which had been Forth's
>> >standard string parser from earliest times.

Yes, but WORD has long been known to be broken for parsing strings,
which caused the famous  ." "  bug.  This has been known to be a bug
since earliest times, so Forth-94 fixed it.

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

Eh?  Why on Earth would you say that?

> Should I ever need a '94 program to generate a zero length string
> then I'll use something that I know will work e.g.  HERE 0
> 
>> A straightforward
>> implementation of S" based on WORD will not work correctly for that
>> program.  There is a reason why we have PARSE.  And just because a
>> word is old does not mean it is more generally useful than a young
>> word.
> 
> WORD and S" are required in '94.  PARSE is not.
> 
> It would be absurd to require S" be able to generate empty strings
> when PARSE was not available. 

And yet, it is so required.

> Even moreso when there exist easier ways of achieving the same
> effect.

It's just an example of a test of correct behaviour.

Andrew.

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

#17467

"Ed" <invalid@nospam.com> writes:
>Anton Ertl wrote:
>> "Ed" <invalid@nospam.com> writes:
>> >I don't recall what conditions '94 has placed on the use of S" in
>> >a Standard Program but I'd be amazed if it sought to exclude
>> >implementations from using WORD - which had been Forth's
>> >standard string parser from earliest times.
>>
>> 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".

>Should I ever need a '94 program to generate a zero length string
>then I'll use something that I know will work e.g.  HERE 0

Sure, as a programmer you are free to avoid using some standard
features working around arbitrary restrictions of your own invention.
As a system implementor, you have to provide standard features if you
want to claim compliance.

>WORD and S" are required in '94.

So what?  U. is also in CORE, but that does not mean it has to be used
in S" or vice versa.

>It would be absurd to require S" be able to generate empty strings when
>PARSE was not available.

It's the system implementors' decision whether PARSE is available to
programs; by contrast, compliant systems are required to have a
correct S".  If the combination of 'no PARSE' and 'correct S"'is
indeed absurd, there will be no such system around; all the better!

- 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 2012: http://www.euroforth.org/ef12/

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

#17490

Anton Ertl wrote:
> "Ed" <invalid@nospam.com> writes:
> >Anton Ertl wrote:
> >> "Ed" <invalid@nospam.com> writes:
> >> >I don't recall what conditions '94 has placed on the use of S" in
> >> >a Standard Program but I'd be amazed if it sought to exclude
> >> >implementations from using WORD - which had been Forth's
> >> >standard string parser from earliest times.
> >>
> >> 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?

> >Should I ever need a '94 program to generate a zero length string
> >then I'll use something that I know will work e.g.  HERE 0
>
> Sure, as a programmer you are free to avoid using some standard
> features working around arbitrary restrictions of your own invention.
> As a system implementor, you have to provide standard features if you
> want to claim compliance.
>
> >WORD and S" are required in '94.
>
> So what?  U. is also in CORE, but that does not mean it has to be used
> in S" or vice versa.
>
> >It would be absurd to require S" be able to generate empty strings when
> >PARSE was not available.

Re-reading the above I can't believe I had to say it.  Just the thought of
generating null strings via S" is mind-boggling.

> It's the system implementors' decision whether PARSE is available to
> programs; by contrast, compliant systems are required to have a
> correct S".  If the combination of 'no PARSE' and 'correct S"'is
> indeed absurd, there will be no such system around; all the better!

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.

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

#17492

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.

..
>>> It would be absurd to require S" be able to generate empty strings when
>>> PARSE was not available.
>
> Re-reading the above I can't believe I had to say it.  Just the thought of
> generating null strings via S" is mind-boggling.

The issue is that if you omit the space *following* S" or ." and expect 
the next space to be part of the string (instead of a Forth delimiter), 
that may not happen. This makes some people mad.

>> It's the system implementors' decision whether PARSE is available to
>> programs; by contrast, compliant systems are required to have a
>> correct S".  If the combination of 'no PARSE' and 'correct S"'is
>> indeed absurd, there will be no such system around; all the better!
>
> 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.

Cheers,
Elizebth

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

#17514

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

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

#17516

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.

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]

#17539

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.

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

#17547

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.

What is not clear from the Forth200x spec is the address of a null
string; is 0 0 allowed?

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

#17548

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.

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 canot be true.

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

Well, yes, or you'd have a special-case restriction on empty comments.

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

Andrew.

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

#17549

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

Yes; /STRING.

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

#17550

Alex McDonald <blog@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?

Andrew.

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

#17554

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

s" A" 1 /string -1 /string should return s" A", but if 1 /string
returns 0 0... 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."

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

#17556

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.

Andrew.

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

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

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

csiph-web