Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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]