From: Timothy Rue
To: Jeff Kreis
Subject: [REBOL] Lang. comparision plus :was>Two block questions
Date: Wed, 21 Oct 98 11:29:00
I've watched as others have comparied Rebol to other programming
languages. Pointing out the upside and downside of rebol.
But I also note that those doing this are those who have background in
other programming languages. A point worth noting if an objective of
rebol is to be geared towards simplifying coding so that more can more
easily learn and do, yet without constraints on Rebol applications
creation complexity potential.
There will always be the ability to compare one thing to other things but
at what point does such a comparision become an apple vs. orange issue?
My main interest in Rebol is simply this:
Being that Rebol is platform independant and intended to be more
geared towards human processes (easier to learn and use) than other
cryptic langauges, I'm interested in using it for producing a project
also intended to be platform independant.
Amiga users here probably know what I'm refering to but there are
other who may not. So here is the foundation. There are nine things we do
in any thing we do. It is these nine things I consider in looking to what
rebol offers in ability to do these nine things.
1) We start and stop (begin and finish) things.
2) We keep track of where we are in doing things.
3) We get input (make use of variables)
4) We define or select where we are getting input from.
5) We define or select where we are sending output to.
6) We do things sequencially (even in parrallel each part is sequencial)
7) We look things up (reference) and do (#6) based on what we find.
8) We identify things and do (#6) based on what we identify.
9) We put constraints on applying #7 and #8 in order to focus our intent
or objective and reduce the time it takes get to doing #6.
I could elaborate more on these, giving many examples....
(I.E. why #2? because we often get distracted in what we are doing, or
otherwise have to put on hold what we are doing in order to do someting
else first, only to need to remember where we left off in order to pick
up where we left off.)
....but I'm sure doing so could make for a long post.
Over the many years from when I first identified these nine, I have looked
into many things and methods of programming (AI, NLP, OOP, Constraint
programming, etc..). But I didn't look into these things to see how I
might apply the nine, but rather to see if I could find the nine (or
makings of) in such a way that I could easily apply them, integrate them
into a simple yet specific configuration.
Also over these years I have had to deal with individuals making
comparisions based on their mindset (*) interpreted perception of this
configuration. (*) mindset -> that which is the current thought tools and
interest of individuals.
In trying to explain the problem here, lets say you have the complete yet
basic tool set by which you can create anything. Thru the use of this tool
set you create any number of things, different and or similiar things, it
does not matter. Now you have all these things you've created thru the use
of this tool set that many others have made great use of, and they fully
understand these creations. But then what happens when you now
try to explain, tell them about this complete yet basic tool set?
We tend to relate something new to that which we already understand.
Actually there is a word for this and it's a bit more than just a "we
tend to" option but rather a required part of learning. Anyway....
The problem is this: you cannot describe such a tool set used to create
things, in terms of these created things. It's like trying to describe the
tools of a carpenter using the description of a house.
There is a second problem: when the product itself contains elements of
the tool set, the distinction between the tool set and the product becomes
even more difficult. Lets' say you have the primary genetic base elements
for human life of which you can create and put together genetic code parts
that make up unique individuals. Now try and use the genetic code of any
given number of individual to explain or define the primary base elements.
The problem is that of trying to identify primary elements from an
incomplete list (potential) of created code parts. Such an incomplete list
that prevents you from correctly identifying the primary elements of
genetic code creation.
Is there something more fundamental in the tool set of rebol by which we
have usability of rebols builtin vocabulary? I don't know. But I do know
that there is this ability of users to use rebol to create additional
vocabulary and that there is the todo list of what rebols vocabulary will
have added to it.
So, how does rebol, it's vocabulary tool set, currently fit or allow us to
apply any or all of the nine identified things we do? (This question is
not in reference to the configuration of the nine but only as nine
separate things.)
We have start and stop (begin, finish) abilities (#1)
*Do we have a way to keep track of where we are? (#2?)
We have a way to get input (#3)
We have a way to define/select where we are getting input from (#4)
We have a way to define/select where we are sending output to (#5)
*Do we have sequencial control in doing things? (#6?)
*Do we have ability to look things up (#7?) and do (#6?) based on what
we find?
We can identify things (#8) and do (#6?) base on what we identify thru
datatype query.
We can put constraints (#9) on what we look up (#7?) and identify (#8)
Thru dialects.
What are the limitations of Rebol in doing these individual things (**)
and doing them easily?
** Note that #2 is not independant in the respect that it would keep track
of where the other eight are (or at least the information relative to
applying them.)
---
*3 S.E.A.S - Virtual Interaction Configuration (VIC) - VISION OF VISIONS!*
*~ ~ ~ Advancing How we Perceive and Use the Tool of Computers!*
Timothy Rue What's *DONE* in all we do? *AI PK OI IP OP SF IQ ID KE*
Email @ mailto:timrue@mindspring.com >INPUT->(Processing)->OUTPUT>v
Web @ http://www.mindspring.com/~timrue/ ^<--------<----9----<--------<
=========================================================================
From: Jrm
To: rebol-userlist
Subject: Re: [REBOL] Lang. comparision plus :was>Two block questions
Date: Wed, 21 Oct 98 13:30:00
Tim,
I was in a rather foul mood this morning and blew off your
question, but on reconsideration I think it deserves a
well-thought out answer. I apologize for my rudeness.
Insofar as REBOL's capability to do everything that you describe,
rest assured that it can indeed.
REBOL isomorphic to Church's Lambda calculus. The way functions
are implemented is designed to follow the substitution rules of
Lambda calculus. You could try out many of Church's examples by
using the FUNC function instead of lambda and single arguments
functions.
Church and Rosser proved that Turing's concept of `effectively
computable functions', and Church's `lambda calculus', and
`recursively enumerable functions' were, in reality, different
aspects of the same thing. They went on to show that all
algorithmically computable functions are members of this set.
Therefore, any computation model as powerful as a Turing machine,
or isomorphic to LAMBDA calculus, is no more or less powerful
as any other.
However, this doesn't address the issue of convenience, which
you raise.
>So, how does rebol, it's vocabulary tool set, currently fit or allow us to
>apply any or all of the nine identified things we do? (This question is
>not in reference to the configuration of the nine but only as nine
>separate things.)
>
>We have start and stop (begin, finish) abilities (#1)
REBOL starts from the command line and stops with the
quit command. Furthermore individual rebol commands can be
run from the command line.
>*Do we have a way to keep track of where we are? (#2?)
This will improve. REBOL, of course, keeps track of where it is,
but this internal state is not always readily available to the user.
(Except via catch-func. But catch-func returns an opaque object,
that is not very enlightening).
>We have a way to get input (#3)
Input function, read from files.
>We have a way to define/select where we are getting input from (#4)
Argument to read.
>We have a way to define/select where we are sending output to (#5)
Argument to send.
>*Do we have sequencial control in doing things? (#6?)
This is implied by sequential execution. Additionally, you can
use the any, all, and reduce functions to sequentially evaluate a block.
>*Do we have ability to look things up (#7?) and do (#6?) based on what
> we find?
You can extend blocks or objects and use select to look things up.
You can use a conditional statement or `do' based on what is found.
>We can identify things (#8) and do (#6?) base on what we identify thru
> datatype query.
The type? command returns a symbol representing a datatype. This
can be dispatched upon.
I hope this is of help to you.
~jrm
==========================================================================
From: Jrm
To: rebol-userlist
Subject: Re: [REBOL] Lang. comparision plus :was>Two block questions
Date: Wed, 21 Oct 98 21:29:00
Thanks for the clarifications. It's been a while since I've read
Church, Rosser, etc.
What I was getting at is that once you show that your computer
language is at least as powerful as a Turing machine, or can
reduce lambda expressions (fairly simple criteria), you have shown
that your computer language is at least as powerful (in an abstract
sense) as any other language.
So in one sense, REBOL satisfies any abstract criteria for powerfulness
as any other Turing complete computer language.
In a more concrete sense, though, we still have a lot of work to do.
What this says is that the limitations of REBOL are simply in
the lack of a complete implementation of the native functions
rather than in a theoretical intractability we may have overlooked.
~jrm
-----Original Message-----
From: Tim Peters
To: rebol-userlist@lists.rebol.com
Date: Wednesday, October 21, 1998 7:11 PM
Subject: RE: [REBOL] Lang. comparision plus :was>Two block questions
>> ...
>> Church and Rosser proved that Turing's concept of `effectively
>> computable functions', and Church's `lambda calculus', and
>> `recursively enumerable functions' were, in reality, different
>> aspects of the same thing. They went on to show that all
>> algorithmically computable functions are members of this set.
>
>Not that it adds anything of value to this discussion <0.9 wink>, but the
>techie details in that exposition are off. The two main Church-Rosser
>theorems weren't concerned with computability per se, but with establishing
>that (theorem 1) if a normal form for a lambda expression exists, it's
>unique; and (theorem 2) there is an effective algorithm for finding a
lambda
>expression's normal form (if one exists -- determining *whether* one exists
>is much harder ("the halting problem")). Those lovely results are the
>theoretical underpinnings of all languages in the Lisp tree, REBOL
included.
>
>Proving the equivalence of various notions of computability was really more
>of a worldwide obsession in the late 1930's, and many people were involved
>(notably Kleene, and Turing himself).
>
>At the end of this chain, Church's Thesis (often called the Church-Turing
>Thesis, but never Church-Rosser) is that, *whatever* we think we mean by
>"effectively computable", it's captured by the formal notion of "partial
>recursive functions" (or Turing machines, or any of the other formal
notions
>that have been proved equivalent to it).
>
>It's called "a thesis" instead of "a theorem" because it makes an
unprovable
>claim: "effectively computable" is an *intuitive* notion, and so not
>subject to formal manipulation. Church's Thesis is simply that every time
>you do try to formalize it, no matter how clever you are you'll end up with
>a system provably equivalent to partial recursive functions (= Turing
>machines = Post productions = etc etc).
>
>To the small extent that it's argued against at all today, Church's Thesis
>is faulted on the grounds that partial recursive functions may be *more*
>powerful than "what we think we mean" by effectively computable.
>
>All that out of that way, no computer constrained by finite memory is as
>powerful as a Turing machine -- but nobody cares since that's just a detail
>(if computers had unbounded memory, "the problem" would go away).
>
>So, ignoring that bit of irksome reality, REBOL is certainly as strong as a
>Turing machine. But so are almost all other programming languages, from
>Fortran to Perl -- the whole point of Turing's construction was that even a
>*very* feeble "machine" could be proved as theoretically powerful as the
>most elaborate consructions that came before his. So, after slogging thru
>all the above , you're left with: (a) yes, practically speaking REBOL
>is Turing-complete; and, (b) but so is everything else.
>
>It's a wonderful field of study, especially for the sheer quantity of deep
&
>beautiful results (like this one!) that nevertheless have few practical
>implications. For anyone interested in pursuing it, I highly recommend
>Hartley Rogers Jr.'s "Theory of Recursive Functions and Effective
>Computability" (MIT Press, 1988). Look for it in a library, though: it's
>"the bible" in this field, and after an excellent intro goes into way more
>deep detail than you're likely to want to keep around the house .
>
>i-had-it-as-a-text-once-and-that's-my-only-excuse-ly y'rs - tim
>
>
>