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

Style R flavour checker ;-)

 [1/20] from: nitsch-lists::netcologne::de at: 8-Jan-2002 13:15


Style R flavour checker ;-) { Hi Joel and all, here is a littel toy to play with style R . based on carls %clean-script.r . clip some code, start script, see if you like it :) -Volker } [ REBOL [ Title: "REBOL Script Cleaner" Hacked-by: "Volker Nitsch" one-bug: "inserts empty lines sometimes" Author: "Carl Sassenrath" File: %clean-script-style-r.r based-on: [%clean-script.r "rebol-library"] Date: 30-May-2000 Email: [carl--rebol--com] Purpose: { Cleans REBOL scripts by parsing the REBOL code and supplying /cut: standard/now: Style R/ indentation and spacing. } Note: { Now it uses Joels Style R. and is hacked. ups. Well, its a toy. if Carl sees this by accident and think its more i have to do some cleanup.. Original Note by Carl: This script produces STANDARD script indentation and spacing. No doubt you will want to modify it to use your own rules. Send your enhancements and I will consider adding them to the distribution... but keep this header intact and keep the code clean. No hacks. } Category: [script util text 3] History: [ "Carl Sassenrath" 1.0.0 27-May-2000 "Original program." ] ] script-cleaner: make object! [ out: none ; output text indent: copy "" ; holds indentation tabs last-indent: none tab-spaces: next detab to-string tab big-letters: charset [#"A" - #"Z"] emit-line: func [] [ if "" = trim/lines copy last-indent [clear last-indent] append out newline ] emit-space: func [pos /local more b2 bracket b1] [ append out any [ if newline = last out [ any [ if all ;move terminating bracket down [ find "[(" bracket: first b2: back back tail out not find "[(" first pos ] [ clear b2 Emit-line Last-indent: tail out join next indent [bracket tab] ] if all [ find ["^-)^/" "^-]^/"] back back b1: back tail out find ")]" first pos any ;starts line with closing bracket? [ tail? more: next skip last-indent length? indent find ")]" first more ] ] [ remove b1 remove last-indent tab-spaces ] do [ last-indent: tail out indent ] ] ] if find ")]" first pos [ if any ;starts line with closing bracket? [ tail? more: skip last-indent 1 + length? indent find ")]" first more ] [ if tab = first back more [remove last-indent] ] either find ")]" last out [tab] [""] ] if find "[(" last out [ either any ;starts line with opening bracket? [ tail? more: skip last-indent length? indent find "[(" first more ] [tab] [""] ] " " ] ] emit: func [from to] [emit-space from Append out copy/part from to] clean-script: func [ "Returns new script text with standard spacing." script "Original Script text" /local str new blk-rule value more ] [ out: append clear copy script newline parse copy script blk-rule: [ any [ str: newline (emit-line) | #";" [thru newline | to end] new: (emit str new) | [ #"[" | #"("] (emit str 1 Append indent tab) blk-rule | [ #"]" | #")"] (remove indent Emit str 1) | skip ( set [value new] load/next str either all [ ;uppercase in line? add sme spaces not find "^/" last out any-word? :value find big-letters first str not any ;starts line with opening bracket? [ tail? more: skip last-indent length? indent find "[(" first more ] ] [ emit-space str append out join tab-spaces copy/part str new ] [ emit str new] ) :new ] ] remove out ; remove first char if error? error: try [ either equal? load script load out [return out] [ alert "formatting error (type 1)! keeping original." return script ] ] [ alert "formatting error (type 2)! keeping original." return script ] ] ] /main make script-cleaner [ view center-face layout [across backdrop [quit] t1: area para [] 600x400 detab clean-script Read clipboard:// s1: slider 16x400 [scroll-para t1 s1] ] ] ]

 [2/20] from: brett:codeconscious at: 8-Jan-2002 23:39


Hi Volker, Well done. I tried it on some of my code and now I'm convinced - I need an Un-Style R ! :-) Brett.

 [3/20] from: carl:cybercraft at: 9-Jan-2002 18:02


On 09-Jan-02, [nitsch-lists--netcologne--de] wrote:
> Style R flavour checker ;-) > {
<<quoted lines omitted: 4>>
> -Volker > }
Nice. But - is style-r (which I'll always think of as Joel's style) going to catch on amongst REBOL coders? Other people's REBOL code is hard enough to read as it is without two styles to contend with. (: -- Carl Read

 [4/20] from: rebol:optushome:au at: 9-Jan-2002 19:35


I've been sitting back holding off commenting, but can't hold off forever. If you really want to make it easier for maintenance programmers, all I can say is to repeat the Designer's Tip Sheet. Tip #7 Code in Style REBOL is a highly dynamic language that allows massive creative freedon in script's design. But, when it comes to the source format of your script, use the standard style (found in the REBOL User's Guide). Adhering to a standard style will make your script easier for you and others to read I see little point in using a style different to the style that is in used REBOL itself. For one thing the source function loses some of its utilty if you have to mentaly map from the standard formatting to your own style. If you have trouble reading the standard style, then maybe you haven't truly learnt to read REBOL yet. (or you might be carrying too much baggage from past languages.) Please stick to the standard guide as much as you can, at the very least please stick to it for posts to this list. When in Rome... etc Cheers, Allen K [close vent]

 [5/20] from: carl:cybercraft at: 9-Jan-2002 23:58


On 09-Jan-02, Allen Kamp wrote:
> I've been sitting back holding off commenting, but can't hold off > forever. If you really want to make it easier for maintenance
<<quoted lines omitted: 9>>
> of its utilty if you have to mentaly map from the standard > formatting to your own style.
But RT could change the output with the next release of REBOL.
> If you have trouble reading the > standard style, then maybe you haven't truly learnt to read REBOL > yet. (or you might be carrying too much baggage from past > languages.)
Nah - it's to get away from the look of other languages and to have a more REBOL-like style - to emphasize the blocks as much as possible. Plus, it's just plain better.
> Please stick to the standard guide as much as you can, at the very > least please stick to it for posts to this list. When in Rome... etc
Vote?
> Cheers, > Allen K > [close vent]
(: -- Carl Read

 [6/20] from: petr:krenzelok:trz:cz at: 9-Jan-2002 12:10


Carl Read wrote:
> > If you have trouble reading the > > standard style, then maybe you haven't truly learnt to read REBOL
<<quoted lines omitted: 6>>
> > least please stick to it for posts to this list. When in Rome... etc > Vote?
Maybe I will be just intollerant, but RT's style is the only one I will use. I am used to it already and none of ABCDEFGH styles presented showed any evident advantage for me to change my mind :-) So, I back up Allen's opinion :-) -pekr-

 [7/20] from: brett:codeconscious at: 9-Jan-2002 22:34


Hi Carl,
> Vote?
Sorry but I don't think a vote will be helpful. My position is in basic agreement with Allen. I'll add that I haven't seen an overwhelmingly better style than the standard yet. So I don't think there is any point making changes that will result in inevitable confusion. I also believe that people who may have just joined the list will already be experiencing some difficulty with recent posts that use a different style. The value of coding style (as laid out by the vendor) in the Powerbuilder world is so strongly recognised that you don't pass a job interview unless you know it. I think RT will, and needs to, lead the way and I'm quite confident that if a much better style is developed it will be adopted. But it would have to be brilliant. :) I think there could also be some effort put towards ways of dressing up the existing standard style (via for example spacing/comments) that will make it more visually pleasant. Brett.

 [8/20] from: rebol665:ifrance at: 9-Jan-2002 13:49


Hi, all I'am afraid that this is becoming a sensitive matter. I would not like to see a war starting between the rebol-listers. I cannot recall who started this, but it was an interesting thread. However I agree with Allen point of view.
> I see little point in using a style different to the style that is in used > REBOL itself.
Patrick ( a voté ) ps : my main problem is the code ending with ] ] ] (as in the following code from Joel Neely's RF article). These are not natural for me (sorry joel). nbt: func [b [block!] /local rt cur pen front ] [ rt: 0 cur: b pen: [] forever [ either empty? cur [ either empty? pen [ return rt] [ cur: first pen pen: second pen] ][ either block? front: first cur [ pen: reduce [next cur pen] cur: front] [ rt: rt + front cur: next cur] ] ] ]

 [9/20] from: chris:starforge:demon at: 9-Jan-2002 13:18


pat665 wrote:
> Hi, all > > I'am afraid that this is becoming a sensitive matter. I would not like to > see a war starting between the rebol-listers.
But.. but.. Holy Wars are fun! Or something...
> ps : my main problem is the code ending with ] ] ] (as in the following code > from Joel Neely's RF article). These are not natural for me (sorry joel).
I can't really comment as my style changes slightly depending upon my mood (this is true regardless of the language I am using) but I too find the ] ] ] scheme rather disconcerting, if only because C and its ilk have trained me over the years to do ] ] ] when matching brakets across multiple lines. Call it psychological damage if you will :) Chris -- .------{ http://www.starforge.co.uk }-----. .--------------------------. =[ Explorer2260, Designer and Coder \=\ P: TexMaker, ROACH, site \ =[___You_will_obey_your_corporate_masters___]==[ Stack: EETmTmTRRSS------ ]

 [10/20] from: mat:b:codeplay at: 9-Jan-2002 12:08


Hello, I'm trying to get Rebol to work with Xitami. I've actually done it before but the box suffered a melt-down. I'm not really interested in doing anything fancy like that fast-CGI type implementation. I just want to do some very simple stuff such as you see in the script library. Anyone know exactly what you do? I've tried a load of different things. Regards, Mat Bettinson Codeplay Tel: +44 (0)20 7482 3382 140-142 Kentish Town Rd, London, NW1 9QB http://www.codeplay.com

 [11/20] from: jason:cunliffe:verizon at: 9-Jan-2002 11:35


I agree with Allen's comments about the virtues of publicly consistent style. As REBOL succeeds more, and the sizxe of its contributed library and user-populatino grows, this becomes a much more important issue. That has been one of the major success stories of Python. Python uses white space indentation, thus to write syntactically correct code, all Pythoneers must write in consisstent readable style. This was a major design feture, and makes it excellent for both novice and advanced user. It seems to me that REBOL needs better tools and strategies only. Ideally a really cool editor written in REBOL for REBOL. "REBEDIT" could also become a great showpiece, allow people to learn from it, enhance it, customize it, benefit from built-in FTP, http etc.. and be 100% cross multi-platform. Most of the pieces exist already.. With such an editor, those who prefer individual 'house' styles would be free to select [A-Z]. The editor would then parse incoming code adn pply selected style. When saved or sent [uploads/transfers], it would re-convert tranparently to the [global] REBOL standard style. In other words expand on an idea REBOL already implements when open and saving code which has travelled across platforms to fix line endings transparently. Is REBOL fast enough to this & compete with exiting editors? How big a project is this? Request for Features? .. The code folding [collapse/expand] suggestion is a very good one. Python has this also in the editor/shell whihc comes with PythonWin. This is based upon Scintilla [A free source code editing component for Win32 and GTK+] http://www.scintilla.org/ Mathematica developed the original idea I think with its wonderful notebook interface. I use UltraEdit irght now as my default text editor, this includes a crude hide/show tool, nice color syntax highlighting, smart indentation and built-in FTP. Most of what is needed, but I would jump for REBEDIT. How about you? ./Jason

 [12/20] from: sunandadh:aol at: 9-Jan-2002 13:03


Hi all, Allen Kamp:
> I see little point in using a style different to the style that is in used > REBOL itself.
But I do! I have two problems. One minor and one more important. Minor point: many bits of Rebol are good examples, but there some bad examples in there too. Asking someone to "do what Rebol does" is not enough. I don't like one-letter variables (source Request) or variables which are just misspelt words (source Request-list). That's just sloppy and I don't want to copy that style But I think you meant your remark to refer mainbly to source layout, not variable names. So, more importantly: Rebol's style and my way of visualising block just don't click. Psychologists will tell us that people think in different ways. The code I produce is a result of the way I visualise and think. And there is not a natural match between Rebol's published style and my development style. If I had to write that way I'd walk away from the language. Simple as that. And I doubt if I'd be the only one. But I have no trouble at all with there being a single "house style". My code can be reformatted however a prettyprinter likes for publication. Just as when I write for magazines they pour my text into their house style at the last moment, saving me from writing in narrow columns and leaving space for adverts. And if the prettyprinter had enough options that I could turn other people's code into something close to what I prefer and can work with, well that's a win/win/play-again situation for all of us. (Wow! I got through that without mentioning the Style Police. and thus almost falling foul of Godwin's Law) Sunanda.

 [13/20] from: joel:neely:fedex at: 9-Jan-2002 16:09


Hi, Pat, and all, pat665 wrote:
> Hi, all > > I'am afraid that this is becoming a sensitive matter. I would > not like to see a war starting between the rebol-listers. >
I agree (with both statements).
> I cannot recall who started this... >
Blame me, but first reread my original post: This is a controversial and sensitive subject with some folks. I'm not trying to start a flame war, and I have no interest in debating aesthetic opinions. I *am* very interested in objective criteria which identify strengths and weaknesses of the alternatives. I was planning on waiting a while before trying to summarize my observations of the discussion, but I agree with Pat's perception that the temperature is rising a bit fast. Dijkstra has often used the phrase "separation of concerns" in discussions on software development. He distinguishes what he calls the "mathematical" concerns -- whether a program behaves correctly/accurately -- from "engineering" concerns -- whether the program exhibits appropriate economies in its behavior. While a good programmer is concerned with both, it is appropriate to know at any moment *which* of these issues one may be most directly engaging, and to be able to discuss them separately. (I believe it was Don Knuth who observed that, in programming, premature optimization is the root of all evil .) Since programming languages induce subcultures, it seems to me that any discussion of stylistic issues involving a specific language engages three separate areas of concern: 1) Objective -- things that can be measured (even if statistically, in a human factors sense) in a non-ambiguous manner; e.g. how many lines are required for a given piece of source code, depending on formatting style. 2) Personal -- things that are a matter of individual preference, aesthetics, taste, etc.; e.g. my previously-mentioned personal dislike for all-upper-case text. 3) Cultural -- things that are a matter of tradition, convention, custom, etc., within a specific society; e.g. the practice within the REBOL community of indenting by 4 spaces per level of nesting. I began experimenting with layout to see whether there was a way to increase the amount of content within a given area of real estate, whether editor screen, browser window, or printed page. I was focused on #1 above. I'm very aware that factors #2 and #3 are entangled in anything with as much personal choice and feeling as how one writes code, but I see some value in applying separation of concerns to the discussion of this issue (as well as many other programming topics). I'll leave it to each individual to read this thread and think about how much of #1, #2, and #3 are present in the various parts of the discussion. I think it is ironic that the "layout style" thread occurred concurrently with another instance of a topic that re-appears every few months on this mailing list: the issue of promoting REBOL in our various environments. I suggest that there are some instructive parallels. A suggestion that we look at an alternative layout style was met with a variety of reactions: - "Interesting!" - "I like it!" - "I don't like it!" - "I don't see the point." - "What we've always done is good enough." - "Here's an apparent limitation.", followed by "Here's a way to deal with that." - "Why are you rocking the boat?" A suggestion that a development team already using Java, Python, Perl, c++, (or whatever...) consider another programming language (REBOL) is often met with responses that boil down to the same reactions as those above. Perhaps a look within ourselves, and at our reactions to the idea of change will give us some insight into how others respond when ask them to take a look at REBOL (another kind of change). My thanks to everyone who has contributed to the discussion. Again, let me say that my motivation wasn't to "own" a new style, nor to rock the boat unnecessarily, but to discuss whether a style that evolved within the Algol heritage was the best approach for a very non-Algol-like language. -jn- P.S.: I'll gladly comply with the judgement of the editor-in-chief as to whether the refactoring article should be resubmitted with the examples in a more conventional style.

 [14/20] from: richard-boyd:worldnet:att at: 9-Jan-2002 21:51


