Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Is Rebol OO?

 [1/40] from: behrangsa::yahoo::com at: 11-Jan-2004 9:52


Hi Sorry if this is a stupid question, but is REBOL Object Oriented? Thanks, Behrang S.

 [2/40] from: tim:johnsons-web at: 11-Jan-2004 9:23


* Behrang Saeedzadeh <[behrangsa--yahoo--com]> [040111 09:10]:
> Hi
Hi Behrang:
> Sorry if this is a stupid question, but is REBOL > Object Oriented?
Yes. But 'Oriented' is relative. see http://www.rebol.com/docs/core23/rebolcore-10.html rebol's OOP features are fairly simple. Nothing like Python's Special Class Methods, and everything is 'public' - although rebol does allow anonymous context/objects which do provide data hiding... Have a look at the link above. tim -- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com<

 [3/40] from: greggirwin:mindspring at: 11-Jan-2004 12:13


Hi Behrang, BS> Sorry if this is a stupid question, but is REBOL BS> Object Oriented? Not a stupid question. REBOL is not OO in the sense that you think of with Smalltalk, Eiffel, Java, Ruby, etc. It has "objects", but they are used as prototypes to create new objects. There is no concept of "class" in REBOL and objects don't have any private/protected members by default (though you can create them if you really want to and think it's worth the effort). REBOL's approach isn't better or worse, but it is definitely different, and not strict OO according to the three main criteria. -- Gregg

 [4/40] from: andreas:bolka:gmx at: 11-Jan-2004 20:17


Sunday, January 11, 2004, 6:52:50 PM, Behrang wrote:
> Sorry if this is a stupid question, but is REBOL Object Oriented?
No. Although this basically boils down to what you consider to be "object oriented" ;) Under the aspects commonly considered, "standard" REBOL is clearly not object oriented. However, due to the flexibility of REBOL, it's possible to build an object system on top of REBOL (just as object systems have been built on top of e.g. Lisp/Scheme). -- Best regards, Andreas

 [5/40] from: jason:cunliffe:verizon at: 11-Jan-2004 14:33


> Sorry if this is a stupid question, but is REBOL > Object Oriented?
No not in the familiar sense.. Rebol does have objects, and can be used for object-oriented programming in a broad way, but it won't much look like anything you know. Quite different from Javascript, Python or Java etc. Rebol has very unique programming paradigm. It includes very good ideas from FORTH, LOGO, and LISP and is closer to them than anything else. It is great fun to program in Rebol and does good things to one head -- a tool for thinking as well as getting things done. I use Python, Javascript, and Actionscript a lot. and working with Rebol gives me a fresh perspective on those languages and how to approach problems. Other people here are far better qualified than me. They can perhaps give you a good technical explanation about Rebol and its object-oriented-ness. It is well known that Rebol's brilliant author, Carl Sassenrath, in a previous lifetime was passionately involved in object-oriented programming. Rebol is an experimental synthesis of Carl's language design ideas and philosophy. Crucially it represents his reaction to object-oriented programming. Rebol is an alternative paradigm. As I understand it, Rebol was created to provide an experimental base for developing language ideas inspired by natural human speech and writing. So the idea of 'Dialects' and how to implement those was very influential on Rebol's features. A key tool for creating dialects in Rebol is the 'parse' function. There is much more to using it than meets the eye. And I believe not yet enough examples or use of dialects for most people to understand yet the long-term implication of the idea or how well this works in reality. hth -Jason

 [6/40] from: AJMartin:orcon at: 24-Jan-2004 11:47


Jason wrote:
> As I understand it, Rebol was created to provide an experimental base for
developing language ideas inspired by natural human speech and writing. So the idea of 'Dialects' and how to implement those was very influential on Rebol's features. A key tool for creating dialects in Rebol is the 'parse' function. There is much more to using it than meets the eye. And I believe not yet enough examples or use of dialects for most people to understand yet the long-term implication of the idea or how well this works in reality. Here's an example of OO code in C#: p = new Panel (); Button Cancel = new Button (); Cancel.Text = "Cancel"; Cancel.DialogResult = DialogResult.Cancel; Cancel.FlatStyle = FlatStyle.System; p.Controls.Add (Cancel); CancelButton = Cancel; Button OK = new Button (); OK.Text = "OK"; OK.DialogResult = DialogResult.OK; OK.FlatStyle = FlatStyle.System; p.Controls.Add (OK); The above creates a Panel control, and adds two buttons, one marked Cancel , the other marked "OK". If it were expressed as a Rebol dialect, I'd use something like: Panel [ Button/System "Cancel" 'Cancel Button/System "OK 'OK ] Which one would you prefer? :) -- Andrew J Martin ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [7/40] from: andreas:bolka:gmx at: 11-Jan-2004 21:49


Sunday, January 11, 2004, 9:20:51 PM, A wrote:
> Here's an example of OO code in C#: > p = new Panel ();
<<quoted lines omitted: 17>>
> ] > Which one would you prefer? :)
I wouldn't start with such kinda "peas and apples" comparisons unless you discuss the various possibilities of REBOL and C#. One could imagine even better REBOL dialects and even worse C# stuff. (Why not go down to IL level in C#? That would look far more ugly, I'm sure!) On the opposite, a bad REBOL dialect could look just as bad as the C# code, whereas with XAML you could just write: <Canvas ID="root" xmlns="http://schemas.microsoft.com/2003/xaml"> <Button>Cancel</Button> <Button>OK</Button> </Canvas> -- Best regards, Andreas

 [8/40] from: AJMartin:orcon at: 24-Jan-2004 11:47


Andreas wrote:
> ...whereas with XAML you could just write: > > <Canvas ID="root" xmlns="http://schemas.microsoft.com/2003/xaml"> > <Button>Cancel</Button> > <Button>OK</Button> > </Canvas>
Or with my ML dialect for Rebol: Canvas/ID/xmlns "root" http://schemas.microsoft.com/2003/xaml [ Button "Cancel" Button "OK" ] :) -- Andrew J Martin ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [9/40] from: AJMartin:orcon at: 24-Jan-2004 11:47


