Message from discussion
RfD: Escaped Strings
Path: g2news2.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!sn-xt-sjc-02!sn-xt-sjc-09!sn-post-sjc-01!supernews.com!news.supernews.com!not-for-mail
From: Elizabeth D Rather <erather...@forth.com>
Newsgroups: comp.lang.forth
Subject: Re: RfD: Escaped Strings
Date: Wed, 31 Oct 2007 11:09:34 -1000
Organization: FORTH, Inc.
Message-ID: <13ihrofit8fvo93@news.supernews.com>
Reply-To: Elizabeth D Rather <erather...@forth.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
References: <13if7ovia4en139@corp.supernews.com> <02813424133560@frunobulax.edu>
In-Reply-To: <02813424133560@frunobulax.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@supernews.com
Lines: 54
Marcel Hendrix wrote:
> Peter Knaggs <pkna...@bournemouth.ac.uk> wrote Re: RfD: Escaped Strings S\" (version 5)
> [..]
>> Translation rules:
>> Characters are processed one at a time and appended to the
>> compiled string. If the character is a '\' character it is
>> processed by parsing and substituting one or more characters
>> as follows, where the character after the backslash is case
>> sensitive:
>> \a BEL (alert, ASCII 7)
> [..]
>> \\ backslash itself
>> \ An ambiguous condition exists if a \ is placed before any
>> character, other than those defined in 6.2.xxxx S\".
> [..]
>
> Why was it necessary to make this an ambiguous condition?
> S\" is not used by any systems not represented in the Forth 200x effort.
> IMHO it is a bit silly (for a standards effort) not to mention all \<char>
> codes in use today, and/or to allow future vendor-specific extensions that
> will break portability of code and require work-arounds.
>
> A general solution could be to require that a deferred (and standardized)
> hook word is executed in case an unknown code is encountered. This would
> guarantee that any future S\" problems can be fixed by user code.
> Thinking this through should convince most people that simply forbidding
> non-standard \-codes is by far preferable.
I don't have any strong feelings about this particular instance of an
"ambiguous condition", but want to suggest that a more appropriate way
of looking at it is that the proposed standard would *guarantee* success
with the listed codes, but make no guarantees about others. That's a
more positive view than saying that codes not on the list are
"forbidden". In general, that's how most "ambiguous conditions" are
intended: some, of course, are errors, but others are merely cases in
which no specific behavior is mandated.
IMO hooks such as you suggest shouldn't be mandated, but implementors
who see a need or value can provide them.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
|
