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

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

RfD: Interpret S\" (Version 2)

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

Contents

  RfD: Interpret S\" (Version 2) "Peter Knaggs" <pjk@bcs.org.uk> - 2014-03-11 11:18 +0000
    Re: RfD: Interpret S\" (Version 2) "Alex McDonald" <blog@rivadpm.com> - 2014-03-11 18:36 +0000
      Re: RfD: Interpret S\" (Version 2) Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-11 21:32 +0100
        Re: RfD: Interpret S\" (Version 2) "Alex McDonald" <blog@rivadpm.com> - 2014-03-11 22:38 +0000
          Re: RfD: Interpret S\" (Version 2) Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-12 13:02 +0100
        Re: RfD: Interpret S\" (Version 2) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-12 04:41 -0500
          Re: RfD: Interpret S\" (Version 2) Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-12 13:16 +0100
      Re: RfD: Interpret S\" (Version 2) Mark Wills <markwills1970@gmail.com> - 2014-03-12 04:33 -0700
        Re: RfD: Interpret S\" (Version 2) Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-12 12:51 +0100
          Re: RfD: Interpret S\" (Version 2) Mark Wills <markwills1970@gmail.com> - 2014-03-12 06:25 -0700
            Re: RfD: Interpret S\" (Version 2) Coos Haak <chforth@hccnet.nl> - 2014-03-12 15:59 +0100
              Re: RfD: Interpret S\" (Version 2) Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-12 19:43 +0100
            Re: RfD: Interpret S\" (Version 2) "Peter Knaggs" <pjk@bcs.org.uk> - 2014-03-13 18:55 +0000

#29008 — RfD: Interpret S\" (Version 2)

Interpret S\" (Version 2)
=============

20140311 Minor revisions thanks to comments on comp.lang.forth
          from Alex McDonald and Steven Pelc.

20140209 Original Text
          Gerry Jackson, Bernd Paysan and Peter Knaggs


Problem
=======

S" is extended in the File-Access word set to be usable in
interpretation mode.

S\" is a sister word to S" but is not extended in the same way in the
File-Access word set.

It seems to me that S\" is just as useful as S" in interpretation
mode.


Discussion
==========

There are two possible solutions:

Revise the definition of 6.2.2266 S\" to include interpretation
semantics.  Alternatively, add a new entry 11.6.2.2266 S\" which adds
the interpretation action, in the same manner as S".

The interpretation semantics of S" are provided in a separate
definition, so that small systems are not required to implement it.
The same can be said of the interpretation semantics for S\". Thus, we
propose taking the second option, and provide a new definition of S\"
in the FILE word set to provide the interpretation semantics.

This brings us to the question of which buffer should S\" use.  As S\"
is intended as an extension to S" it would make sense to allow S\" to
use the same buffer as S".  The description of the buffer lifetime in
S" will need to be revised.

The number of available buffers is defined as "At least one".  As a
number of FILE words require two strings, this would be the right time
to change this to "at least two".


Solution
========

Provide a new definition in the FILE EXT word set, 11.6.2.2266 S\"
which extends 6.2.2266 S\" by providing interpretation semantics.


Proposal
========

a) Replace 11.3.4 Transient String Buffers:

     The list of words using memory in transient regions is extended to
     include 11.6.1.2165 S". See: 3.3.3.6 Other transient regions.

    with:

     The system provides transient buffers for S" and S\" strings.
     These buffers shall be no less than 80 characters in length,
     and there shall be at least two buffers.  The system should
     be able to store two strings defined by sequential use of S"
     or S\".

b) Add section A.11.3.4 Transient String Buffers

     Additional transient buffers are provided for use by S" and S\".
     The buffers should be able to store two consecutive strings,
     thus allowing the command line:

         S" name1" S" name2" RENAME-FILE

     The buffers may be implemented in a circular arrangement, where
     a string is placed into the next available buffer.  When there
     are no buffers available, the oldest buffer is overwritten.

     S" and S\" may share the same buffers.

     The list of words using memory in transient regions is extended
     to include 11.6.1.2165 S" and 11.6.2.2266 S\".  See 3.3.3.6 Other
     transient regions.

