On 7/19/12, Kartik Agaram <a...@akkartik.com> wrote: >> define-syntax list-of >> syntax-rules (is in) >> ; base case >> \ >> . list-of x >> . \ list x >> ; handle (var in x) clause >> \ >> . list-of x >> . var in expr >> . clauses \ ... >> . \ concatenate >> . . map >> . . lambda (var) >> . . list-of x >> . . clauses \ ... >> . . expr >> ; handle (var is x) clause >> \ >> . list-of x >> . var is expr >> . clauses \ ... >> . \ let ((var expr)) >> . . list-of x >> . . clauses \ ... >> ; handle (pred? x) clause >> \ >> . list-of x >> . pred?(args ...) >> . clauses \ ... >> . \ if pred?(args ...) >> . . list-of x >> . . clauses \ ... >> . . '() > > As a first experiment, let's see if I can easily recreate what this > translates to: > > (define-syntax list-of > (syntax-rules (is in) > ((list-of x) > (list x)) > ((list-of x (var in expr) clauses ...) > (concatenate (map (lambda (var) (list-of x clauses ...)) > expr))) > ((list-of x (var is expr) clauses ...) > (let ((var expr)) > (list-of x clauses ...))) > ((list-of x (pred? args ...) (clauses ...)) > (if (pred? args ...) > (list-of x (clauses ...)) > '())))) > > Observations: > > a) If this is right, why do we need the period-backslash construct, say in > the base case? Wouldn't just indentation (two periods) suffice?
\ . list-of x . \ list x ===> ( (list-of x) (list x)) ------- \ . list-of x . . list x ===> ( (list-of x list x)) > > b) Should we really have to insert a backslash in empty lines? Wart just > applies the enter-enter rule at the repl, not in batch mode. Did y'all > consider that? The use case is when you edit some file, but aren't 100% sure of the correctness of your edits. So you copy-paste the file's contents into the REPL. If the REPL supports ENTER-ENTER but the file has empty lines, you're going to have to insert backslashes or empty comment lines to your file anyway. So using the same rule in the file and in the REPL gives this advantage. > > c) Are the periods for indentation optional? It's confusing/distracting to > mix spaces with periods in the same code. Yes. I find it easier for telling me whether I'm looking at syntax-rules pattern code or generated code -> one "." is pattern code, 2 "." is generated code . It's useful in really long cond expressions: align a "." at the condition's indentation, so that adding a new clause somewhere is easy - just press space until your cursor reaches the "." > > d) I notice that avoiding parens is *much* more compact. It lets me see the > global structure at a glance. Let me see if I can reconstruct that property > by bringing back some parens: > > define-syntax list-of > syntax-rules (is in) > \ list-of x > list x Incorrect. This yields: \ list-of x list x ( list-of x list x) This is a consequence of only wanting one symbol for GROUP and SPLICE. Here's a more parenthes-y version that is correct: define-syntax list-of syntax-rules (is in) (list-of x) list x (list-of x (var in expr) clauses ...) ...blah blah blah... > \ list-of x (var in expr) clauses ... > concatenate > map (lambda (var) (list-of x clauses ...)) > expr > \ list-of x (var is expr) clauses ... > let ((var expr)) > list-of x clauses ... > \ list-of x pred?(args ...) (clauses ...) > if pred?(args ...) > list-of x (clauses ...) > '() > > Ok, I see why you need GROUP support :) It's because common lisp and scheme > use more parens than arc. I also found myself missing arc's syntax for > compose, so that I could say: > > concatenate:map (lambda (var) (list-of x clauses ...)) > expr > > Is this translation correct? I'm not sure which proposal this maps to. Is > it subsumed by one of the suggestions? Your proposal looks more like GRIT, which despite its name is a combination of what I call ENLIST and SPLIT. --- disgression on GROUP and ENLIST The problem lies in the original SRFI-49 from which we got I-expressions. It said "The GROUP symbol is used to allow lists whose first element is also a list" David Wheeler (and no doubt many others) thought it meant "The GROUP symbol is used to FORCE a list to have the first element be a list". So they assumed that: group a b c d was the same as: group a b c d But it wasn't. You see, group ALLOWS the first element to be a list. It doesn't FORCE the first element to be a list. So: group a b c d ===> ( a b c d) But people were expecting: ( (a b) (c d)) I renamed this "more intuitive" interpretation of group as "ENLIST" to prevent confusion with the original GROUP meaning (i.e. GROUP-as-in-SRFI-49, which doesn't force listing). I called it ENLIST because it forcibly conscripts the rest of the line as a sublist. Dwheeler persists in calling the GROUP-with-intuitive-behavior as GROUP, while I prefer to use the term ENLIST, and that's why he called GRIT = GROUP + SPLIT, when properly it should be ENLIST + SPLIT. I also pointed out that ENLIST is more problematic to spec. In particular, it seems that it should introduce multiple indentation levels. Please think about it more - there's a reason why I prefer SPLIT to ENLIST. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Readable-discuss mailing list Readablefirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/readable-discuss