[REBOL] Re: Correct Behaviour? Was False = 2 ?????
From: joel:neely:fedex at: 2-Jul-2001 3:49
Since you asked... ;-)
- "correctness" requires specification
- "consistency" is A Good Thing, but sometimes isn't free
- REBOL is REBOL; anything else is something else
> JOEL NEELY,
> Hi Joel, are you saying that you think this should
> be the "CORRECT" or "CONSISTENT" REBOL Behaviour.
I distinguish between "correct" and "consistent". A program
is "correct" (or not) if it conforms to specification (or not).
In the absence of specification, one is unable to call *any*
program behavior "incorrect".
Since an implementation (compiler and/or interpreter) of a
programming language is a program, I can only describe its
correctness in terms of the specification for the language.
I do assume that the standard laws of arithmetic and numerical
analysis apply to any language that represents arithmetic as
part of its capabilities. Therefore, any language (using
standard arithmetic notation!) that evaluated
2 + 2
as equal to 5 would be incorrect IMHO.
OTOH, "consistency" is an admittedly subjective quality, but
is important in that it promotes learning and understanding.
Self-consistency is critical for a language to be usable;
it is also reasonably easy to discuss objectively.
I think that self-consistency is preserved when, for example
write %foo.file foo-data
save %foo.file foo-data
use the same ordering for destination and content arguments.
Had they not done so, there would have been an easily-
avoidable opportunity for programmers to make needless errors.
Consistency with familiar "common sense" habits and inferences
is much harder to argue (or refute) with objectivity, but is
still highly important because it affects the ability of new-
comers to become comfortable and confident with a language.
Most people of my acquaintance -- geeks or non-geeks -- are
familiar with the concept of the "case" of a letter, as in
upper-case "A" versus lower-case "a". Since this is a property
of the individual letter, I question the "common sense"
consistency of the following:
>> uppercase "why"
>> uppercase #"w"
** Script Error: uppercase expected string argument of
** Near: uppercase #"w"
This example would be easy to fix without breaking any existing
REBOL code IMHO. That's not always the case. Consider
>> the-block: [2 3 5 7 9] == [2 3 5 7 9]
>> the-list: make list! the-block == make list! [2 3 5 7 9]
>> remove the-block == [3 5 7 9]
>> remove the-list == make list! [3 5 7 9]
>> the-block == [3 5 7 9]
>> the-list == make list! 
IMHO it is inconsistent with "common sense" that REMOVE would
leave blocks and lists in differing states after evaluating
analogous expressions. (I might be persuaded that it is even
self-inconsistent...) But I suspect that if REBOL/Core 2.6
changed REMOVE to leave all series values in the same resulting
state, there might be breakage in some people's code.
In such a case, RT (i.e., Carl) would have to decide between
preserving existing code vs. changing the behavior of REMOVE
in the interest of future benefits of consistency, learnability,
and understandability (for generations of future programmers yet
to be enlightened to the virtues of REBOL ;-) Not that I have
a preference, of course! ;-}
However, if someone gets tripped up by the current behavior and
posts a question to this list, I think that fairness compells
both RT and us on the list to acknowledge the root cause --
inconsistency/exceptions in the notation itself -- and offer
- explanation for the inconsistency (if there is one),
- suggestions for how to remember the exceptions,
- documentation that explicitly warns of the stumbling
blocks most often encountered.
I would prefer not to have the questioner think that I lay the
at his door, and regard him as having inadequate REBOL
> Notice I've given 'PICK the ability to accept an
> integer! logic! & none! value for indexing values,
> is this correct / consistent in your opinion?
> Should REBOL display & act with "correctness" and
> "consistency" or should it mimic the abiguity and
> inconsistency that both Larry & yourself imply / state
> with your previous posts on this thread?
I'd love to see (and would be willing to provide labor
toward) a complete REBOL specification. Until that document
exists, discussion of "correctness" is largely meaningless.
I'd love to see internal and "common-sense" inconsistencies
eliminated whenever possible, but I am realistic enough to
know that this can't happen without effort/cost.
However, when you say that you've "given 'PICK the ability"
to behave in some particular way, we must be clear that we're
no longer talking about REBOL. Anyone is entitled to make up
his/her own language with whatever properties (s)he wishes.
If the goal of such an effort is to "mimic" REBOL, then it
seems clear that faithfully reproducing REBOL behavior is
implicit to that goal.
If the goal of such an effort is to create your own language,
I'd certainly suggest that you put serious effort into first
specifying the language, examining/refining that specification
to eliminate all possible inconsistencies (of any kind), and
then faithfully reproducing the behavior called for in the spec.
But in neither case should you call it "REBOL".
Programming languages: compact, powerful, simple ...
Pick any two!