[REBOL] Re: Looking over the horizon - Rebol 3
From: joel:neely:fedex at: 10-Nov-2003 8:10
Hi, Andrew,
Thanks for starting what I hope will be a productive thread! Now,
speaking strictly for myself, little of my REBOL wish list is about
adding features to the language.
Andrew Martin wrote:
> * Lots more datatypes! For example, a Telephone! data type, temperature,
> audio/sound data-type, metric and imperial units like 123.5Km, 50MpH,
> and so on...
>
No. Please, no. Please, please, no.
There have been plenty of threads in the past about the confusing and
not-completely-documented behavior associated with the existing plethora
of types. Do we really want that situation compounded??? (e.g. what
happens when I add 2 to 123.5Km, what happens when I multiply 50MpH by
32F, ...)
I realy have only two wishes in regard to data types:
1) Fully document the existing ones.
2) Add support for promoting objects to true user-defined types.
I hope the first is obvious (and non-controversial) to the list.
Let me give a trivial example of the second issue, and then apply it
(in a non-trivial way, I hope! ;-) to your wish list above.
REBOL has a PAIR! type which can be used for 2D points, but suppose I
am working on projective geometry in a serious way. I can define
; projective point
ppoint: make object! [
u: v: w: 0 ; projective coordinates of pline
to-string: func [] [...] ; create a printable representation
... ; other natural behavior of a ppoint
]
; projective line
pline : make object! [
p: q: r: 0 ; projective coordinates of pline
to-string: func [] [...] ; create a printable representation
... ; other natural behavior of a pline
]
after which I can sprinkle such things as the following thru my code:
P1: make ppoint [u: -1 v: 2 w: 1]
P2: make ppoint [u: 4 v: 5 w: -1]
L1: make pline [p: 1 q: -1 r: 0]
but the list of useful things I *can't* do includes the following:
; function that returns the point where two lines intersect
common-point: func [l1 [pline] l2 [pline]] [
...
]
; function that returns the line joining two points
common-line: func [p1 [ppoint] p2 [ppoint]] [
...
]
; is the given point on the given line?
pt-on-line?: func [p1 [ppoint] l1 [pline]] [
...
]
print ["line 2 is " common-line P1 P2] ; and get meaningful output
P3: 2 * P1 ; by defining for REBOL what it means to multiply
; a ppoint by a number
If I want to define a function that takes a ppoint as an argument, I
can only say:
some-function: func [ppt [object!] ...] [...]
but then REBOL will allow *any* object to be passed (likely giving me
a run-time error when I try to actually perform some operation on/with
it inside the function body).
Now, let's apply this idea to your list; many of your desired types
are just numbers with an associated dimensionality -- so many degrees F
(or C or K ...), yea many pounds (or grams or kilograms or stone ...),
and (with composite dimensions) thus many grams per cubic centimeter
(or miles per hour, or liters per second ...)
If we had true type support for objects, we (*any* REBOL programmer
with enough experience/determination) could write something like
(I'm making this up as an illustration, so it's not debugged! ;-)
dimensions: make object! [
numerators: []
denominators: []
to-string: func [] [...]
...
]
dimensioned-number: make object! [
value: 0
units: make dimensions []
to-string: func [] [...]
...
]
distance: dimensioned-number 6 [mile]
how-long: dimensioned-number .1 [hour]
print distance / how-long ; or print divide distance how-long
and get
60 mile per hour
Then someone who wanted to compute earth's escape velocity in
furlongs per fortnight could do so without further support from RT!
> * A way to access words outside of the current context. Perhaps
> extending the refinement! data-type, like:
> /Foo: 123 ; set the value of 'Foo outside this
> context to 123.
>
Could you give an example of what this means and how it would be
used/useful? I must confess that I don't understand it at all.
> * Regular Expressions as well as parse, which acts much like Perl's
> regexp.
>
At the risk of sounding inconsistent, I believe that this one added
feature would do more to broaden REBOL's appeal than anything I've
seen on the list in a long time. Even though there's some variation
in syntax (and number of extensions), REs are a core, mainstream
concept in the world I live in. Recognizing that fact, and making a
(tiny) concession to the existing skills of the programming community
would eliminate one more excuse for serious geeks to dismiss REBOL.
> * Native XML! data-type.
>
My top XML wish is simply a beefed-up XML parser which does validation
(natively coded if necessary for performance). Adding that level of
support for standards (coupled with the above suggestion for true
object-type support) would allow the community to finish the job.
> Anything else you'd want on your wish list for Rebol 3?
>
1) complete documentation
2) open bug tracking, feedback, and resolution process
3) View on OS/X
4) either an implementation of RT's module facility or a statement
that it has been dropped (or deferred indefinitely... ;-)
I could be happy for a long time if the above issues were addressed
before *any* new features were added to the language. Getting true
object-type support would leave me nearly delirious! ;-)
Now let's be brutally honest with ourselves; what would we say if the
question had been instead:
What could be done in/with the next release of REBOL to
maximize its appeal to the larger programming community
and its long-term viability?
I suggest that the answers to that question would be quite different
from most of the wish-lists of existing REBOL users. In defense of
that view, I can rephrase the question as:
Given that you do not currently know REBOL, what benefit
could it offer to you that would help you be willing to invest
the time to learn and use it?
I believe that we, as a community, would benefit REBOL (and RT) by
addressing that question as well.
-jn-
