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

[REBOL] Re: Antwort: Re: WYSIWYG programming

From: jeff:rebol at: 29-Oct-2000 21:03

Howdy, Joel: [ . . . much snipping and it's still like 8 pages . . .]
> I've been on the list for about a year now, and > occasionally see questions or comments go by followed by a > response that tends toward (I'm exaggerating for effect > here!), "Well, you just don't 'get' REBOL yet. You're > still thinking in some other language."
It's a response that works for many people, and points to something that I, too, feel indicates a real phenomenon. I don't see what it buys to dismiss the phenomenon, really.
> As I tried to say in my earlier post, a change of mind-set > is often worth including in the "pain pill", but I think it > is also sometimes too easy to assume that the entire > problem is ONLY due to "switching pain".
Sure. That is too simple. There are many factors when it comes to developing living breathing languages, and to me it really comes down to the abilities of a language to solve problems and the cultivation of a thriving developer community. Today, languages with far less cleanliness of design and internal consistency as REBOL are vastly more popular by many orders of magnitude.
> > guys don't let us > > off the hook and you hold us to the fire!! :-) Hah hah > > -- Just jokin around, ya-know! > > > > Well, it's more fun that pulling legs off of ants! ;-)
Seeing this just huge monster of an email you replied to me made my jaw drop! :) I simply can not keep up with this kind of letter writing! I have to write code, dear sir! Not trying to cop out, but please understand I can't do these marathon email sessions! :) [Though, I'll give it half a shot here..]
> I also am working up a list of errata and suggestions for > improvement (but in background mode, due to schedule > pressures). I'll send them as soon as I can.
Great! We always appreciate this kind of stuff pointing to aspects of non-orthogonality, even if we don't address it right away. Our priority lately has been express. We don't forget the improvements people offer, like Robert Muench compiled a list of improvements that could be made to parse (and many others out there too). This is a primary drive to getting our contribution system running.
> However, one significant area I can think of (at least the > current pebble in my shoe ;-) is the need for documentation > on contexts. ... I still can't find anywhere in the > available documentation where I can go to confirm or refute > what I think I've learned on that subject.
Well, the definition of contexts is context dependent. :) I have an operative definition of contexts that works for me: "where a word is looked up" [simple things should be simple to do... and simple to explain, too.]
> A few examples, to make the point: > > a) We can convert integer! and decimal! values to time! > values, > > with the (reasonable, IMHO) assumption that the units > are seconds. However, we can't go the other way (which > I would think of as equally reasonable).
Well, it is more than reasonable. You're apparently not running core 2.4.38. ;-)
> b) Most loop control functions (e.g., Forskip, Foreach, > For, > Repeat) "localize" the controlled word(s). However, > Forall does not do so, leaving the value of the > controlled word altered upon loop exit.
Actually forskip has the same behavior as forall, leaving the series pegged at the tail on completion (or left where ever you were when you did a break). This is by design. Forall and forskip are made to operate on series indexes. This allows you to modify series as you go, or to use variable amounts of look ahead, or perform other series operations on the series as you move it. The series is moved forward by moving the word that points to the series forward. x: [1 2 3 4 5 6] forskip x 2 [change x pick x random length? x] head x == [3 2 6 4 6 6] You can't do what's above with foreach. Foreach merely gives you consecutive values or sets of values from a series. Foreach is very handy when you are just pulling out data, but not modifying the series. So you have two cases and one for each. One common characteristic of REBOL design is you will find that a lot of functionality is accomplished by spliting the cases in two and providing a function for each. For, repeat, and loop aren't series iterators, so they don't really pertain here, except in that they use a local variables like foreach. Some people find foreach pegging the series to be disconcerting, but it is a rather core aspect of REBOL, and it has a valid reason why it works that way.
> c) On the subject of "simple things are simple to do" I'd > ask: > ... Given an > array (nested blocks of equal size)... > > >> a: array/initial [3 3 3] 0 > == [[[0 0 0] [0 0 0] [0 0 0]] [[0 0 0] [0 0 0] [0 0 > 0]] > [[0 0 0] [0 0 0] [0 0 0]]] > ... It's not nearly so easy [to change inner values] as > > for i 1 3 1 [a/:i/:i/:i: 0] > > ...because that's not legal code!
or repeat i 3 [change at a/:i/:i i 0] It would be handier the way you have it, but I wouldn't go so far as calling the above "hard".
> d) On the subject of confusing inconsistencies vs. "foolish > consistency" we can consider modifications to series > values.
[. . .]
> >> insert s-b "z" == ["x" "b" "c" "d" "e"] > >> insert s-l "z" == make list! ["x" "b" "c" "d" "e"] > >> insert s-h "z" == make hash! ["x" "b" "c" "d" "e"] > >> insert s-s "z" == "xbcde" > > BUT, this time there is a datatype-dependent > inconsistency! Most of the series references have > unaltered positions, but for the list! case, the > position is different.
Yep. Lists are the black sheep of the series. They have absolute indexing instead of relative indexing. A list IS where it is. The reasons have to to do with what lists are, namely doubly linked lists, and how they are implemented in REBOL. It's a question of docs.
> e) The RCUG specifically states that "the concept of none is > not the same as an empty block, empty string, or null > character". Yet there's an inconsistency in Parse when an > empty string (zero IS a valid string length) matches a > pattern.
The problem of information loss you point out with none in parse more points to a bug, but it doesn't mean NONE is equivalent to to an empty string. There's a few more things Carl wants to do to PARSE before it will enter parse nirvana. [ . . . ]
> f: func [a /local b] [ > either a = 0 [ > exit > ][ > use [c] [ > c: a b: a print ["in " c b] f (a - 1) print > ["out" c b] > ] > ] exit > ] > > >> f 3 > in 3 3 in 2 2 in 1 1 out 1 1 out 1 2 out 1 3 > > Here, instead of shielding the inner block from the outer > world, Use actually exposes that block to interference from > elsewhere.
USE is actually primarily offered as a shield for the outside environment from whatever bindings you make inside the USE context than the other way around. I don't think the documentation ever portrays USE in the manner you are expecting. Also, what you are pointing at here is more a symptom of function contexts and how they work. In either case, indefinite extent is another issue we rap a fair bit about at the office, and one that we intend to poke at pretty soon. . . .
> The consequence of these two facts is that I cannot use a > previously- defined Does block which has access to the > loop-controlled variable(s). > > obscurity: function [ > n [integer!] > ][ > mystery reveal > ][ > mystery: -1 reveal: does [print mystery] reveal for > mystery 1 4 1 [reveal] reveal > ] > > >> obscurity 4 ; instead of the possibly-expected > -1 ; -1 1 ; 1 1 ; 2 1 ; 3 1 ; 4 1 ; -1 > > If I want to use a single definition (either for space or > maintenance purposes) of a block to be evaluated at various > places -- including within a loop -- I have to write it as > a function with a parameter (so that I can pass the loop > control value in to it).
FOR is implemented by creating a function. When you create a function you create a separate context where the loop variables live. TRY: SOURCE FOR Maybe you would like to make another version of FOR using a save/restore scheme which will let other things in the same scope have access to the loop variables? I think dealing with recursion and nested FORs might be the tricky two there.
> > By any other name: BUG. Yes, software has bugs. Bugs > > are frustrating. > > Yes, but it's more frustrating to be uncertain about > whether something IS a bug! I've seen disagreement on this > list between experienced REBOL programmers over whether a > particular piece of behavior is a bug or not. ..
Pioneers often have to go forward with out a perfect Rand McNalley road atlas and triple-A. :)
> In the following, though, I must disagree a bit. > > > > > We all want to understand what hurdles people face in > > learning and adopting REBOL. We rap about this often > > in the office, and your breakdown above is pretty good, > > though I would throw out 7, 5 and 4 and just look at > > the remaining issues: Bugs and docs. > > The end of that sentence is where we part company. I'm not > willing to discard any avenue of inquiry into how we > programmers come to be confused about a language and what > might be done either to prevent or alleviate that > confusion.
I see where you're coming from. Just like to keep things in scale. Fixing bugs, developing more docs and cultivating community support are the top three things to my mind that would make an immediate difference. An honest question: How could we know if there are new users coming in and suddenly being turned off because they see that in REBOL they can't test if: false < true ?
> I'm also not persuaded that REBOL (nor any programming > language designed by mortals ;-) is so perfect in design and > concept that any issues must be considered as implementation > glitches, explanation breakdowns, or user head gaps.
Naw, but as I said, REBOL's design is solid and very consistent. That's not saying perfect, it's just to say that it is, in my view, an excellent design. I don't think we'd all be here if REBOL was riddled with design problems (not implying that's what you're implying!) Just trying to put things into perspective. . . .
> >> letter: "i" == "i" select gpa letter == none > >> gpa/:letter > ** Script Error: Invalid path value: i. Where: > ** gpa/:letter > > Is this really a bug? Is this an inconsistency that's > there for some historical reason? Is there some benefit to > having these two be subtly different? I think the > questions are worth asking, rather than ruling some > possibilities out of bounds.
Path notation is a shortcut. A shortcut takes a different path through the woods. In the woods it trips on a branch and has an error.
> > ... They want tutorials, and FAQs and how-tos, > > and cool examples, etc. REBOL Tech.'s worked hard on > > providing a lot of that stuff, and many others have as > > well, but this is one big area where any one can > > contribute in a meaningful way to the spread and > > adoption of REBOL. > > > > I hope these essays are serving such an end.
Certainly if people (newbies especially) manage to read through these huge ol' emails! :) I think there's something to the idea of trying to accomplish too many things in one single email. There should be an automatic send cut off switch when an email has covered, say, 5 concepts. :)
> > > > EITHER places the TRUE block first, the ELSE/FALSE > > block second. Pick thinks of TRUE/FALSE in that way. > > > > I don't see EITHER and PICK as analogous. EITHER is not a > construct with varying numbers of blocks, nor can we use > positional numeric selection with EITHER; therefore we are > free to use a "linguistic" model instead of a numerical > order model for deciding how to arrange its parts.
Okay, so you would like the following: pick [#1st #2nd] false == #1st pick [#1st #2nd] true == #2nd and true > false == true so.. none < false == ? Also in REBOL, TRUE is equivalent in a test to: (not none and not false) so what are the results to the following: false < "foo" false < false < 0 false < -1 false < print "This will be unset" etc... ?
> Actually, the underlying problem goes deeper. If we > allowed numeric labeling of elements in a collection to > follow the natural number progression of 0, 1, 2, ..., then > it would be even more obvious that FALSE selects the same > labeled position as 0 and TRUE selects the same labeled > position as 1.
which would be: pick [1 2] 0 == none ; for false pick [1 2] 1 == 1 ; for true Which means ....
> Before anyone responds with a claim that it's confusing for > the "first" position to be 0,
You would also like REBOL to be 0 based indexing?
> > Whenever we run into situations where we say "gee, that > > really dosn't work the way people would 'normally' > > expect" we fix them. > > > > That sounds good. However, natural language and the > common-sense expectations of 'normal' people (or even > programmers when they're not programming) are notorious for > their ambiguity and fuzziness.
And formalisms are notorious for their lack of conceptual accessibility.
> I humbly propose that the need for precision in programming > means that rigorous, elegant, and minimalist definition > should take priority over everyday conversational comfort, > should they ever come into conflict.
Good science should be easily explainable to children.
> > The thing I just want to exclude from the equation is > > the design of REBOL. > > Unfortunately, as I mentioned above, that requires the > assumption that the design is already perfect.
Just to reiterate my points: It's a matter of scale. Design issues are important, but design matters (and disagreements with), though certainly a passionate thing for creative thinkers such as yourself, are probably less important to the immediate and near term goals of REBOL, the language and the company, than your good old basic bug fixes, docs, and support (and for the company specifically: making products! (-:) --Not meant as a discouragement of you taking issue with REBOL's design where you see fit. I'm prone to being defensive of REBOL's design, but I hope I don't come off as prejudiced in my opinions. I also hope I haven't misrepresented anything in my response here. I appreciate all the effort you put forward into understanding and pushing for greater understanding of REBOL. Salutations! -jeff