[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
