[REBOL] Re: Model hacking
From: lmecir:mbox:vol:cz at: 22-Jun-2001 21:42
Hi,
> OBTW, I really liked your article
>
> http://www.rebolforces.com/articles/series.html
>
> Would it do violence to your model to address the notion that
>
> index? foo
>
> must lie within the range 1 thru 1 + LENGTH? FOO and that
yes, it is incorrect in my model... ;-) ,
I would say, that it must lie within the range 1 thru 1 + LENGTH? HEAD FOO
> tail? foo
>
> is equivalent to
>
> index? foo = (1 + length? head foo)
>
That wouldn't do any violence, I may try to find an appropriate place for it
> > > 1) LITERAL -- Some types (e.g., decimal!, time!, block!) have
> > > the property that you can explicitly represent
> > > a value of that type in REBOL source code. For other types
> > > (e.g., list!, object!, or function!) you can only write
> > > expressions (e.g., make or copy) that cause such a value to
> > > be constructed with the expression is evaluated.
> >
> > This is an interesting category. The only "problem" (thinking out
> > loud) is, that if you want, you can use any Rebol value as
> > "literal" in a composed block.
> >
>
...snip...
> Part of the motivation has to do with our old friend...
>
> koan: func [x /local z] [
> z: [] append z x mold head z
> ]
>
...snip...
> Finally, if we
> wished KOAN to deal with LIST! instead of BLOCK! data, we are
> forced to write...
>
> koan: func [x /local z] [
> z: make list! 0 append z x mold head z
> ]
>
> >> koan 4
> == "make list! [4]"
> >> koan 6
> == "make list! [6]"
> >> koan 17
> == "make list! [17]"
>
> ...because there's no "literal" syntax for list. Consequently,
> we cannot create the situation that occurred in the first
> case.
My motivation was exactly the same: you can create almost anything
(especially in Rebol!), if you will:
koan: func [x /local z] reduce [
first [z:] make list! 0 'append 'z 'x 'mold 'head 'z
]
source koan
; koan: func [x /local z][z: make list! [] append z x mold head z]
koan 4 ; == "make list! [4]"
koan 6 ; == "make list! [4 6]"
koan 17 ; == "make list! [4 6 17]"
This doesn't mean I have got anything against the classification you
proposed :-)
LM
