Slashdot REBOL mention

Yeah, read some of those myself. Sure are a lot of programmers willing to make judgements on something they know nothing about. :-(

I did get a note from my boss pointing it out for me. At least he was aware enough to pass it along. :-) [snip] Nice dialog! :-) Rod. Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

I read Larry Wall's comments on Rebol again and the most funny stuff was his claim, that Perl did use dialecting :-)

There's an English version Cyphre: "You can't teach an old dog new tricks." -- Carl Read

-- Tim Johnson <[tim--johnsons-web--com]> http://www.johnsons-web.com

hasn't

seems

I have been forced to learn Perl, and while I agree it is not the most likable language on the planet but there are a few points I think should be considered: - - A script is as readable as the author makes it. I can write obfusticated REBOL as easily as I can Perl. I can write very readable, sensible code in either language as well. - - I use REBOL and Perl for two things: CGI scripting and database work. As far as CGI is concerned they are not particularly different - once you get the hang of the syntax it is almost possible to copy a piece of REBOL code, paste it and then add ing a few symbols (function paramters aside, those are stupid in Perl..) As for the database work.. as I have explained elsewhere, I needed Oracle access but bying /command was not an option, neither was using mySQL instead. Perl and DBI did the job as easily. You see, if you're going to get all fancy with the language then I agree - REBOL would be far better than Perl. But I'd use C/C++ or even Java if I wanted to do anything particularly complicated because I believe that each language has its place. Where I think REBOL is suitable, I use REBOL. Where I think Perl would do the job as well or better, I use Perl. REBOL is not the be all and end all of languages; it has good and bad points the same as any other. If you want to do dialects, use REBOL. If you want cheap database and shell access, use Perl. If you want speed use C. If you want platform independant graphical programs, use Java. Many people here will disagree with this view and think that REBOL can be used for all of them. If everyone agreed on everything life would be boring. Chris - -- New sig in the works Explorer2260 Designer and Coder http://www.starforge.co.uk - -- E = MC ** 2 +- 3db -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE73ggEtwxr0HXns0wRAsX2AJ9Z3CzWlpX7Ri7DvDq8QgiNNHU9bACfY6Ur ti37UFPcdz33XfM2xneINDs=szpT -----END PGP SIGNATURE-----

-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400

I like the Czech saying better than our traditional colloquial `You can't teach an old dog new tricks'. I might try an English rendering of the Czech with something like `Old dogs can't learn new manners'

hasn't

seems

functions.

that

Could you be more elaborate on Perl dialecting (I am not a Perl expert)? As an example of a dialect, let's take my PIF function from http://www.rebol.cz/cffr.html Is there a possibility to do that in Perl? Regards Ladislav

