RfD: Make ENVIRONMENT? obsolescent

Make ENVIRONMENT? obsolecent
============================

20120704 Initial proposal

Problem
=======

The Forth-94 standard specified an environmental query system, which
allows to query the system for capabilities and some constants, like PAD
and HOLD buffer sizes and maximum integers (which can be calculated
using standard words). This interface was not common practice when it
was proposed, and it didn't attract followers afterwards. Almost 20
years later, it's time to revisit this word, and look at current
practice.

Current Practice
================

The Forth200x TC has already figured out that wordset queries are not
used and offer no additional value, and so made these environmental
queries obsolescent. However, there is little evidence that other
queries are actually used. In Gforth's sources, only three queries are
used, and these three queries are Gforth-specific and therefore non-
standard (and probably should never have been queries).

Portable libraries don't use ENVIRONMENT?, instead they try to figure
out what Forth system they are running on, and then load a harness for
this system. It is common practise that a Forth system has its own name
defined as a word, so you can write code like

[IFDEF] gforth
require gforth-harness.fs
[ELSE] [IFDEF] vfxforth
require vfx-harness.fs
....
[THEN] [THEN]

The SUBSTITUTE word has not yet been used for system-specific
expansions, but the author of this proposal suggests to use the macro
%forth% to be replaced with the system name.

Proposal
========

Move 6.1.1345 ENVIRONMENT? from CORE to TOOLS EXT

Merge table 3.5 (environmental query) and table 3.6 (obsolescent
environmental queries), declaring both obsolescent. Mark table 3.7
(extension queries) as obsolescent, as well.

Remove the last sentence of 1.4.2

- Using ENVIRONMENT? ...

and add ENVIRONMENT? to the list of obsolescent words.

Add a rationale for 15.6.2.--- [DEFINED]:

A.15.6.2.--- [DEFINED]

[DEFINED] can be used to query if certain features are available. If a
standard system has a definition for a word listed in this standard,
this word behaves accordingly to this document. So when [DEFINED] F+
returns true, it does not only indicate that a word called F+ is
defined, but also that it will behave according to the specification in
this document. Therefore, [DEFINED] supersedes the feature queries of
ENVIRONMENT?.

Furthermore, it is common practice that each Forth system defines a
unique word to identify itself: its own name. [DEFINED] <system-name>
therefore can be used to identify if the program is running under a
particular system, e.g. to load a harness written for this particular
system.

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

On 04.07.2012 23:21, Bernd Paysan wrote:
> Make ENVIRONMENT? obsolecent
> ============================
>
> 20120704 Initial proposal
>
> Problem
> =======
>
> The Forth-94 standard specified an environmental query system, which
> allows to query the system for capabilities and some constants, like PAD
> and HOLD buffer sizes and maximum integers (which can be calculated
> using standard words). This interface was not common practice when it
> was proposed, and it didn't attract followers afterwards. Almost 20
> years later, it's time to revisit this word, and look at current
> practice.
>
> Current Practice
> ================
>
> The Forth200x TC has already figured out that wordset queries are not
> used and offer no additional value, and so made these environmental
> queries obsolescent. However, there is little evidence that other
> queries are actually used. In Gforth's sources, only three queries are
> used, and these three queries are Gforth-specific and therefore non-
> standard (and probably should never have been queries).
>
> Portable libraries don't use ENVIRONMENT?, instead they try to figure
> out what Forth system they are running on, and then load a harness for
> this system. It is common practise that a Forth system has its own name
> defined as a word, so you can write code like
>
> [IFDEF] gforth
> require gforth-harness.fs
> [ELSE] [IFDEF] vfxforth
> require vfx-harness.fs
> ...
> [THEN] [THEN]
>
> The SUBSTITUTE word has not yet been used for system-specific
> expansions, but the author of this proposal suggests to use the macro
> %forth% to be replaced with the system name.
>
> Proposal
> ========
>
> Move 6.1.1345 ENVIRONMENT? from CORE to TOOLS EXT
>
> Merge table 3.5 (environmental query) and table 3.6 (obsolescent
> environmental queries), declaring both obsolescent. Mark table 3.7
> (extension queries) as obsolescent, as well.
>
> Remove the last sentence of 1.4.2
>
> - Using ENVIRONMENT? ...
>
> and add ENVIRONMENT? to the list of obsolescent words.
>
> Add a rationale for 15.6.2.--- [DEFINED]:
>
> A.15.6.2.--- [DEFINED]
>
> [DEFINED] can be used to query if certain features are available. If a
> standard system has a definition for a word listed in this standard,
> this word behaves accordingly to this document. So when [DEFINED] F+
> returns true, it does not only indicate that a word called F+ is
> defined, but also that it will behave according to the specification in
> this document. Therefore, [DEFINED] supersedes the feature queries of
> ENVIRONMENT?.
>
> Furthermore, it is common practice that each Forth system defines a
> unique word to identify itself: its own name. [DEFINED] <system-name>
> therefore can be used to identify if the program is running under a
> particular system, e.g. to load a harness written for this particular
> system.
>

