BTW the subject is misleading, shouldn't we be discussing this on
Beni's proposal thread?

On Sun, Feb 24, 2013 at 4:55 AM, Alan Manuel Gloria <almkg...@gmail.com> wrote:
> On Sun, Feb 24, 2013 at 12:17 AM, David A. Wheeler
> <dwhee...@dwheeler.com> wrote:
>> As I posted earlier, I'm *really* uncomfortable with losing the ability to 
>> auto-check the grammar.  But I do understand the notion that extending 
>> SUBLIST, especially to handle "let" and similar constructs, could be useful.
>>
>> Beni Cherniavsky-Paskin:
>>>[I'm asking this because if it's 'fixed, my
>>>closing-SUBLIST-by-unmatched-dedent would allow:
>>>let $
>>>! ! x $ compute 'x
>>>! ! y $ compute 'y
>>>! body...
>>
>> I have a counter-proposal, maybe I can call it "Beni-Lite" :-) ???   And I 
>> even have a sample implementation that we can try out.
>>
>> I've just posted to the "devel" branch a change to the ANTLR implementation 
>> that permits closing SUBLIST by an unmatched DEDENT, but *only* if the "$" 
>> is the last item on a line (and there's something before "$" other than 
>> indent chars).  This limited semantic ("Beni-lite"?) covers the primary use 
>> cases I've seen, *AND* I've found a way to formulate it so that we can 
>> continue to use ANTLR's grammar checking and run-time input checking.
>>
>> To do this, I've tweaked the indent processor.  After you dedent, if the 
>> dedent doesn't match the parent indent, it then generates a RE_INDENT. This 
>> retains a whole lot of error-checking, both of the BNF and of the input 
>> during processing.  This means that:
>> let $
>> ! ! var1 value1
>> ! body...
>>
>> becomes:
>> let SUBLIST EOL
>> INDENT var1 value2 EOL
>> DEDENT RE_INDENT body...
>>
>>
>>
>> It includes a few test cases, which show how it works:
>>
>> let $
>> ! ! var1 value1
>> ! body...
>> ; ==> (let ((var1 value1)) body...)
>>
>> let $
>> ! ! var1 value1
>> ! ! var2 value2
>> ! body...
>> ; ==> (let ((var1 value1) (var2 value2)) body...)
>>
>> let $
>> ! ! var1 value1
>> ! ! var2 value2
>> ! ! var3 value3
>> ! body1 param1
>> ! body2 param2
>> ; ==>
>> ; (let ((var1 value1) (var2 value2) (var3 value3))
>> ;        (body1 param1) (body2 param2))
>>
>>
>>
>> Even this backed-off version is complicated, but it's not MUCH more 
>> complicated, and it does retain all the error-checking that I'm very loathe 
>> to drop.  It only works when "$" is at the end of the line... but that seems 
>> like a reasonable limitation.
>>
>> Comments?
>>
>> I *especially* want to hear from Beni Cherniavsky-Paskin and Alan Manuel 
>> Gloria, since both have expressed an interest in this kind of capability, 
>> but I certainly want to hear from all.  I want to make this final notation a 
>> good balance between "simple" and "capable"... I worry that even this subset 
>> may be a step too far.
>>
>
> I think that, conceptually, having a limitation is an additional
> complication when teaching the notation.
>
> When explaining the Beni formulation we can say "A $ indicates a
> further indent, with the promise that either you will have a
> 'staggered dedent' like FIGURE X, or that you will close the sublist
> with a dedent to a 'real' indentation level on this line or a parent
> line of this line."
>
> Granted we could just mandate these patterns, but I worry that we are
> now slipping into the "notation is tied to underlying semantic" bug.
> Or in this case, "notation is tied to underlying legacy syntax".
>
> I'd rather have the full Beni formulation of SUBLIST or the classic
> 0.4 formulation, in that preference order.
>
> 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.
>
> --
>
> Beni-full formulation, informally:
>
> The SUBLIST or "$" marker indicates that the text following it on that
> line will be indented by one more "virtual" indentation level than the
> current line.  The direct child lines of this line will then be
> considered child lines of only the text after the last SUBLIST marker,
> and the text after the SUBLIST marker will be considered a child of
> the text before the SUBLIST marker.  You can also chain SUBLIST
> markers, like so:
>
> probe $ call/cc $ lambda (exit)
> ! exit 42
> ==>
> probe
> ! call/cc
> ! ! lambda (exit)
> ! ! ! exit 42
>
> In addition, the SUBLIST marker allows a "staggered dedent", like so:
>
> foo $ a b
> ! ! c
> ! d
>
> In this case, the "a b" text has as its child the directly succeeding
> child line of its line, while the line with "staggered" dedent will be
> the next sibling of the "a b" text.  So the above is equivalent to:
>
> foo
> ! a b
> ! ! c
> ! d
>
> In general, the "staggered dedent" capability of SUBLIST is not used;
> you are more likely to just close it directly:
>
> foo $ a b
> ! c
> d
> ===>
> foo
> ! a b
> ! ! c
> d
>
> However, the staggered dedent is useful for LET:
>
> let $
> ! ! var
> ! !   value
> ! ! var2
> ! !   value2
> ! body
> ! ...

------------------------------------------------------------------------------
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

Reply via email to