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.
> > ...you 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 < http://foo.bar
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
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