My personal view:

There can be different environments, commonly OS and SYSTEM. It is
sometimes necessary to get and set such variables. And then it is
sometimes necessary to send commands to the environment(s). My problem
with ENVIRONMENT? is that it does not really help within this context.
And it is poorly designed from the beginning, as others have stated.

Conclusion: Move ENVIRONMENT? from CORE somewhere to the backyard,
wherever you like. Anyhow we manage without.

On Jul 4, 5:21*pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Make ENVIRONMENT? obsolecent
> ============================
>
> 20120704 *Initial proposal
>
> Problem
> =======
>
> The Forth-94 standard specified an environmental query system, which
> allows to query the system for capabilities and some constants, like PAD
> and HOLD buffer sizes and maximum integers (which can be calculated
> using standard words). *This interface was not common practice when it
> was proposed, and it didn't attract followers afterwards. *Almost 20
> years later, it's time to revisit this word, and look at current
> practice.
>
> Current Practice
> ================
>
> The Forth200x TC has already figured out that wordset queries are not
> used and offer no additional value, and so made these environmental
> queries obsolescent. *However, there is little evidence that other
> queries are actually used. *In Gforth's sources, only three queries are
> used, and these three queries are Gforth-specific and therefore non-
> standard (and probably should never have been queries).
>
> Portable libraries don't use ENVIRONMENT?, instead they try to figure
> out what Forth system they are running on, and then load a harness for
> this system. *It is common practise that a Forth system has its own name
> defined as a word, so you can write code like
>
> [IFDEF] gforth
> require gforth-harness.fs
> [ELSE] [IFDEF] vfxforth
> require vfx-harness.fs
> ...
> [THEN] [THEN]
>
> The SUBSTITUTE word has not yet been used for system-specific
> expansions, but the author of this proposal suggests to use the macro
> %forth% to be replaced with the system name.
>
> Proposal
> ========
>
> Move 6.1.1345 ENVIRONMENT? from CORE to TOOLS EXT
>
> Merge table 3.5 (environmental query) and table 3.6 (obsolescent
> environmental queries), declaring both obsolescent. *Mark table 3.7
> (extension queries) as obsolescent, as well.
>
> Remove the last sentence of 1.4.2
>
> - Using ENVIRONMENT? ...
>
> and add ENVIRONMENT? to the list of obsolescent words.
>
> Add a rationale for 15.6.2.--- [DEFINED]:
>
> A.15.6.2.--- [DEFINED]
>
> [DEFINED] can be used to query if certain features are available. *If a
> standard system has a definition for a word listed in this standard,
> this word behaves accordingly to this document. *So when [DEFINED] F+
> returns true, it does not only indicate that a word called F+ is
> defined, but also that it will behave according to the specification in
> this document. *Therefore, [DEFINED] supersedes the feature queries of
> ENVIRONMENT?.
>
> Furthermore, it is common practice that each Forth system defines a
> unique word to identify itself: its own name. *[DEFINED] <system-name>
> therefore can be used to identify if the program is running under a
> particular system, e.g. to load a harness written for this particular
> system.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/

Environmental queries that are at least marginally useful (at least to
the point of bail and warn that script A won't work, some of them
substantially more useful than that), and would be more useful as
reserved constant names:

Non-testables:
/HOLD /PAD RETURN-STACK-CELLS STACK-CELLS FLOATING-STACK #LOCALS
WORDLISTS MAX-FLOATING