[ arg [ ][ [ return a arg ['negative] ['zero] ['possitive] [ ]

== negative

== zero

== possitive See? Enjoy!! Ammon

Not unbelievable, True! I just wanted you to see the way REBOL thinks. ;-) My point was that testing could be changed to: testing: func [ arg ][ return sif arg ['negative] ['zero] ['positive] ] which would minimize the code, & use a function to return a value to a function, as REBOL is so good at doing. ;-) Just a little more elegant. Enjoy!! Ammon

;-)

It surely is more elegant. The only disadvantage is, that it won't reveal the bug I am mentioning.

I can't find that claim anywhere in Larry's remarks. Could you point me to it? The only comments by Larry that I could find were a link someone else posted to a three-year-old email reposted to Google... -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

Larry wrote (http://groups.google.com/groups?q=larry+wall+rebol&hl=en&safe=off&rnum=1&ic =1&selm=36406F9F.40E9CB59%40ndirect.co.uk_NOSPAM): I don't think REBOL is any more English-like than any other dialecting language such as, say, Tcl. (Or Perl, for that matter.) :-))

I parsed it as I don't think REBOL is any more English-like than ( (any other dialecting language such as, say, Tcl) or (Perl) ) instead of I don't think REBOL is any more English-like than any other dialecting language, such as, say ( Tcl or Perl ) My perception, as a long-time user of Perl, is that one might describe Tcl as a "dialecting language" (for some senses of the word "dialecting"), but I would never say that about Perl. -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

dialecting ),

No. I've looked at it a couple of times, but haven't been able to work up the enthusiasm (or time) to really learn it. My (admittedly cursory, and lightly-held) opinion on its "dialecting" capability arises from these two observations: 1) The syntax of Tcl commands revolves around a simple verb param-a param-b param-c... statement format. 2) There's apparently a well-documented and widely-used set of conventions for writing extensions that present externally- written c functions/libraries as Tcl commands (and, BTW, for embedding Tcl as a command interpreter into c programs). Those led me to the view that it would be easy to write code (either in Tcl or as an extension) that would have the appearance of adding new verbs/commands to the language in a manner that would be indistinguishable from "built-in" features. That's the sense in which I was referring to "dialecting". Of course, that's not unique to Tcl, but it also doesn't quite fit the REBOL concept of a dialect either... -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

I guess it depends on which meaning of "closer" we're using... 1) Surface similarities? -- I do NOT want to program in anything that looks like human language. Consider that COBOL (the only major surviving programming language that pinned its hopes on being natural-language-like) looks like this: MOVE ZERO TO TOTAL. PERFORM ADDING-ACTION THRU ADDING-COMPLETE VARYING COUNT FROM 1 BY 1 UNTIL COUNT > 10. ... ADDING-ACTION. ADD COUNT TO TOTAL. ADDING-COMPLETE. instead of the far more succinct (although not fake English) total: 0 for count 1 10 1 [total: total + count] or $total=0; foreach my $count (1..10) {$total += $count} or even int total=0; for (int count=1; count<=10; ++count) {total += count} Natural languages are big, redundant, sloppy, ambiguous, and have no concepts relating to things that I have to think about when trying to compose non-trivial processes: (re)definition of concepts on the fly; scope of nomenclature; abstraction, parameterization, and reuse of concepts/patterns, etc. 2) Deep linguistic structure, Zipf's Law, ad hoc shortcuts, irregular and non-orthogonal grammer? -- I have yet to see a programming language that comes close to Perl. (It even has adverbs and a pronoun!) -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

I was referring strictly to the dialecting. In that sense (having/not having this ability to a certain degree) the languages can be compared. Cheers Ladislav

Just a trial, OK? Example #1 The C printf dialect. The string s="%s" surely has got a different meaning than usual if used as a format string for the printf function in the C language. The format string is understood as a formatting language sentence in that case. Conclusion: we can find a dialect in C (a C "sublanguage"). Similar dialects are not the C language specialty. Their usefulness lies in the fact, that they are better suited for a particular purpose than the main language is. More examples: * switch in C - see the meaning of the 'case word * cycle blocks *- 'continue has different meaning in nested cycles e.g. * printf formatting strings * macro directives (#include #ifdef ...) * etc Example #2 Rebol PARSE function. Let's have a block: block: [copy result telephone] If we simply DO this block, we are evaluating the COPY function that should set 'result to refer to a copy of TELEPHONE. If we instead use block as a parse rule, BLOCK would have totally different meaning. Namely, 'result would be set to a copy of a part of PARSE INPUT argument that would satisfy the TELEPHONE subrule. The difference isn't that big, but it is only natural, that 'copy should always communicate similar meaning, isn't it? There is a whole lot of native Rebol dialects, examples: * blocks treated as code can communicate totally different meanings than the same blocks treated as data * DO versus REDUCE versus COMPOSE - different handling of the contents of their BLOCK arguments * IF versus DO - DO always handles BLOCK argument as CODE, the behaviour of IF depends on the condition (treat BLOCK as data, or evaluate it?) * block as the SPEC argument of MAKE OBJECT! * block as the SPEC/BODY argument of the FUNC function * the VID * etc The existence of dialects doesn't distinguish these languages. The real difference is, that we can define our own REBOL dialects (using PARSE e.g.), while we cannot define our own C dialects without changing the language specification. A "buzzword" that communicates this meaning is, that REBOL is a language with meta-circular semantics. This feature makes the language much more communicative than any other language not having this feature is. HTH Ladislav

I like to think that: [copy result telephone] has no meaning before the program give it one. There are not keywords (words with fixed meanings). Before DO-ing it, you must give a meaning to the words of that block, binding them to a context. Everything is a dialect in Rebol.

Parse can be util to change the syntax, like in the parse dialect itself, where set-word and get-word have a different use, but context is the key for meaning: x: [copy result telephone] bind x in context [copy: :+ result: 3 telephone: 5] 'self ; now the words in x have others meanings until we re-bind them do x bind x in context [copy: :view result: :layout telephone: [button ""]] 'self do x

Semantic -> bind, parse cannot directly change the meaning of a word. Fixed, in Rebol, are only some syntax rules: the use of "[]", of "()", strings {}, set-word, get-word, comment ; and little more. Datatypes are almost fixed (to-word is not datatype aware) but only because RT did not give us the mode to change the load function to change/add/remove some datatypes.

--- Ciao Romano

This isn't a dialect definition I would suggest to use, according to that all languages would be dialecting, because you can change the variables in any language. The existence of dialects doesn't distinguish (C and Rebol e.g.) languages. The real difference is, that we can define our own Rebol dialects (using PARSE e.g.). PARSE can be used to totally change the way how the block is being interpreted. Rebol can easily handle blocks, which can be basically considered sentences of the language. The interesting consequence of that is, that as opposed to C, Rebol will never have any macro language, because Rebol is a macro language for itself. (Don't you like that?) A "buzzword" that communicates this meaning is, that REBOL is a language with meta-circular semantics. The above feature makes the language much more communicative than any other language not having the feature is. Hope the text is a little bit more consistent now. Regards Ladislav

What i want to say is that, in Rebol, the "ufficial" language is very poor. It is almost all made by variables (there are not instruction (vs functions), also the operators are functions, syntax and punctuaction marks are very limited. In many others languages there is a big fixed part and an unlimited variable part, in Rebol the fixed part is very small and this leaves a great freedom in programming.

I agree.

I think that this feature is also in other interpreted languages. Rexx, for example, has an instruction "parse" and an istruction "interpret", so it can make the same things than Parse/Do. In C, you can always create your parser and interpret-compile-link the result as C language at run time (it is not so easy and direct...).

Yes, also if, to me, is not clear the true difference between a macro and a non-macro language.

I'm not sure. I think that semantic refers to the meaning of words, not to syntax rules. When I listen the word "semantic", I think to Bind and Context and to the fact che no word in Rebol has a meaning outside a given context (no keyword).

My error, not your, if i did not understand well your message.

--- Ciao Romano

poor. It

unlimited

great

I think, that it can be paraphrased as follows: "Rebol has very simple syntax".(no keywords, little punctuation, etc.) ...

a

I am not going to write a definition. I point you to the description of C macro language: #include, #define, #ifdef, etc. as opposed to the C language.

meaning

These all are semantics. Consider the following code: [ a: | "1"] Syntactically it is Rebol. Even if you knew the binding of the words you wouldn't know what is the meaning of it as a whole, because it would depend on the way how would you interpret it. The meaning (the semantics) differs if we use the code as an argument of DO or as an argument of PARSE, etc.

I'd prefer to say that REBOL doesn't *need* a distinct macro language. In a programming language context, I believe it's fair to say that language X is being *used as* a macro language if one is using it to write code that creates source code. This is particularly relevant to programming language implementations that (as is typical with c) run source code thru a compiler to produce object code when then is able to be run. Languages which can * interpret (or compile on demand) newly-constructed code, and * explore and manipulate the run-time representation of their code, can serve as their own macro language, thus eliminating the need for learning a separate syntax and performing a separate processing step. Such languages include LISP and REBOL. Of course, it's entirely possible to write code (in whatever language one wishes) that would construct REBOL source code. In such a case, one would be using that other language as a REBOL macro-language (but without "official" sanction, of course! ;-) As for the discussion of syntax, I'm working on an article now that will address some aspects (and consequences) of REBOL's choice of lexical-only syntax. -jn-

Not only: Rebol has little fixed semantic (keywords).

For me, semantic + syntax = meaning. Semantic and syntax are two different fields and togheter make the meaning of a sentence. Your vision makes no difference between meaning and semantic. So we are using two different notion of semantic. In few words, for me: syntax: sequence of words semantic: meaning of words The meaning can change if you change semantic (bind) or if you change syntax (parse or other), but it is not the same thing which you are changing. --- Ciao Romano