c) Add the following definition to the FILE EXT word set:

     11.6.2.2266 S\"            "s-backslash-quote"            FILE EXT

         Extend the semantics of 6.2.2266 S\" to be:

     Interpretation: ( "ccc<quote>" -- c-addr u )
         Parse ccc delimited by " (double quote) according to the
         translation rules given in 6.2.2266 S\".  Store the resulting
         string in a temporary string buffer (c-addr u).

     Compilation:  ( "ccc<quote>" -- )
         Parse ccc delimited by " (double quote) according to the
         translation rules given in 6.2.2266 S\".  Append the run-time
         semantics given below to the current definition.

     Run-time: ( -- c-addr u )
         Return a string c-addr u describing the translation of ccc.
         A program shall not alter the returned string.

     See: 6.2.2266 S\", 11.3.4 Transient String Buffers, 11.6.1.2165
          S", A.11.3.4 Transient String Buffers.

d) Alter the interpretation semantics of 11.6.1.2165 from:

         Parse ccc delimited by " (double quote). Store the resulting
         string c-addr u at a temporary location. The maximum length
         of the temporary buffer is implementation-dependent but shall
         be no less than 80 characters. Subsequent uses of S" may
         overwrite the temporary buffer. At least one such buffer shall
         be provided.

    to:

         Parse ccc delimited by " (double quote). Store the resulting
         string in a temporary string buffer (c-addr u).

e) Add 11.6.2.2266 S\" and A.11.3.4 Transient String Buffers to the
    see list of 11.6.1.2165 S".

f) Adjust the documentation requirements in 11.4.1.1 Implementation-
    defined options from:

         - number of string buffers provided (11.6.2.2165 S")

         - size of string buffer used by 11.6.1.2165 S".

    to:

         - number of temporary string buffers provided (11.3.4
         Temporary String Buffers)

         - size of temporary string buffers (11.3.4 Temporary String
           Buffers).

g) Replace 3.3.3.4 Text-literal regions with:

         The text-literal regions, specified by strings compiled with
         S", S\" and C", may be read-only.

         A program shall not store into the text-literal regions
         created by S", S\" and C" nor into any read-only system
         variable or read-only transient regions.

[toc] | [next] | [standalone]

#29012

on 11/03/2014 11:18:40, "Peter Knaggs" wrote:
> Interpret S\" (Version 2)
> ===========20140311 Minor revisions thanks to comments on
> comp.lang.forth from Alex McDonald and Steven Pelc.
> 
> 20140209 Original Text
> Gerry Jackson, Bernd Paysan and Peter Knaggs
> 
> 
> Problem
> =====S" is extended in the File-Access word set to be usable in
> interpretation mode.
> 
> S\" is a sister word to S" but is not extended in the same way in the
> File-Access word set.
> 
> It seems to me that S\" is just as useful as S" in interpretation
> mode.
> 
> 
> Discussion
> ========There are two possible solutions:
> 
> Revise the definition of 6.2.2266 S\" to include interpretation
> semantics.  Alternatively, add a new entry 11.6.2.2266 S\" which adds
> the interpretation action, in the same manner as S".
> 
> The interpretation semantics of S" are provided in a separate
> definition, so that small systems are not required to implement it.
> The same can be said of the interpretation semantics for S\". Thus, we
> propose taking the second option, and provide a new definition of S\"
> in the FILE word set to provide the interpretation semantics.
> 
> This brings us to the question of which buffer should S\" use. As S\"
> is intended as an extension to S" it would make sense to allow S\" to
> use the same buffer as S". The description of the buffer lifetime in
> S" will need to be revised.
> 
> The number of available buffers is defined as "At least one".  As a
> number of FILE words require two strings, this would be the right time
> to change this to "at least two".

Andrew Haley objected that it doesn't follow the zero, one, many model. 

> 
> 
> Solution
> ======Provide a new definition in the FILE EXT word set, 11.6.2.2266
> S\" which extends 6.2.2266 S\" by providing interpretation semantics.
> 
> 
> Proposal
> ======a) Replace 11.3.4 Transient String Buffers:
> 
> The list of words using memory in transient regions is extended to
> include 11.6.1.2165 S". See: 3.3.3.6 Other transient regions.
> 
> with:
> 
> The system provides transient buffers for S" and S\" strings.
> These buffers shall be no less than 80 characters in length,
> and there shall be at least two buffers.  The system should
> be able to store two strings defined by sequential use of S"
> or S\".

The length of the buffer is ambiguously defined, since 80 untranslated \l
characters (backslash-L or linefeed) requires 160 characters in the parse
buffer but only 80 characters in the S\" buffer.

> 
> b) Add section A.11.3.4 Transient String Buffers
> 
> Additional transient buffers are provided for use by S" and S\".
> The buffers should be able to store two consecutive strings,
> thus allowing the command line:
> 
> S" name1" S" name2" RENAME-FILE
> 
> The buffers may be implemented in a circular arrangement, where

s/The buffers/When more than two buffers are desired, they/

> a string is placed into the next available buffer.  When there
> are no buffers available, the oldest buffer is overwritten.

This isn't the classic definition, which is an index into some space,
incremented modulo the buffer size.


[snip]

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

#29015

Alex McDonald wrote:

> on 11/03/2014 11:18:40, "Peter Knaggs" wrote:
>> The number of available buffers is defined as "At least one".  As a
>> number of FILE words require two strings, this would be the right time
>> to change this to "at least two".
> 
> Andrew Haley objected that it doesn't follow the zero, one, many model.

Sure, but sometimes though shalt count to three, neither to two nor to four, 
because three is the right number.  Or so.  The reason for having two 
buffers is that RENAME-FILE needs two strings, one is clearly insufficient, 
and many are too many.  We have other places were we don't follow this rule, 
either.

>> The system provides transient buffers for S" and S\" strings.
>> These buffers shall be no less than 80 characters in length,
>> and there shall be at least two buffers.  The system should
>> be able to store two strings defined by sequential use of S"
>> or S\".
> 
> The length of the buffer is ambiguously defined, since 80 untranslated \l
> characters (backslash-L or linefeed) requires 160 characters in the parse
> buffer but only 80 characters in the S\" buffer.

Actually not.  The rule is "store the resulting string in the buffer".  This 
defines it that you need to fit in the 80 translated characters, regardless 
how many untranslated there were (\x20 needs four untranslated characters 
per translated character).

>> b) Add section A.11.3.4 Transient String Buffers
>> 
>> Additional transient buffers are provided for use by S" and S\".
>> The buffers should be able to store two consecutive strings,
>> thus allowing the command line:
>> 
>> S" name1" S" name2" RENAME-FILE
>> 
>> The buffers may be implemented in a circular arrangement, where
> 
> s/The buffers/When more than two buffers are desired, they/

"Circular" works even for just two.

>> a string is placed into the next available buffer.  When there
>> are no buffers available, the oldest buffer is overwritten.
> 
> This isn't the classic definition, which is an index into some space,
> incremented modulo the buffer size.

Yes, because the "classic definition" doesn't make much sense here.

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

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

#29016

on 11/03/2014 20:32:47, Bernd Paysan wrote:
> Alex McDonald wrote:
> 
>> on 11/03/2014 11:18:40, "Peter Knaggs" wrote:
>>> The number of available buffers is defined as "At least one".  As a
>>> number of FILE words require two strings, this would be the right time
>>> to change this to "at least two".
>>
>> Andrew Haley objected that it doesn't follow the zero, one, many model.
> 
> Sure, but sometimes though shalt count to three, neither to two nor to
> four, because three is the right number. Or so. The reason for having
> two buffers is that RENAME-FILE needs two strings, one is clearly
> insufficient, and many are too many. We have other places were we
> don't follow this rule, either.

Was it addressed elsewhere? I didn't see it.

> 
>>> The system provides transient buffers for S" and S\" strings.
>>> These buffers shall be no less than 80 characters in length,
>>> and there shall be at least two buffers.  The system should
>>> be able to store two strings defined by sequential use of S"
>>> or S\".
>>
>> The length of the buffer is ambiguously defined, since 80 untranslated \l
>> characters (backslash-L or linefeed) requires 160 characters in the parse
>> buffer but only 80 characters in the S\" buffer.
> 
> Actually not. The rule is "store the resulting string in the buffer".
> This defines it that you need to fit in the 80 translated characters,
> regardless how many untranslated there were (\x20 needs four
> untranslated characters per translated character).

Does the spec say that?  

> 
>>> b) Add section A.11.3.4 Transient String Buffers
>>>
>>> Additional transient buffers are provided for use by S" and S\".
>>> The buffers should be able to store two consecutive strings,
>>> thus allowing the command line:
>>>
>>> S" name1" S" name2" RENAME-FILE
>>>
>>> The buffers may be implemented in a circular arrangement, where
>>
>> s/The buffers/When more than two buffers are desired, they/
> 
> "Circular" works even for just two.

Agreed, I overspecified.

> 
>>> a string is placed into the next available buffer.  When there
>>> are no buffers available, the oldest buffer is overwritten.
>>
>> This isn't the classic definition, which is an index into some space,
>> incremented modulo the buffer size.
> 
> Yes, because the "classic definition" doesn't make much sense here.
> 

Then don't use it.

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

#29025

Alex McDonald wrote:

> on 11/03/2014 20:32:47, Bernd Paysan wrote:
>> Sure, but sometimes though shalt count to three, neither to two nor to
>> four, because three is the right number. Or so. The reason for having
>> two buffers is that RENAME-FILE needs two strings, one is clearly
>> insufficient, and many are too many. We have other places were we
>> don't follow this rule, either.
> 
> Was it addressed elsewhere? I didn't see it.

We have 16 locals, which also is in the "zero, one, many" range.  We have 
minimum stack depths.  We have the 84 characters for PAD.  There are a lot 
of arbitary minimums in the standard.

>> Actually not. The rule is "store the resulting string in the buffer".
>> This defines it that you need to fit in the 80 translated characters,
>> regardless how many untranslated there were (\x20 needs four
>> untranslated characters per translated character).
> 
> Does the spec say that?

Yes:

"Parse ccc delimited by " (double quote) according to the
translation rules given in 6.2.2266 S\".  Store the resulting
string in a temporary string buffer (c-addr u)."

And the spec of the temporary string buffer is

"These buffers shall be no less than 80 characters in length,
and there shall be at least two buffers."

It is clear that you first do the parsing according to the rules, and then 
the storing into the string buffer.

>>>> a string is placed into the next available buffer.  When there
>>>> are no buffers available, the oldest buffer is overwritten.
>>>
>>> This isn't the classic definition, which is an index into some space,
>>> incremented modulo the buffer size.
>> 
>> Yes, because the "classic definition" doesn't make much sense here.
> 
> Then don't use it.

I actually don't see the "classic definition".  We talk about several 
buffers in a circular arrangement, not a circular buffer.  Apparently you 
are mislead by the word "circular".  Circular here means only that the 
oldest data is overwritten when there's no new space to allocate from.

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

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

#29020

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Alex McDonald wrote:
> 
>> on 11/03/2014 11:18:40, "Peter Knaggs" wrote:
>>> The number of available buffers is defined as "At least one".  As a
>>> number of FILE words require two strings, this would be the right time
>>> to change this to "at least two".
>> 
>> Andrew Haley objected that it doesn't follow the zero, one, many model.
> 
> Sure, but sometimes though shalt count to three, neither to two nor
> to four, because three is the right number.  Or so.  The reason for
> having two buffers is that RENAME-FILE needs two strings, one is
> clearly insufficient, and many are too many.  We have other places
> were we don't follow this rule, either.

We do, but two is so aribtrary that IMO it needs better justification
than that's what RENAME-FILE needs.  Is it really a common case that
you use Forth interactively to rename a file like this?

I'll grant you that "two" is better than "one".

Andrew.

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

#29026

Andrew Haley wrote:
> We do, but two is so aribtrary that IMO it needs better justification
> than that's what RENAME-FILE needs.  Is it really a common case that
> you use Forth interactively to rename a file like this?

Let's try to be logical: The file wordset specifies interactive S" to allow 
the file words to be used interactively.  The one word with two strings as 
input is in the file wordset.  If you deduce S"'s capabilities from the use 
case (file words), you need to support RENAME-FILE.  Is this a frequently 
used case?  Probably not.  The only case I've ever used RENAME-FILE in Forth 
is in editors, where you write your new file as <name>+, and then rename the 
old file to <name>~ and the new file to <name>.  Ok, well, maybe I've used 
RENAME-FILE on some systems where the obnoxious file manager didn't allow 
some names, which the file system itself allowed, and then Forth came to 
rescue (e.g. Android).

Whether there should be a buffer in all cases is also a bit questionable: 
The way small systems deal with s" is to define the interactive part as

'"' parse

and leave the string in the input buffer.  This allows to have as many 
strings as you want, granted they fit into a single line (together with the 
operation), which is usually limited to 80 characters.

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

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

#29023

Meh. Why not just bite the bullet: Define interpretation semantics for S". That would be *far* more useful, since it's in core. Then assert that S\" interpretation semantics are that of S" and be done with it.

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

#29024

Mark Wills wrote:

> Meh. Why not just bite the bullet: Define interpretation semantics for S".
> That would be *far* more useful, since it's in core. Then assert that S\"
> interpretation semantics are that of S" and be done with it.

Oh, Mark, we already do that.  Well, the interpretation semantics is in the 
file wordset, just as with S\".  And of course S\"'s interpretation semantic 
differs from S"'s by interpreting \<char>.

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

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

#29027

Hi Bernd. I think you mis-understand me. S" has no interpretation semantics. I checked (the 200x standard). And that is kind of where the real issue of the problem lies. S" has well defined compilation semantics, because it's easy to know what to do at compile time: compile the string into the definition.

We avoid specifying interpretation semantics for S" because it gets messy. Where do we put the string? Do we leave it in place? If so, how long is it available for? Do we allocate space for it on the heap? If so, what frees the space? Etc etc. It's hard to sepcify the behaviour of S" at interpretation time.

And we're in exactly the same position with S\". How do we specify the interpretation semantics? Well, if (big if ;-) we could specify the interpretation semantics for S" then S\" , having decoded its string, can simply call S" do the "work" of compiling it into a definition, or performing the interpretation semantics, since you'll want the interpretation/compilation semantics of the two words to be the same. S\" only differs in terms of how it decodes its string; its semantics should be the same.

So, what I'm saying is, we could kill two birds with one stone if we can agree on interpretation semantics for S". Why S" specifically? Because S" is in CORE, so we add more utility/get more bang for the buck by targeting S".

Just my two pennies worth.

Mark

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

#29028

Op Wed, 12 Mar 2014 06:25:31 -0700 (PDT) schreef Mark Wills:

> Hi Bernd. I think you mis-understand me. S" has no interpretation semantics. I checked (the 200x standard). And that is kind of where the real issue of the problem lies. S" has well defined compilation semantics, because it's easy to know what to do at compile time: compile the string into the definition.
> 
> We avoid specifying interpretation semantics for S" because it gets messy. Where do we put the string? Do we leave it in place? If so, how long is it available for? Do we allocate space for it on the heap? If so, what frees the space? Etc etc. It's hard to sepcify the behaviour of S" at interpretation time.
> 
> And we're in exactly the same position with S\". How do we specify the interpretation semantics? Well, if (big if ;-) we could specify the interpretation semantics for S" then S\" , having decoded its string, can simply call S" do the "work" of compiling it into a definition, or performing the interpretation semantics, since you'll want the interpretation/compilation semantics of the two words to be the same. S\" only differs in terms of how it decodes its string; its semantics should be the same.
> 
> So, what I'm saying is, we could kill two birds with one stone if we can agree on interpretation semantics for S". Why S" specifically? Because S" is in CORE, so we add more utility/get more bang for the buck by targeting S".
> 
> Just my two pennies worth.
> 
> Mark

6.1.2165 S" is in CORE and compilation semantics only but 11.6.1.2165 S" is
in FILE ACCESS and has interpretation semantics.
You lose EUR 0,02 ;(

-- 
Coos

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

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

#29030

Coos Haak wrote:
> 6.1.2165 S" is in CORE and compilation semantics only but 11.6.1.2165 S"
> is in FILE ACCESS and has interpretation semantics.
> You lose EUR 0,02 ;(

And that's what he asks for is just what we do: Specify the interpretation 
semantics of S" and S\", specify where the strings go (in now at least two 
string buffers with at least 80 characters each), etc..

I was about to suggest adding a cross reference, but of course there already 
is one.

FWIW, while we are at changing S" and S\": For all those maybe-state-smart 
words (or however they are implemented), which have different interpretation 
and compilation semantics, there must be a

"Note: An ambiguous condition exists if any of POSTPONE, [COMPILE], ’ or [’] 
are applied to <word>."

boilerplate before the cross-reference line (just as for TO).

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

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

#29038

On Wed, 12 Mar 2014 13:25:31 -0000, Mark Wills <markwills1970@gmail.com>  
wrote:
>
> So, what I'm saying is, we could kill two birds with one stone if we can  
> agree on interpretation semantics for S". Why S" specifically? Because  
> S" is in CORE, so we add more utility/get more bang for the buck by  
> targeting S".

Isn't that exactly what this proposal attempting to do?  Its doing in
FILE rather than CORE, but otherise...

-- 
Peter Knaggs

[toc] | [prev] | [standalone]

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

csiph-web