Testables:
ADDRESS-UNIT-BITS FLOORED

Bernd Paysan <bernd.paysan@gmx.de> writes:
> In Gforth's sources, only three queries are used

That's a very weak argument, because Gforth's sources generally assume
that they are running on Gforth, so many system queries won't be used
there. Better take a look at the intended-to-be-portable applications
in <http://www.complang.tuwien.ac.at/forth/appbench.zip>. I once
posted statistics on ENVIRONMENT? uses in these programs somewhere,
but I guess you can just as easily redo them.

, and these
> three queries are Gforth-specific and therefore non-standard (and probably
> should never have been queries).
>
> Portable libraries don't use ENVIRONMENT?, instead they try to figure out what
> Forth system they are running on, and then load a harness for this system.

Yes, that seems more common, but I think this system checking is
mostly for doing things that you cannot do with environmental queries
anyway. This practise is actually a testament to the weakness of the
standard: We don't need a standard for writing "portable" programs this
way.

> It
> is common practise that a Forth system has its own name defined as a word, so
> you can write code like
>
> [IFDEF] gforth
> require gforth-harness.fs
> [ELSE] [IFDEF] vfxforth
> require vfx-harness.fs
> ...
> [THEN] [THEN]

[~:77740] gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
gforth
:1: Undefined word
>>>gforth<<<

So much for "common practise".

> Proposal
> ========
>
> Move 6.1.1345 ENVIRONMENT? from CORE to TOOLS EXT
....
> and add ENVIRONMENT? to the list of obsolescent words.

Also add a sentence about the obsolescence to the glossary entry
of the word itself.

> A.15.6.2.--- [DEFINED]
>
> [DEFINED] can be used to query if certain features are available. If a
> standard system has a definition for a word listed in this standard, this word
> behaves accordingly to this document. So when [DEFINED] F+ returns true, it
> does not only indicate that a word called F+ is defined, but also that it will
> behave according to the specification in this document. Therefore, [DEFINED]
> supersedes the feature queries of ENVIRONMENT?.

There are some Forth200x extensions that tighten the behaviour of some
words (e.g., X:fasinh-lt0), and others that don't deal with defined
words at all (e.g., X:number-prefixes). This cannot be checked with
[DEFINED], and some behavioural properties cannot be checked easily;
and these behavioural properties are cases where we actually really
need to check, because, unlike undefined words, the absence of the
feature does not reveal itself by an "undefined word" error or other
error.

> Furthermore, it is common practice that each Forth system defines a unique
> word to identify itself: its own name.

It's not as common as you want to make us believe, and as mentioned
above, if a standard recommends checking for particular systems,
that's admitting defeat; if that is the way to achieve portability, we
could reduce the standard to four words: [DEFINED] [IF] [ELSE] [THEN].

- 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 2012: http://www.euroforth.org/ef12/

Am Donnerstag, 5. Juli 2012, 12:52:05 schrieb Anton Ertl:
> It's not as common as you want to make us believe, and as mentioned
> above, if a standard recommends checking for particular systems,
> that's admitting defeat; if that is the way to achieve portability, we
> could reduce the standard to four words: [DEFINED] [IF] [ELSE] [THEN].

Yes, it's unfortunately not as common as it should be. Some systems
have their own name defined as environment query instead, which makes it
more cumbersome to access. Gforth (up to 0.7.0) and Win32Forth have
their own name only as environmental query. SwiftForth has nothing.
This is not as common as it should be, so my suggestion is to make it
more common. Programs need it, and e.g. FFL addresses the issue by
advicing the user to install the appropriate harnesses depending on the
system he uses.

It's also true that some extensions can't be checked with [DEFINED], but
we have already decided to remove the extesion queries.

Concerning portable programs: I also checked FFL, which is probably a
better example, because it is designed as portable library:

There's a little ENVIRONMENT? usage in FFL, which checks for ADDRESS-
UNIT-BITS and MAX-U (the first is 8 for all platforms supported by FFL,
and can be easily computed, the latter is -1, because one complement
machines died), and for FLOATING-EXT+FLOATING-STACK, where FFL requires
separate floating stack (we made that standard) and floating point words
(which can be done by [IFDEF]).

