[REBOL] Re: Does REBOL cons?
From: volker:nitsch:gma:il at: 16-Mar-2006 0:06
Blocks are areas, not lists.
On 3/15/06, Jeff Massung <massung-gmail.com> wrote:
> Okay, so, I've been trying something out, comparing REBOL to Lisp. The
> functions in REBOL make it appear as though the lists (series!) in REBOL are
> just your average conses (first, next, associations, etc). Because of this
> and constant data optimizations, etc, this function in REBOL makes sense:
> foo: func [/local a] [
> a: [a b c]
> append a [d]
> >> foo
> == [a b c d]
> >> foo
> == [a b c d d]
> This makes sense, at least, until after the second call. The above function
> would be akin to the following Lisp code, which does *almost* the same
> (defun foo ()
> (let ((a '(a b c)))
> (nconc a '(d))))
> The main difference being that the second call to (foo) will result in an
> infinite list, because '(d) is scoped data, just like '(a b c), and the
> second call will cons '(d) with itself, giving us '(a b c d d d d d ...).
> In REBOL, everything seems to match up, except that [d] doesn't cons with
> itself. Now, IMO, this is good, desired behavior (not generating an infinite
> list). However, what this implies "under-the-hood" is that REBOL doesn't use
> traditional consing for lists, but does something else instead.
> I was wondering if anyone could shed a little light on this. If REBOL does
> use consing, then why don't I end up with an infinite, self-referencing
> list? If it doesn't using consing, what does it use (not that it matters,
> I'm just curious)? This is actually a little exciting to me, because if it
> isn't using your typical consing, then that means REBOL's associated lists
> could potentially be a lot faster than Lisp's (which, of course, have O(n)
> access times).
> Jeff M.
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
Any problem in computer science can be solved with another layer of
indirection. But that usually will create another problem.