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
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