> Which one would you prefer? :)
Of course, the ultimate, magical dialect is something like: Computer, do what I want! :) -- Andrew J Martin ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [10/40] from: jason:cunliffe:verizon at: 11-Jan-2004 16:56


> function. There is much more to using it than meets the eye. And I believe > not yet enough examples or use of dialects for most people to understand
yet
> the long-term implication of the idea or how well this works in reality.
I was not trolling. And I am certainly not against dialects. Simply stating the situation as I see it - rebol dialects really have not been tested and used my large numbers of people in complex apps, so we donlt know yet the deeper implications of using them. One issue of dialects has come up here, is that while they can lead to sweet short code, dialects are only as good as their documentation. Since one is possibly creating a specialistssub- language within the parent language, there has to be excllent way for people to know what it contains, whether it behaves differently or if its sytnax is consistent or not with their expectations and the parent language. VID for example is one dialect for view. But already in places it is fuses a slightly different syntactic set of conventions than regular rebol. That is good or bad depending on your POV. In general I am in favor of as much syntax consistency as possible. But its early days, so experimentation and diversity are required. When a solo developer to creates a dialect , they are 100% free to do whatever works best for their need and style. But if that work is to be really helpful to a wide community, then subtle variations and idiosyncrasies can soon become an obstacle to adoption.
> Panel [ > Button/System "Cancel" 'Cancel > Button/System "OK 'OK > ] > > Which one would you prefer? :)
Yes no contest. But I think its a rather misleading comparison you offer. In standard OO languages like Python you typically package up any verbose complexity to create an class/object which is as easy and concise to use as your Rebol example. Rebol is lovely and clean partly because it removes extra punctuation. I think rebol is much easier to write than read. Python is perhaps the most balanced language where write-ability read-ability. Python's named function arguments have much to do with this. Programmers in Rebol and Python both have to be very aware of namespace. I think this is what Max's SLiM is addressing and so I imagine could greatly help dialect use in Rebol. In rebol if you see 'button' in some code how do you know if that's a default button or dialected word also named "button" which may have overlapping behavior. Beyond namespace there is the social aspect of how customized developments can be elegant but harder to use/maintain because they have smaller population. In fact its the same problem in real life - lawyer politicians scientists, rap artists, poets all have their own dialects and often cannot communicate well. And there are traditional regional dialects too where its quite possible to sit at dinner a family and find they share only some words. I have experienced this first hand with people from southern China. The guy's wife could not speak to her mother-in-law. ouch. The solution is almost always for people to know several languages so they have at least one in common. With rebol dialects, success is a tradeoff between readability, write-ability, documentation, name-space and learning curve. They're a great idea, but not been around long enough to know how to use them best, grasp the trade-offs. Brody wrote brilliantly in his two classic books "Starting Forth" and Thinking Forth about the art and science of naming words carefully in Forth. Charles Moore has also spoken about this. And I think it applies deeply to Rebol also, perhaps because Rebol is like 'reverse' Forth -- it goes forwards] ;-) Designing Rebol dialects is not easy. And there are few guidelines yet. The minimal introductory presentation the Rebol documentation implies that god dialect share an emergent representation of a problem domain. banking, gui, etc When you understand the problem well and then want to simplify and focus the cod so it is more readable, then you write a dialect. Make-swf source is good reading to see how David Oldes' has been learning and improving his own dialect. I think make-swf is one of the most advanced uses thus far of rebol dialect. I look forwards to seeing copies of O'Reilly latest: "Rebol Dialects in a Nutshell". Then we'll know they really arrived! - Jason

 [11/40] from: gosbell:myrealbox at: 12-Jan-2004 9:03


Has anyone actually done this - built an OO framework in REBOL?

 [12/40] from: jason:cunliffe:verizon at: 11-Jan-2004 16:58


> Of course, the ultimate, magical dialect is something like: > > "Computer, do what I want!"
That's a great exmple! It should be used in the docs.. - Jason<

 [13/40] from: AJMartin:orcon at: 24-Jan-2004 11:47


Trevor wrote:
> Has anyone actually done this - built an OO framework in REBOL?
I think so, back about two or three years ago some one mentioned they had a object framework which could hide data and had some thing like a virtual table. I can't recall anything more about it. -- Andrew J Martin ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [14/40] from: andreas:bolka:gmx at: 12-Jan-2004 0:06


Sunday, January 11, 2004, 11:03:43 PM, Trevor wrote:
> Has anyone actually done this - built an OO framework in REBOL?
I've actually built a very simplistic implementation of prototype-based OO (as in e.g. Self, JavaScript or Io) some time ago. I could dig it up, but it was really just a very ugly proof of concept and then prototype-based OO is not what is nowadays commonly associated with OO :) -- Best regards, Andreas

 [15/40] from: chrismorency:videotron:ca at: 11-Jan-2004 18:51


Hi, Yep, I did start work on a OO framework... I've been away from rebol for the past two year and the reason I just subscribed back is to see if anybody would be interested in something like that ;) Best, Chris

 [16/40] from: chrismorency:videotron:ca at: 11-Jan-2004 18:57


Hi, I don't know if you're talking about RECOIL, I remember sharing part of the code and idea with someone else... But who ??? Yep, it was a very ugly proof of concept... But it was a proof ;) Anyway, I need to get back in the code... And rewrite the whole thing. Basically, it was able to support: Metaclass Class Object Inheritance (ie not copy functions but inherits them)... It had pros and cons. Chris Ps I'm still an happy Smalltalk programmer by day ! But I want to get back to Rebol on personal time... And Recoil is just what is missing for OO in Rebol.

 [17/40] from: greggirwin:mindspring at: 11-Jan-2004 18:08


Hi Andrew, AJM> Here's an example of OO code in C#: Not to be picky, but a more accurate description for that C# code would be "object based". This was a long-standing distinction in the VB world. While VB was object based, it didn't really support the three main OO features (as they are generally interpreted), so it wasn't considered OO. -- Gregg

 [18/40] from: greggirwin:mindspring at: 11-Jan-2004 18:10


AJM> Of course, the ultimate, magical dialect is something like: AJM> "Computer, do what I want!" Actually, that almost works today... computer DO what-I-want The hard part, of course, is defining what you want. :) -- Gregg

 [19/40] from: AJMartin:orcon at: 24-Jan-2004 11:47


