On 2/11/13, Arne Babenhauserheide <arne_...@web.de> wrote: > Hi Alan, > > (I’m answering to both mails here) > > Am Montag, 11. Februar 2013, 11:07:30 schrieb Alan Manuel Gloria: >> Your main contributions seem to be the extended "." behavior (. a => >> a, . a b -> a b) and the ":" syntax. I don't see any use, even in >> your examples, of the single-item-on-a-line-is-single-item-list >> behavior. > > The reason for that is consistency: Making sure that when you learn a > minimal set of rules you can understand the structure of all code you see. >
Consistency and convenience are both needed in a notation. The key is to find the balance between both. I think in this case, the single-item case tends to occur more often than the single-item-function-call case. Even for preprocessing, consider the following rule: A line is considered a "single-item line" if: 1. Strip trailing and leading spaces from the line. 2. If there are any spaces inside the line that are outside matched () [] {} "" #||#, it is not a single-item line. 3. Newlines/EOL inside matching () [] {} "" #||# are considered spaces and do not "terminate" the line. So even if you insist on a separate preprocessing pass rather than a full parser, it's possible to still correctly process the single-item-line. >> That's fine and all, but suppose I'm defining a method for Guile GOOPS? >> >> define-method : hack (x <cat>) >> ! do-hack-on-cat x >> >> Oops, except hack only works on cats anyway, so I'll just optimize >> things (because profiling shows that method calls in GOOPS take up all >> my time, LOL) and turn hack into an ordinary function: >> >> define : hack x >> ! do-hack-on-cat x >> >> Oh, no!! Now I have to adjust the indentation of everything inside >> it! Luckily hack x just contains do-hack-on-cat, so all I need to do >> is adjust that single line. >> >> define : hack (x <cat>) >> ! do-hack-on-cat x > > Well, I’m a Python-Programmer. In Python you run into that everytime you > remove or add an if. Before I used rectangle-edit, it disturbed me a bit. > Now it’s quite painless: > > C-SPACE M-↓ ↑ C-7 → C-x C-r C-k The example I show is worse, because it doesn't apply to just if: it applies to every misspelled token. Although .... > There would be a simple way to fix it, though: Make the position of : only > significant when you want to indent deeper. To make this consistent: Make > the indentation of a line only relevant for deeper nested lines (child > lines). Then the following would all be valid code: > > if : = a 1 > b > c > > if > = a 1 > b > c > > if : = a 1 > b > c > > if > = a 1 > b > c > > If the indentation is equal or lower than a previous indentation layer, the > bracket of that indentation layer gets closed. I see. This does lessen (but not remove) problem #1. > >> 3. You need to explicitly specify how double-width CJK characters are >> handled when found before a ":" (ban them in code? But what about >> strings and #| |# comments?). Do we treat them as single character >> columns (easy implementation, but potentially confusing, and possibly >> limiting international code) or do we treat them as double character >> columns (need to consider encoding, and implementations need to keep a >> list of all such double-width characters)? > > Being able to reduce indentation of later lines (as long as they stay child > lines) would also solve this for most cases. Please tell me: what should an implementation do when a double-width CJK character is encountered? Treat it as a +1 column position or +2 columns position? At the very least, say "+1 column position, so people should avoid using a : followed by a line more-indented than the : after a double-width character, as it would be confusing." Unless you're willing to pay the price of every implementation keeping a list of each double-width character. > >> ":" seems to put a lot of pressure on implementations, using your >> current explanation. Perhaps we can change ":" to be more local (i.e. >> it won't require keeping track of column position, and won't cause >> cascading affects when text before it changes)? > > For me the inline : mainly exists for consistency: It generalizes GROUP. > > Essentially GROUP adds a new indentation layer, so you could just allow > using it inline. But I use : for group, because I think that \\ looks alien > to normal text and so it hampers readability for all people who aren’t used > to bash-escaping. Our current semantic has settled on GROUP/SPLIT, not GROUP. So: ; Arc if cond1 \\ consequent 1 cond2 \\ consequent 2 \\ else-consequent 3 ==> (if cond1 (consequent 1) cond2 (consequent 2) (else-consequent 3)) The advantage of using GROUP/SPLIT rather than a separate GROUP and SPLIT is that \\ can be used to "spoof" such constructs as above. Basically, to "line up" the else-consequent together with its buddies in the Arc example. Compare the Scheme: ; Scheme cond cond1 $ consequent 1 cond2 $ consequent 2 else $ else-consequent 3 ==> (cond (cond1 (consequent 1)) (cond2 (consequent 2)) (else (else-consequent 3))) There's a reason why \\ and $ are defined the way they are, and that is because they are duals (in the above sense) of one another. One is used for explicit list pairing ($) the other is used for implicit list-pairing a la keywords and Arc if (\\) > > Inline : has nice features - if used sparingly - and I think it improves the > readability of function definitions a lot. But if it were not necessary for > double brackets, I would not propose adding it. > > Indentation based lisp syntax MUST support double brackets. That’s why : > exists. Also it MUST support continuing the parameter list after a function > call. That’s why . exists. > > Am Montag, 11. Februar 2013, 12:23:20 schrieb Alan Manuel Gloria: >> 2. It seems that multiple ": " at the start of each line are ignored, >> and only the last one is used. So the following is possibly (?) >> valid: >> >> define foo(bar) >> : cond >> : : meow?(bar) >> : : : cat bar >> : : woof?(bar) >> : : : dog bar >> : : else >> : : : error 'foo "error!" > > It’s not valid, since the “: cond” would start at the same indentation as > the define, but the converter would process it. So this is a bug in the > converter… Okay. >> How about this semantic instead? >> >> ":" introduces a (, and a promise to add ) at the end of that line. > > To make it more general, you can add that the ) is added before the first > less or equally indented line, but that a later line can add a new > indentation layer. I'm trying to make : more local here. ":" with the "generalized" form makes implementing a reader more difficult, xref. the need to re-implement string, number, symbol, and even () #() #t #f parsing. I guess you're more towards "preprocess only" without actually replacing the reader. I suggest looking at Haskell's layout rules, which have a similar "preprocess only" for layout (except the bit about "if error insert }". > > That would give the full behaviour (defining an indentation layer) while > keeping the enhanced readability for deeply nested functions. > >> In the first place, ":" can't support the shown cond-pattern. So >> without $, it would look like (without probe): >> >> define-stream stream-map(f s) >> cond > … >> >> With probe: >> >> define-stream stream-map(f s) >> probe >> cond > … > > I think I see the merit of $ now: It wraps the rest of the code in a > function call. Yes. SUBLIST is useful in many, many places. > >> A new synthesis? >> >> Perhaps we can *keep* GROUP/SPLIT \\, SUBLIST $, and COLLECTINGLIST <* >> *>, use the EXTENDPERIOD . a b, and add the new LINELIST : > … >> what you think? > > That would be the exact opposite of why I wrote. Instead of having 3 syntax > elements, we now have 4 plus the . (which is just a generalization of (. > a)). > > My intention was not to add more syntax overhead, but to reduce it by > generalizing existing functionality. *shrug*. $ is not reducible to : - xref. above. Consider also that $ is useful for other forms that could usefully get only one argument, but that argument usually is a complex thingy. Such as: call/cc $ lambda (return) blah ... return(42) blah ... delay $ let \\ ! x $ whatever blah ... delay-force $ cond stream-null?(whatever) $ blah ... else $ blah ... So I don't see : displacing $. You can't say: call/cc : lambda (return) blah .. return(42) blah ... Because it parses to: (call/cc (lambda (return)) (blah ... return(42) blah...)) To use it as a "$" replacement, you need to indent a *lot*. $ allows reducing both horizontal and vertical space simultaneously; : requires trading off one for the other. Either: call/cc : lambda (return) blah ... return(42) blah ... or: call/cc lambda (return) blah ... return(42) blah ... Collecting list's primary raison d'etres is for Scheme R6RS library / R7RS define-library, and is overloaded to give double brackets for let. I don't see : displacing <* *> either, at least in the define-library department. GROUP/SPLIT has a "SPLIT" behavior that is not addressed by :. So it seems that : can do many of the things that SUBLIST GROUP/SPLIT and COLLECTINGLIST can do, but each has a domain that : cannot access. > > There is required stuff: double brackets and continuing the parameter list. > Let’s see how many of the general usecases we can fit by just using the > solutions to those. They must be there anyway, so generalizing them does not > have a (high) cost. It might actually make the code easier to understand > (and that way reduce the cost for the syntax), because the symbols then > always have a fixed meaning. You forgot the define-library thing. > > Additionally there is syntactic sugar which optimizes some rough edges. That > isn’t required and adds overhead for those who want to learn the language. > So I think it should be kept at a minimum: Keep in mind that every > additional syntax-element has a price, so its benefit has to be higher than > that price to merit an addition. Okay. > > Best wishes, > Arne > -- > A man in the streets faces a knife. > Two policemen are there it once. They raise a sign: > > “Illegal Scene! Noone may watch this!” > > The man gets robbed and stabbed and bleeds to death. > The police had to hold the sign. > > …Welcome to Europe, citizen. Censorship is beautiful. > > ( http://draketo.de/stichwort/censorship ) > > > ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss