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

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

RfD: Interpret S\"

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

Contents

  RfD: Interpret S\" "Peter Knaggs" <pjk@bcs.org.uk> - 2014-02-25 01:14 +0000
    Re: RfD: Interpret S\" "Alex McDonald" <blog@rivadpm.com> - 2014-02-25 08:26 +0000
    Re: RfD: Interpret S\" stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-25 09:29 +0000
      Re: RfD: Interpret S\" m.a.m.hendrix@tue.nl - 2014-02-25 03:43 -0800
        Re: RfD: Interpret S\" Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:46 +0100
      Re: RfD: Interpret S\" albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-25 12:25 +0000
      Re: RfD: Interpret S\" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 11:00 +0000
        Re: RfD: Interpret S\" stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-26 15:18 +0000
          Re: RfD: Interpret S\" "Elizabeth D. Rather" <erather@forth.com> - 2014-02-26 08:28 -1000
        Re: RfD: Interpret S\" Mikael Nordman <oh2aun@gmail.com> - 2014-02-26 12:33 -0800
          Re: RfD: Interpret S\" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-27 15:00 +0000
    Re: RfD: Interpret S\" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-25 04:55 -0600
      Re: RfD: Interpret S\" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 11:53 +0000

#28758 — RfD: Interpret S\"

Interpret S\"
=============

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 no less than 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\" 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) Add S\" to the list of string compilation words in 3.3.3.4 Text-
    literal regions:

         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. An ambiguous
         condition exists when a program attempts to store
         into read-only regions.

-- 
Peter Knaggs

[toc] | [next] | [standalone]

#28766

on 25/02/2014 01:14:26, "Peter Knaggs" wrote:

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

The same may be said for C". Can this be addressed here too?

[snip]
> S" and S\" share the same buffers.

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

[snip]
> 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. An ambiguous
> condition exists when a program attempts to store
> into read-only regions.
> 

The ambiguous condition is superfluous given "shall not".

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

#28768

On Tue, 25 Feb 2014 01:14:28 -0000, "Peter Knaggs" <pjk@bcs.org.uk>
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".

While I agree that multiple buffers for S" and S\" are useful, RAM
is very limited on embedded systems, even those that have file
systems. Even on 32 bit embedded systems, we run out of RAM long
before we run out of Flash space. We are not going to use more
RAM just to ease the very occasional interactive use of RENAME-FILE.

I am currently against having to have an embedded subset for Forth,
but am willing to be persuaded.

On the desktop, it's a different matter. I know that a number of
desktop Forths, including VFX, support multiple buffers. Which
ones do not?

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#28772

On Tuesday, February 25, 2014 10:29:03 AM UTC+1, Stephen Pelc wrote:
> On Tue, 25 Feb 2014 01:14:28 -0000, "Peter Knaggs" <pjk@bcs.org.uk> 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". 
[..]
> While I agree that multiple buffers for S" and S\" are useful, 
> RAM is very limited on embedded systems, even those that have 
> file systems. Even on 32 bit embedded systems, we run out of 
> RAM long before we run out of Flash space. We are not going 
> to use more RAM just to ease the very occasional interactive
> use of RENAME-FILE. 

As the size of an S" or S\" buffer is unlimited, I don't think 
it matters that you can have more than one of them.

-marcel

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

#28898

m.a.m.hendrix@tue.nl wrote:
> As the size of an S" or S\" buffer is unlimited, I don't think
> it matters that you can have more than one of them.

The standard only requires the buffer to be 80 characters long, not 
unlimited.  So it's essentially 80 more characters to be wasted on a 
precious embedded system...

The solution I've used on Gforth EC is that S" in interpretation mode 
actually just returns the input buffer space, so it doesn't live longer than 
the current line.  This works just fine, and it even would allow a RENAME-
FILE, if Gforth EC had the file word-set (it doesn't, but using S" in 
interpretation mode is still a good idea).  In so far as I don't claim that 
Gforth EC implements the File wordset, the S" is "standard", because its 
interpretation semantics is undefined.  The choice is the one I think is 
most reasonable on an embedded system.  S\" is not implemented, and never 
will (on Gforth EC), it wastes way too much precious memory to be 
implemented.

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

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

#28774

In article <530c6015.1058201878@news.demon.co.uk>,
Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>On Tue, 25 Feb 2014 01:14:28 -0000, "Peter Knaggs" <pjk@bcs.org.uk>
>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".
>
>While I agree that multiple buffers for S" and S\" are useful, RAM
>is very limited on embedded systems, even those that have file
>systems. Even on 32 bit embedded systems, we run out of RAM long
>before we run out of Flash space. We are not going to use more
>RAM just to ease the very occasional interactive use of RENAME-FILE.
>
>I am currently against having to have an embedded subset for Forth,
>but am willing to be persuaded.
>
>On the desktop, it's a different matter. I know that a number of
>desktop Forths, including VFX, support multiple buffers. Which
>ones do not?

ciforth doesn't, strictly speaking. All quoted strings are permanently
allocated in the dictionary. There are no buffers, and no overruns.

After
    "AAP" $,
you'll see AAP two times in the dictionary and only FORGET can
get rid of it.

This is terribly crude, but I've never seen a disadvantage.

>
>Stephen

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]

#28782

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>While I agree that multiple buffers for S" and S\" are useful, RAM
>is very limited on embedded systems, even those that have file
>systems. Even on 32 bit embedded systems, we run out of RAM long
>before we run out of Flash space. We are not going to use more
>RAM just to ease the very occasional interactive use of RENAME-FILE.

Two ways out:

1) We leave the number of buffers at one; users can write standard
code for interpretive use of RENAME-FILE that uses PARSE or PARSE-NAME
such as

parse-name file1 s" file2" rename-file

(or they write non-standard code).

2) We standardize "at least two" buffers, and systems that don't want
to provide that have an environmental restriction.

- 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 2013: http://www.euroforth.org/ef13/

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

#28787

On Wed, 26 Feb 2014 11:00:34 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>stephenXXX@mpeforth.com (Stephen Pelc) writes:
>>While I agree that multiple buffers for S" and S\" are useful, RAM
>>is very limited on embedded systems, even those that have file
>>systems. Even on 32 bit embedded systems, we run out of RAM long
>>before we run out of Flash space. We are not going to use more
>>RAM just to ease the very occasional interactive use of RENAME-FILE.
>
>Two ways out:
>
>1) We leave the number of buffers at one; users can write standard
>code for interpretive use of RENAME-FILE that uses PARSE or PARSE-NAME
>such as
>
>parse-name file1 s" file2" rename-file
>
>(or they write non-standard code).
>
>2) We standardize "at least two" buffers, and systems that don't want
>to provide that have an environmental restriction.

I suspect that most embedded system Forths already have environmental
restrictions, so adding another one makes little difference.

In the longer term, standardising an embedded subset of Forth200x
may be a good thing to do.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#28789

On 2/26/14 5:18 AM, Stephen Pelc wrote:
> On Wed, 26 Feb 2014 11:00:34 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>> stephenXXX@mpeforth.com (Stephen Pelc) writes:
>>> While I agree that multiple buffers for S" and S\" are useful, RAM
>>> is very limited on embedded systems, even those that have file
>>> systems. Even on 32 bit embedded systems, we run out of RAM long
>>> before we run out of Flash space. We are not going to use more
>>> RAM just to ease the very occasional interactive use of RENAME-FILE.
>>
>> Two ways out:
>>
>> 1) We leave the number of buffers at one; users can write standard
>> code for interpretive use of RENAME-FILE that uses PARSE or PARSE-NAME
>> such as
>>
>> parse-name file1 s" file2" rename-file
>>
>> (or they write non-standard code).
>>
>> 2) We standardize "at least two" buffers, and systems that don't want
>> to provide that have an environmental restriction.
>
> I suspect that most embedded system Forths already have environmental
> restrictions, so adding another one makes little difference.
>
> In the longer term, standardising an embedded subset of Forth200x
> may be a good thing to do.

Whatever became of the project to update the proposed Forth cross 
compiler standard and get it passed?

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]

#28791

On Wednesday, February 26, 2014 1:00:34 PM UTC+2, Anton Ertl wrote:
> stephenXXX@mpeforth.com (Stephen Pelc) writes:
> >While I agree that multiple buffers for S" and S\" are useful, RAM
> >is very limited on embedded systems, even those that have file
> >systems. Even on 32 bit embedded systems, we run out of RAM long
> >before we run out of Flash space. We are not going to use more
> >RAM just to ease the very occasional interactive use of RENAME-FILE.
> 
> Two ways out:
> 1) We leave the number of buffers at one; users can write standard
> code for interpretive use of RENAME-FILE that uses PARSE or PARSE-NAME
> such as
> 
> parse-name file1 s" file2" rename-file
>
> (or they write non-standard code).
> 
Why is a buffer needed at all if the strings are processed on the same line ?

In a small embedded system you can implement s" so that it gives addr/len
directly into the input buffer. No copying anywhere unless PLACE is used.
That would gives some restrictions but works if the strings are  processed on the same line.

s" file1" s" file2" rename-file 

I am using this principle in FlashForth which works with less than 1 Kbyte of ram. Also WORD just writes the length byte directly into TIB. Ugly but saves space. 

But I guess all of this falls under s" non-standard" :-)

Mikael
--
http://flashforth.sourceforge.net

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

#28801

Mikael Nordman <oh2aun@gmail.com> writes:
>Why is a buffer needed at all if the strings are processed on the same line ?
>
>In a small embedded system you can implement s" so that it gives addr/len
>directly into the input buffer.
...
>But I guess all of this falls under s" non-standard" :-)

Correct.  Or "system with an environmental restriction".  Which may be
a good compromise for your users.

It's a little worse for S\".  There the string is translated, so you
have the choice of using a buffer for that, or you do the translation
in-place and have restrictions on the use of SOURCE and >IN.

- 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 2013: http://www.euroforth.org/ef13/

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

#28771

Peter Knaggs <pjk@bcs.org.uk> 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".

From a language design viewpoint this is generally a bad idea: the
"zero, one, or infinity" (ZOI) rule of software design suggests that
one should not place random limits on the number of instances of a
given entity.  IMO there are already far too many apparently arbitrary
limits in Standard Forth.

Having said that, I don't how to implement a system that permits many
string buffers in a Forth system because there isn't usually a garbage
collector.  So, perhaps I'm being idealistic.  For interactive use I'd
be very tempted just to allocate buffers and throw them all away on an
ABORT, but I'm not proposing that such a thing should be standard.

Andrew.


http://www.catb.org/jargon/html/Z/Zero-One-Infinity-Rule.html

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

#28783

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>For interactive use I'd
>be very tempted just to allocate buffers and throw them all away on an
>ABORT, but I'm not proposing that such a thing should be standard.

Throwing away on ABORT would be non-standard indeed (although I doubt
that many would notice).

"Just allocate" works fine in practice, though.

- 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 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [standalone]

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

csiph-web