Hi Max,
MOA> I love philosophy so, nothing here is personal... :-)
Yes, same here.
MOA> a lot of the code I see from
MOA> the guru is hard to read for me, simply because it uses tricks I have not
MOA> stumbled on yet... The words are all similar, but when looking at them, they
MOA> seem to have no meaning.
MOA> have you tried going through all the view code... there is much to learn, but
MOA> darn some of it is almost impossible to grasp.
This is one of the mindset changes I still struggle with. I used to
design and code so that things were as generically-understandable as
possible, at the expense of elegance. What I think about more and more
with REBOL is how to make things as clear as possible to a subset of
people--people that I want to communicate with. This is tough with
things like reusable modules and functions that could have a wide
audience and be put to use in many contexts.
Rather than writing for drop-in usage everywhere, I'll allow myself
to make assumptions and know that people will modify things to suit
their needs. It's a whole different view, and not an easy change for
me. But when I look at Carl's code in many places, that's how I
interpret what he has done. Really advanced REBOL is a different
language than very basic REBOL; a dialect if you will. :)
MOA> nothing is clear in rebol, until you've programmed in it a few months.
I can only speak for myself, but I *think* programmers coming from
other languages may have the hardest time with things. Even after two
years, I still don't always think of things how I know I should in
REBOL.
One of the best tricks I have found for myself is a twist on the idea
of "playing turtle" in Logo. I "play interpreter" by reading my code
as a series of values and stepping through it mentally. It's fun. :)
MOA> My guess is that RT can make sure that if they found a path value
MOA> with a block in it, they'd simply understand it as a range
MOA> instead... isn't that what a dialect is? context specific code?
...
MOA> it isnt really a change, its more of an addition, but I guess you mean that
MOA> people creating dialects and expecting paths, would have to handle range
MOA> notations too, then you are right, that it causes some mishaps. But then most of
MOA> the code I get from this list already isn't supported in older versions of
MOA> rebol... especially view v1.2.3
Yes, but I guess I see it as a more sweeping change than that, because
it's adding a dialect to a datatype, which has a specific lexical
form, so if you do it for paths: do you do it for other datatypes; is
it only valid as a complete path element; are they aggressively
evaluated; does it cause other side effects; how does COMPOSE work
with it (i.e. block flattening); can they be nested; do we go as far
as the concept of generators in Icon, and what would that mean, etc.
Maybe I just worry too much. :)
Could I do stuff like this?
start: 2
stop: 12
foreach ip 192.168.[1:10].1 [
; time! values as range boundaries?
foreach data read join http:// [ip "/dat[(00:00):(4:30)].html"] [
foreach addr data-monitor-[#"a":#"f"[EMAIL PROTECTED] [
send addr data/[:start::stop] ;<< ??? syntax
]
]
]
And what would be the cost in time, effort, and complexity, versus
what we gain, maybe compared with writing a RANGE function that knows
how to handle this stuff, but makes it an explicit dialected function?
MOA> don't want to look picky but
MOA> a: 1
MOA> b: 5
MOA> excerpt b [a to b]
MOA> I know someone will say do this:
MOA> excerpt b compose [(a) to (b)]
Wouldn't a range notation have the same issue? A dialect is a dialect
(no matter how small :).
How would a range notation handle it?
b/[a:b] ; aggressively evaluated. Only integer! boundaries OK?
b/:[a:b] ; per current path evaluation syntax
b/[:a::b] ; with a twist
compose b/[(a:b)] ; COMPOSE has to know about range notation
compose b/[(a):(b)] ; COMPOSE doesn't know about range notation
Thanks for the conversation on this!
-- Gregg
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
