[REBOL] Re: Model hacking
From: joel:neely:fedex at: 22-Jun-2001 11:54
Hi, Ladislav,
Specific observations further below...
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
tail? foo
is equivalent to
index? foo = (1 + length? head foo)
or is that there and I just missed it?
>> phlarp: ["a" "b" "c" "d"] == ["a" "b" "c" "d"]
>> length? phlarp == 4
>> index? phlarp == 1
>> index? tail phlarp == 5
>> gloop: [] == []
>> length? gloop == 0
>> index? gloop == 1
>> tail? gloop == true
>> map func [s] [(index? s) = (1 + length? head s)] reduce [
[ phlarp
[ tail phlarp
[ gloop]
== [false true true]
>> map func [s] [tail? s] reduce [
[ phlarp
[ tail phlarp
[ gloop]
== [false true true]
Ladislav Mecir wrote:
> Hi,
>
> I modified (again) the http://www.sweb.cz/LMecir/evaluation.html
>
> It now sports three functions: IDENTICAL?, EQUAL-STATE? and
> FIND-OCCURRENCE.
>
I'm looking forward to re-reading it (but it may take a couple
of days to fit it in...)
> See my notes below:
>
> >
> > 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.
>
Perhaps the problem is my explanation. If by "in a composed block"
you mean something like
>> gorp: [1 12:34:56 [1 2] (make list! [1 2])]
== [1 12:34:56 [1 2] (make list! [1 2])]
>> length? gorp
== 4
>> foreach item gorp [print type? :item]
integer
time
block
paren
>> glop: compose gorp
== [1 12:34:56 [1 2] make list! [1 2]]
>> length? glop
== 4
>> foreach item glop [print type? :item]
integer
time
block
list
then I'd say that it illustrates the distinction I'm trying to
draw. There was no LIST! until the paren got evaluated by the
COMPOSE. As another demo, given a file named foo.r containing
1 12:34:56 [1 2] make list! [1 2]
we can say
>> foo: load %gorp.r
== [1 12:34:56 [1 2] make list! [1 2]
]
>> length? foo
== 6
>> foreach item foo [print type? item]
integer
time
block
word
word
block
>> foo: reduce load %gorp.r
== [1 12:34:56 [1 2] make list! [1 2]]
>> length? foo
== 4
>> foreach item foo [print type? item]
integer
time
block
list
Again, there's no LIST! until after the REDUCE evaluated the
MAKE... expression.
Part of the motivation has to do with our old friend...
koan: func [x /local z] [
z: [] append z x mold head z
]
>> koan 4
== "[4]"
>> koan 6
== "[4 6]"
>> koan 17
== "[4 6 17]"
The second element of the body of KOAN is a "literal" block.
Once Z refers to that block, any changes via Z are changing the
second element of the body of KOAN.
On the other hand, in this version...
koan: func [x /local z] [
z: make block! 0 append z x mold head z
]
>> koan 4
== "[4]"
>> koan 6
== "[6]"
>> koan 17
== "[17]"
...there is no literal block, only instructions to make a new
one. There's no persistence to trouble us. 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.
> >
> > 3) ELEMENTARY vs. COMPOSITE -- Values of some types have
> > "sub-"components that REBOL
> > explicitly lets us talk about (e.g., time! values with their
> > /hour, /minute, and /second fields). Other types (e.g. char!
> > and logic!) do not.
>
> A rather subjective notion. Don't you think, that type is an
> attribute of any Rebol value?
>
It is certainly something I can say *about* the value, but it
is not a sub-component *of* the value IMHO. Jeff recently had
quite a bit to say in a recent post about viewing a series as
a single value vs. considering it as a collection of values.
I can do that with (e.g.) time! or tuple! values as well,
taking them apart...
>> t: now/time == 11:45:41
>> t/hour == 11
>> t/minute == 45
>> t/second == 41
>> u: 12.34.56.78 == 12.34.56.78
>> first u == 12
>> second u == 34
>> third u == 56
>> fourth u == 78
...or putting them together...
>> tt: make time! reduce [t/hour t/minute t/second]
== 11:45:41
>> uu: make tuple! reduce [u/1 u/2 u/3 u/4]
== 12.34.56.78
...but I know of no corresponding way in which REBOL invites me
to think about the "parts" of a logic! value.
> >
> > 4) ACTIVE vs. PASSIVE -- Values of some types actually "take
> > some action" when evaluated, while
> > others are "just there". This is tied to the distinction
> > between
> >
> > a: b
> >
> > and
> >
> > a: :b
> >
> > of course. "Active" types include function! and tuple!, while
> > "passive" types include issue! and money!.
>
> I see three categories here:
>
> 1) how a value behaves as a "literal" in a block ...
> 2) how a value behaves as a "contents" of a word ...
> 3) all other values I call Passive
>
Let me think about that one for a while.
> 8) Second class values: ERROR! and UNSET! datatypes
>
> the ERROR! values cannot be normally obtained as a result of a block
> evaluation, e.g. For more see REP.html
>
> UNSET! type value isn't considered a value by Rebol sometimes
>
Thanks! A distiction between FIRST-CLASS and SECOND-CLASS seems
useful for the kinds of categorizations I had in mind
-jn-
It's turtles all the way down!
joel'dot'neely'at'fedex'dot'com