ENVIRONMENT?

Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
be a numeric value?

It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
sizeable routine, because of the strings that need to be stored in a
lookup table etc. This is a real pain for embedded/memory constrained
systems.

The committee could have standardised numeric values (i.e. 1=/COUNTED
STRING, 2=/HOLD etc).

Grrr!

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> Why on earth does ENVIRONMENT accept a string? Why couldn't it
> simply be a numeric value?
>
> It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a
> rather sizeable routine, because of the strings that need to be
> stored in a lookup table etc. This is a real pain for
> embedded/memory constrained systems.

So what? ANS Core doesn't all have to be loaded in a small system,
and ENVIRONMENT can return false for all queries.

Andrew.

Mark Wills <markrobertwills@yahoo.co.uk> writes:
>Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
>be a numeric value?
>
>It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
>sizeable routine, because of the strings that need to be stored in a
>lookup table etc. This is a real pain for embedded/memory constrained
>systems.

A very simple implementation of ENVIRONMENT?:

: environment? ( ( c-addr u -- false | i*x true )
2drop false ;

- 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/

In article <f7528036-6314-419c-9e10-4b095531abff@z19g2000vbe.googlegroups.com>,
Mark Wills <markrobertwills@yahoo.co.uk> wrote:
>Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
>be a numeric value?
>
>It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
>sizeable routine, because of the strings that need to be stored in a
>lookup table etc. This is a real pain for embedded/memory constrained
>systems.

Everybody uses a wordlist to store the environment strings.
Then you can use Forth herself to look up those names.

>
>The committee could have standardised numeric values (i.e. 1=/COUNTED
>STRING, 2=/HOLD etc).

Embarassing. I'm all in favor of numeric values for error conditions,
but that is only because in extreme error nothing works, and you will
be happy that at least the number is printed, but not for environment
strings.
So in my Forth the number is output in decimal on the error channel,
before I even attempt to look up a message or tell the user where it
went wrong. Environments are used with no indication in sight that the
system is failing badly.

>
>Grrr!

If you're a minimalist you can cheat by just telling that you don't
have the string.

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 3, 5:03*am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
> be a numeric value?
>
> It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
> sizeable routine, because of the strings that need to be stored in a
> lookup table etc. This is a real pain for embedded/memory constrained
> systems.
>
> The committee could have standardised numeric values (i.e. 1=/COUNTED
> STRING, 2=/HOLD etc).
>
> Grrr!

This is exactly the kind of post that I would expect from Mark Willis
--- I never really see even a flicker of intelligence out of anybody
else on comp.lang.forth.

On Jul 3, 4:29*pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Mark Wills <markrobertwi...@yahoo.co.uk> writes:
> >Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
> >be a numeric value?
>
> >It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
> >sizeable routine, because of the strings that need to be stored in a
> >lookup table etc. This is a real pain for embedded/memory constrained
> >systems.
>
> A very simple implementation of ENVIRONMENT?:
>
> : environment? ( ( c-addr u -- false | i*x true )
> * 2drop false ;
>
> - 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/

Which makes a mockery of the ENVIRONMENT? word, which kind of proves
my point.

If something in the standard is just going to be ignored, one has to
ask if it deserves a place in the standard!

On Jul 3, 7:24*pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <f7528036-6314-419c-9e10-4b095531a...@z19g2000vbe.googlegroups..com>,
> Mark Wills *<markrobertwi...@yahoo.co.uk> wrote:
>
> >Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
> >be a numeric value?
>
> >It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
> >sizeable routine, because of the strings that need to be stored in a
> >lookup table etc. This is a real pain for embedded/memory constrained
> >systems.
>
> Everybody uses a wordlist to store the environment strings.
> Then you can use Forth herself to look up those names.
>
>
>
> >The committee could have standardised numeric values (i.e. 1=/COUNTED
> >STRING, 2=/HOLD etc).
>
> Embarassing. I'm all in favor of numeric values for error conditions,
> but that is only because in extreme error nothing works, and you will
> be happy that at least the number is printed, but not for environment
> strings.
> So in my Forth the number is output in decimal on the error channel,
> before I even attempt to look up a message or tell the user where it
> went wrong. Environments are used with no indication in sight that the
> system is failing badly.
>
>
>
> >Grrr!
>
> If you're a minimalist you can cheat by just telling that you don't
> have the string.
>
> Groetjes Albert
>
> --
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=nhttp://home.hccnet.nl/a.w.m.van.der.horst

Which would contravene the standard... You either implement the word
fully, producing a 'standard compliant system', or, you

a) Implement it as a loadable extra, only to be used when needed (a
'standard compliant subset')
b) Bodge it, having it return false for everything, which is much
worse, because the word no longer behaves as documented. Therefore
your system is not standard compliant.

