CfV: Extension queries
Anton Ertl
and how popular it is among the programmers. It is called a CfV
(call-for-votes) because the process is inspired by the Usenet Rdf/CfV
process.
You find the actual ballot further down (look for "VOTING PROCEDURE"),
after the proposal on which you vote.
Since there were no normative changes since the last RfD, and the
discussion seemed to bring up no new issues, I decided to go ahead
with the CfV.
- anton
CHANGE HISTORY
2005-03-16
No change in the normative section. Made reference implementation
case-insensitive. Added non-normative section on naming
guidelines. Fixed typo.
2nd RfD 2005-01-17
No change to the normative section. New, non-trivial reference
implementation. More discussion of "Why not let ENVIRONMENT?
return a flag and true, like for wordset queries?" and "Why the
"X:" prefix?". New sections "Won't there be too many extension
names?", "How about defining a way to query for implementor
extensions?", "Why not just ask for word names with [UNDEFINED]?"
PROBLEM
How does a program know whether the system it runs on supports one of
the extensions that ran through the RfD/CfV process, so that the
program can implement the extension itself or work around its absence?
PROPOSAL
If the string passed to ENVIRONMENT? starts with "X:", ENVIRONMENT?
returns false if the system does not implement the extension indicated
by the query string in full, or if there is no such extension that has
gone to a CfV.
For an extension from the list of CfVs
<http://www.complang.tuwien.ac.at/forth/ansforth/rfds.html>, take the
linked-to filename, delete the ".html", and prepend "X:" to construct
a query string for the extension.
If the system implements the extension, ENVIRONMENT? may return true
(without additional values) or false.
TYPICAL USE
S" X:deferred" ENVIRONMENT? 0= [IF]
... \ reference implementation of the deferred words proposal
[THEN]
REMARKS
Why allow returning false when the system supports the extension?
Returning false when the system supports the extension will usually be
safer than returning true when the system does not support the
extension; in the former case the program will be slower, or have
degraded features; in the latter case the program will usually fail in
unpredictable ways.
Therefore, systems must not return true for extensions that have not
yet gone to a CfV (the proposal for the extension could still change).
So, if a system happens to already support the extension, it will have
to report false on queries for the extension at least from the time
when the proposal goes to a CfV until the time that an update of the
system with updated extension queries is released.
Moreover (and possibly more importantly), this feature means that
systems whose implementors have never heard of (or ignore) RfDs and
CfVs will work correctly for extension queries (as long as they don't
support any queries starting with "X:" on their own), so a program
written to cope with this specification will usually work correctly
even on such systems.
Why not let ENVIRONMENT? return a flag and true, like for wordset queries?
This proposal is easier to use. What is the point of returning an
extra flag? "Yes, we have heard of that extension, but no, we have not
implemented it"? That's not a useful information to have; what should
a program do with that information?
Mitch Bradley and Guido Draheim would prefer a wordset-query-like
behaviour, i.e., an additional flag if ENVIRONMENT? returns
true. Richard Borrell would prefer a single flag (i.e., the proposed
behaviour).
With the wordset-query-like behaviour, the typical use above would
look like:
S" X:deferred" ENVIRONMENT? dup [IF]
drop
[THEN]
0= [IF]
... \ reference implementation of the deferred words proposal
[THEN]
Here are some statistics about the use of ENVIRONMENT? in general and
wordset queries in particular in ANS Forth programs:
Program Author ENVIRONMENT? wordset queries
brainless David Kuehling yes no
brew-0_03z9 Robert Epprecht yes no
brew_..._38 Robert Epprecht yes floating-ext
CD16v11 Brad Eckert no no
anagrams Wil Baden no no
pentomino Bruce Hoyt no no
tscp Ian Osgood no no
Gray4 Anton Ertl yes no
garbage-coll Anton Ertl yes no
I believe that one of the reason that wordset queries are used so
rarely is that they are so cumbersome to use (that's certainly one of
the reasons that kept me from using it).
Why the "X:" prefix?
This will hopefully ensure that there is no naming conflict with any
existing environmental query of any system; it also reserves a part of
the environmental query name space (by requiring a false result for
anything that has not gone to a CfV), without consuming all of it.
If you know of any name conflict of the "X:" prefix with an existing
system and have a better suggestion for a prefix, let me know.
Bruce McFarling has suggested changing the prefix such that the query
string can be used as a filename on DOS/Windows. However the prefix
can be cut away easily, leading to a filename compatible with
DOS/Windows (if the extension name is compatible), as the reference
implementation demonstrates.
Guido Draheim suggested using a suffix, as it has advantages with
input completion. A prefix can also be used to profit with input
completion, and overall this issue does not seem very
important. Prefixes are more traditional for tagging names in programs
(while suffixes are used for file names).
What about extension proposals that have not (yet) gone to a CfV?
If you want to introduce queries for them, do it with a different
prefix.
Why not include extension proposals that have not (yet) gone to a CfV?
They may still change before they go to a CfV, so it would not be
clear if the system and the querying program refer to the same
proposal.
Won't there be too many extension names?
Guido Draheim thinks that we will see many backwards-compatible
revisions of proposals, so the number of extension names that should
be known around for a the extensions would be a problem (since the nth
revision would satisfy the requirements of revision 1-n, and thus n
names would have to be kept around).
One way to deal with this would be to use a consistent naming scheme
for backwards-compatible extensions: deferred, deferred-2, deferred-3
etc. Then the system just needs to store the base name and the current
revision number, and can check with a little code whether the
queried-for extension is supported.
Keeping this naming scheme would be the responsibility of the person
who maintains the list of CfVs. (It's not the responsibility of the
system implementor and therefore not in the normative part of this
proposal).
How about defining a way to query for implementor extensions?
Guido Draheim suggested this. With this one system implementor could
formally define an extension, and another system could adopt that
extension, and programs could query for this extension.
Doing this would require reserving some part of the ENVIRONMENT? name
space for implementor-extension queries, with each query having an
implementor part, and an extension name. A naming authority would
assign implementor part names to implementors, and the implementor would
assign extension part names. (Actually the implementor could use
it for arbitrary queries, not just extension queries).
I am not convinced that there is enough demand for that. In any case,
I would like to see it handled in a separate RfD/CfV.
Why not just ask for word names with [UNDEFINED]?
Hans Bezemer and Albert van der Horst favour this approach.
That only tells whether a word exists in the system, but not how it
behaves.
It would also require asking separately for each word. And for
on-demand loading, it would require organizing each word
separately. Lots of effort for the programmer and the system
implementor.
Guidelines for extension names
Extension names should limited to 29 characters (excluding the "X:"
prefix), so they can be stored into a wordlist systems with 31-char
names.
The names of the extension queries (excluding the "X:" prefix) and the
file names of the reference implementations should be lower case, so
that the reference implementation of extension queries works on
case-sensitive file systems (most Forth systems and the reference
implementation match extension-query names case-insensitively, but
making that standard is another RfD).
The names of the extension queries (excluding the "X:" prefix) should
only contain printable ASCII characters that are allowed in all common
file systems; it's probably best to just use alphanumeric characters
and the "-".
Implementation and Tests
* Reference implementation
<http://www.complang.tuwien.ac.at/forth/ansforth/reference-implementations/extension-query.fs>;
to make it useful, you should also download and unpack
<http://www.complang.tuwien.ac.at/forth/ansforth/extensions.zip>,
containing a directory of reference implementations of voted-on
extensions (if available).
* Tests
EXPERIENCE
All ANS Forth systems I know implement this proposal in a minimal way
(answer all queries with false). None implement it in a non-minimal
way. No programs have used the proposal yet.
VOTING PROCEDURE
Fill out the appropriate ballot(s) below and mail it/them to me
(followup is set to poster). Your vote will be published
(including your name (without email address) and/or the name of your
system) on
<http://www.complang.tuwien.ac.at/forth/ansforth/extension-query.html>. The
results will also be posted here in two weeks. You can continue
voting (or changing your vote) afterwards by mailing to me, and the
results will be published on the Web.
Note that you can be both a system implementor and a programmer, so
you can submit both kinds of ballots.
BALLOT FOR SYSTEMS
If you maintain several systems, please mention the systems separately
in the ballot. Insert the system name or version between the
brackets. Multiple hits for the same system are possible (if they do
not conflict).
Since most ANS Forth systems already support this proposal in full
in a minimal way (i.e., they return false on every extension query),
this ballot also asks for non-minimal support.
Note that for this proposal non-implementation means that you
reserve the right to answer "X:" queries with true even if you do not
implement the queried-for extension. If the system answers the query
with false, it supportsthe proposal in full in a minimal way.
[ ] conforms to ANS Forth.
[ ] already implements the proposal in full since release [ ].
[ ] implements the proposal in full in a development version.
[ ] implements the proposal in full non-minimally in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full non-minimally in release [ ].
[ ] will implement the proposal in full in some future release.
[ ] will implement the proposal in full non-minimally in some future release.
There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.
If you want to provide information on partial implementation, please
do so informally, and I will aggregate this information in some way.
BALLOT FOR PROGRAMMERS
Just mark the statements that are correct for you (e.g., by putting an
"x" between the brackets). If some statements are true for some of
your programs, but not others, please mark the statements for the
dominating class of programs you write.
[ ] I have used (parts of) this proposal in my programs.
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it.
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it non-minimally.
[ ] I would use (parts of) this proposal in my programs if this
proposal was in the Forth standard.
[ ] I would not use (parts of) this proposal in my programs.
If you feel that there is closely related functionality missing from
the proposal (especially if you have used that in your programs), make
an informal comment, and I will collect these, too. Note that the
best time to voice such issues is the RfD stage.
--
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.complang.tuwien.ac.at/forth/ansforth/forth200x.html
Ian Osgood
>
...
> Program Author ENVIRONMENT? wordset queries
> tscp Ian Osgood no no
FCP does do lots of conditional compilation based on the presence of
individual words:
[DEFINED] defer [IF]
...
[ELSE]
...
[THEN]
This mechanism was also used to define a portable millisecond timer
word (ms@) and to define [DEFINED] and [UNDEFINED] from FIND if needed.
I also avoided words that did not have portable behavior (FM/MOD
instead of MOD, for example).
(At the time, I was learning Forth knowing only C's #ifdef constructs.
Instead of using ENVIRONMENT, I documented a bunch of the restrictions
in the comment header of the program.)
Ian
Anton Ertl
Systems
[ ] conforms to ANS Forth.
Gforth
[ ] already implements the proposal in full since release [ ].
[ ] implements the proposal in full in a development version.
Gforth
[ ] implements the proposal in full non-minimally in a development version.
Gforth
[ ] will implement the proposal in full in release [ ].
Gforth 0.7
[ ] will implement the proposal in full non-minimally in release [ ].
Gforth 0.7
[ ] will implement the proposal in full in some future release.
[ ] will implement the proposal in full non-minimally in some future release.
There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.
Programmers
[ ] I have used (parts of) this proposal in my programs.
Anton Ertl
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it.
David N. Williams
Anton Ertl
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it non-minimally.
David N. Williams
Anton Ertl
[ ] I would use (parts of) this proposal in my programs if this
proposal was in the Forth standard.
David N. Williams
Anton Ertl
[ ] I would not use (parts of) this proposal in my programs.
Further Voting and Web version
You can still vote by sending me your vote by email, and the result
will be published in the Web. The proposal, the voting instructions,
and the results are available at
<http://www.complang.tuwien.ac.at/forth/ansforth/extension-query.html>
- anton
ward mcfarland
> You can still vote by sending me your vote by email, and the result
> will be published in the Web. The proposal, the voting instructions,
> and the results are available at
> <http://www.complang.tuwien.ac.at/forth/ansforth/extension-query.html>
I do not see the voting instructions on that page.
I have no plans to include this in MacForth at present. However, it is
trivial to add additional ENVIRONMENT? responses for anything at any
time, except our method for doing so requires returning an additional
item if the result is true. I do not see an easy way to change our
mechanism for registering ENVIRONMENT? calls to return just a true flag
for some items.
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>
>> You can still vote by sending me your vote by email, and the result
>> will be published in the Web. The proposal, the voting instructions,
>> and the results are available at
>> <http://www.complang.tuwien.ac.at/forth/ansforth/extension-query.html>
>
>I do not see the voting instructions on that page.
Thanks. Fixed.
>I have no plans to include this in MacForth at present.
Well, I assume that MacForth implements it minimally (i.e., returns
false for all extension queries), like everyone else.
> However, it is
>trivial to add additional ENVIRONMENT? responses for anything at any
>time, except our method for doing so requires returning an additional
>item if the result is true. I do not see an easy way to change our
>mechanism for registering ENVIRONMENT? calls to return just a true flag
>for some items.
An easy way would be to include the reference implementation:
http://www.complang.tuwien.ac.at/forth/ansforth/extensions/extension-query.fs
ward mcfarland
> An easy way would be to include the reference implementation:
>
> http://www.complang.tuwien.ac.at/forth/ansforth/extensions/extension-query.fs
That works, but I have several issues that make me reluctant to add it:
1. It was bad enough that ANS ENVIRONMENT? had 2 optional return stack
maps, this adds a 3rd option.
2. I have basic reluctance to overload standard defintions.
3. ENVIRONMENT? is cleary a query, yet your version acts like an action
verb and may try to include a file.
4. I dislike hard-coding directory path names into compiled code.
5. It is a fair amount of code to do what I would do currently as
LACKING SOMEWORD S" SOMEDIRECTORY/SOMEFILE" INCLUDED
Your function is a bit ingenious. I would see your function better
served with a new name. A pithy one does not come to mind at the moment
but it should express the function of your word: LOAD-IF-LACKING
MAYBE-INCLUDE
These could have the added advantage of posting an error if the required
file is not available. Your proposal would require this sort of thing
in practice for every invocation:
s" X:deferred" environment?
not [IF] cr .( Requires Deferred extension file)
-- w
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>
>> An easy way would be to include the reference implementation:
>>
>> http://www.complang.tuwien.ac.at/forth/ansforth/extensions/extension-query.fs
>
>That works, but I have several issues that make me reluctant to add it:
>
>1. It was bad enough that ANS ENVIRONMENT? had 2 optional return stack
>maps, this adds a 3rd option.
What are "return stack maps"?
>3. ENVIRONMENT? is cleary a query, yet your version acts like an action
>verb and may try to include a file.
As I understand it, ENVIRONMENT? may do that already, e.g., when one
is querying for a wordset; and AFAIK PFE does something like this for
some wordset queries. Also, A.3.2.6 says:
|For example an application might test for the presence of the Double
|Number word set using an environment query. If it is missing, the
|system could invoke a system-dependent process to load the word set.
Anyway, if you don't like the loading part, you can just remove or
disable that part of the reference implementation, and just use
s" deferred" insert-extension
to declare the presence of the deferred words extension.
A simple way to disable the loading part is to have an empty
extensions directory.
>4. I dislike hard-coding directory path names into compiled code.
I dislike it, too. But what should I do instead (especially in
standard code)?
>5. It is a fair amount of code to do what I would do currently as
> LACKING SOMEWORD S" SOMEDIRECTORY/SOMEFILE" INCLUDED
True, it is a fair amount of code, but:
- It is pretty standard and portable (ok, you still need to adjust the
directory); if I had relied on, e.g., Gforth extensions, it would be
smaller. You can probably make it smaller by using extensions of your
system.
- It is set up to cooperate with and make best use of the support for
the extension queries that the system already has.
- If you are into having little code loaded (for little RAM usage), it
might eventually (once there are lots of reference implementations
around) save much more than it costs.
- If, OTOH, you have the extensions loaded all the time anyway, you
can disable the loading part, which consumes the bulk of the code.
- It's just one implementation. If it does not suit your needs, you
can do your own. Or you can use this implementation now and replace
it with something smaller or otherwise better when you find the time.
E.g., in Gforth the non-minimal implementation of the proposal
consisted of adding the following code in the appropriate place
' noop alias X:deferred
' noop alias X:extension-query
As for LACKING, various such schemes have been discussed during the
RfD phase, and I don't want to repeat that discussion here.
>Your function is a bit ingenious. I would see your function better
>served with a new name. A pithy one does not come to mind at the moment
>but it should express the function of your word: LOAD-IF-LACKING
>MAYBE-INCLUDE
Are you thinking of NEEDS or REQUIRE as implemented in Gforth,
Win32Forth, and others (but where the names were destroyed by later
conflicting definitions from other people)? I would see that as a
separate issue with a separate proposal.
>These could have the added advantage of posting an error if the required
>file is not available. Your proposal would require this sort of thing
>in practice for every invocation:
> s" X:deferred" environment?
> not [IF] cr .( Requires Deferred extension file)
Actually typical usage would be
s" X:deferred" environment? not [if] s" deferred.fs" included [then]
However, an alternative is:
s" extensions/extension-queries.fs" included \ reference implementation
s" X:deferred" environment? drop
Thus the application will load the reference implementation for
extension-queries, and the query for X:deferred will ask the system
whether the extension "deferred" is available, and if not (or not
known), load the reference implementation for this extension that came
with the application.
ward mcfarland
> >3. ENVIRONMENT? is clearly a query, yet your version acts like an action
> >verb and may try to include a file.
>
> As I understand it, ENVIRONMENT? may do that already, e.g., when one
> is querying for a wordset; and AFAIK PFE does something like this for
> some wordset queries. Also, A.3.2.6 says:
>
> |For example an application might test for the presence of the Double
> |Number word set using an environment query. If it is missing, the
> |system could invoke a system-dependent process to load the word set.
I do not understand "the system" to mean that the query word would do
it. In fact, the statement "could invoke a system-dependent process"
implies to me the contrary.
> Anyway, if you don't like the loading part, you can just remove or
> disable that part of the reference implementation, and just use
>
> s" deferred" insert-extension
>
> to declare the presence of the deferred words extension.
>
> A simple way to disable the loading part is to have an empty
> extensions directory.
We have our own method for appending environment items that can return
i*x items and do not need "insert-extension". I would agree that each
new "standard extension" should specify an environment query string and
response. I do not agree that the best way to do it is to redefine the
behavior of an ANS core word. And I still have real issue with using a
word that is clearly a query to take an action that changes the
environment? Would you have " x-raining" environment? seed some clouds
if the sun were out?
The other failing of your definition, imo, is that it does not stop
compilation if it does not find the required file in the "standard"
location. I would have it do ABORT" if it fails. Else, the compilation
will fail later on "missingextword" which the user may not recognize
that is was supposed to be part of a required extension.
> However, an alternative is:
>
> s" extensions/extension-queries.fs" included \ reference implementation
> s" X:deferred" environment? drop
>
> Thus the application will load the reference implementation for
> extension-queries, and the query for X:deferred will ask the system
> whether the extension "deferred" is available, and if not (or not
> known), load the reference implementation for this extension that came
> with the application.
And what happens if s" extensions/extension-queries.fs" was already
loaded when this bit of code was encountered? Since I typically preface
most files with a forgettable marker to allow re-including, that line
would cause all subsequent files to be forgotten. Not a nice behavior.
And s" X:deferred" environment? drop again fails to notify the user if
the included file was not found.
I would have interest in a word/short phrase that does what you propose,
with one addition:
1. tests for the presence of an extension
2. attempts to load that extension if it is not found
3. reports a meaningful error if it cannot find the extension file
I do not think ENVIRONMENT? is the word to do this. NEEDS or REQUIRES
wouldn't be bad. If you argue that these have been redefined by others,
why not re-redefine them? Why take an ANS word and redefine it to do
something it clearly was not intended to do?
-- w
Albert van der Horst
ward mcfarland <wa...@megawolf.com> wrote:
<SNIP>
>
>I do not think ENVIRONMENT? is the word to do this. NEEDS or REQUIRES
>wouldn't be bad. If you argue that these have been redefined by others,
>why not re-redefine them? Why take an ANS word and redefine it to do
>something it clearly was not intended to do?
If worries about REQUIRE relate to my ciforth:
1) ciforth is insignificant
2) In effect it uses REQUIRED ( adr len -- )
REQUIRE is an additional convenience that could be dropped easily
( Like INCLUDE / INCLUDED )
3) I would rename/drop it instantly as soon there is consensus
about some word that is officially called REQUIRE
4) I would rename it to WANT / WANTED if that word was safe in the sense
that nobody uses it. Or I would come up with yet another word.
But I don't like changing this several times.
Pending an official REQUIRE I still use that word, but this should
stop nobody from submitting a proposal for REQUIRE.
In particular I will not complain that the word is used in
ciforth with a different meaning.
[
( adr len -- ) REQUIRED
Try to make the word (adr len) available.
(Because there is no additional requirement, it is up to the system
how to do that. This can be by switching on a word list, load
a file or blocks, or by adding some binary stuff from a unix
library .a file.
The virtue of this word is that it does *not* assume any particular
means, INCLUDE directories, environment variables or a
hierarchical file system.)
It is not an error if the word cannot be made available, but
a warning is allowed (and nice).
Anton Ertl has objected that individual words should not be
required but wordsets.
]
>
> -- w
Groetjes Albert
--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>
>> >3. ENVIRONMENT? is clearly a query, yet your version acts like an action
>> >verb and may try to include a file.
>>
>> As I understand it, ENVIRONMENT? may do that already, e.g., when one
>> is querying for a wordset; and AFAIK PFE does something like this for
>> some wordset queries. Also, A.3.2.6 says:
>>
>> |For example an application might test for the presence of the Double
>> |Number word set using an environment query. If it is missing, the
>> |system could invoke a system-dependent process to load the word set.
>
>I do not understand "the system" to mean that the query word would do
>it.
ENVIRONMENT? is part of the system (this is wording from the standard,
where you have "the system" vs. "the program").
>In fact, the statement "could invoke a system-dependent process"
>implies to me the contrary.
I can't follow you here.
>> Anyway, if you don't like the loading part, you can just remove or
>> disable that part of the reference implementation, and just use
>>
>> s" deferred" insert-extension
>>
>> to declare the presence of the deferred words extension.
>>
>> A simple way to disable the loading part is to have an empty
>> extensions directory.
>
>We have our own method for appending environment items that can return
>i*x items and do not need "insert-extension".
Great! My suggestion was meant for the case where you would use this
reference implementation to get around the restriction you apparently
have on the kind of stack effects for environmental queries. But
since you do not like the reference implementation, go ahead and do it
in another way.
> I would agree that each
>new "standard extension" should specify an environment query string and
>response. I do not agree that the best way to do it is to redefine the
>behavior of an ANS core word.
The only way in which the _behaviour_ is redefined is by adding query
strings.
I guess what you mean is that you disapprove of extending the
implementation of that word by redefining the name.
>And I still have real issue with using a
>word that is clearly a query to take an action that changes the
>environment?
The answers given by ENVIRONMENT? are not changed. If the reference
implementation for X:deferred is there as a file, then querying for
X:deferred will always return true with the reference implementation
for extension queries.
>Would you have " x-raining" environment? seed some clouds
>if the sun were out?
If you provide the implementation of this extension:-).
>The other failing of your definition, imo, is that it does not stop
>compilation if it does not find the required file in the "standard"
>location. I would have it do ABORT" if it fails.
This is a query; the program can do with this information what it
wants, e.g., abort, load its own implementation of the extension, or
work around its absence. Does your ENVIRONMENT? ABORT" rather than
returning false when the user asks for a wordset that your system does
not provide?
You are apparently thinking of a word like INCLUDED or REQUIRED, but
ENVIRONMENT? is not such a word. The reference implementation does
load under some circumstances, but it is still primarily a mechanism
for communicating between the program and the system what the system
provides.
>> However, an alternative is:
>>
>> s" extensions/extension-queries.fs" included \ reference implementation
>> s" X:deferred" environment? drop
>>
>> Thus the application will load the reference implementation for
>> extension-queries, and the query for X:deferred will ask the system
>> whether the extension "deferred" is available, and if not (or not
>> known), load the reference implementation for this extension that came
>> with the application.
>
>And what happens if s" extensions/extension-queries.fs" was already
>loaded when this bit of code was encountered? Since I typically preface
>most files with a forgettable marker to allow re-including, that line
>would cause all subsequent files to be forgotten. Not a nice behavior.
That's the extensions/extension-query.fs that came with the
application, so it's up to the application whether the file has nice
behaviour. The reference implementation for extension queries
certainly behaves nicer; loading it again will just waste a little
space.
>And s" X:deferred" environment? drop again fails to notify the user if
>the included file was not found.
The application knows that ENVIRONMENT? will return true here: either
the system has deferred words and the system's ENVIRONMENT? answers
true when asked for X:deferred (the ideal case); or the application's
ENVIRONMENT? loads the extension/deferred.fs that came with the
application and then returns true.
Of course, if you want to flag unforseen errors (e.g., file error
because of badly installed application or other mishaps) where they
happen, you could write the query like this:
s" X:deferred" environment? 0= throw
>I would have interest in a word/short phrase that does what you propose,
>with one addition:
>1. tests for the presence of an extension
>2. attempts to load that extension if it is not found
>3. reports a meaningful error if it cannot find the extension file
One way to do that would be to load the extension-query reference
implementation, and then define:
: <unnamed> ( addr u -- )
environment? 0= abort" extension not available" ;
But I guess you don't like that.
>I do not think ENVIRONMENT? is the word to do this. NEEDS or REQUIRES
>wouldn't be bad.
NEEDS would be very bad. REQUIRES is not taken yet AFAIK; people
apparently prefer to destroy words that are already widely in use with
a different meaning, like REQUIRE.
>If you argue that these have been redefined by others,
>why not re-redefine them?
You will never get consensus on a word that has different meanings in
different systems, and adding another meaning does not help.
> Why take an ANS word and redefine it to do
>something it clearly was not intended to do?
Lets differentiate between the proposal and the reference
implementation. My impression is that your dislike is mainly for the
reference implementation, right?
The proposal extends ENVIRONMENT? with new queries, and answering
queries was something that ENVIRONMENT? was meant to do, no?
The reference implementation may load files, and you don't like that,
and you think that ENVIRONMENT? was never intended to do that. If you
think so, don't use the reference implementation. Problem solved.
OTOH, I believe that ENVIRONMENT? has always been clearly and
intentionally allowed to load stuff, or I would not have written the
reference implementation in this way.
Anton Ertl
>If worries about REQUIRE relate to my ciforth:
Yes, and NEEDS in PFE (vs. the more common meaning of loading a file
unless it is already loaded).
>1) ciforth is insignificant
Yet you post code that uses REQUIRE in the ciforth way.
>2) In effect it uses REQUIRED ( adr len -- )
That's not any better, since it conflicts with the REQUIRED in Gforth
(which loads a file unless it is already loaded).
>3) I would rename/drop it instantly as soon there is consensus
> about some word that is officially called REQUIRE
There have been postings where a loading word REQUIRE or NEEDS was
mentioned as a candidate for standardization, without dissent.
Albert van der Horst
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>
>>3) I would rename/drop it instantly as soon there is consensus
>> about some word that is officially called REQUIRE
>
>There have been postings where a loading word REQUIRE or NEEDS was
>mentioned as a candidate for standardization, without dissent.
If there is not even a firm name, that doesn't look like consensus
to me.
>- anton
ward mcfarland
> I guess what you mean is that you disapprove of extending the
> implementation of that word by redefining the name.
I have no problem with ENVIRONMENT? being able to add additonal items it
can respond to. I object to redefining it from being just a query word
to one that is an action word. I do not expect query words to take any
actions. An action has the potential for side effects.
> The proposal extends ENVIRONMENT? with new queries, and answering
> queries was something that ENVIRONMENT? was meant to do, no?
again, agreed
> The reference implementation may load files, and you don't like that,
> and you think that ENVIRONMENT? was never intended to do that. If you
> think so, don't use the reference implementation. Problem solved.
Basically, yes. However, if your goal is to make it easier to have
portable code, then your method encourages people to use simply:
S" X:deferred" ENVIRONMENT? drop
rather than a more useful bit like your example:
S" X:deferred" ENVIRONMENT? dup [IF]
drop
[THEN]
0= [IF]
... \ reference implementation of the deferred words proposal
( or maybe a link to where said code can be obtained)
[THEN]
> OTOH, I believe that ENVIRONMENT? has always been clearly and
> intentionally allowed to load stuff, or I would not have written the
> reference implementation in this way.
It would be interesting if anyone from the X3J14 committee had a comment
about this. I am not a language lawyer, but I do not interpret the
standard that way, unless I assume that any behavior not specifically
prohibited is de facto permitted. I might allow that assumption for
some CORE words, but not for a query word.
As I have said, a conditional version of INCLUDED would be nice to have.
I just don't think it should be wrapped into ENVIRONMENT? I would
approve of somthing like:
S" X:deferred" ENVIRONMENT? not ?INCLUDE" ..deferred.fs"
-- w
Anton Ertl
>I have no problem with ENVIRONMENT? being able to add additonal items it
>can respond to. I object to redefining it from being just a query word
>to one that is an action word. I do not expect query words to take any
>actions. An action has the potential for side effects.
The side effects of loading the reference implementation files should
be rather limited; the worst is probably that HERE might change (or,
in ANS Forth terminology, that the current contiguous region ends).
>Basically, yes. However, if your goal is to make it easier to have
>portable code, then your method encourages people to use simply:
> S" X:deferred" ENVIRONMENT? drop
>
>rather than a more useful bit like your example:
>
>S" X:deferred" ENVIRONMENT? dup [IF]
> drop
>[THEN]
>0= [IF]
>... \ reference implementation of the deferred words proposal
>( or maybe a link to where said code can be obtained)
>[THEN]
Well, with the final stack effect of the X:deferred query the latter
version would look like this:
S" X:deferred" ENVIRONMENT? 0= [IF]
... \ reference implementation of the deferred words proposal
( or maybe a link to where said code can be obtained)
[THEN]
Another alternative would be this:
S" X:deferred" ENVIRONMENT? 0= [IF] s" deferred.fs" included [THEN]
But you seem to be right about the encouragement, for sbpcp.fs I used
S" X:deferred" ENVIRONMENT? drop
Why?
- sbpcp.fs is just one file, so adding another file for the version
with INCLUDED makes the distribution much more complex.
- Adding the reference implementation in-line would grow the source
code, increases the number of versions of the deferred code that may
have to be maintained, and is probably slower on systems that have
implemented the deferred proposal, but do not answer X:deferred with
true (hmm, maybe I should do that; it might encourage system
implementors to implement the deferred proposal and answer X:deferred
with true:-).
- The 's" ..." ENVIRONMENT? drop' is at worst a noop, but it does give
a hint (to the user, even if the system does not take it as a hint)
that the program uses the "deferred" extension. If the system does
not support that extension, the user could just unzip the extensions
<http://www.complang.tuwien.ac.at/forth/ansforth/extensions.zip> in
the right place, and then load extensions/deferred before sbpcp.fs; or
load extensions/extension-query.fs, and rely that the extensions will
be loaded by ENVIRONMENT?.
I found the third option preferable in that program (which also uses
lots of other (non-CfVed) extensions without querying for them or
anything).
>> OTOH, I believe that ENVIRONMENT? has always been clearly and
>> intentionally allowed to load stuff, or I would not have written the
>> reference implementation in this way.
>
>It would be interesting if anyone from the X3J14 committee had a comment
>about this.
Seconded.
> I am not a language lawyer, but I do not interpret the
>standard that way, unless I assume that any behavior not specifically
>prohibited is de facto permitted.
No, that would make the standard useless (e.g., imagine "+" being
allowed all kinds of side effects).
OTOH, the standard does not state all the behaviour explicitly in all
cases, and it mentions adding standard features to a core system in
several places, in particular in the Rationale for ENVIRONMENT?.
I thought a little bit about whether the intention might have been
that ENVIRONMENT? should load features, but not in a way detectable by
standard programs. However, I think that standard programs can detect
the presence or absence of normal standard words with FIND, so loading
extensions is always visible in this way. Also, it would require
special mechanisms to make the loading of features as invisible as
possible, and I doubt that that was the intention.