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

[REBOL] Re: [data structures] (was Re: [append][series]Appending to a series of

From: joel:neely:fedex at: 21-Nov-2003 11:54

Hi, Ladislav, et al, Ladislav Mecir wrote:
> Joel Neely napsal(a): > >> REBOL seems to occupy a middle-ground position on this issue; it >> does not require you to declare the existence of a data structure >> (as e.g. Java does) but it *does* require that you allocate and >> initialize it explicitly. > > I think, that you are describing *only* a top-down approach here. > A bottom-up approach might lead to: >
No, not the way I understand those terms ("top-down" = beginning with the overall "top" goal and working "down" to successively finder- grained detail; "bottom-up" = beginning with detailed "bottom" concepts and aggregating/building them "up" to the final goal). Those terms have to do with *when* in the development process we address a given level of detail; what I'm trying to focus on is the issue of *whether* certain levels of detail have to be addressed at all (regardless of when).
> get-value: function [ > ... > ] > > set-value: func [ > ... > ] > > inc: func [ > ... > ] > ... > > In Rebol you can "teach" the language to do what you want it to, > because Rebol facilitates the process of the language extension. >
While I would probably write such things as methods on an object, presenting those capabilities as three individual functions is certainly a way to get the job done. But in either case, whether we sweep those details under an object or into separate functions, the fact remains that -- at some point in our design and development process -- we had to pick up the broom!
>> ... Finally, (back to the original discussion) Perl will even >>automatically figure out when to allocate/initialize structures and >>elements for me. >> > > What if you needed a different default value, wouldn't that leave > you on your own in Perl? >
Certainly, although the default applied in a given case depends on the operation being performed: zero for numerical operations and the empty string "" for string operations. And overriding those defaults is easy; if we wanted to accumulate products of values associated with keys (instead of sums) the key expressions would be: if (defined $tallies [$key]) { $tallies [$key] *= $val; } else { $tallies [$key] = $val; } or $tallies [$key] = 1 unless defined $tallies [$key]; $tallies [$key] *= $val; And note, in passing, that the test to see whether a given element of the data structure is defined is independent of what types of data might be stored there. The corresponding test in your GET-VALUE was equivalent to: value: pick array index + 1 either value [value] [0] which would have to be re-engineered if we wanted e.g. an array which might include LOGIC! or NONE! values. (The fact that we even have to think of such details is again my real point here.)
> I think, that the "effect on thinking" in Rebol may be caused more > by inertia than by language limitations. >
I'm not condemning REBOL for "limitations", but merely observing that different language designs reflect the designers' philosophies of programming and choices about what would be most likely needed by the programmer. And I could certainly give examples of nice REBOL features of REBOL that aren't built into Perl (see footnote). I'd certainly agree that "inertia" in the sense that "one tends to think in habitual ways" is a factor in almost everything we humans do. But please reread my statement before taking issue with it: As a polyglot, I'm less interested in picking sides in a political debate than understanding deeply the effects on my own thinking when I begin to "think like a native" in one or more of them. As one begins to "think like a native" in language X, that means that one has begun to overcome the pre-X habits, IMHO. I'm not going to lay any claim to REBOL-guru-hood, but I do believe my approach to writing-in/thinking-with REBOL is different than when I began using it some years ago. I recently spent some time with a decades-old book of programming puzzles of the "recreational mathematics" flavor. I used REBOL to construct my solutions, then compared my approach with the code in the back of the book (given in C, BASIC, and Pascal). I was repeatedly struck by the differences in my designs and those of the book -- to the point that it was very difficult to compare some of them in any meaningful way (although REBOL on my 600 MHz laptop handily outperformed the timings in the book for compiled C on an 8MHz Pc! ;-) I often used recursive functions and/or dynamically-managed blocks in my solutions; needless to say, both of these were absent from the book. But my interest goes even deeper than language features. In at least one puzzle, I had a single loop that operated on a small number of variables holding only integer values. But the thought process by which I arrived at that solution was radically different than that taken in the book's solution. To whatever degree my design approach was an improvement over the book's (and over my own that many decades ago! ;-), I must credit in part the influence of great ideas in more effective languages, including LISP, FORTH, Prolog, Perl, Java, Ruby, ..., and (last but certainly not least!) REBOL. -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Enron Accountingg in a Nutshell: 1c=$0.01=($0.10)**2=(10c)**2=100c=$1