Mm, that does help me understand... Sorta.
'append calls 'insert, and no explicit call to 'copy, but 'insert is a
native, so we can't look at it's source....
Unless someone who knows more about it replies, my best guess is that, if
Rebol uses cons, 'insert does copy the second value before inserting it into
the series.
>> source append
append: func [
{Appends a value to the tail of a series and returns the series head.}
series [series! port!]
value
/only "Appends a block value as a block"
][
head either only [
insert/only tail series :value
] [
insert tail series :value
]
]
>> source insert
insert: native [
{Inserts a value into a series and returns the series after the insert.}
series [series! port! bitset!] "Series at point to insert"
value [any-type!] "The value to insert"
/part "Limits to a given length or position."
range [number! series! port! pair!]
/only "Inserts a series as a series."
/dup "Duplicates the insert a specified number of times."
count [number! pair!]
]
> Hehe. Let me explain why I'm a bit confused and maybe that will help. I
> just
> want to build off what you originally replied with.
>
> Okay, so, the definition of a cons, of course, is just a trivial,
> uni-directional, linked-list:
>
> (A . (B . (C . NIL))) -> (A B C)
> (D . NIL) -> (D)
>
> The reason that the original list in FOO changes (assuming that REBOL uses
> conses) is that the cons holding 'C' is modified to also include the D
> cons:
>
> (A . (B . (C . (D . NIL)))) -> (A B C D)
>
> And, of course, since the function FOO just makes use of that
> pre-allocated
> list in bytecode (or whatever REBOL uses for interpretation of data), the
> "source" of FOO changes with each call.
>
> However, [d] is no different from [a b c] in the source (meaning that both
> are "pre-allocated data" - for lack of a better term - they aren't
> recreated
> each call). Suppose I wrote the function like this:
>
> foo: func [/local a b] [
> a: [a b c]
> b: [d]
> append a b
> ]
>
> Now, after the first call, the function's source is now:
>
> foo: func [/local a b] [
> a: [a b c d]
> b: [d]
> append a b
> ]
>
> Simple enough. But, the last cons in the list that 'a' points to is the
> same
> cons that 'b' points to (if REBOL is consing). So, after the second call,
> we
> should have an infinite list:
>
> foo: func [/local a b] [
> a: [a b c d d d d d ... ]
> b: [d d d d d d ... ]
> append a b
> ]
>
> This is what Lisp does, and if REBOL conses, is what I would expect that
> it
> would do as well.It could also be that APPEND has a built-in safe guard,
> in
> that maybe it copies the second argument to prevent self-referencing
> objects?
>
> Anyway, perhaps this better explains my question. :-)
>
> Jeff M.
>
> --
> [EMAIL PROTECTED]
>
> On 3/15/06, Izkata <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> I have no idea, I was trying to explain your "This makes sense, at least,
>> until after the second call. "
>>
>> I've only ever even seen one example of Lisp code.. ='^.^=
>>
>>
>> > Yes. I know. Sorry, I don't mean to be rude or curt, and I do thank you
>> > for
>> > your reply, but it in no addressed my question. :-)
>> >
>> > I understand "everything is data" (I come from Lisp, which has been
>> doing
>> > this for a very long time). And that, as in Lisp, is what gives REBOL
>> its
>> > power.
>> >
>> > My question was more fundamental: "Does REBOL use consing for its lists
>> > internally?"
>> >
>> > Jeff M.
>> >
>> > --
>> > [EMAIL PROTECTED]
>> >
>> > --
>> > To unsubscribe from the list, just send an email to
>> > lists at rebol.com with unsubscribe as the subject.
>> >
>>
>> --
>> To unsubscribe from the list, just send an email to
>> lists at rebol.com with unsubscribe as the subject.
>>
>>
>
> --
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
>
--
To unsubscribe from the list, just send an email to
lists at rebol.com with unsubscribe as the subject.
