Reading Rebol and structures => was {Re: [Edu-sig] Top 5 All Time Novice Obstacles => #3 Where am I ?}

[Jason Cunliffe]

> I'm not sure, but I think a Rebol statement can look like
>
>   a b c d
>
> This could mean a(b, c, d) or a(b(c), d) or a(b, c(d)) or a(b(c, d)),
> depending on how many arguments a takes and what b and c are.

Yes that's right. In practice REBOL 'blocks' [lists] help delineate most
contexts clearly. One of the good edu-sig questions to ask is perhaps, why in
practice do most people find this aspect of Rebol so very familiar and easy to
deal with?

My theory is that its because it partly follows the way our human
(spoken,written) languages are structured. Clusterings of clauses and phrases
with modifiers which move from beginning to end as narrative flow.. Different
from more logic- or mathematically oriented structures.

I like to think that Rebol moves in two directions at the same time.
A sort of reverse FORTH communications stream ...

<<<---
--->>>

gathering up arguments and evaluating expressions,
building functions sequenced series and narrative.

Rebol is above all a messaging language, designed to handle expressions. Rebol
PARSE is touted by some to be its 'jewel in the crown', allowing one to define
sub-languages or 'Dialects'. I am still not sure how good an idea or not in
practice. Too early to say yet anyway.
Pro: Sweet short customized syntax fulfill application domain, meet end-user
needs
Con: Hidden behavior, and unfamiliar vocabulary risk [human] namespace
confusion.

http://www.rebol.com/docs/rebolintro.html
http://rebol.com/docs/core23/rebolcore.html
http://rebol.com/docs/core23/rebolcore-15.html

Rebol parents are REXX, ARexx, FORTH, LISP, and LOGO. After designing the
original AmigaOS, Carl Sassenrath became deeply involved in Smalltalk, then
moved towards a different approach for Rebol. Declarative expressions where
everything is data, and natural language is a major inspiration. Its FORTH roots
are visible in the way it lets one define words very freely in-line. LISP
influences mean that nested lists are the natural form, as expressed in blocks
[]. Mathematica does the same.

One interesting parallel to draw is how Zope publishes the ZODB as URLS

http://somesite.org/zope/section/subsection/method/quailfier/data/method/args

But Zope 'acquisition' means that we are not looking at just an ordinary
descending traversal of a tree path. Acquisition is Zope's maybe most potent,
but confusing feature. I've not been following Zope closely for about 8 months,
but I read somewhere that Zope3 is moving away from acquisition, because people
find is too 'hard' to manage. Component framework is now the chosen design
pattern.

Python moves consistently, lucidly in one direction --->>> but lets one choose:

function(object)
object.function()


Python white space indentation is main feature which makes it so 'readable'.
But I am curious, when people teach Python and want to read/speak it out loud
what do you say? How does one 'speak' Python?

The object tree can be far from linear. It's been really fascinating to a view
Leo's own python source in Leo. Once can load any file, but here's LeoPy.leo:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leo/leo/LeoPy.leo

It presents a clear tree structure interface, but 'clones' [aliases] and in-line
'includes' allow one get a much better overview than normal. It's easier to read
visually, perhaps in a classroom out loud too.

The new browsable 2.1++ module docs are very cool. Since Leo is 100% python,
with API and full control of the outline tree, it is perhaps a fast way to
explore alternate ideas/representations of the module docs idea.

http://personalpages.tds.net/~edream/scripting.html#anchor612831

./Jason