-Sunanda >> I strongly agree with your summary. -Volker >> When I first tried your "cleaner" on some of my script, I thought your clean-script-style-r was not working because I didn't notice much difference when I toggled between my original code and the "cleaned" version output from your script. Then I realized why ... there wasn't much difference!! I am going to try modifying my style from "L" to "R" ... just because of the convenience of being able to use your pretty printer on it ... as per my Smalltalk days. Thanx for a nice tool. -richard- [SunandaDH--aol--com] wrote:

 [15/20] from: sunandadh:aol at: 10-Jan-2002 6:04


Hi Joel,
> I was planning on waiting a while before trying to summarize my > observations of the discussion, but I agree with Pat's perception > that the temperature is rising a bit fast.
Thanks for your summary, and the call to cool it. I think is was the current US President Bush who pointed out the someone you agree with 80% is not your enemy. And I'm sure we all agree far more that that on the value of Rebol. I guess I got slightly sharp because though I'm happy to listen to (and contribute) passionate opinions and persuasive options, I react badly to what I read as policy orders. I must learn to chill out before I chip in. Sunanda

 [16/20] from: rebol665:ifrance at: 10-Jan-2002 12:57


Hi, If it is time to invoke J.W.Bush wisdom (some call it bushism), we are far beyond the point I had feared. I still hope the Jihad is not started? (see for details http://www.unn.ac.uk/societies/islamic/jargon/jihad1.htm ). Patrick in 80% agreement with Sunanda

 [17/20] from: joel:neely:fedex at: 10-Jan-2002 0:16


Hi, Sunanda, et al [SunandaDH--aol--com] wrote:
> Hi Joel, > > > I was planning on waiting a while before trying to summarize my > > observations of the discussion, but I agree with Pat's > > perception that the temperature is rising a bit fast. > > Thanks for your summary, and the call to cool it.
Let me emphasize that my comments weren't about, nor directed to, anyone in particular. I found the range of reactions quite fascinating! As someone who routinely writes and reads several different programming languages, I tend to "look through" layout style to the meaning of the code, and therefore think of layout as being something one simply decides on (and may try changing), just as I decide which shirt to wear. I forgot that some cultures have dress codes and react very emphatically when the code is not taken seriously! ;-) I should also add that, while I have no concerns over different people using different styles, I accept Allen's point that there is societal value (especially for recent "immigrants" to the language) in having some consistency in "officially" published code, especially when it is offered as "how to" examples. I'll be submitting a revised version of the refactoring article to REBOLforces which uses the conventional layout style in all of its examples. (It makes the source text and printed web pages both about 10% longer...) Of course, I regard code posted for the purpose of discussing coding styles to be an exception to the general principle of the last paragraph... ;-) -jn- -- Seen in a foreign hotel: Visitors are expected to complain at the office between 9 and 11 am daily. -- [krm--mail--ips--ca] joel0dot0neely0FIX0PUNCTUATION0at0fedex0dot0com

 [18/20] from: lmecir:mbox:vol:cz at: 10-Jan-2002 14:31


Hi all, <<Joel>> (...) Since programming languages induce subcultures, it seems to me that any discussion of stylistic issues involving a specific language engages three separate areas of concern: 1) Objective -- things that can be measured (even if statistically, in a human factors sense) in a non-ambiguous manner; e.g. how many lines are required for a given piece of source code, depending on formatting style. 2) Personal -- things that are a matter of individual preference, aesthetics, taste, etc.; e.g. my previously-mentioned personal dislike for all-upper-case text. 3) Cultural -- things that are a matter of tradition, convention, custom, etc., within a specific society; e.g. the practice within the REBOL community of indenting by 4 spaces per level of nesting. I began experimenting with layout to see whether there was a way to increase the amount of content within a given area of real estate, whether editor screen, browser window, or printed page. I was focused on #1 above. I'm very aware that factors #2 and #3 are entangled in anything with as much personal choice and feeling as how one writes code, but I see some value in applying separation of concerns to the discussion of this issue (as well as many other programming topics). I'll leave it to each individual to read this thread and think about how much of #1, #2, and #3 are present in the various parts of the discussion. (...) <</Joel>> Here are my 0,20 CZK: 1) the "density" criterium is truly objective. The trouble is, that it leads to unacceptable style, when used as the only measure. That is why I am sure, that (objectively) a good style must (above all) have the property to visually separate relatively independent parts of the code while grouping the parts that are connected in some way. Let's start with a simple code (style 1): either a b c either d e f The style 1 code sample is written on one line omitting the fact, that it contains two, relatively independent expressions (style 2): either a b c either d e f Style 2 underlines the fact, that the code can be separated to two expressions. That is why I prefer style 2 here, although it is a "low density" style. Now let's consider a situation, when the CONDITION, TRUE-BLOCK and FALSE-BLOCK arguments of the EITHER function are much longer (style 3): either indeed-very-long-logic-condition indeed-very-long-true-block indeed-very-long-false-block I would prefer the expression to be on one line, because it is just one long expression, but I am out of luck here. I expressed the fact, that it is just one expression, using indentation of the second line, which is understandable for humans as far as I know. What if the blocks are written as literals? Here is a code sample (style 4): either some-long-logic-condition [true-block-contents] [ false-block-contents ] either d e f Style 4 looks even better, than style 3, because it not only shows the fact, that the first EITHER expression is one expression (that doesn't fit on one line, though), but it visually separates it from the next expression using the "]", while the fact, that the expression doesn't end at the first line is expressed by indentation as well as by the "[" at the end of the first line. For me, Rebol is expression-based, not block-based, that is why I prefer an expression-based style. Other objective criteria: 1) compatibility with natives/mezzanines: MOLD, SOURCE, cut/paste. 2) compatibility with existing code base 3) zero cost of switch (not too important, I admit) 4) lower cost of modification (it is easier to modify and expression-based style code, than a block-based style code). Cheers Ladislav

 [19/20] from: joel:neely:fedex at: 10-Jan-2002 10:35