> AJM> "Computer, do what I want!" > > Actually, that almost works today... > > computer DO what-I-want > > The hard part, of course, is defining what you want. :)
As we all know it's currently at this stage: computer do %"What I say.r" :) -- Andrew J Martin ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [20/40] from: AJMartin:orcon at: 24-Jan-2004 11:47


Gregg wrote:
> While VB was object based, it didn't really support the three main OO
features (as they are generally interpreted), so it wasn't considered OO. What were those three features? -- Andrew J Martin ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [21/40] from: andreas:bolka:gmx at: 12-Jan-2004 3:44


Monday, January 12, 2004, 2:50:07 AM, A wrote:
> Gregg wrote: >> While VB was object based, it didn't really support the three main >> OO features (as they are generally interpreted), so it wasn't >> considered OO. > What were those three features?
encapsulation, inheritance, polymorphism (I guess). -- Best regards, Andreas

 [22/40] from: greggirwin:mindspring at: 11-Jan-2004 20:47


Hi Andrew,
>> While VB was object based, it didn't really support the three main OO
AJM> features (as they are generally interpreted), so it wasn't considered OO. AJM> What were those three features? Andreas beat me to it. -- Gregg

 [23/40] from: g:santilli:tiscalinet:it at: 12-Jan-2004 10:07


Hi Jason, On Sunday, January 11, 2004, 10:56:22 PM, you wrote: JC> I was not trolling. And I am certainly not against dialects. Simply stating JC> the situation as I see it - rebol dialects really have not been tested and JC> used my large numbers of people in complex apps, so we donlt know yet the JC> deeper implications of using them. How many scripts do you know that do NOT use any dialect? JC> One issue of dialects has come up here, is that while they can lead to sweet JC> short code, dialects are only as good as their documentation. Since one is That applies to any language, or library/API, or class, or whatever... I don't see it as a special disadvantage of dialects. JC> Python is perhaps the most balanced language where write-ability JC> read-ability. Python's named function arguments have much to do with this. Personally I don't see any real advantage in "named function arguments". That is, why don't you see people doing something like: nam-arg-func: func [spec code] [ use [spec' code'] [ code': code spec': context spec func [block] [ block: make spec' block do bind/copy code' in block 'self ] ] ]
>> f: nam-arg-func [a: 1 b: 2] [a + b] >> f []
== 3
>> f [a: 3]
== 5
>> f [a: 3 b: 5]
== 8 You can also have "default local" vars with a little variation, nam-arg-func: func [spec code] [ use [spec' code'] [ code': code spec': context spec func [block] [ make make spec' block code' ] ] ] It's almost a one liner... JC> With rebol dialects, success is a tradeoff between readability, JC> write-ability, documentation, name-space and learning curve. They're a great JC> idea, but not been around long enough to know how to use them best, grasp JC> the trade-offs. The concept of domain specific languages is not that new. Giving the power to use them to anyone is new, however. And of course if you're not a language designer you're probably going to feel a little lost. ;-) But anyone can become a language designer. :) JC> I look forwards to seeing copies of O'Reilly latest: "Rebol Dialects in a JC> Nutshell". JC> Then we'll know they really arrived! If you mean, how to implement a dialect, that's already easy enough. If you mean, how to design it, well, won't ever be an easy task , as any other design problem. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [24/40] from: nitsch-lists:netcologne at: 12-Jan-2004 11:18


Am Sonntag 11 Januar 2004 18:52 schrieb Behrang Saeedzadeh:
> Hi > > Sorry if this is a stupid question, but is REBOL > Object Oriented? >
i would call it OE, object enabled. its harder to use than "native" rebol. that is, its as hard as OO-only ;) when comming from OO, i would say: patterns are coded in functions, instead of in special objects. patterns are used a lot, reducing the need for methods implemented in objects. objects then only need to handle reactions to dispatchers, not dealing that much with inter-object- and subclass-realations. works nice. after a while i would forget that terminalogie - uhm, actually i have.. ;)
> Thanks, > Behrang S. >
-Volker

 [25/40] from: rotenca:telvia:it at: 12-Jan-2004 14:35


Hi,
> Sorry if this is a stupid question, but is REBOL > Object Oriented?
Yes, like Self: http://research.sun.com/self/language.html --- Ciao Romano

 [26/40] from: joel:neely:fedex at: 12-Jan-2004 7:42


