[REBOL] Re: Model hacking
From: lmecir:mbox:vol:cz at: 22-Jun-2001 15:38
Hi,
I modified (again) the http://www.sweb.cz/LMecir/evaluation.html
It now sports three functions: IDENTICAL?, EQUAL-STATE? and FIND-OCCURRENCE.
Sample code:
a: []
insert/only a a
b: []
insert/only b b
o: make object! [a: 1]
p: make object! [a: 1]
identical? a b ; == false
identical? o p ; == false
equal-state? a b; == true
equal-state? o p; == true
Warning! Don't try to use SAME? or EQUAL? instead!
See my notes below:
----- Original Message -----
From: Joel Neely <[joel--neely--fedex--com]>
To: <[rebol-list--rebol--com]>
Sent: Thursday, June 21, 2001 11:23 AM
Subject: [REBOL] Model hacking
> I (personally) think that the recent discussions on mutability
> and SAME? vs. EQUAL? may have narrowed our scope and bogged
> us down a bit too much (and I hereby claim my share of the
> blame for that! ;-)
>
> I think we'd agree that understanding the rich set of available
> data types is one of the keys to using REBOL more effectively
> and accurately. One of the issues I've been pondering lately
> is the kinds of characteristics that allow us to group,
> distinguish, and describe this embarrasment of riches.
>
> I thought I'd make it an "open source" pondering and toss out
> some ideas for expansion, refinement , pruning, and improvement
> by the community. I've made up some terms here, and am very
> open to suggestions for better jargon. Some of these
> distinctions are:
>
> 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.
> 2) REFERENCE vs. SCALAR -- Values of some types (series!, for
> example) are "referred to" in a
> way that lets them be shared among words, blocks, etc. Other
> type (such as integer!) are not shared.
Let me translate the last sentence to something that might be correct:
INTEGER! type values are (probably) implemented as non-shared values in a
Language I Do Not Want To Name Here in the current implementation of Rebol
from RT.
If RT implemented them as shared values in a LIDNWTNH, you would
have no chance to see any difference observing the behaviour of your
programs. In different words: this notion is not saying anything about the
properties of Rebol.
> 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?
> 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 - Activity. Active values
are:
active?: func [
{finds out, if a Rebol value is active}
value [any-type!]
] [
found? any [
any-function? get/any 'value
get-word? get/any 'value
lit-word? get/any 'value
set-word? get/any 'value
word? get/any 'value
lit-path? get/any 'value
path? get/any 'value
set-path? get/any 'value
]
]
2) how a value behaves as a "contents" of a word - Callability. Callable
values are:
callable?: func [
{finds out, if a Rebol value is callable}
value [any-type!]
] [
found? any [
any-function? get/any 'value
lit-word? get/any 'value
set-word? get/any 'value
lit-path? get/any 'value
path? get/any 'value
set-path? get/any 'value
]
]
3) all other values I call Passive
> 5) SYSTEM vs. USER -- Some types are predefined by REBOL and
> the user cannot create values of that
> type (e.g., op!) while other types can be created at will
> by the user's expressions (object! and function!)
>
> 6) CLOSED vs. OPEN -- Some types (logic! and datatype!) have
> a set-in-concrete set of possible
> values, while others are open-ended and new values may be
> created at will (function! and block!)
>
> 7) MUTABLE vs. IMMUTABLE -- ... I don't think I'll say any more
> about this one right now! ;-)
>
> Are these useful distinctions? Are there others that would
> be helpful? Can we actually identify how each type fits into
> each of these?
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