Hi, Ladislav, et al, Ladislav Mecir wrote:
> Here are my 0,20 CZK: > > 1) the "density" criterium is truly objective. The trouble is, > that it leads to unacceptable style, when used as the only > measure. >
I completely agree. Any style design is the result of balancing conflicting criteria. I had assumed that the layout I was trying out would make self-evident some of the other criteria I had in mind, such as the use of indentation to show nesting, using degrees of visual separation to show grouping of (sub-)expressions, etc. about which I'm sure we agree. I was only focusing on a specific change and assuming all else equal.
> That is why I am sure, that (objectively) a good style must (above > all) have the property to visually separate relatively independent > parts of the code while grouping the parts that are connected in > some way. >
I agree, except for the "above all" part, but I think we actually are agreeing on the fundamental principle that the visual organization of the source should reflect its conceptual organization. IMHO, this single statement is what so-called "structured programming" is all about (see footnote).
> What if the blocks are written as literals? Here is a code sample > (style 4): > > either some-long-logic-condition [true-block-contents] [ > false-block-contents > ] > either d e f >
Here we part company. My (personal) view is that the two alternative blocks are in some sense in a parallel or side-by-side relationship. Therefore I prefer not to break that symmetry by positioning them differently. I'd write the above as either some-long-logic-condition [ true-block-contents ][ false-block-contents ] either d e f in Style B (and as either some-long-logic-condition [ true-block-contents ] [ false-block-contents] either d e f in Style R) to draw attention to the facts that a) the two blocks are side-by-side alternatives equal in importance, b) both are under control of EITHER and its first argument.
> Other objective criteria: > > 1) compatibility with natives/mezzanines: MOLD, SOURCE, cut/paste. > > 2) compatibility with existing code base >
The above are nice, but let's not let ourselves fall into the trap of IBM in the 70's (or microSoft in the 90's) of becoming so obsessive about backward-compatibility that every decision we've ever made (for good or ill) becomes set in concrete.
> 3) zero cost of switch (not too important, I admit) >
Agreed (on both counts).
> 4) lower cost of modification (it is easier to modify and > expression-based style code, than a block-based style code). >
I agree that modifiability is important. (I don't understand the parenthetical distinction.) That's why I prefer either some-long-logic-condition [ true-block-contents ][ false-block-contents ] over either some-long-logic-condition [true-block-contents] [ false-block-contents ] precisely because extending the fully-laid-out version to read either some-long-logic-condition [ true-block-contents more-true-consequences ][ false-block-contents more-false-consequences ] requires nothing more than inserting the additional lines in either case. Of course, if I consider the likelihood of major change to be small enough, I'd write either short-cond [yep][nope] for compactness. However I'd maintain parallelism of visual layout even if only one conseqence were long, as in either short-cond [ yep ][ amazingly-long-block consisting-of-stuff for-the-nope-alternative ] to keep the structure clearly represented. Of course, I'm not mandating style for anybody else! Just giving the rationale for my preferences. -jn-

 [20/20] from: carl:cybercraft at: 11-Jan-2002 11:47


On 10-Jan-02, Joel Neely wrote:
> I should also add that, while I have no concerns over different > people using different styles, I accept Allen's point that there > is societal value (especially for recent "immigrants" to the > language) in having some consistency in "officially" published > code, especially when it is offered as "how to" examples.
This was why I thought some agreement on whether style-r was a good thing should be sought. Not that I'd be adverse to allowing nature to take its course and just letting the most popular style win through. (:
> I'll > be submitting a revised version of the refactoring article to > REBOLforces which uses the conventional layout style in all of > its examples.
But how about also keeping a copy of the style-r version on the site too as an example of an experiment of a different REBOL style? Could be useful for those thinking of writing dialects - it's a good example of the different ways of thinking about scripting styles.
> (It makes the source text and printed web pages > both about 10% longer...)
The few experiments I did seemed to indicate you'd save about 1 line in ten. I wonder how much shorter it would've made the Core User Guide? Save enough pages to give it an index with no extra cost perhaps? (; -- Carl Read

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