[REBOL] Re: Antwort: Re: WYSIWYG programming
From: holger:rebol at: 30-Oct-2000 9:08
On Thu, Oct 26, 2000 at 10:25:28PM -0500, Joel Neely wrote:
> I'm sure that all of us who have written and deployed code for a
> living can understand schedule pressure. Speaking for myself,
> THANK YOU VERY MUCH! for taking the time to respond. I really
> cannot emphasize enough how much I appreciate having someone from
> RT giving us the benefit of your perspective on these issues!
My pleasure :)
> (May I respectfully reserve the right to disagree, however? ;-)
Sure.
> However, I think it a bit hasty to dismiss the issues discussed in
> this thread as being primarily due to "switching pain".
I did not intend to dismiss ALL of the issues to switching pain. My
comment was mostly directed at Ladislav's interpretation of something
being "self-modifying code".
> We would, I believe, all concur with the statement in R/CUG
> (page 3-3) that, "How information is processed determines whether
> it is code or data."
Yes, although to me there is more to it than that. There is not just
this technical side (the application of the von Neumann model to high-level
languages), along with the requirements for syntax. There is also the
semantic side of it. Most languages clearly separate data from code. If
you want to do something "dynamically", i.e. determine the flow of control
and the executed code at runtime, then you need to resort to very awkward
workarounds, often involving state machines, which keep the "code" very
generic, and put the actual semantics into the "data". If you have ever
looked at the output of lex/flex or yacc/bison you know what I mean :).
Compared to that REBOL not just allows but actually encourages the dynamic
creation of "items" (for lack of a better word, meaning to include classical
notions of "code", "data" etc.). "Items" can be very "code-like" (the
standard REBOL dialect), very "data-like" (e.g. a block of numbers), or anywhere
in between. For instance you could dynamically create a block which is then fed
to 'parse. The dialect of parse (basically a grammar description with some
code-like
additions) can be as "data-like" or "code-like" as you want -- or
need in any particular situation. Now, would you consider such a block to be
code or data ? :-)
To me one of the more fascinating qualities of REBOL is how that distinction
between "code" and "data" gets blurred, which is why I am very reluctant to
distinguish between the two. In particular the rule taught in every
introductory Assembly language class "self-modifying code is BAD, cute maybe,
but still bad", for good reasons (interference with caching, pipelining etc.)
should not be applied to REBOL, as long as the modification is done correctly.
Correctly
means: you can modify anything except for the block which is just
being evaluated. More about this in a separate mail. It does not matter whether
what you modify looks like "code" or "data", as long as you follow that simple
rule.
> [...] do, in fact, have consequences on the data within the interpreter
> and/or on the environment (file system, etc.) If backed into the
> corner on the terminology, I'd suggest labeling the latter kind
> of expressions as "Consequences On Data/Environment" expressions,
> with the acronym of CODE. Of course, I sometimes forget to hit
> the shift key (and REBOL is case-insensitive anyway) so I trust
> that we all can accept "code" as equivalent to "CODE". ;-)
*grin*. Now repeat this trick in, say, 20 different foreign languages and
I'll be really impressed :-).
> Again, the further we go down this list, the more we have to shift
> our focus to the concepts, notation, specifications, implementation,
> and documentation of the language (and away from the programmer) as
> the causes and remedies of the frustration.
Agreed. I am not commenting in detail, because Jeff already did.
> Now, notice that we aren't allowed to compare logic! values????
YES ! And that is the key to it :-). See below.
> This seems consistent with the forbidden comparison that would
> apparently have "false" less than "true".
Forbidden comparison
: yes. "false" less than "true": no, that is
a rather hasty conclusion.
> So, we can't compare logic! values, apparently due only to some
> type-checking rule in the comparison operators.
No. We cannot compare logic! values by magnitude because no ordering
has been defined for the logic! value domain. We CAN compare logic!
values for (in)equality.
> But if we could,
*grin*. Sounds like you are reaching here.
> the way they inter-convert with integer! values would lead us to
> conclude that FALSE precedes TRUE. But that is inconsistent with
> the fact that the TRUE-th position of a block precedes the FALSE-th
> position of the block!
You are implying that whenever there exists a conversion between two
data types, and for both of them an ordering has been defined, that
the orderings of both data types are equivalent, i.e. the relative
position of any two items should remain the same after the conversion.
This assumption is, from experience, not always true. For instance
consider the domains "signed integer" and "unsigned integer", of
equal bit length, in C ("int" and "unsigned int" for example):
int as=0, bs=-1;
unsigned int au,bu;
(as>bs)?TRUE:FALSE; -> TRUE
au=(unsigned int)as;
bu=(unsigned int)bs; // On a 32-bit machine this becomes 0xffffffff
(au>bu)?TRUE:FALSE; -> FALSE
Here the ordering is not preserved. And it is an even stronger case than
the integer!/logic! case in REBOL, because the type conversion between
int and unsigned int is bijective, whereas conversion between integer! and
logic! is not. To me the behavior in C does not indicate any inconsistency,
and neither does the one in REBOL.
The fact that REBOL does not allow you to perform magnitude comparisons
on logic! values should be enough of an indication that in the user model
REBOL uses logic! values do not really HAVE a magnitude :-).
That's why IMHO the behavior of 'to-integer vs. 'pick is not inconsistent.
Both are implemented to be as intuitive as possible, as Jeff already
explained. 'to-integer returns the integers most users would expect to
be associated with boolean values (1 for true and 0 for false). 'pick is
consistent with 'either in that 'true precedes 'false.
I don't disagree with you that there may very well inconsistencies in
REBOL (and if so, we need to think about resolving them). I just don't
think that the example you gave illustrates one such case.
--
Holger Kruse
[holger--rebol--com]