On 2/25/13, David A. Wheeler <dwhee...@dwheeler.com> wrote: > Beni Cherniavsky-Paskin: >> Here is yet another idea for opening multiple levels on one line, that >> does >> NOT involve column counting, only comparison of leading whitespaces. >> >> It's a backward-compatible extension to SUBLIST (similarly applicable to >> any competing FOOLIST semantics), so we could leave it undecided for now, >> and legalize it later. >> >> $ lets one open an inner list on one line, but currently it's only usable >> when this list is the last element of the containing list: >> >> outer1 outer2 $ inner1 >> ! inner2 >> >> You cannot express (outer1 outer2 (inner1 inner2) outer3) >> without giving up on use of $. >> >> The proposal is to allow an unmatched dedent after inner2, and have that >> return you to the outer level: > ... > > > Note: I earlier replied with a variant idea with subject > "$ at end of line bug?", but Alan Manuel Gloria > noted, "shouldn't we be discussing this on > Beni's proposal thread?" so I'll continue on THIS thread instead. > Sorry for the confusion... > > > As noted earlier, this is an interesting proposal, but > I have a variety of concerns with it. > > > Alan Manuel Gloria: >> I think that, conceptually, having a limitation is an additional >> complication when teaching the notation. > ... >> I'd rather have the full Beni formulation of SUBLIST or the classic >> 0.4 formulation, in that preference order. > > Okay. > > If that's so, and no one else speaks up, perhaps we should > just continue to use the classic formulation. I'm fine with that; > we know that works well, and I think it's well-specified.
Awww..... (^.^)v Since you're unwilling to put the full Beni formulation in *right now*, then let's use classic formulation. I hope somebody else speaks up for the full Beni formulation and gives a fully interesting example *real soon now* (^_^) > > We could ensure that nothing we do now *forbids* later > extending it this way, and document this as a potential future extension. > That would keep our options open. Sound reasonable? > Per the email quote above, Beni Cherniavsky-Paskin was fine with > not specifying at this time as long as we didn't close the door to it, > and this would be consistent with it. I volunteer to write up the Beni formulation for the SRFI-sweet document - unless Beni wants to write it up himself. > > Should we allow "$" at the end without partial dedents (creating an extra > ()), > or should we just drop that too? I don't see a use for it, but I see no harm in specifying it that way. Note that: $ foo ==> ((foo)) which is both non-obvious and not something I see as *useful*. So raising an error is fine with me too. Sincerely, AmkG ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