Hi, Behrang, Behrang Saeedzadeh wrote:
> ... is REBOL Object Oriented? >
As you can tell from the variety of responses, the question is a bit tricky to handle. Unfortunately, the phrase "object oriented" has been siezed on by marketers, reporters, comp sci researchers, methodologists, consultants, and snake oil salesmen, and given different spins by all of the above. Let me duck the phrasing of your original question, and answer a closely-related one, in the hope that something I say will address your needs: I already know how to program in language XYZ, which is commonly regarded as an object-oriented language. How much of what I know about programming in XYZ will be useful to programming in REBOL? Answering this modified question would require addressing some of the following issues: 1) REBOL is a dynamically-typed language. This is familiar territory if you are used to Smalltalk, Python, or Perl; It may take some adjustment if you are used to Java, C++, Eiffel, Delphi, etc. Type errors (attempting to apply an innappropriate operation on a value, trying to access a non-existent component of an object, etc.) are caught at run time, not prevented at compile time. 2) An object in REBOL is a namespace. The values associated with the words defined in an object represent the state of the object, and functions defined (at creation time) within the object use those words in the familiar way: sample: make object! [ some-data: "Hello, world!" some-method: func [] [print some-data] ] Immediately after evaluating the above definition, an evaluation of SOME-METHOD results in the output of Hello, world! regardless of whether there's a word SOME-DATA defined anywhere else (e.g. globally, within another object, etc.) 3) All words defined within an object are "public". That's why I had to say "immediately after evaluating..." in the previous point. Given the above object, you can also say sample/some-data: "Goodbye, cruel world!" to change the state of SAMPLE. There's no built-in way to make SOME-DATA private, and inaccessible to the rest of the world. 4) REBOL uses a prototype model of object creation, rather than a class-based model or a delegation model. Objects are made one-at-a-time and one-of-a-kind. You can use a block (as in the above example) as a specification for creating an object, and can use the same block repeatedly: sample-spec: [ some-data: "Hello, world!" some-method: func [] [print some-data] ] sample1: make object! sample-spec sample2: make object! sample-spec sample3: make object! sample-spec but once those objects are created, each has a life (state) of its own; any resemblance is viewed by REBOL as merely coincidental. In particular, each of the above objects has its *own* function named SOME-METHOD . There's no concept in REBOL of "instance method" shared between the objects. You can also use an existing object as a specification: demo1: make object! [ some-data: "Hello, world!" some-method: func [] [print some-data] ] demo2: make demo1 [] demo3: make demo2 [] but, again, a newly created object is like a newly-hatched sea turtle; it resembles any siblings which may have come from the same parent, but immediatly upon hatching, it must face the wild ocean on its own. It has no parent. 5) As a consequence of all of the above (and the dynamic nature of REBOL itself) you can build your own convenience methods to implement some features you may be accustomed to using: greeter-class: make object! [ _greeter: make object! [ greetee: "TBD" greet: func [] [greeter-class/_greet self] ] new: func [who [string!]] [ make _greeter [greetee: copy who] ] _greet: func [which [object!]] [ print ["Hello," which/greetee] ] ] which provides a constructor (NEW) and a single shared method for all "instances" (GREETER-CLASS/GREET), which defer to the "class" definition...
>> world-greeter: greeter-class/new "world!" >> mom-greeter: greeter-class/new "Mom!" >> lonesome-greeter: greeter-class/new "anybody?"
...so that each "instance" uses the common behavior:
>> world-greeter/greet
Hello, world!
>> mom-greeter/greet
Hello, Mom!
>> lonesome-greeter/greet
Hello, anybody? Of course this is overkill for something as simple as shown above, but if the GREET method were complex and lengthy, it would save space to have each "instance" object contain only "stub" methods that dispatch themselves to a common function. (There's nothing magic about the underscores; I just used underscore prefixes to remind myself that some parts of GREETER-CLASS are not intended for general use. There's no mechanism in REBOL that enforces that idea.) Perhaps this gives you some sense of what you can do with objects in REBOL, but of course there's always more... Hope this helps! -jn-

 [27/40] from: nitsch-lists:netcologne at: 12-Jan-2004 14:58


Am Sonntag 11 Januar 2004 22:56 schrieb Jason Cunliffe:
> > function. There is much more to using it than meets the eye. And I > > believe not yet enough examples or use of dialects for most people to
<<quoted lines omitted: 5>>
> used my large numbers of people in complex apps, so we donlt know yet the > deeper implications of using them.
We know. 'parse 'func (the argument header) 'compose are all dialects. Works well :) Make-doc is proven enough, i can read the howtos well :) Rebol OTOH has proven that some problems do not need complex apps. And complex design for this problems can not compete with rebol sometimes, despite offering visual magicall wizardry tools.
> One issue of dialects has come up here, is that while they can lead to > sweet short code, dialects are only as good as their documentation. Since > one is possibly creating a specialistssub- language within the parent > language, there has to be excllent way for people to know what it contains, > whether it behaves differently or if its sytnax is consistent or not with > their expectations and the parent language. >
Thats the same with OO, only harder. Thats why OO is only usable with lots of tooltips on code and auto-completion and whatnot. You can't do what a dialect do simpler in OO. I agree one needs documents. what is nice, this documents can be at howto/tutorial-level and show usefull examples in some lines of code. which makes helping other people lots easier than pagelong examples.
> VID for example is one dialect for view. But already in places it is fuses > a slightly different syntactic set of conventions than regular rebol. That
<<quoted lines omitted: 4>>
> that work is to be really helpful to a wide community, then subtle > variations and idiosyncrasies can soon become an obstacle to adoption.
As Andreas mentioned: <Canvas ID="root" xmlns="http://schemas.microsoft.com/2003/xaml"> <Button>Cancel</Button> <Button>OK</Button> </Canvas> this is the short way with oops ;) where have i seen that before? and when? Could it even be a hint that dialects in OO have merits? ;)
> > Panel [ > > Button/System "Cancel" 'Cancel
<<quoted lines omitted: 6>>
> complexity to create an class/object which is as easy and concise to use as > your Rebol example.
Naa. This classes are then used in the same long way as they are created to compose more sophisticated classes. while in rebol the layouts are used in larger layouts. Think of styles build out of styles. now calculate: if a level needs 5 lines in rebol and 25 with oops, two levels need 25:625, three 125:15625 (if my console calculates right). And suddely you know where the mb's are comming from. (Q&D-statistic, don't trust it ;)
> Rebol is lovely and clean partly because it removes > extra punctuation. I think rebol is much easier to write than read.
Rebol is lovely because of excellent defaults IMHO.
> Python is perhaps the most balanced language where write-ability > read-ability. Python's named function arguments have much to do with this. > > Programmers in Rebol and Python both have to be very aware of namespace. I > think this is what Max's SLiM is addressing and so I imagine could greatly > help dialect use in Rebol.
The difference is in length of code. Requirements change with that. So rebol can solve a level II - problem with level I tools, where python needs its level II tools. means rebol can work without namespaces in arrays where python cant. the big question is, can you keep the problem at level II, or do you need level V? the higher the level, the more python catches up. but this is by design, rebol is tuned as dragster, python for paris-dakar.
> In rebol if you see 'button' in some code how do you know if that's a > default button or dialected word also named "button" which may have > overlapping behavior.
because the layout is quarter page away. You have the same problem with OO, which of this 23**x draw()-methods in the source do you really call with face.draw() ?
> Beyond namespace there is the social aspect of how > customized developments can be elegant but harder to use/maintain because > they have smaller population. In fact its the same problem in real life - > lawyer politicians scientists, rap artists, poets all have their own > dialects and often cannot communicate well.
All this people would have its own overloaded methods/libraries in python?
> And there are traditional > regional dialects too where its quite possible to sit at dinner a family
<<quoted lines omitted: 3>>
> The solution is almost always for people to know several languages so they > have at least one in common.
This people need a translator who is quick in learning new languages? That would be similar to rebol beeing tuned for doing dialects. The people would need to adopt his style, speaking a reduced language while he gets started. like using rebols datatypes. but better then a complete perl-python-switch.
> With rebol dialects, success is a tradeoff between readability, > write-ability, documentation, name-space and learning curve. They're a > great idea, but not been around long enough to know how to use them best, > grasp the trade-offs. >
The more complex lacks teaching. And dialects lacks experience which teaching too. It seems stuff like the cookbook works better than traditional bibles.
> Brody wrote brilliantly in his two classic books "Starting Forth" and > "Thinking Forth" about the art and science of naming words carefully in > Forth. Charles Moore has also spoken about this. And I think it applies > deeply to Rebol also, perhaps because Rebol is like 'reverse' Forth -- it > goes forwards] ;-) >
Brodies style of illustrations would work wonderfull with rebol! IIRC he is now a puppet-player. And we have more bandwith/cd's. If Brodie would illustrate rebol-concepts with talking puppets instead of pen&paper.. dreaming.. :)
> Designing Rebol dialects is not easy. And there are few guidelines yet. The > minimal introductory presentation the Rebol documentation implies that god > dialect share an emergent representation of a problem domain. banking, gui, > etc When you understand the problem well and then want to simplify and > focus the cod so it is more readable, then you write a dialect. >
Same for OO-libraries. but i disagree. ad-hoc-dialects for data can make live a lot easier sometimes. once one knows a bit about the block-parser. needed an internall representation a while ago. translating data to dialect1 and then parsing dialect1 to create dialect2 worked well. before rebol such multi-pass-work was terrible, never could really immagine the intermediate data. with rebol it was just 'probe and having a dialect with the right keywords in some places.
> Make-swf source is good reading to see how David Oldes' has been learning > and improving his own dialect. I think make-swf is one of the most advanced > uses thus far of rebol dialect. >
IMHO complex <> advanced. I would not say "when we can do this advanced stuff, we are really good". Its more like a fully fledged kitchen compared with a microwave. sometimes i would not change. (assuming a fully fledged kitchen would force me to always do fully-fledged cooking).
> I look forwards to seeing copies of O'Reilly latest: "Rebol Dialects in a > Nutshell". > Then we'll know they really arrived! >
I am not sure O'Reilly would need a nutshell for that. Given that they manage to put some other languages in such size. But maybe they use coconuts there? ;)
> - Jason
-Volker

 [28/40] from: jason:cunliffe:verizon at: 12-Jan-2004 12:33