On Jul 4, 5:46*am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
> On Jul 3, 5:03*am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>
> > Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
> > be a numeric value?
>
> > It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
> > sizeable routine, because of the strings that need to be stored in a
> > lookup table etc. This is a real pain for embedded/memory constrained
> > systems.
>
> > The committee could have standardised numeric values (i.e. 1=/COUNTED
> > STRING, 2=/HOLD etc).
>
> > Grrr!
>
> This is exactly the kind of post that I would expect from Mark Willis
> --- I never really see even a flicker of intelligence out of anybody
> else on comp.lang.forth.

Thank you! ;-)

But seriously, *why* on earth is it a *string* for god's sake?!!!

If it were a single cell value, the implementation would be no more
complex than:
CREATE _EnvironmentLUT
: ENVIRONMENT? ( query_index -- result)
CELLS _EnvironmentLUT + @ ;

Simple. *That's* Forth!

As currently mandated, I have to write string comparison routines,
just to parse the bloody string passed in, and see if it's in the list
of recognised strings. Simple enough in just about *any* other
language, *except* Forth. I've got to say, whereas most words in Forth
have an elegant simplicity attached to them, this one sticks out like
a sore thumb, a pork sausage at a Jewish wedding, a turd in a swimming
pool, and any other hyperboles you care to mention.

How ridiculous. Who's idea was this??!!

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> On Jul 3, 4:29?pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>> Mark Wills <markrobertwi...@yahoo.co.uk> writes:
>> >Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
>> >be a numeric value?
>>
>> >It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
>> >sizeable routine, because of the strings that need to be stored in a
>> >lookup table etc. This is a real pain for embedded/memory constrained
>> >systems.
>>
>> A very simple implementation of ENVIRONMENT?:
>>
>> : environment? ( ( c-addr u -- false | i*x true )
>> ? 2drop false ;
>
> Which makes a mockery of the ENVIRONMENT? word, which kind of proves
> my point.
>
> If something in the standard is just going to be ignored, one has to
> ask if it deserves a place in the standard!

Eh? In what sense is it being ignored? ENVIRONMENT? gives a system a
way to advertise capabilities; if a system implementer doesn't want to
advertise any, they can still be compliant.

And you're still failing to address the point:

"A system need not provide all words in executable form. The
implementation may provide definitions, including definitions of words
in the Core word set, in source form only."

Your complaint that ENVIRONMENT? wastes memory in an embedded system
is not valid.

Andrew.

> Everybody uses a wordlist to store the environment strings.
> Then you can use Forth herself to look up those names.

Right. So, as per your suggestion, one would have to (in the
implementation of ENVIRONMENT):

a) Add the ENVIRONMENT wordlist to the current context (possibly
saving the current context first?)
b) Use WORD and FIND (or what ever the ANS equivalents are) (since the
argument is passed in as a string)
c) Assuming the word is found in the dictionary, EXECUTE it, or return
0 (false)
d) Restore the search context

Riiiiiiiight. As opposed to a simple lookup table...

That's not Forth; it's masochism! Forgive me while I go bang my head
against a wall!