The way larger ported programs achieve portability, regardless if that
is FFL or MINOS, is to define a harness, which does some necessary
things beyond the standard in system-specific ways (e.g. MINOS needs
Xlib bindings). We can say that the standard failed to address all
issues of a portable program, and this is indeed true. There however is
no point in fundamentalism - the standard is not good enough, but it is
also not that bad that we need to abandon it completely.

ENVIRONMENT? however is ill-designed and therefore little used. I'm not
discussing hypothetical possible uses, I try to discuss what's actually
used - and that is little, and mostly superfluous. More input is
certainly wellcome.

Systems who have put non-standard information into the environmental
query wordlist, and actually use that should put it as non-standard
words into their normal dictionary. Like OS-CLASS, OS-TYPE and GFORTH
in Gforth.

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

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Concerning portable programs: I also checked FFL, which is probably a
>better example, because it is designed as portable library:

The programs in appbench were designed as portable programs, and were
written by several authors (and I think that's important), so you
should take a look at them as well.

> There however is
>no point in fundamentalism - the standard is not good enough, but it is
>also not that bad that we need to abandon it completely.

That was not my point.

>Systems who have put non-standard information into the environmental
>query wordlist, and actually use that should put it as non-standard
>words into their normal dictionary. Like OS-CLASS, OS-TYPE and GFORTH
>in Gforth.

Maybe. But:

1) There is no point to standardizing a way to supply non-standard
things. A system can define such things in any way it deems
appropriate, and if a program wants to do system-specific things, it
can do it in system-specific ways. E.g., there is no problem if VFX
supplies a word "vfxforth" to be checked with [DEFINED] (except for
programs that want to confine themselves to not using Forth-200x words
like [DEFINED]), while Gforth supplies an environmental query
"gforth". Then your example looks as follows:

s" gforth" environment? [IF]
2drop require gforth-harness.fs
[ELSE] [DEFINED] vfxforth [IF]
include vfx-harness.fs
....
[THEN] [THEN]

[I also fixed two other bugs in your example: [IFDEF] is not
standardized anywhere and is not present in VFX; and VFX has no
REQUIRE (both tested with 4.30).]

So if a system decides to put words for the system name or whatever in
the default search order instead of having an environmental query, the
only issue at hand is which one is more convenient.

It is, however important to have ways to query such things such that
the program can still run on other systems. [DEFINED] and
ENVIRONMENT? provide such ways.

2) In the long run our goal should be to make the standard
sufficiently complete that we can run significant programs without
needing to resort to system-specific harnesses or (worse) having to
fiddle with the code. Or at least that's my goal; some seem to be
happy with the current state of non-portability.

- 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 2012: http://www.euroforth.org/ef12/

On Jul 5, 12:09*pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> 2) In the long run our goal should be to make the standard
> sufficiently complete that we can run significant programs without
> needing to resort to system-specific harnesses or (worse) having to
> fiddle with the code. *Or at least that's my goal; some seem to be
> happy with the current state of non-portability.

I'd be happy with getting to a single harness that gives access to a
broad library of portable source code.