Volker wrote: ...snip...
> The more complex lacks teaching. And dialects lacks experience which
teaching
> too. It seems stuff like the cookbook works better than traditional
bibles. ..snip.. Wow. Great reply. Volker thank you. I need more time to absorb. When I say that Rebol is more write-able than readable, that is meant as a complement, but should perhaps have been posed as a question. Rebol first and foremost is about personal hands-on programming. Small fast clever fun. I am trying to discern how well it work at a collaborative scale. The question for everyone is how well do you read other people's rebol code? I hope many of my posts recently appear too critical or negative lately. I am just looking harder for deeper understanding of Rebol and how to discuss, explain, compare its strengths its virtues and idiosyncrasies. For me, what I truly value most is how Rebol influences my thinking. And I am fascinated by the differences between Rebol and the mainstream. In particular I am doing early research into many different kinds of learning for a big documentary resource project. Its very wide in scope, but a big part includes the affects and process of learning computer programming. This is not an academic project, and it tries to focus on personal experience over theory. So anecdotal and emotional facets are important. I believe Rebol embodies many deeply good ideas for new kind of programming - and at the heart of that is implied a fresh approach to what learning is about. Still hard to discuss this though. Anyway I really appreciate all your care and attention and for answering my arguments and digressions. There is a pattern behind the chaos. Hopefully that will become clear in time. Jason

 [29/40] from: greggirwin:mindspring at: 12-Jan-2004 11:04


Hi Jason, Just some comments, not criticisms, just my perspective. JC> ...rebol dialects really have not been tested and used my large JC> numbers of people in complex apps, so we donlt know yet the JC> deeper implications of using them. As Gabriele said, Domain Specific Languages are definitely a known quantity, used widely for a long time. A good example is the game industry. Most games today are built with a specialized language that was developed in-house, or built by a vendor whose toolkit you use. Coding the high-level logic of complex games in C++ just doesn't make sense, so they build an engine to do the heavy lifting and use a dialected interface to it to build the actual game content. It's really just another form of abstraction. JC> ...whether it behaves differently or if its sytnax is consistent JC> or not with their expectations and the parent language. People don't have to know that a dialect has a "parent language". What's important is that all the similarities you *can* leverage with embedded languages reduce the "impedance mistmatch" for users and makes it more accessible. The less there is to learn, the better, in most cases. Now, in cases where the end user is a regular person--not a programmer or other "genus geekus" :)--there won't be any expectation, except that of the domain. That's where it's important to match expectations. JC> VID for example is one dialect for view. But already in places it is fuses a JC> slightly different syntactic set of conventions than regular rebol. That is JC> good or bad depending on your POV. In general I am in favor of as much JC> syntax consistency as possible. One of the main reasons I see for not worrying about syntax compatibility is leverage. The more you constrain yourself in your DSL, the less opportunity you have to make great strides--focus on the domain first. Also, we have to separate syntax from semantics. If you write a block-based dialect, you're going to be syntax compatible with REBOL; this is one of REBOL's greatest strengths and achievements IMO--the foundation it gives us to build on, with so little syntax to get in the way. More importantly, REBOL's syntax allows us to work with "human syntax" very closely (or at least English syntax, as far as word-forms and such are concerned). Think about dialects for humans as much, or more, as dialects for developers. JC> Python is perhaps the most balanced language where write-ability JC> read-ability. Python's named function arguments have much to do with this. I did a named-arg experiment a while back, using a different approach than Gabriele IIRC. In the general case, I think they help most when something is poorly designed (e.g. has too many args or bad arg order), though there were rare occasions when I used them for clarity. JC> ...In fact its the same problem in real life - JC> lawyer politicians scientists, rap artists, poets all have their own JC> dialects and often cannot communicate well. But they can communicate with each other much more effectively--i.e. within their domain. That's what it's all about IMO; effective communication. If your message were not written in a dialect, would it have been as effective? Consider the following terms: trolling parent-language syntax VID View POV OO REBOL Python named-function-arguments namespace Forth GUI Now consider how much you would have to explain to someone, in order to convey what "named function arguments" are. Here's a great paper, from Guy Steele: Growing a Language http://homepages.inf.ed.ac.uk/wadler/steele-oopsla98.pdf JC> Designing Rebol dialects is not easy. Agreed 100%. Good post. Every time dialects come up this way, it makes me think, and re-think, how I want to explain them to people, why I think they're important, etc. So, thanks! --Gregg

 [30/40] from: jason:cunliffe:verizon at: 12-Jan-2004 13:14


