Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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