|
|
 | | From: | Bruce McFarling | | Subject: | Re: Current standings: CfV: Deferred words | | Date: | 19 Jan 2005 07:19:36 -0800 |
|
|
 |
John Doty wrote:
> Your "network of ifs and buts" is, of course, completely
unnnecessary,
> so this is misdirection. Demanding that the implementor bear the
burden
> of implementation complexity is a good thing, especially here where a
> sane implemention is very simple. Demanding that the user bear this
> burden is bad.
Of course there is a network of ifs ands and buts. >BODY takes you
to the dataspace associated with a word created by CREATE, AND if
DEFER is defined it takes you to the location which acts like
dataspace but may or may not be in the dataspace where you can
grab and restore a value the represents the current state of a
word created with DEFER.
(1) demanding that I, the user, that is ME, see the process
of deferring a word as storing a value in dataspace because
implementers have IMPLEMENTED it that way. Instead of thinking
of it and searching for directions on how to do it in terms of
"what" I am doing, I must think of it and search for it in
terms of HOW it is done.
(2) forbidding implementers from implementing DEFER in any
way OTHER than by acting on some cell value stored in
dataspace.
To prevent the terrible state of affairs where:
If some implementer decides to implement DEFER@ DEFER! they
must do it in the way defined by the standard to claim
standard compliance.
To me, standardising by restricting what implementations can
do in this way is far less likely to work in terms of the goal
of allowing programming with fewer ifdef's than standardising
by specifying how to say what it is you do. Standardising
by restricting implementers invites non-compliant
implementations. Standardising by standard names for given
semantics only affects the naming of the word -- if these
are those semantics, use that name, and if not, don't use
that name.
As a user, I want is a standard that will be
implemented. Standardise in a way that interferes
with an implementers instinct of craftmanship, and
you are begging for noncompliance. Standardise in a
way that take advantage of implementer's laziness in
coming up with names and you are far more likely.
Its just like the Forth-83 problem. As soon as you standardise
a cell as 16-bits, someone will come out with hardware where
it is more direct and efficient for some purpose to have 32bit
cells with 8bit bytes, and implementers will break the standard,
and break all code that thinks that 2+ steps through cells.
You can say, "it's not just three words, its all the other words
defined in the same way if we start doing this in terms of
small, coherent, internally consistent lexicons, instead of
by appending extensions to existing words". My answer will
be, "its not just the if and and but added for >BODY, and
not just the restriction on legal ways to implement DEFER --
its all the other ifs ands and buts to extend existing words
by analogy or some common existing implementation technique,
and the accumulation of restrictions on compliant
implementations".
On its own, its not worth bothering about, but as the thin
edge of the wedge, small coherent lexicons are something
I like you implementers giving to me rather than seeing as
an imposition on me.
And I DEFINITELY think the argument that "the computer
should sort out which of several analogous actions the
user may be wanting to take" is extraordinarily anti-Forth.
One of the first hurdles anyone coming to Forth from one
of the Algol languages faces is "plus? WHICH plus? what
EXACTLY do you want me to do?". Where is my simplicity-
through- complexity? Except after you get used to it,
there are advantages lurking in there. When you say
"+", you are always adding two cells to result in a
cell. So you do not have to specify what arguments
it takes, it takes the arguments that its component
words takes. And you never have to learn how to "cast"
a type to tell the computer to do it a different way
than the way it normally wants to do it, because you
always pick the precise plus operation you want, so
instead of having to escape, you just pick another one.
The problem is that when you implementers implement
something, you are always convinced its "the right
way". You never see it as adding to complexity to
anyone trying to write for multiple implementations
that each do it differently and each are convinced
that their way is the right way. That's why a "how
to do it" specification like this that effectively
requires DEFER to act on an xt stored in dataspace
accessible "as if" it was created by CREATE will
temp non-compliance. The only way to hide that
"how to do it" feuding between vain and quarrelsome
implementers is to provide small coherent lexicons
for saying "what is being done".
|
|
| | From: | John Doty | | Subject: | Re: Current standings: CfV: Deferred words | | Date: | Wed, 19 Jan 2005 20:32:26 -0700 |
|
|
| Bruce McFarling wrote:
> John Doty wrote:
>
>>Your "network of ifs and buts" is, of course, completely
>
> unnnecessary,
>
>>so this is misdirection. Demanding that the implementor bear the
>
> burden
>
>>of implementation complexity is a good thing, especially here where a
>
>
>>sane implemention is very simple. Demanding that the user bear this
>>burden is bad.
>
>
> Of course there is a network of ifs ands and buts. >BODY takes you
> to the dataspace associated with a word created by CREATE, AND if
> DEFER is defined it takes you to the location which acts like
> dataspace but may or may not be in the dataspace where you can
> grab and restore a value the represents the current state of a
> word created with DEFER.
>
> (1) demanding that I, the user, that is ME, see the process
> of deferring a word as storing a value in dataspace because
> implementers have IMPLEMENTED it that way. Instead of thinking
> of it and searching for directions on how to do it in terms of
> "what" I am doing, I must think of it and search for it in
> terms of HOW it is done.
OK, so you want to be able to look up what you're trying to do on some
sort of crib sheet, and copy the recipe. I prefer the *insight* that
allows me to throw away the crib sheet. Knowing the Euler Identity is
much handier than carrying around a page full of special-purpose trig
identities. Knowing a single general-purpose mechanism is much handier
than having to look up TO and IS every time I forget which is which.
>
> (2) forbidding implementers from implementing DEFER in any
> way OTHER than by acting on some cell value stored in
> dataspace.
Implementors should not be free to pollute the language. That >BODY
locates the data associated with a word is a perfectly reasonable
specification. There is no need to pollute the language with specialized
words when a general facility is defined.
>
> To prevent the terrible state of affairs where:
>
> If some implementer decides to implement DEFER@ DEFER! they
> must do it in the way defined by the standard to claim
> standard compliance.
>
> To me, standardising by restricting what implementations can
> do in this way is far less likely to work in terms of the goal
> of allowing programming with fewer ifdef's than standardising
> by specifying how to say what it is you do. Standardising
> by restricting implementers invites non-compliant
> implementations. Standardising by standard names for given
> semantics only affects the naming of the word -- if these
> are those semantics, use that name, and if not, don't use
> that name.
All of the factors needed to build and use DEFER are already in the
language. So, it doesn't belong in the language at all, but in a
portable toolkit.
>
> As a user, I want is a standard that will be
> implemented. Standardise in a way that interferes
> with an implementers instinct of craftmanship, and
> you are begging for noncompliance. Standardise in a
> way that take advantage of implementer's laziness in
> coming up with names and you are far more likely.
You ask for a complex, kludgy, unusable language.
>
> Its just like the Forth-83 problem. As soon as you standardise
> a cell as 16-bits, someone will come out with hardware where
> it is more direct and efficient for some purpose to have 32bit
> cells with 8bit bytes, and implementers will break the standard,
> and break all code that thinks that 2+ steps through cells.
>
> You can say, "it's not just three words, its all the other words
> defined in the same way if we start doing this in terms of
> small, coherent, internally consistent lexicons, instead of
> by appending extensions to existing words". My answer will
> be, "its not just the if and and but added for >BODY,
Those are only in your mind. They are not needed.
> and
> not just the restriction on legal ways to implement DEFER --
A highly desirable restriction. The purpose of a standard is to restrict.
> its all the other ifs ands and buts to extend existing words
> by analogy or some common existing implementation technique,
> and the accumulation of restrictions on compliant
> implementations".
As if ANS Forth was some valuable thing that had helped popularize Forth
instead of marginalizing it.
>
> On its own, its not worth bothering about, but as the thin
> edge of the wedge, small coherent lexicons are something
> I like you implementers giving to me rather than seeing as
> an imposition on me.
>
> And I DEFINITELY think the argument that "the computer
> should sort out which of several analogous actions the
> user may be wanting to take"
I never made that agument. Analogous actions beg for factoring. Break
them down into their primitive factors, standardize *those*, and then
build portable toolkits.
> is extraordinarily anti-Forth.
Asking for obfuscated unfactored crap in place of transparent simplicity
is extraordinarily anti-Forth.
> One of the first hurdles anyone coming to Forth from one
> of the Algol languages faces is "plus? WHICH plus? what
> EXACTLY do you want me to do?". Where is my simplicity-
> through- complexity? Except after you get used to it,
> there are advantages lurking in there. When you say
> "+", you are always adding two cells to result in a
> cell. So you do not have to specify what arguments
> it takes, it takes the arguments that its component
> words takes. And you never have to learn how to "cast"
> a type to tell the computer to do it a different way
> than the way it normally wants to do it, because you
> always pick the precise plus operation you want, so
> instead of having to escape, you just pick another one.
Ah, but + *is* overloaded, and it constrains implementations in exactly
the way you argue against above. The implementation *must* encode signed
integers, unsigned integers, and addresses in a way that's compatible to
allow there to be a common +. It would certainly be stupid for an
implementor to want to violate this requirement. However, I've actually
written programs (not in Forth!) on hardware where integer arithmetic
didn't work on addresses: special address arithmetic instructions were
required.
>
> The problem is that when you implementers implement
> something, you are always convinced its "the right
> way".
I'm only an implementor when I need to be.
> You never see it as adding to complexity to
> anyone trying to write for multiple implementations
> that each do it differently and each are convinced
> that their way is the right way.
That's why the specification needs to force implementations to bury
unspecified details deeply enough that they are invisible to the casual
user, not just to a "language lawyer" carefully trained to be blind to
the details that are taboo.
> That's why a "how
> to do it" specification like this that effectively
> requires DEFER to act on an xt stored in dataspace
> accessible "as if" it was created by CREATE will
> temp non-compliance. The only way to hide that
> "how to do it" feuding between vain and quarrelsome
> implementers is to provide small coherent lexicons
> for saying "what is being done".
You won't face the logic of your argument. A "small, coherent lexicon"
wouldn't include DEFER at all. There's nothing small and coherent about
the lexicon of ANS Forth.
The major reason I rolled my own Forth recently is that my clients have
actually used a Forth with a "small, coherent lexicon", so there's no
way I could have foisted anything as flabby as ANS Forth on them.
-jpd
|
|
|