> I hope many of my posts recently appear too critical or negative lately.
arggh sorry bad edit type -- that should be: I hope many of my posts recently DON'T appear too critical or negative lately.

 [31/40] from: gerardcote:sympatico:ca at: 12-Jan-2004 14:14


Hi Joel, Joel wrote: ======== ...
> Answering this modified question would require addressing some > of the following issues:
<<quoted lines omitted: 13>>
> some-method: func [] [print some-data] > ]
... I know I repeat again myself but ... Your example and explanation about the way REBOL manages its own OBJECTS and how someone can use them to create something useful (even that simple) comes hand in hand with the way I think the DOC can be enhanced by many other small code examples. This is generally well done by the ML members like you and any other advanced REBOLER when required - and there will always be some need in this area - but I really think there is some place in the official DOC to put at least some minimal examples that could help beginners to first read by themselves if they can find and understand what the look for before having to always restate their questions here. Understand me well - I am not trying to prevent anybody to ask any question here since I do this myself as often as I feel I need it. The problem to doing it like it now relates more with the dependancy we create towards this ML from the point of view of a true beginner that has some difficulty at finding real simple functioning and well explained examples before trying himself at coding. I am currently collecting many of these snippets that the ML answered during the last 2 years ans I try to classify them around keywords. When I will consider my effort to be mature enough for submission and review I'll let you know. In this sense if anybody here did the same kind of work and would share his ideas with others, I would be glad to share some ideas with this or these people. If I remember well Jason and Graham already put online some information of this nature that could be used by any newcomer to REBOL and myself I will reuse some of their material with their permission. Fell free to contribute and send me everything you already have that could help me further in this direction. May be someone even did classify his own code examples according to some criteria that could be used by others and could be submitted to me too for discussion. I currently see 2 general categories to start with : (but some may be added later if needed) 1- In the current "How-to-do" sense a) for very small Core or View features (similar to the cookbook but for even simpler features - traps, gotchas and limitations also included and somehow explained) b) day-to-day small to do tasks (currently adding to the actual cookbook that does very well for now) 2- In the current "Concepts" explained a) for delivering internal REBOL secrets (like documenting the system object, the many facets and default values offered by all the View- VID styles, the eval-exec cycle, context, binding and objects workings, ... but also in the sense of and advanced how to a bit like what the REBOL ZINE did sometime ago - i.e. extending the way objects are used to include more classical OO features, showing how to design a simple dialect and implement it using parse or other more traditional techniques for comparison purpose, ...) Don't forget this is only my wish list ... Everybody welcomed to contribute and many of you already contributed a lot in the past What is missing is an index - a bit like the menu appearing on main page Jabber IM web site. I visited it this afternoon and found it to offer some easy to dispatch themes when looked even for the first time. Why seems ours (REBOL) so dispersed to me ? Am I so lost in my own head or is it simply something that we can help become more useful with a minimal reorganization ? ... Regards, Gerard

 [32/40] from: gerardcote:sympatico:ca at: 12-Jan-2004 16:02