Even the standard appears to aknowledge that it's a PITA to use
effectively:
<quote>
A.6.1.1345 ENVIRONMENT?
In a Standard System that contains only the Core word set, effective
use of ENVIRONMENT? requires either its use within a definition, or
the use of user-supplied auxiliary definitions. The Core word set
lacks both a direct method for collecting a string in interpretation
state ( 11.6.1.2165 S" is in an optional word set) and also a means to
test the returned flag in interpretation state (e.g. the optional
15.6.2.2532 [IF]).

The combination of 6.1.1345 ENVIRONMENT?, 11.6.1.2165 S", 15.6.2.2532
[IF], 15.6.2.2531 [ELSE], and 15.6.2.2533 [THEN] constitutes an
effective suite of words for conditional compilation that works in
interpretation state.
</quote>

Interesting that they (the standards TC) thought it necessary to point
that out in the document!

So... anyway, yeah, okay, I get that. If your standard program relied
on a 32 bit cell (for example), you would have to put the test in a
colon definition at the start of your load script and execute the
colon definition:

: Is32Bit? ( -- )
S" ADDRESS-UNIT-BITS" ENVIRONMENT?
32 < ABORT" 32 bit processor required" ;
Is32Bit?
FORGET Is32Bit?

Which would:

* Erase Is32Bit? from memory if the cell size was >= 32 bits
* Stop loading, *but leave Is32Bit? in memory* if cell size < 32 bits



Yack.

Mark Wills <markrobertwills@yahoo.co.uk> wrote:

> But seriously, *why* on earth is it a *string* for god's sake?!!!
>
> If it were a single cell value, the implementation would be no more
> complex than:
> CREATE _EnvironmentLUT
> : ENVIRONMENT? ( query_index -- result)
> CELLS _EnvironmentLUT + @ ;
>
> Simple. *That's* Forth!
>
> As currently mandated, I have to write string comparison routines,
> just to parse the bloody string passed in,

No, you don't. This has already been explained to you.

Andrew.

On Jul 4, 10:04*am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> On Jul 4, 5:46*am, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
>
>
>
>
> > On Jul 3, 5:03*am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>
> > > Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
> > > be a numeric value?
>
> > > It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
> > > sizeable routine, because of the strings that need to be stored in a
> > > lookup table etc. This is a real pain for embedded/memory constrained
> > > systems.
>
> > > The committee could have standardised numeric values (i.e. 1=/COUNTED
> > > STRING, 2=/HOLD etc).
>
> > > Grrr!
>
> > This is exactly the kind of post that I would expect from Mark Willis
> > --- I never really see even a flicker of intelligence out of anybody
> > else on comp.lang.forth.
>
> Thank you! ;-)
>
> But seriously, *why* on earth is it a *string* for god's sake?!!!
>
> If it were a single cell value, the implementation would be no more
> complex than:
> CREATE _EnvironmentLUT
> : ENVIRONMENT? ( query_index -- result)
> * CELLS *_EnvironmentLUT + *@ ;
>
> Simple. *That's* Forth!
>
> As currently mandated, I have to write string comparison routines,
> just to parse the bloody string passed in, and see if it's in the list
> of recognised strings. Simple enough in just about *any* other
> language, *except* Forth. I've got to say, whereas most words in Forth
> have an elegant simplicity attached to them, this one sticks out like
> a sore thumb, a pork sausage at a Jewish wedding, a turd in a swimming
> pool, and any other hyperboles you care to mention.
>
> How ridiculous. Who's idea was this??!!- Hide quoted text -
>
> - Show quoted text -

Sorry, that should be:

CREATE _EnvironmentLUT
<data> , <data> , <data> , <data> , <data> , <data> , etc

: ENVIRONMENT? ( query_index -- result)
CELLS _EnvironmentLUT + @ ;

You get the idea...

