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.
Arne Babenhauserheide: > > 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 completely agree, both are needed. I'll gladly cede that it's unlikely that any notation would please *everyone*, but that is a goal worth striving for. So let's look at the pros and cons of this idea, and if there are bad cons, if it's fixable or if pieces are ripe for stealing :-). > I think in this case, the > single-item case tends to occur more often than the > single-item-function-call case. Agree. Many Scheme procedures involve recursing down structures to eventually return some leaf or base cases, so single-items occur quite a bit at the leaves... and we want common cases to be easy to notate. In general, the common cases should be optimized and the hard cases possible. ... > 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. > > 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: This semantic assumes there's something called a "column width" that you can measure for different characters, and that would be exactly the same for all systems. That once existed with fixed-width ASCII-only terminals, but increasingly that is simply not true. Alan mentioned CJK characters; there are also variable-width characters, varying fonts, and unsupported glyphs. Variable-width characters in particular bring this problem into sharp relief, even with ASCII. I think a notation that presumes that different character sequences have some equivalent "width" is broken. You can distinguish "beginning of line" from "not beginning of line", and after that, there's really nothing you can depend on. > >> ":" 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)? ... > >> 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. This semantic for ":" makes lots more sense to me, since this avoids making the (false) assumption that we know anything about the widths of different character sequences. Let me call the older semantics magic-column-position semantics (because somehow you can magically figure out what a 'current' position is). Let me calls this newer semantic "line-ending" semantics, because the effect of ":" would end at the end of the line. > >> 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: Agree, you can't use ":" to substitute for "$" or <*...*>. Especially if it just has the "insert ( here, and ) at the end of line" semantics. I do grant that I can see use cases for ":" defined with this limited semantic, and it's obviously easy to describe by itself. However, like Arne, I'm also concerned about adding ANOTHER syntactic construct. Especially because now you have to clearly explain how they work together (precedence returns!!). But for intellectual argument, let's continue the discussion; it may turn out to be worthwhile, or suggest something worthwhile. And if not, at least we can say we looked under that rock too :-). > 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 ... Yes, and as Alan's examples show, these would be completely impractical (even if you accept "I can figure out what a column position is", which I think is a false premise). The "$" is powerful specifically because it collects child lines. > 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. Right. I don't see ":" (with either magic-column-position semantics or line-ending semantics) as replacing it. It appears that even if we added ":", we would have to KEEP the other operators. Which means that ":" would have to have sufficient utility to add it in ADDITION to the rest (!), possibly with some big reshuffling. Separately, the idea of using leading "." as some sort of "join-lines" is not insane. Early on I had "\\" at the end of a line be a continuation marker, which is similar (without adding a new reserved marker). I don't know if there are enough use cases, but there might be. However, I do worry that it'd be confusing; that was a concern with the previous continuation marker too. Consider this: aa bb cc ! dd ee ! . ff gg My understanding is that, under this proposal, this would map to: (aa bb cc (dd ee) ff gg) but I suspect many humans would interpret this as: (aa bb cc (dd ee ff gg)) Basically, I fear that a marker that meant "continue" at the beginning of the line might be interpreted by a human to mean something different than intended, because there can be different lines that could be conceptually "continued". Especially if there was a long multi-line span between them. Perhaps you'd just grow used to this... but I'm a little skeptical. I don't know of any other language that does this, for example; Fortran had a "C" continuation marker, but that always continued the PREVIOUS line not the PARENT line. > 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. ... > > 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. Oh absolutely, I've always believed that. The challenges, of course, is what "minimum" means. Clearly "too much" and "too little" are possible, but there's a gray area between. --- David A. Wheeler ------------------------------------------------------------------------------ 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
