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

[REBOL] Re: syntax across languages

From: joel:neely:fedex at: 6-Nov-2003 7:20

Hi, Maarten, and all, There's a serious question at the end of all the yammering below! ;-) Maarten Koopmans wrote:
>>came accross an interesting site on "syntax across languages" >>which is soliciting help with constructs in various languages >>including rebol. >>They are currently missing 120 syntax constructs for rebol. > > Most of them are available in REBOL but not in the comparison. If I only > had time... >
I can relate! On the other hand, I'm also ambivalent their terminology; the table of contents maintains the "syntax" pretense, but there are really three different levels being addressed (somewhat indiscriminantly): 1 lexical rules (e.g. structure of a user-defined name/word) 2 higher-order syntax (e.g. structure of an "if" statement) 3 language features (e.g. "get type/class [of] object/instance/value") I'd be glad to be updated, but I haven't seen (1) fully documented anywhere for REBOL. (Remember recent -- and not so recent -- posts about what characters are allowed in a word? IIRC most such questions get resolved by trial and error or advice from someone who's already traveled that road, not by pointing to section x.y in the manual.) As for (2), it doesn't exists! I'm not trying to be pedantic here, but sincerely believe that one of the early steps to "getting" REBOL is to realize that e.g. THERE IS NO "IF" STATEMENT, but merely some functions (IF, IF/ELSE, EITHER) that take an argument of type [LOGIC! NONE!] and one or two arguments of type [BLOCK!] and, if you so choose, YOU CAN WRITE YOUR OWN. Being pragmatic, I know that a short answer to the question: "How can I say the likely equivalent of if (buff [0] == '\0') { p--; } else { p = q % ++r; } is either zero? length? buff [ p: p - 1 ][ p: q // r: r + 1 ] but that doesn't necessarily help the questioner make the leap to p: either zero? length? buff [ p - 1 ][ q // r: r + 1 ] or even more REBOL-ish reconceptualizations of the programming task. That brings me to (3), where IMHO it becomes most clear that efforts such as the page in question often become either too encylpaedic for ease of use, or else too superficial for useful ... use. It's one thing to take two languages that share most of their conceptual base (e.g. Pascal and C, ALGOL and Pascal, etc.) and address in a fairly complete way the questionS (plural emphasized): - What are the correspondences between the languages (i.e. for those features that are conceptually similar, how does one "respell" from one notation to the other)? In this category, explaining that Pascal uses "begin ... end" for sequences of statements, while C uses "{ ... }" is reasonable. - What are points of NON-CORRESPONDENCE between the languages, and what effect does that have on one's programming/design thinking? In this category, the nesting of lexical scope (e.g. procedures defined locally to enclosing procedures in Pascal, vs. the flatter, assembly- like model of C) can cause one to think and design quite differently. I should also add that many of the issues under the second point above often become significant when [only when?] designing programs that deal with larger-than-toy problems. But when approaching languages with substantially different conceptual models, the second issue becomes so dominant that the first issue is either irrelevant or misleading IMHO. For example, what is the REBOL equivalent for the elementary PROLOG idiom conc( [], L, L ). conc( [X | L1], L2, [X | L3] ) :- conc( L1, L2, L3 ). ??? As much as we might like to write conc: 'join that just won't cut it, when trying to understand why last( Item, List ) :- conc( _, [Item], List ). works. Inspired by discussions on this list, I started putting together some recipes for a Perl-to-REBOL cookbook. I say "started" because I was smacked in the face by the above issues on the very first recipe, which dealt with the Perl substr function. You see, in Perl, substr can be used both as an lvalue and an rvalue (a distinction which doesn't exist in REBOL). And OBTW, using an rvalue string expression as an rvalue in Perl implicitly copies, while an lvalue string expression mutates... And OBTW, the Perl splice function (more or less) does for arrays what substr does for strings, but REBOL blocks are the closest analog to arrays, and block! and string! types are both subsumed in the REBOL meta-type series! so instead of defining SUBSTR, shouldn't one actually define SUBSER and ... So instead of a one-page recipe, I suddenly had a very long chapter (I know you can't believe that I found lots to say on such a narrow topic ;-) and began to question whether anyone would bother to read it! On the other hand, I don't want to spend the effort to produce something that ends up being so superficial that it's a read-once-and-throw-away (as is the case with too many books and articles in the computing field IMHO). So, here's my question (or two... sorry! ;-) Does the attempt to provide a Berlitz-phrase-book mapping across really different languages do more harm than good, or is it a reasonable foot in the door for beginners? Would a (for example) Perl-to-REBOL cookbook be of enough value to justify the (substantial) effort to produce it with reasonable quality and completeness, and would there be a large enough market for such a thing to have reasonable ROI? Where could I place the balance between simplicity/brevity versus honesty/completeness to maximize the value? With only a hint toward to the recent thread started by Petr, I have to admit that there are many more things about REBOL to play with than I have time for, there are many more ways to (try to) help REBOL grow than I can fit in, and REBOL is only a small part of my life agenda (with many work obligations and other responsibilities/commitments). I have to work hard at budgeting my increasingly tight discretionary time to those areas that have the greatest value (in multiple senses of the word). Any/all feedback/comments are welcome! -jn-