On 7/12/12, David A. Wheeler <dwhee...@dwheeler.com> wrote: > Alan Manuel Gloria: >> All right all right, let's use this thread to discuss GROUP, SPLICE, >> SPLIT, and ENLIST. > > Agree. > > By the way, thanks very much for creating this summary on the mailing list + > the info on the Wiki. Nicely done + very helpful. > > ... >> 1. NO to GROUP and SPLICE >> >> 2. YES to SPLIT, and use \ for it, and ignore other language's habit >> of using it to mean "continue to next line" >> >> 3. YES to ENLIST, and use ~ for it, and really start to crystallize >> what exactly is meant with ~ in various contexts. > >> Cons to my position: >> >> 1. Both SPLIT-by-itself and ENLIST-by-itself, followed by a line that >> is more indented, mean exactly the same thing. This is arguably Not a >> Good Thing, as there is now more than one way to express something, >> neither being a truly "preferred" way. > ... >> 3. Using "\" for SPLIT is not compatible with most other language's >> usage, especially when it occurs at end-of-line. > > 4. Using up two punctuation symbols. They're in short supply. > > 5. The "\" meaning is incompatible with its meaning in CL, and many other > Lisps (including many Scheme implementations) also use this interpretation. > > We could implement both SPLIT and ENLIST, but I don't think that we really > need the SPLIT char to work at the beginning of a line (after indent), and > ENLIST could easily be limited to only apply at the beginning of a line > (after indent). > > So here's another variant semantic that combines GROUP and SPLIT, let's call > it "GRIT" :-). > > GRIT: - a proposed combination of GROUP and SPLIT, where a single SYMBOL is > used. Semantics: > 1. If SYMBOL is at the beginning of the line (after indent), and nothing > else on the line (other than maybe space/tab/;-comment), then it creates a > list without header using all children lines, like GROUP. > 2. If SYMBOL is anywhere after the first datum on a line, it works like > SPLIT. (What if it's the last one?)
Uhm. What you call GRIT *is* SPLIT. SPLIT is the combination of GROUP and SPLICE, where a single SYMBOL is used for both, and removing the SYMBOL-at-eol rule from SPLICE (so that the only possible interpretation for SYMBOL-at-eol is the same as SYMBOL-inline - it ends the previous expression and starts a new one at the same ident). So: let . SPLIT . . x y . result ==> (let ( (x y)) result) See example/streams.scm in my latest bundle for usage of SPLIT as a replacement for GROUP. GRIT ***is*** SPLIT, down to the unresolved question of "What if it's the last one?". As to the end-of-line thing: One way of viewing this would be to think of things such that SPLIT means "end the current expression at the current indentation level", and that indentation figures out WHERE to put the SPLIT's. This means that: foo bar quux nitz kuu is equivalent to foo bar quux \ nitz kuu \ \ is equivalent to (foo (bar quux) ; <-- ended at this point (nitz kuu) ; <-- ended at this point ) ; <--- ended at this point Or something. This is Haskell's view of indentation processing: it figures out where to put the ";" that ends expressions. > > If something else follows on the line I'm not sure what it should be. It'd > be good to focus on how to cleanly handle stuff like "let" since that seems > to be a common case. It could be like ENLIST - force an extra list. Or, it > could force a list in certain situations. Ideas? We want to support something like this in Arc: if . pred(f) . \ let x f(g) . . . something(x) . . . something-else(y) . pred2 . . f . . g . \ with . . . \ . . . . x \ g(f) . . . . y \ something-something g f . . . something-something(y) . . . something-something(x) . ; else . \ do . . . remove-all foo x bar . . . convoke meow cat Also remember that the same problem occurs with :keyword arguments, so we need to support something much like this even if we decide that only PG uses Arc anyway: ; CL some-keyword-func . :pred . \ let ((x f(g))) . . . something(x) . . . something-else(y) . :pred2 . \ let . . . \ . . . . x g(f) . . . . y something-something g f . . . something-something(y) . . . something-something(x) . :else . \ begin . . . remove-all foo x bar . . . convoke meow cat So: if something follows SPLIT on the same line, where SPLIT is at the start of a line, then SPLIT **must** be ignored/removed from the input stream, except for its effect on defining where the indentation is - i.e. the current GROUP semantics. Hence: SPLIT = GROUP + SPLICE = GRIT. > > The obvious question is what "SYMBOL" should be. I'm wondering if ~ would > be a better choice than \, since \ has a meaning in so many places. Either way will do. Note that we have a significant tension between CL keywords and CL/Scheme's let (and arguably the rest of Lisp). So I think we should consider he use of a *different* symbol to support keyword-pairing and another symbol for list-pairing: (foo ; juxtaposition is enough :key value :key2 value2) (let ( ; explicit list grouping is required (key value) (key2 value2) ) ... ) In both cases, we want to show that "value" is "under" "key", so we want to indent it more - but this fails for :keywords, because further indentation causes it to be wrapped into a list rather than being juxtaposed, as they are expected to act like. Hence my continued position: SPLIT (to support :keyword-style juxtaposition pairings) and ENLIST (to support (k v)-style explicit pairings), using two different symbols. You can drop ENLIST, maybe, because SPLIT-by-itself can do part of its work, at the cost of adding one vertical line, but ENLIST can't do SPLIT's work, which is to juxtapose an "indented" line (i.e. to cancel an indentation). Sincerely, AmkG ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