Hi Jason, After your Jabber ref. I went to their main site and will probably try it soon just to see how it works for real exchanging. I also got another ref. that could be of some interest to you about extensible scripting languages (ESL) http://www.vydra.net/esl/paper/ . Found this one from the Trevor link about the REBOL-UNIT.R script which is broken. After investigating a bit around the broken link I found this paper that describes some dialect examples and I think it would be interesting for some of us as a starting point to experiment and document parse. What do you think about ? Additionally I could not resist to buy the book David referred to in his paper which was written in 2001 by Steven John Metsker, Building Parsers With Java. I got it used for 15 $ USD. As Volker and Gregg said I don't think too that it is trivial to design domain specific languages and grammars that accompany them (I never learned formally in school to do so and this is one of the most complex concepts I read about until now) even if we have some tools like parse to help cope with. I don't think either that it is what you said but nevertheless I can't say I already tamed these animals even with a lot of books to refer to. I am not much mathematically inclined either and that can explain a bit the many difficulties I got in the past with many of the books I have read until now. May be someone has yet to write the ultimate book that will permit every programmer that wants to do some steps in this way to be able to do so ... by itself - as easily as it can be done ! I think that as REBOL learners we could begin some common experiment around parse and the design of some small specific dialects for illustrative purpose and may be for some common useful use too - one for automatically completing file names (like some well known tools under DOS did it some time ago...) for use under Windows would be of some help to me. This could be done with the help of some advanced level REBOLer(s) that could interact (or even drive the group in some way by suggesting some plan, giving hints or even explaining some obscure or difficult concepts that must be learned to really understand the whole) with the learning members exchanging on IOS or AltMe or even on a Forum. The important think to remember is that what will be done should be kept for archiving and later retrieval. And later (or sooner) this could be done about any concept suggested by someone on the ML (or by the REBOL learning classes - if some entity existed). It might be done this way : Someone decides to start with any idea submitted to the cookbook or the ML and starts some exchange and experiment about this theme - starting with some DESIGN PHASE (Generally just questions to guide about where to start with and why to do it - traditionnaly called a DATA analysis followed by some ALGORITHM design) what could be. The ML actually plays much of this role but this not really the place to do so for everything that is submitted in - even if it is a lot useful to everybody and it must continue in some way. The problem is that after some thread is completed, the results are generally lost since they are not of general interest and not much useful in a planned learning. This is what is missing. The Zine was the part that permitted every newcomer to study some material of this kind - planned for more or less advanced stuff. Why is it no more in use then ? I think I can answer to this by myself since I know the sum of voluntary this represents for each submitter - and it must be a talented one since it must be understandable by the readers - and the reviewer work is not to be underestimated too. In fact it is an enourmous task that must be shared between many volunteers and done on a pleasure basis. I think it is time to raise it again in some form or in another. As a starting point - since we were talking about dialects and parsing - read the following : ============================================================ For example I find it so annoying to me to completely rewrite my complete paths (switching the / for the \ plus adding the " at both ends and stripping the : after the Drive name) each time I have to type some copied file name and path from my Windows Explorer to the console prompt - I mnow ther must exist some script to help somewhere but this could be useful to have defined a dialect for managing files any time it would be needed to express for example the listing of the files contained in "E:/DOCUMENTS/Gerard/credit card Orders/Alibris/" and limiting those to only the ones created during the month of february of the current year (or before or after some date or between 2 dates) with a command such : "my-list-dir named-dir yyyy-mm 2004-02" . For sure I implicitly sent the named path-file into a named-dir word. We could elaborate more and add many facets as to how to specify the order of the listing and the nature of the displayed info la DOS (dir cmd) or some variant of it. At least this task is easy to understand even if the details can be cumbersome to mix together on the same command line - la Unix - may be with pipes for connecting them. In another context some time ago I thought of some "calendar" query language to help display the many reservations recorded in a collaborative agenda for example (or a skating reservation registry for an arena). I am not sure this kind of tool would never replace the old and proven pen and paper registry but I would liek to experiment with these concepts. Just to give you an idea of the involved difficulties, imagine a customer that phones at the arena and want to know if he can take a reservation one time each week for the next 12 weeks preferably during the wednesday evenings. This should not be of a real problem if the 12 wednesdays are free. The problem begins when some of the weeks are not free and the clerk must go back and forth interrogating the system to see where it will fit another evening to accomodate the client for all of his needs - IN REAL TIME PLEASE - the client is waiting at the other end of the phone. I know how real and good is the efficiency of the paper method in such a case but I always dreamed of some tool to explore with a computer. I think REBOL could be this tool - if we could get some way to connect it to some external way to enter data like a touch screen can do instead of a mouse and a keyboard. In fact the three should intermixed in this app. Regards, Gerard

 [33/40] from: jason:cunliffe:verizon at: 12-Jan-2004 17:17


Hi Gerard
> http://www.vydra.net/esl/paper/
Thanks I'll look into it.
> May be someone has yet to write the ultimate book that will permit every
programmer that wants to do some steps in this way to be
> able to do so ... by itself - as easily as it can be done !
There is no 'ultimate' - just keep learning keep growing keep changing.. But a high level book which discussed dialects would be a very interstnig thing. There are maybe some good Phd. thesis papers on the subject.
> generally lost since they are not of general interest and not much useful
in a planned learning. This is what is missing. The Zine
> was the part that permitted every newcomer to study some material of this
kind - planned for more or less advanced stuff. Yeah I like Zine very much. If Rebol population grows then I expect rebol blogs to appear just as they have for Flash. It fills in nice learning space bewteen mailing lists and elsewhere. That's one reason I think Vanilla is a natural fit for beginner. It icombines wiki wiht blog. And beacuase it in rebol very motivating to learn hands-on as needs emerge. In fact virtually all my Rebol experience is based on hacking aroudn Vanilla. Nothing sophisticated compared to people here, but satisfying useful and motivating. I owe you a post about Vanilla from discussion many days back. Will try to complete it this evening.
> For example I find it so annoying to me to completely rewrite my complete
paths (switching the / for the \ plus adding the " at both
> ends and stripping the : after the Drive name) each time I have to type
some copied file name and path from my Windows Explorer to
> the console prompt - I mnow ther must exist some script to help somewhere
but this could be useful to have defined a dialect for
> managing files any time it would be needed to > express for example the listing of the files contained in
E:/DOCUMENTS/Gerard/credit card Orders/Alibris/ Well yeah it is annoying. Rebol and Python both have their own consistent intenal syntax. But it strikes me they shoul dbe smart enough to just check for the path syntax of the platform being used and then accept and convert to the internal. . I imagine such functions have been written many times over already by people.
> Just to give you an idea of the involved difficulties, imagine a customer
that phones at the arena and want to know if he can take a
> reservation one time each week for the next 12 weeks preferably during the
wednesday evenings.
> This should not be of a real problem if the 12 wednesdays are free. The
problem begins when some of the weeks are not free and the
> clerk must go back and forth interrogating the system to see where it will
fit another evening to accomodate the client for all of
> his needs - IN REAL TIME PLEASE - the client is waiting at the other end
of the phone. That's the kind of problem interactive calendars are great for. As it happens I've just been working on this problem using Flash for online house rental bookings. And its one of the reasons I am big fan of Jabber because its presence mechanism makes it ideal transport for connecting collaborative apps like this. I want the user interface elements to be both control and display devices, capable of changing state when send or receive events. Of course Rebol/View can be good for that too. Personally I just find Flash is much more sophisticated and fun for that kind of gui development. I don't know how far the calendar component of IOS went. Perhaps it has what you want already in it ? Generally dialects and local uses of parse seem to emerge from some direct need. Some job grows really repetitious or lengthy. So a dialect can help simplify the code keep focus to the task at hand. Beyond that is the idea of hidden smarts, where they can embed logic and contextual behavior hiding the guts from the casual use. Extreme example was already provided: Computer do [what I want] Life do [what I need] not [what I want] etc.. If I understand correctly Rebol dialects are a *much* kinder version of what XSLT does. - Jason

 [34/40] from: AJMartin:orcon at: 24-Jan-2004 11:47


