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

[REBOL] Re: Cunning use of [], () & {} in R# and in future? Rebol versions?

From: greggirwin:mindspring at: 20-Oct-2003 10:48

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"]@synedyne.dom [ 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