In article <2012Jul5.131705@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>[~:77740] gforth
>Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `bye' to exit
>gforth
>:1: Undefined word
>>>>gforth<<<
>
>So much for "common practise".

80386 ciforth 4.0.6
lina
lina? ciforth ERROR # 12 : NOT RECOGNIZED
ciforth
ciforth? ciforth ERROR # 12 : NOT RECOGNIZED
ENVIRONMENT
OK
NAME TYPE
ciforth OK

: gforth ;
OK
gforth
OK


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

On Jul 5, 7:13*pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> The code reads better (and also writes better) if you have consistent
> ways for checking these things. *At the moment, you have to remember
> both the Forth system's name and how it is supposed to be checked (plus
> how many values its environmental query leaves on the stack to be
> removed). *Do this a hundred times in some code, and you simply add
>
> s" gforth" environment? [IF] 2drop : gforth ; [THEN]

I prefer constants to presence tokens, since constants can be provided
for by amending the specification of environmental queries from being
disjoint with the namespace to being conjoint with the namespace.
Declare all the environmental queries regarding wordset names
obsolescent, the ones that are computable can be computed if absent
and needed, the ones the represent non-computable information, if
something more than the absolute minimum is required, can generate a
warning or an abort with a request to define an appropriate value.

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> The programs in appbench were designed as portable programs, and were
>> written by several authors (and I think that's important), so you
>> should take a look at them as well.
>
>Ok, I did that. The most typical environment query there is to check
>for the system name (i.e. nonstandard queries strings like "Gforth",
>"bigForth", "iForth"). There are a few queries for MAX-U and ADDRESS-
>UNIT-BITS, and for floored division (can check directly) or the presence
>of the floating point wordset (equal to [DEFINED] F+).

PFE makes the Float wordset available if you query for FLOATING-EXT,
but not if you check with [DEFINED] F+:

\ Portable Forth Environment 0.33.34 (Jun 14 2004 01:04:19)
Copyright (C) Dirk Uwe Zoller 1993 - 1995.
Copyright (C) Tektronix, Inc. 1998 - 2003.
ANS/ffa ITC Forth - Please enter LICENSE and WARRANTY.
Running on x86_64 linux-gnu - to quit say BYE. ok
[defined] f+ . 0 ok
s" floating-ext" environment? .s
-1 [FFFFFFFFFFFFFFFF]
1994 [00000000000007CA] ok
[defined] f+ . 46912503573385 ok

Of course, one could modify the systems such that "[DEFINED] F+" makes
F+ available (the way that Albert van der Horst (IIRC) does it with
WANT); but that would require quite a large number of [DEFINED]s to
get the wholes FP wordset. Or if such systems already have the data
to make these words available individually, they could be made
available automatically when encountered in the text interpreter
without WANT or [DEFINED].

>The code reads better (and also writes better) if you have consistent
>ways for checking these things. At the moment, you have to remember
>both the Forth system's name and how it is supposed to be checked (plus
>how many values its environmental query leaves on the stack to be
>removed). Do this a hundred times in some code

Why would you load a hundred compatibility harnesses, and if you do,
why would you need to check for the system every time you load one?

>> It is, however important to have ways to query such things such that
>> the program can still run on other systems. [DEFINED] and
>> ENVIRONMENT? provide such ways.
>
>Yes, with different usefullness. Querying for an ext wordset is not
>particularly helpful, as the implementer can cherry-pick which words he
>implements. [DEFINED] can check for each of them, so you could say
>something like
>
>[DEFINED] fsin [DEFINED] fcos and [DEFINED] fatan2 and [DEFINED] fsqrt
>and 0= [IF] include basic-trigonometry.fs [THEN]

I think this will be as rare as wordset queries, for the same reason.

>We could argue that we can make ENVIRONMENT? obsolescent, because we now
>have [DEFINED], which does - apart from a few constants - a better job
>than ENVIRONMENT? ever did.

Actually even for the constants. Just define them as Forth words in
an extension, and one can check for their presence with [DEFINED], or
(more likely) use them without check.

>> 2) In the long run our goal should be to make the standard
>> sufficiently complete that we can run significant programs without
>> needing to resort to system-specific harnesses or (worse) having to
>> fiddle with the code. Or at least that's my goal; some seem to be
>> happy with the current state of non-portability.
>
>Yes, but in the short run we don't achieve the long-run goal, and still
>wan to write significant programs that are ported to several systems.

Sure, but we shouldn't present this way of writing several-system
specific programs as the only way to achieve portability (it actually
does not achieve real portability at all).

- 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 2012: http://www.euroforth.org/ef12/

Anton Ertl wrote:
> PFE makes the Float wordset available if you query for FLOATING-EXT,
> but not if you check with [DEFINED] F+:

Yes, a pretty weird mechanism to load the floating point wordset.

> Of course, one could modify the systems such that "[DEFINED] F+" makes
> F+ available (the way that Albert van der Horst (IIRC) does it with
> WANT); but that would require quite a large number of [DEFINED]s to
> get the wholes FP wordset.

No, please not. [DEFINED] is there to check, not to make available.

> Or if such systems already have the data
> to make these words available individually, they could be made
> available automatically when encountered in the text interpreter
> without WANT or [DEFINED].

Yepp. There is no requirement to have all words resident if you can
load them on demand. This is what I would consider a standard approach
- the word as such is "there", it just gets loaded and compiled on
demand.

> Why would you load a hundred compatibility harnesses, and if you do,
> why would you need to check for the system every time you load one?

Well, maybe you load one harness, and then you still have places in your
code that need checking for a particular system, because the special-
casing there is not worth to go into a general harness. I've still
several [defined] VFXForth [IF] in MINOS, because VFX needs some tweaks
here and there (deny inlining a word and similar things).

>>We could argue that we can make ENVIRONMENT? obsolescent, because we
>>now have [DEFINED], which does - apart from a few constants - a better
>>job than ENVIRONMENT? ever did.
>
> Actually even for the constants. Just define them as Forth words in
> an extension, and one can check for their presence with [DEFINED], or
> (more likely) use them without check.

Yes.

>>Yes, but in the short run we don't achieve the long-run goal, and
>>still wan to write significant programs that are ported to several
>>systems.
>
> Sure, but we shouldn't present this way of writing several-system
> specific programs as the only way to achieve portability (it actually
> does not achieve real portability at all).

I don't know what you think "real portability" is. This seems to be a
fundamentalistic approach. People will provide additional features in
their Forth systems, and if you want to use that feature in another
Forth system, you have to make it available there, too. It might
require carnal knowledge to do so (like C library bindings).

Example: MINOS runs under two different graphical systems (Win32 and
Xlib), and it runs in two different Forth systems. It achieves the
latter by loading two different harnesses, and the former by being full
of [defined] win32 [if] and [defined] x11 [if] code, because of course,
Xlib and Win32 are not at all compatible. However, they offer a similar
set of features, so a MINOS program itself is portable - it neither
needs to check for VFXForth nor for win32/xlib, it just works.

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

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> PFE makes the Float wordset available if you query for FLOATING-EXT,
>> but not if you check with [DEFINED] F+:
>
>Yes, a pretty weird mechanism to load the floating point wordset.

It's a pretty cool mechanism, especially compared to crap like

include Hfp387.fth

Why is it cool?

1) Because all standard systems process it. The program won't fail
because of this check. Every system but one will fail with the
INCLUDE above.

2) It's much easier to remember that, on some systems, I have to check
for FP with the standard mechanism in order to get it loaded than to
remember a weird filename like Hfp387.fth.

>> Actually even for the constants. Just define them as Forth words in
>> an extension, and one can check for their presence with [DEFINED], or
>> (more likely) use them without check.
>
>Yes.

But then your proposal should include making these constants standard
Forth words.

>> Sure, but we shouldn't present this way of writing several-system
>> specific programs as the only way to achieve portability (it actually
>> does not achieve real portability at all).
>
>I don't know what you think "real portability" is.

I can run the program unchanged on every standard system (modulo
memory requirements and wordset presence).

> This seems to be a
>fundamentalistic approach.

I don't think that name-calling leads to a productive discussion.

>People will provide additional features in
>their Forth systems, and if you want to use that feature in another
>Forth system, you have to make it available there, too. It might
>require carnal knowledge to do so (like C library bindings).

Yes, but that's the opposite of portability through a standard. The C
interface is one example of a feature that many Forth systems have,
and that we should standardize. It's like FP before Forth-94.

- 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 2012: http://www.euroforth.org/ef12/

Bernd Paysan wrote: <jt7p05$eov$1@online.de>
> Anton Ertl wrote:
>> PFE makes the Float wordset available if you query for FLOATING-EXT,
>> but not if you check with [DEFINED] F+:
>
> Yes, a pretty weird mechanism to load the floating point wordset.

Why is that weird? It's even suggested in the standard (A.3.2.6):

"The other group of queries are for things that may legitimately change
over time. 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."

>> Or if such systems already have the data
>> to make these words available individually, they could be made
>> available automatically when encountered in the text interpreter
>> without WANT or [DEFINED].
>
> Yepp. There is no requirement to have all words resident if you can
> load them on demand. This is what I would consider a standard approach
> - the word as such is "there", it just gets loaded and compiled on
> demand.

That's problematic, as when you encounter a word you may be in the
middle of building a definition or data structure, and loading code
would break things...

>> Why would you load a hundred compatibility harnesses, and if you do,
>> why would you need to check for the system every time you load one?
>
> Well, maybe you load one harness, and then you still have places in your
> code that need checking for a particular system, because the special-
> casing there is not worth to go into a general harness. I've still
> several [defined] VFXForth [IF] in MINOS, because VFX needs some tweaks
> here and there (deny inlining a word and similar things).

>>>We could argue that we can make ENVIRONMENT? obsolescent, because we
>>>now have [DEFINED], which does - apart from a few constants - a better
>>>job than ENVIRONMENT? ever did.
>>
>> Actually even for the constants. Just define them as Forth words in
>> an extension, and one can check for their presence with [DEFINED], or
>> (more likely) use them without check.

The trouble I see with [DEFINED] is that it just checks for the presence
of a name -- it doesn't check whether it actually conforms to the
standard... Given that almost all of the so-called standard Forth
systems have very noticeable deviations, you can't just assume that
standard word names do what you think they do.

And testing for the proper behavior can be difficult or impossible to do
without crashing the Forth system, so you really want the knowledge to
be built-in or pre-computed and stored in a database.

Of course, as we have seen, most people who write Forth code don't
really care about portability -- just write simple well-factored code
and modify it for new systems, or write a new harness. So it may be
that nobody would use it anyway...

> I don't know what you think "real portability" is. This seems to be a
> fundamentalistic approach. People will provide additional features in
> their Forth systems, and if you want to use that feature in another
> Forth system, you have to make it available there, too. It might
> require carnal knowledge to do so (like C library bindings).
>
> Example: MINOS runs under two different graphical systems (Win32 and
> Xlib), and it runs in two different Forth systems. It achieves the
> latter by loading two different harnesses, and the former by being full
> of [defined] win32 [if] and [defined] x11 [if] code, because of course,
> Xlib and Win32 are not at all compatible. However, they offer a similar
> set of features, so a MINOS program itself is portable - it neither
> needs to check for VFXForth nor for win32/xlib, it just works.

It seems to me that it would be pretty straightforward to build a Forth
package manager even without support from implementations. System
support in the form of making system/version available would be nice.
But even without that, it's easy enough to run each Forth system through
a script which loads that information. Again, building a package
database would be a lot of boring drudgery and probably no one cares
enough to do it, but I don't think it would be difficult.

--Josh

In article <jt7p05$eov$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote:
>Anton Ertl wrote:
>> PFE makes the Float wordset available if you query for FLOATING-EXT,
>> but not if you check with [DEFINED] F+:
>
>Yes, a pretty weird mechanism to load the floating point wordset.

That may not as weird as you think. ciforth has very little present
out of the box. If some one asks whether COMPARE is defined, he
probably wants to use it. The effect is that loadable extensions
look as if they are defined, without taking up place in the kernel.
So instead of
: [DEFINED] NAME PRESENT ;
I have
: [DEFINED] NAME 2DUP WANTED PRESENT ;

>
>> Of course, one could modify the systems such that "[DEFINED] F+" makes
>> F+ available (the way that Albert van der Horst (IIRC) does it with
>> WANT); but that would require quite a large number of [DEFINED]s to
>> get the wholes FP wordset.
>
>No, please not. [DEFINED] is there to check, not to make available.

I agree. I wouldn't object to replace the documentation like
Anton put in a sbpcp.frt (slightly better prime counting program")
"
\ The program uses the following words
...
\ from EXCEPTION :
\ throw
....
\ from FLOAT :
\ d>f f>d
\ from FLOAT-EXT :
\ fsqrt f**
...
\ from LOCAL :
\ TO
"
by a more formal
( EXCEPTION : ) WANT THROW
( FLOAT : ) WANT D>F F>D
( FLOAT-EXT : ) WANT FSQRT F**
( LOCAL : ) WANT TO
which would allow a so-equipped system to get the maximum
of loadable extensions to prepare for running the program.

But
[DEFINED] THROW DROP
[DEFINED] D>F DROP
[DEFINED] F>D DROP

is plain weird.

>
>> Or if such systems already have the data
>> to make these words available individually, they could be made
>> available automatically when encountered in the text interpreter
>> without WANT or [DEFINED].
>
>Yepp. There is no requirement to have all words resident if you can
>load them on demand. This is what I would consider a standard approach
>- the word as such is "there", it just gets loaded and compiled on
>demand.

This I try with `` lina -t aap.frt ''
It is not as easy as it looks, it gets messy with immediate words,
wordlists and I need a second pass.

It is a good idea to have this facility loaded for interactive
sessions that start with `` lina -e ''

>
>> Why would you load a hundred compatibility harnesses, and if you do,
>> why would you need to check for the system every time you load one?
>
>Well, maybe you load one harness, and then you still have places in your
>code that need checking for a particular system, because the special-
>casing there is not worth to go into a general harness. I've still
>several [defined] VFXForth [IF] in MINOS, because VFX needs some tweaks
>here and there (deny inlining a word and similar things).
>
>>>We could argue that we can make ENVIRONMENT? obsolescent, because we
>>>now have [DEFINED], which does - apart from a few constants - a better
>>>job than ENVIRONMENT? ever did.
>>
>> Actually even for the constants. Just define them as Forth words in
>> an extension, and one can check for their presence with [DEFINED], or
>> (more likely) use them without check.
>
>Yes.
>
>>>Yes, but in the short run we don't achieve the long-run goal, and
>>>still wan to write significant programs that are ported to several
>>>systems.
>>
>> Sure, but we shouldn't present this way of writing several-system
>> specific programs as the only way to achieve portability (it actually
>> does not achieve real portability at all).
>
>I don't know what you think "real portability" is. This seems to be a
>fundamentalistic approach. People will provide additional features in
>their Forth systems, and if you want to use that feature in another
>Forth system, you have to make it available there, too. It might
>require carnal knowledge to do so (like C library bindings).
>
>Example: MINOS runs under two different graphical systems (Win32 and
>Xlib), and it runs in two different Forth systems. It achieves the
>latter by loading two different harnesses, and the former by being full
>of [defined] win32 [if] and [defined] x11 [if] code, because of course,
>Xlib and Win32 are not at all compatible. However, they offer a similar
>set of features, so a MINOS program itself is portable - it neither
>needs to check for VFXForth nor for win32/xlib, it just works.

That is where the real challenge is. Note that once it becomes
clear how the API has to look, you have a candidate for
standardization.
>
>--
>Bernd Paysan

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

Anton Ertl wrote:
>>Yes, a pretty weird mechanism to load the floating point wordset.
>
> It's a pretty cool mechanism, especially compared to crap like
>
> include Hfp387.fth
>
> Why is it cool?
>
> 1) Because all standard systems process it. The program won't fail
> because of this check. Every system but one will fail with the
> INCLUDE above.

Well, the problem is the weird name. Why not call the file float.fs or
float.fth or float.fb if it is a block file?

> 2) It's much easier to remember that, on some systems, I have to check
> for FP with the standard mechanism in order to get it loaded than to
> remember a weird filename like Hfp387.fth.

Weird filenames are indeed a nuisance.

require float.fs

doesn't look that weird.

> But then your proposal should include making these constants standard
> Forth words.

Yes, I'll do so.

>>I don't know what you think "real portability" is.
>
> I can run the program unchanged on every standard system (modulo
> memory requirements and wordset presence).
>
>> This seems to be a
>>fundamentalistic approach.
>
> I don't think that name-calling leads to a productive discussion.

IMHO, pragmatic approaches are more likely to get implemented than
strict approaches. I would like to have my programs run unchanged, too,
but it takes time to get there.

>>People will provide additional features in
>>their Forth systems, and if you want to use that feature in another
>>Forth system, you have to make it available there, too. It might
>>require carnal knowledge to do so (like C library bindings).
>
> Yes, but that's the opposite of portability through a standard. The C
> interface is one example of a feature that many Forth systems have,
> and that we should standardize. It's like FP before Forth-94.

Yes, we should, but last time we analyzed the situation, we found that
every Forth system tried to do something minimalistic, which solves its
particular platform's problems, and no more. Problems more portable
systems like Gforth have aren't solved with the other approaches. On
the other hand, Gforth's current approach only specifies the Forth type
of each passed value, and leaves the C type to the C compiler - this
won't work in a system like VFX or bigForth, which needs the C type,
because it generates the binding itself.

In any case, this all won't happen over night, and in the meantime, we
still need a way to facilitate porting programs, even though it is more
cumbersome than we would like.

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