> JC> Designing Rebol dialects is not easy. > > Agreed 100%. > > Good post. Every time dialects come up this way, it makes me think, and
re-think, how I want to explain them to people, why I think they're important, etc. So, thanks! I totally agree. I keep revising my dialects to better fit the domain and to be easier to use. For example in my earliest version of ML dialect, I started off by using functions and their arguments, like this for generating a list of items: List: func [Type [word!] Items [block!]] [...] I discovered that this had the problem of having to be changed for each variety of HTML, WML and XML, plus it grew way too hard to maintain. It was also harder to learn than standard HTML, WML or XML, which was the reverse of what I wanted! Then I discovered how to use words themselves as the name part of tags, and using block! values to group content, along with using 'parse on block values. I expanded the words to use path! values to generate tags and 'compose/deep to insert outside values. My most version of ML which uses "<" and ">" matches better the domain of XML and allows very complex tags with name spaces like: foo:bar for each tag attribute. Rebol unfortunately can't handle two namespace attributes in a path value like:
>> X: 'x/foo:bar/ding:dong
== x/foo:bar/ding:dong
>> LENGTH? x
== 2
>> x/2
== foo:bar/ding:dong With "<" and ">" to group the tag, ML can be like this:
>> random/seed now >> RandomID: random 1234
== 859
>> From_Address: "Andrew's Example"
== "Andrew's Example"
>> print ML compose/deep [
[ < stream:stream [ xmlns:stream http://etherx.jabber.org/streams [ id (RandomID) [ xmlns jabber:client [ from (From_Address) [ > [ [ "My content goes here! " [ "plus any other content!" [ ] [ ] <stream:stream xmlns:stream="http://etherx.jabber.org/streams" id="859" xmlns="jabber:client" from="Andrew's Example">My content goes here! plus any other content!</stream:stream> -- Andrew J Martin ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [35/40] from: AJMartin:orcon at: 24-Jan-2004 11:47


Jason wrote:
> Generally dialects and local uses of parse seem to emerge from some direct
need. Some job grows really repetitious or lengthy. So a dialect can help simplify the code keep focus to the task at hand. I agree. I had the need to generate lots of HTML, and I couldn't bear the thought of writing it by hand, and all the tools still did things in a brain-dead manner. So I went smarter and created my ML dialect, which I've described in my earlier post. Then I discovered how to use XML for other things and extended the use of ML to WML and XML, so allowing me to do more. Similarly for my C# code. I write several C# classes and noted that for each class I had to write several support classes! All these classes were intensely boring to write and it was very easy to make a small mistake or three and have lots of defects when the programs were compiled. I wrote my C# classes Rebol dialect to automatically generate these support classes and even the originating class! So now, I don't get errors when I need to change a class or it's supporting classes. I just change the dialect code and all classes are the same in their own way as it were.
> Beyond that is the idea of hidden smarts, where they can embed logic and
contextual behavior hiding the guts from the casual use. http://c2.com/cgi/wiki?LittleLanguage Quote: ...the realization that it is easier to implement a task-specific language optimized for that task than it is to implement a general-purpose language optimized for all possible uses. -- Andrew J Martin ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

 [36/40] from: andreas:bolka:gmx at: 13-Jan-2004 0:27


Monday, January 12, 2004, 2:35:51 PM, Romano wrote:
>> Sorry if this is a stupid question, but is REBOL Object Oriented? > Yes, like Self: > http://research.sun.com/self/language.html
Or maybe rather not like Self as REBOL misses Self's crucial capability for inheritance (Self's parent slots). -- Best regards, Andreas

 [37/40] from: behrangsa:yaho:o at: 12-Jan-2004 16:37


Hi
> JC> ...whether it behaves differently or if its > sytnax is consistent
<<quoted lines omitted: 9>>
> learn, the better, in > most cases.
I totally agree with that. Learning a new dialect (syntax) is not harder than learning a new API, at least for experienced programmers who have worked at least with 3+ languages in real world scenarios. Having worked with Java and C++ alot I didn't feel any difficulties in learning Jython, (and REBOL of course ;) According to the messages sent to the list I learned that REBOL is not OO. But it doesn't look to be procedural or something else too. Isn't it an instance of a new yet to be named paradigm?? Behrang.

 [38/40] from: greggirwin:mindspring at: 12-Jan-2004 21:42


Hi Behrang, BS> According to the messages sent to the list I learned BS> that REBOL is not OO. But it doesn't look to be BS> procedural or something else too. Isn't it an instance BS> of a new yet to be named paradigm?? RT calls it a "messaging" language. My favorite definition is that it's "designed to facilitate the semantic exchange of information between people and machines." It's a symbolic language, like Forth; it's a functional language, like Lisp; it's accessible to mere mortals, like Logo. You can use it in many ways: imperative, functional, declarative. I've had a number of "AHA!" moments (many of them thanks to the good people on this list)in my time with REBOL, as I'm sure you will. Realizing that "code is data, and data is code" is important. After I got there, it took a while before someone said "everything is data until it's evaluated" and another light went on. Other things like words refer to values; they don't contain them are important distinctions too. Learning when to use COPY on series! values, and the really important "local variable" behavior (someone must have a boilerplate example on hand for that one :). The number of "gotcha's" in REBOL is rally low (IMO), but you do have to keep an open mind sometimes and think about why it works the way it does. There's nearly always a good reason. Happy REBOLing! -- Gregg

 [39/40] from: ingo:2b1 at: 13-Jan-2004 11:00


Hi Jason, just a quickie ... Jason Cunliffe wrote:
> Hi Gerard
<...>
>>For example I find it so annoying to me to completely rewrite my complete > paths (switching the / for the \ plus adding the " at both
<<quoted lines omitted: 11>>
> over already by people. >> help "-file"
to-local-file Converts a REBOL file path to the local system fil... to-rebol-file Converts a local system file path to a REBOL file ... Of course, having it automatically detect the right file notation would be nice. Kind regards, Ingo

 [40/40] from: gerardcote:sympatico:ca at: 13-Jan-2004 20:47


Hi Ingo, Glad to hear from you again. You wrote:
> >> help "-file" > > to-local-file Converts a REBOL file path to the local system fil... > to-rebol-file Converts a local system file path to a REBOL file ... >
Thanks for the post. I will try it as soon as I will get my hands at my keyboard.
> Of course, having it automatically detect the right file notation would be > nice. >
Many other things too in this computer world would benefit from the same behavior I think... But sometimes we can help too ! Regards, Gerard

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted