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

INDENT var1 value2 EOL

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.


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.

--- David A. Wheeler

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Readable-discuss mailing list

Reply via email to