Peter said:

> Ed raised an interesting point in his comments. In that the reference
> implementation uses the PAD. The standard makes a point of stating that
> the PAD is for the application programmer, and that no standard word
> will use it. Thus I have re-worked the reference implementation to
> replace the escaped string in situ. While this is frowned on by the
> standard, writing into source, it is allowed.
>
> The change is actually fairly minor, it simple requires the definition
> of readEscape to be replace with the following:
>
> : readEscape
> source >in @ /string
> tuck over 1- dup >r
> parse\"
> nip - >in +!
> r>
> ;
>
> I have checked this on several system and they are all happy with it.

This fine for hosted systems running in RAM. PARSE\" requires a
writable destination area. In embedded systems, it is not
unusual to store text such as web scripts in Flash. Thus read-
only memory can easily become the input stream. I would much
rather leave the reference implementation alone, but state that
it is not standard because of its use of PAD.

Mitch said:
> Will there be problems if the string to be modified is in ROM, as with a
> string compiled into a colon definition in a ROM dictionary?

Yes.

Peter said:
> It shouldn't do, as S\" returns a string, which is then copied into the
> ROM space at compile time, the same as for S".

So it's in ROM at run time, and the assumption is that it is
expanded at compile time, which is true unless it is interpreted
at run time, e.g. for a web script.

Regardless what the standard says, the majority of Forth systems
(common practice) permit interpretation of S" and friends.

Regards, Stephen
--
Stephen Pelc, stephen@...
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