Re: [Readable-discuss] Proposal: allow closing SUBLIST by dedenting
I said: Once it's removed from the BNF, I think we need to make sure that the Scheme specifically checks for it and forbids it. That way, people won't accidentally use such constructs for now, and that'll make it easier to add later if indeed it's added later. Alan Manuel Gloria: I propose making it an explicit error in the BNF rather than just making it an invalid sequence by implication of its absence. Okay, I'll do that. --- David A. Wheeler -- 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
Re: [Readable-discuss] Proposal: allow closing SUBLIST by dedenting
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. 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. Should we allow $ at the end without partial dedents (creating an extra ()), or should we just drop that too? I'll admit that I don't have a use for the full Beni formulation other than for let, though. I suspect there may be further use cases; but I haven't found any others yet. That's my point, too. Indent-and-dedent generally works just fine, so this complicated approach doesn't seem justified enough. The current approach even works nicely for let, it just requires two short lines: let ! \\ ! ! var1 value1 ! body... --- David A. Wheeler -- 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
Re: [Readable-discuss] Proposal: allow closing SUBLIST by dedenting
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
Re: [Readable-discuss] Proposal: allow closing SUBLIST by dedenting
Alan Manuel Gloria: 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* (^_^) Absolutely! Thanks for being willing to do this. This particular formulation is definitely interesting, I think documenting it is important. And please make it clear that this is an upward-compatible extension that could be added later, without interfering with any existing sweet-expressions. I volunteer to write up the Beni formulation for the SRFI-sweet document - unless Beni wants to write it up himself. That'd be great. Please feel free to document my $-at-end attempt at a compromise. If you don't want to do that, I'll add it. 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. Okay. John Cowan made the same point too. Looks like we'll drop that, at least for this edition. Once it's removed from the BNF, I think we need to make sure that the Scheme specifically checks for it and forbids it. That way, people won't accidentally use such constructs for now, and that'll make it easier to add later if indeed it's added later. --- David A. Wheeler -- 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
Re: [Readable-discuss] Proposal: allow closing SUBLIST by dedenting
On 2/25/13, David A. Wheeler dwhee...@dwheeler.com wrote: Alan Manuel Gloria: 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* (^_^) Absolutely! Thanks for being willing to do this. This particular formulation is definitely interesting, I think documenting it is important. And please make it clear that this is an upward-compatible extension that could be added later, without interfering with any existing sweet-expressions. I volunteer to write up the Beni formulation for the SRFI-sweet document - unless Beni wants to write it up himself. That'd be great. Please feel free to document my $-at-end attempt at a compromise. If you don't want to do that, I'll add it. Yeah, although I'll wait a few days to see if Beni wants to write it himself first. 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. Okay. John Cowan made the same point too. Looks like we'll drop that, at least for this edition. Once it's removed from the BNF, I think we need to make sure that the Scheme specifically checks for it and forbids it. That way, people won't accidentally use such constructs for now, and that'll make it easier to add later if indeed it's added later. I propose making it an explicit error in the BNF rather than just making it an invalid sequence by implication of its absence. 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
Re: [Readable-discuss] Proposal: allow closing SUBLIST by dedenting
On 2/19/13, Beni Cherniavsky-Paskin c...@users.sf.net wrote: 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: outer1 outer2 $ inner1 ! ! inner2 ! outer3 which would be equivallent to: outer1 outer2 ! inner1 ! ! inner2 ! outer3 More formally (described for simplicity in terms of numeric indentation levels; easily doable in terms of exact substrings): - Every $ pushes a ? placeholder onto the stack of known indent levels. - As before, increases in indentation push a specific number onto the stack. - Dedents matching a level on the stack are handled as before, closing all levels to the right, whether specific or placeholders. - A dedent that doesn't match any specific level is *only* allowed if there is at least one placeholder between the closest specific levels. All higher levels are closed, and the *rightmost* (see rationate at end) of these placeholders is converted to the specific level seen. Let's say you had (10 ? ? 16) on the stack and you encounter a line starting with 14 spaces. This closes 16 and the new stack is (10 ? 14). A following 13 line would close 14 and leave (10 13), and then a following 12 line would be an error. I think it's also important to consider the SAME (as opposed to INDENT or DEDENT) token. In particular: x ! foo $ bar ! a b == (x (foo bar) (a b) ) Since the INDENT/SAME/DEDENT decision is based on the indentation stack, I think we should specify it as follows: 1. Every $ adds a ? to the indentation stack, and emits an INDENT. 2. On encountering an EOL, slurp the indentation. 3. If the indentation is greater than the topmost non-? stack entry, push its indentation level on the stack and consider it an INDENT. 4. If the indentation is equal to the topmost non-? stack entry, pop off ? stack entries (emitting a DEDENT for each). If there are no ? on the stack top, emit a SAME. 5. If the indentation is less than the topmost non-? stack entry, pop off ? stack entries (emitting a DEDENT for each) until you reach a state where the topmost non-? stack entry is less than or equal to the indentation. 5.1. If the topmost non-? stack entry is equal to the indentation, pop off ? stack entries (emitting a DEDENT for each). 5.2. if the topmost non-? stack entry is less than the indentation, and there is at least one ? entry, pop off the topmost ? entry and replace it with the current indentation (do not emit any INDENT or DEDENT tokens). 5.2. Otherwise, error! So, let's consider this classic SUBLIST text: probe $ call/cc $ lambda (exit) $ cond foo? $ exit 1 bar? $ 2 == probe INDENT call/cc INDENT lambda (exit) INDENT cond ; at this stage, stack is (0 ? ? ?) INDENT foo? INDENT exit 1 ; at this stage, stack is (0 ? ? ? 2 ?) ; it sees an indent of 2, so it emits a DEDENT here ; via rule #4. DEDENT bar? INDENT 2 ; at this stage, stack is (0 ? ? ? 2 ?) ; an empty line may be considered an indent of 0, ; so insert 5 DEDENT's DEDENT DEDENT DEDENT DEDENT DEDENT == probe ! call/cc ! ! lambda (exit) ! ! ! cond ! ! ! ! foo? ! ! ! ! ! exit 1 ; 5 indent's so far, so 5 levels, seems right ! ! ! ! bar? ! ! ! ! ! 2 ; 5 dedents after this, so we close!! -- Looks about right. Now the main reason to implement SUBLIST this way is, of course, the bane of indentation syntax, LET: let !!$ x $ compute 'x y $ compute 'y !!use x y == let ; the first indent below is the real indent INDENT INDENT INDENT x INDENT compute 'x ; at this point, stack is (0 2 ? ?) ; again, first indent below is real indent INDENT y INDENT compute 'y ; at this point, stack is (0 2 ? ? 4 ?) ; since we get back to an indent of 2, ; emit 2 DEDENT's to get past the 4, ; then (via rule 5.1) pop off all ? to ; reach the 2 (which involves popping ; off 4 indents). DEDENT DEDENT DEDENT DEDENT use x y ; again, empty line, pop off the single dedent DEDENT == let !\\ !!\\ !!!x compute 'x !y !!compute 'y . well, bummer, doesn't work. Oh well. Sincerely, AmkG A common objection to any scheme allowing unmatched dedents is that it requires lookahead, both for machine parsing *and humans*. When you read: foo ! ! bar ... pages of stuff ! ! baz ! quux it's very disconcerting to realize that all this bar...baz stuff was not a direct child of foo but was nested within a
Re: [Readable-discuss] Proposal: allow closing SUBLIST by dedenting
let !!$ x !!compute 'x y !!compute 'y !!use x y == let INDENT INDENT x ; stack: (0 2 ?) INDENT compute 'x ; stack: (0 2 ? 6) DEDENT ; stack: (0 2 ?), indentation = 4 y ; stack: (0 2 4) INDENT compute 'y ; stack (0 2 4 6) DEDENT DEDENT ; stack (0 2) use x y DEDENT == let !\\ !!x !!!compute 'x !!y !!!compute 'y !use x y --- Hmmm. let !!$ x (compute 'x) y (compute 'y) !!use x y === let INDENT INDENT x (compute 'x) ; stack: (0 2 ?) INDENT y (compute 'y) ; stack: (0 2 ? 4) - bummer DEDENT DEDENT ; stack: (0 2) use x y DEDENT let !\\ !!x (compute 'x) !!!y (compute 'y) !use x y bummer On 2/19/13, Alan Manuel Gloria almkg...@gmail.com wrote: On 2/19/13, Beni Cherniavsky-Paskin c...@users.sf.net wrote: 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: outer1 outer2 $ inner1 ! ! inner2 ! outer3 which would be equivallent to: outer1 outer2 ! inner1 ! ! inner2 ! outer3 More formally (described for simplicity in terms of numeric indentation levels; easily doable in terms of exact substrings): - Every $ pushes a ? placeholder onto the stack of known indent levels. - As before, increases in indentation push a specific number onto the stack. - Dedents matching a level on the stack are handled as before, closing all levels to the right, whether specific or placeholders. - A dedent that doesn't match any specific level is *only* allowed if there is at least one placeholder between the closest specific levels. All higher levels are closed, and the *rightmost* (see rationate at end) of these placeholders is converted to the specific level seen. Let's say you had (10 ? ? 16) on the stack and you encounter a line starting with 14 spaces. This closes 16 and the new stack is (10 ? 14). A following 13 line would close 14 and leave (10 13), and then a following 12 line would be an error. I think it's also important to consider the SAME (as opposed to INDENT or DEDENT) token. In particular: x ! foo $ bar ! a b == (x (foo bar) (a b) ) Since the INDENT/SAME/DEDENT decision is based on the indentation stack, I think we should specify it as follows: 1. Every $ adds a ? to the indentation stack, and emits an INDENT. 2. On encountering an EOL, slurp the indentation. 3. If the indentation is greater than the topmost non-? stack entry, push its indentation level on the stack and consider it an INDENT. 4. If the indentation is equal to the topmost non-? stack entry, pop off ? stack entries (emitting a DEDENT for each). If there are no ? on the stack top, emit a SAME. 5. If the indentation is less than the topmost non-? stack entry, pop off ? stack entries (emitting a DEDENT for each) until you reach a state where the topmost non-? stack entry is less than or equal to the indentation. 5.1. If the topmost non-? stack entry is equal to the indentation, pop off ? stack entries (emitting a DEDENT for each). 5.2. if the topmost non-? stack entry is less than the indentation, and there is at least one ? entry, pop off the topmost ? entry and replace it with the current indentation (do not emit any INDENT or DEDENT tokens). 5.2. Otherwise, error! So, let's consider this classic SUBLIST text: probe $ call/cc $ lambda (exit) $ cond foo? $ exit 1 bar? $ 2 == probe INDENT call/cc INDENT lambda (exit) INDENT cond ; at this stage, stack is (0 ? ? ?) INDENT foo? INDENT exit 1 ; at this stage, stack is (0 ? ? ? 2 ?) ; it sees an indent of 2, so it emits a DEDENT here ; via rule #4. DEDENT bar? INDENT 2 ; at this stage, stack is (0 ? ? ? 2 ?) ; an empty line may be considered an indent of 0, ; so insert 5 DEDENT's DEDENT DEDENT DEDENT DEDENT DEDENT == probe ! call/cc ! ! lambda (exit) ! ! ! cond ! ! ! ! foo? ! ! ! ! ! exit 1 ; 5 indent's so far, so 5 levels, seems right ! ! ! ! bar? ! ! ! ! ! 2 ; 5 dedents after this, so we close!! -- Looks about right. Now the main reason to implement SUBLIST this way is, of course, the bane of indentation syntax, LET: let !!$ x $ compute 'x y $ compute 'y !!use x y == let ; the first indent below is the real indent INDENT INDENT INDENT x INDENT compute 'x ; at this point, stack is (0 2 ? ?) ; again, first indent below is real indent INDENT y
Re: [Readable-discuss] Proposal: allow closing SUBLIST by dedenting
Okay, okay, currently: let $ x $ compute 'x use x == (let ((x (compute 'x)) (use x)) So, let's try the new formulation: let !!$ x $ compute 'x !!use x == let INDENT INDENT x INDENT compute 'x ; stack: (0 2 ? ?) DEDENT DEDENT ; stack: (0 2), indentation = 2 use x DEDENT === let !\\ !!x !!!compute 'x !use x So it works right even in the degenerate case. But it doesn't *extend* the way it might be naively expected, as seen in the previous posts: let $ x $ compute 'x y $ compute 'y use x y == let !\\ !!x !!!compute 'x y !compute 'y !use x y --- Hmm. I wonder if, however, using a similar approach for ENLIST rather than SUBLIST would work??? 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
[Readable-discuss] Proposal: allow closing SUBLIST by dedenting
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: outer1 outer2 $ inner1 ! ! inner2 ! outer3 which would be equivallent to: outer1 outer2 ! inner1 ! ! inner2 ! outer3 More formally (described for simplicity in terms of numeric indentation levels; easily doable in terms of exact substrings): - Every $ pushes a ? placeholder onto the stack of known indent levels. - As before, increases in indentation push a specific number onto the stack. - Dedents matching a level on the stack are handled as before, closing all levels to the right, whether specific or placeholders. - A dedent that doesn't match any specific level is *only* allowed if there is at least one placeholder between the closest specific levels. All higher levels are closed, and the *rightmost* (see rationate at end) of these placeholders is converted to the specific level seen. Let's say you had (10 ? ? 16) on the stack and you encounter a line starting with 14 spaces. This closes 16 and the new stack is (10 ? 14). A following 13 line would close 14 and leave (10 13), and then a following 12 line would be an error. A common objection to any scheme allowing unmatched dedents is that it requires lookahead, both for machine parsing *and humans*. When you read: foo ! ! bar ... pages of stuff ! ! baz ! quux it's very disconcerting to realize that all this bar...baz stuff was not a direct child of foo but was nested within a ...quux construct! But in our case, $ already declares that we opened an inner construct, so I think it won't be surprising to humans. What about multiple $ ambiguity? Given: A1 $ B1 $ C1 !! C2 ! B2 why does the dedent return you to the inner B level and not the outer A level? It's the only sane choice, for several reasons: - Continuity with current usage, which I expect will remain the dominant use of $: without unmatched dedents you only have access to innermost C level, so the accessible level should be the next innermost. - It's the only way (without magic lookahead) that allows you to access all levels, if desired. - It's similar to the standard resolution of if A1 if B1 if C1 else C2 else B2. -- 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
Re: [Readable-discuss] Proposal: allow closing SUBLIST by dedenting
On Feb 18, 2013 10:11 PM, David A. Wheeler dwhee...@dwheeler.com wrote: Beni Cherniavsky-Paskin: A common objection to any scheme allowing unmatched dedents is that it requires lookahead, both for machine parsing *and humans*. When you read: ... But in our case, $ already declares that we opened an inner construct, so I think it won't be surprising to humans. Points for cleverness, at least! But I think the required human look-ahead for this idea is a terrible cost. Having to possibly scan a lot of future lines to understand the local meaning is, I think, a net *loss* to readability. I'm skeptical that it wouldn't be surprising to humans, but even so, the human still has to do the lookahead with such a construct. When I'm programming or debugging I already have enough to keep track of! I agree that requiring humans to look ahead would be terrible. I'm only proposing this since as I see it it does NOT happen here. The $ opened the list anyway; the only thing you don't expect up-front is that this list can be closed without immediately closing the surrounding list. The same is also true with s-expressions - encountering the dedent is equivallent to encountering a ). You cannot express (outer1 outer2 (inner1 inner2) outer3) without giving up on use of $. True, but there are non-$ forms that are pretty easy to use and read with the current notation, such as: outer1 outer2 ! inner1 inner2 ! outer3 Indeed. I forgot to mention that I don't have a justification why we need it. I felt it's a natural extension, but it's not a must. -- 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
