|
|
 | | From: | Hans Bezemer | | Subject: | RfD: extension queries | | Date: | 13 Jan 2005 05:31:21 -0800 |
|
|
 | > 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?
Easy, you check whether the word you need is [DEFINED] or [UNDEFINED].
I feel this is much more elegant than grouping bunches of words
together in a group. It doesn't give detailled answers, e.g. I've
defined only a part of of this wordset what should my query
S" WORDSET" ENVIRONMENT?
return? 0.5? And even that doesn't provide any useful information!
[DEFINED] thisword
Does. Better:
[UNDEFINED] thisword [IF] [ABORT] [THEN]
kills the compilation. I always found ENVIRONMENT? a major
misconception (so any queries on 4tH always return false) but this one
is really ugly... :-(
Hans Bezemer
|
|
| | From: | Guido Draheim | | Subject: | Re: RfD: extension queries | | Date: | Thu, 13 Jan 2005 16:09:48 +0100 |
|
|
|
Hans Bezemer wrote:
>>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?
>
>
> Easy, you check whether the word you need is [DEFINED] or [UNDEFINED].
> I feel this is much more elegant than grouping bunches of words
> together in a group. It doesn't give detailled answers, e.g. I've
> defined only a part of of this wordset what should my query
>
> S" WORDSET" ENVIRONMENT?
>
> return? 0.5? And even that doesn't provide any useful information!
>
> [DEFINED] thisword
>
> Does. Better:
>
> [UNDEFINED] thisword [IF] [ABORT] [THEN]
>
> kills the compilation. I always found ENVIRONMENT? a major
> misconception (so any queries on 4tH always return false) but this one
> is really ugly... :-(
>
> Hans Bezemer
I am using the environment-queries to map them to a "required"
call - the wordset may be compiled into the base system or it
is loaded from an external module. The application writer can
state what he wants. In pfe, a `NEEDS floating-ext` is actually
a self-parsing variant of an environment-query and only from
there it is mapped to a load-module. The environment-query is
not file-centric - one can even have a totally different file
to implement two or more wordsets which the module can declare
by creating two constants in the environment-wordlist.
As for the defined-test vs environment-test: if you do just
test for the word then you will only know that it is there but
you can not be sure how it works. The environment-test can
give you a hint as to the intended behavior of the word, i.e.
if the behavior is compliant with the description of some
standard document. Note there are even extra environment-hints
for non-wordset informations, like the FLOORED hint.
In essence, you need both defined-test and environment-hints.
|
|
| | From: | Anton Ertl | | Subject: | Re: RfD: extension queries | | Date: | Thu, 13 Jan 2005 18:28:54 GMT |
|
|
| hansoft@bigfoot.com (Hans Bezemer) writes:
>> 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?
>
>Easy, you check whether the word you need is [DEFINED] or [UNDEFINED].
That does not tell me which of several extensions that implement the
word is actually implemented in the system.
It also provides no way for checking whether an extension for an
existing word (e.g., ENVIRONMENT? in this proposal, or >BODY in an
alternative deferred word proposal) is implemented.
It would also require asking for each word separately, and if a system
wanted to do on-demand loading of extensions, it would have to
organize each word separately. Lots of effort for the programmer and
the system implementor.
>I feel this is much more elegant than grouping bunches of words
>together in a group. It doesn't give detailled answers, e.g. I've
>defined only a part of of this wordset what should my query
>
> S" WORDSET" ENVIRONMENT?
>
>return?
False (although the standard is not very clear about this).
The current proposal hopefully is clear that the system must return
false unless it fully implement the asked-for extension.
>kills the compilation. I always found ENVIRONMENT? a major
>misconception (so any queries on 4tH always return false) but this one
>is really ugly... :-(
Well, you actually implement it all right (in the minimal way).
- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html
|
|
| | From: | Albert van der Horst | | Subject: | Re: RfD: extension queries | | Date: | 13 Jan 2005 21:04:04 GMT |
|
|
| In article <2005Jan13.192854@mips.complang.tuwien.ac.at>,
Anton Ertl wrote:
>hansoft@bigfoot.com (Hans Bezemer) writes:
>
>It would also require asking for each word separately, and if a system
>wanted to do on-demand loading of extensions, it would have to
>organize each word separately. Lots of effort for the programmer and
>the system implementor.
I have some experience with this. ciforth loads block based on
REQUIRE SOME-WORD. In practice one defines a wordset
(<# # #S #> HOLD ) (2>R 2R> 2R@ 2RDROP )
(SAVE-SYSTEM TURNKEY) (TICKS MS@ TICKS-PER-SECOND) etc. together
and loads them with an example word
REQUIRE 2>R
Sometimes words sowieso make only sense if you load the whole group.
REQUIRE class loads `` class end-class M: M; ''
This works well in practice, especially were blocks allow
a rather small granularity without problems.
Alternatively the programmer can specify all foreign words and
thus document his program.
Of course one needs some index to find the file/block.
In a block-file this is traditionally played by the index-line.
It works well.
My REQUIRE fails silently such that you can do
REQUIRE ms@
[UNDEFINED] ms@ [IF] ...
The problem with an environment returning false is that you
then not try to load the facility any more. This promotes
bloated systems with everything in the kernel.
I also have the -t option. Then ciforth does a REQUIRE for
all missing words automatically. I can't see how one
could build upon ENVIRONMENT in a similar way.
>
>>kills the compilation. I always found ENVIRONMENT? a major
>>misconception (so any queries on 4tH always return false) but this one
>>is really ugly... :-(
>
>Well, you actually implement it all right (in the minimal way).
I think environment strings are great for discriminating
between floored and symmetric division and such.
>
>- anton
>--
Groetjes Albert
P.S. The space bar of my keyboard has the hick-ups. Sorry.
--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.
|
|
| | From: | Anton Ertl | | Subject: | Re: RfD: extension queries | | Date: | Fri, 14 Jan 2005 17:49:59 GMT |
|
|
| Albert van der Horst writes:
>In article <2005Jan13.192854@mips.complang.tuwien.ac.at>,
>Anton Ertl wrote:
[asking for words instead of extensions]
>>It would also require asking for each word separately, and if a system
>>wanted to do on-demand loading of extensions, it would have to
>>organize each word separately. Lots of effort for the programmer and
>>the system implementor.
>
>I have some experience with this. ciforth loads block based on
>REQUIRE SOME-WORD.
Now that's absolutely great. A long time ago various Forth systems
introduced REQUIRE and NEEDS for including files only once. Then
Guido Draheim said: "I'll use NEEDS for feature requests; please
switch to REQUIRE for including files." Now you say: "I'll use
REQUIRE for word request. Switch to NEEDS for including files." Grr.
> In practice one defines a wordset
>(<# # #S #> HOLD ) (2>R 2R> 2R@ 2RDROP )
>(SAVE-SYSTEM TURNKEY) (TICKS MS@ TICKS-PER-SECOND) etc. together
>and loads them with an example word
> REQUIRE 2>R
Well, if one system groups words one way, and another system groups
them differently, the effect is that a program has to ask for each of
those words.
If the grouping and meaning of words is standardized, using word
requests is not that different from extension queries, except that:
- They are not Forth-94 in the forms proposed here ([DEFINED] and
REQUIRE).
- There is no provision for extensions of existing words.
- There is no provision for overlapping extensions.
>The problem with an environment returning false is that you
>then not try to load the facility any more. This promotes
>bloated systems with everything in the kernel.
You lost me here. Who is "you"? Why would he not try to load the
facility anymore? And why would the system return false if the
facility could be loaded?
>I also have the -t option. Then ciforth does a REQUIRE for
>all missing words automatically.
You mean, if the text interpreter would report an undefined word,
instead it loads the extension containing the word? Does that not
give you nested-compilation problems?
> I can't see how one
>could build upon ENVIRONMENT in a similar way.
There is no conflict between ENVIRONMENT? and such a facility. If
your system cannot use ENVIRONMENT? to implement such a facility, then
implement it in some other way. ENVIRONMENT? exists for communication
between the program and the system, not for implementing the system.
>I think environment strings are great for discriminating
>between floored and symmetric division and such.
Right for "and such". Division is easier to check without
ENVIRONMENT?. Compare:
s" FLOORED" ENVIRONMENT? [IF]
[IF]
\ do something for floored division
[ELSE]
\ do something for symmetric division
[THEN]
[ELSE]
\ Oh boy, what should I do?
[THEN]
with
-3 2 / -2 = [IF]
\ do something for floored division
[ELSE]
\ do something for symmetric division
[THEN]
The latter is shorter, and does not fail.
- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html
|
|
| | From: | Bruce McFarling | | Subject: | Re: RfD: extension queries | | Date: | 14 Jan 2005 00:07:27 -0800 |
|
|
|
Albert van der Horst wrote:
> The problem with an environment returning false is that you
> then not try to load the facility any more. This promotes
> bloated systems with everything in the kernel.
I always liked the idea of a standard facility to ask how to
get something if it needs to be loaded. It would work
something like:
ACCESSIBLE? \ or whatever name you prefer
( caddr len --
FALSE if unavailable
TRUE if already present
1 if available from a block
2 if available from a file
3 if available in a wordlist
)
BLOCK-ACCESS ( caddr len -- block# )
FILE-ACCESS ( caddr len -- caddr' len' )
WORDLIST-ACCESS ( caddr len -- xt )
|
|
|