On Jul 4, 10:12*am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> > On Jul 3, 4:29?pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> > wrote:
> >> Mark Wills <markrobertwi...@yahoo.co.uk> writes:
> >> >Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
> >> >be a numeric value?
>
> >> >It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
> >> >sizeable routine, because of the strings that need to be stored in a
> >> >lookup table etc. This is a real pain for embedded/memory constrained
> >> >systems.
>
> >> A very simple implementation of ENVIRONMENT?:
>
> >> : environment? ( ( c-addr u -- false | i*x true )
> >> ? 2drop false ;
>
> > Which makes a mockery of the ENVIRONMENT? word, which kind of proves
> > my point.
>
> > If something in the standard is just going to be ignored, one has to
> > ask if it deserves a place in the standard!
>
> Eh? *In what sense is it being ignored? *ENVIRONMENT? gives a system a
> way to advertise capabilities; if a system implementer doesn't want to
> advertise any, they can still be compliant.
>
> And you're still failing to address the point:
>
> "A system need not provide all words in executable form. The
> implementation may provide definitions, including definitions of words
> in the Core word set, in source form only."
>
> Your complaint that ENVIRONMENT? wastes memory in an embedded system
> is not valid.
>
> Andrew.- Hide quoted text -
>
> - Show quoted text -

Of course it's valid. If you have a memory constrained embedded
system, and you wish you use ENVIRONMENT?, then you need the behemoth
that ENVIRONMENT? is. Whether it's included at start-up, or loaded
from source is irrelevant to the point I was making: It's fat and ugly!

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> On Jul 4, 10:12?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>> > On Jul 3, 4:29?pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>> > wrote:
>> >> Mark Wills <markrobertwi...@yahoo.co.uk> writes:
>> >> >Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
>> >> >be a numeric value?
>>
>> >> >It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
>> >> >sizeable routine, because of the strings that need to be stored in a
>> >> >lookup table etc. This is a real pain for embedded/memory constrained
>> >> >systems.
>>
>> >> A very simple implementation of ENVIRONMENT?:
>>
>> >> : environment? ( ( c-addr u -- false | i*x true )
>> >> ? 2drop false ;
>>
>> > Which makes a mockery of the ENVIRONMENT? word, which kind of proves
>> > my point.
>>
>> > If something in the standard is just going to be ignored, one has to
>> > ask if it deserves a place in the standard!
>>
>> Eh? In what sense is it being ignored? ?ENVIRONMENT? gives a system a
>> way to advertise capabilities; if a system implementer doesn't want to
>> advertise any, they can still be compliant.
>>
>> And you're still failing to address the point:
>>
>> "A system need not provide all words in executable form. The
>> implementation may provide definitions, including definitions of words
>> in the Core word set, in source form only."
>>
>> Your complaint that ENVIRONMENT? wastes memory in an embedded system
>> is not valid.
>
> Of course it's valid. If you have a memory constrained embedded
> system, and you wish you use ENVIRONMENT?, then you need the behemoth
> that ENVIRONMENT? is.

So you need it. But in what memory-constrained embedded system do you
actually need ENVIRONMENT? And why don't you implement it with a
wordlist in the obvious way, like everyone else?

Your complaint that ENVIRONMENT? wastes memory in an embedded system
is, still, not valid.

Andrew.

On Jul 4, 11:01*am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> > On Jul 4, 10:12?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> > wrote:
> >> Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> >> > On Jul 3, 4:29?pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >> > wrote:
> >> >> Mark Wills <markrobertwi...@yahoo.co.uk> writes:
> >> >> >Why on earth does ENVIRONMENT accept a string? Why couldn't it simply
> >> >> >be a numeric value?
>
> >> >> >It's annoying that ENVIRONMENT? is part of ANS Core, yet it's a rather
> >> >> >sizeable routine, because of the strings that need to be stored ina
> >> >> >lookup table etc. This is a real pain for embedded/memory constrained
> >> >> >systems.
>
> >> >> A very simple implementation of ENVIRONMENT?:
>
> >> >> : environment? ( ( c-addr u -- false | i*x true )
> >> >> ? 2drop false ;
>
> >> > Which makes a mockery of the ENVIRONMENT? word, which kind of proves
> >> > my point.
>
> >> > If something in the standard is just going to be ignored, one has to
> >> > ask if it deserves a place in the standard!
>
> >> Eh? *In what sense is it being ignored? ?ENVIRONMENT? gives a systema
> >> way to advertise capabilities; if a system implementer doesn't want to
> >> advertise any, they can still be compliant.
>
> >> And you're still failing to address the point:
>
> >> "A system need not provide all words in executable form. The
> >> implementation may provide definitions, including definitions of words
> >> in the Core word set, in source form only."
>
> >> Your complaint that ENVIRONMENT? wastes memory in an embedded system
> >> is not valid.
>
> > Of course it's valid. If you have a memory constrained embedded
> > system, and you wish you use ENVIRONMENT?, then you need the behemoth
> > that ENVIRONMENT? is.
>
> So you need it. *But in what memory-constrained embedded system do you
> actually need ENVIRONMENT? *And why don't you implement it with a
> wordlist in the obvious way, like everyone else?
>
> Your complaint that ENVIRONMENT? wastes memory in an embedded system
> is, still, not valid.
>
> Andrew.- Hide quoted text -
>
> - Show quoted text -

Well, firstly, implementing it as a wordlist is hardly "obvious", is
it? Especially if my earlier post re the machinations required to do
so is valid. That's hardly obvious, is it?

Secondly, how is my complaint invalid? I claim that ENVIRONMENT?, as
directed in the standard is a massive waste of memory, *however* it is
implemented. It's not Forth. It's a waste. To implement it as a
wordlist is even worse, for two reasons:

1) The overhead of the dictionary entries adds even more fat

2) Worldists are not required for CORE i.e. a *STANDARD* system - that
is, a system that is able to be advertised as ANS94 compliant -doesn't
*need* to implement wordlists. So, you're saying that to implement a
*CORE* requirement it is "obvious" to first implement an optional
component: Wordlists. So now my memory constrained system needs to
load (or have at startup) wordlist support just to support the
"obvious" implementation technique for a *single* CORE word.

Of course. You're right. It's obvious. I don't know why it didn't
occur to me before! Just implement wordlists first!

What a joke!

I say I'm right and you're wrong. Any way you look at, ENVIRONMENT is
an abomination.