[REBOL] Model hacking
From: joel::neely::fedex::com at: 21-Jun-2001 4:23
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.
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.
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.
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!.
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?
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com