On Sat, 2009-09-05 at 13:53 -0500, Eduardo Cavazos wrote:
> I wrote:
>
> >> The macro:
> >>
> >> (define-syntax &&
> >> (syntax-rules ()
> >> ( (&& (f ...) (x ...))
> >> (lambda (x ...)
> >> (and (f x ...)
> >> ...)) )
> >> ( (&& (f ...))
> >> (&& (f ...) (x)) )))
> >>
> >> Just curious, what do y'all use for this sort of thing?
>
> Derick Eddington wrote:
>
> > lambda or my `and?' higher-order procedure.
>
> Looking for 'and?' in xitomatl ... found it. Yep, it's similar.
>
> > I find syntax like this
> > confusing, because I have to learn the syntax for no syntactic benefit
> > (IMO) over lambda (but the same could be said of my `and?', which I've
> > barely used, I mostly made it for fun).
>
> I use things like '&&' or your 'and?' with procedures like 'every',
> 'any', 'find', etc. For example:
>
> (every (&& (number? odd?)) '(1 3 5))
>
> as opposed to:
>
> (every (lambda (x) (and (number? x) (odd? x))) '(1 3 5))
>
> of course, there's something to be said for factoring out 'odd-number?'
> :-) But this is just an example.
>
> Alot of stuff that comes from my corner is experimental. Lately I've
> been doing alot of "FP" style stuff and so '&&' is right at home there.
>
> Your 'and?' is (sensibly) single-arity which is the common case. I made
> '&&' useful with other arities. E.g.:
>
> (&& (f g h) (x y))
My and? could be made any-arity, and then it would be like your && but
without the need for the extra formals clause.
((and? f g h) x y)
But then it would be using a "rest" arg and apply, which you don't like.
An issue with yours and mine is that all the predicates must have the
same arity. Ours cannot do something like
(lambda (x y) (and (foo? x y) (bar? x) (zab? y)))
> The trouble is, this mucks up the common case with those extra
> parenthesis! It would be nice to just say:
>
> (&& number? odd?)
>
> Just yesterday, you cited a note from Clinger [1] where he listed a few
> principles of language design. Seems like '&&' goes against #1:
>
> Thou shalt not hair up the common case just to
> simplify unusual cases.
The problem is, everybody has different ideas about what's "hair up",
"common", "simplify", and "unusual" ... And then when your own change
back and forth, it's even more conflicting ... :)
> There are a few ways out of this. One is, leave '&&' for the common case
> of single arity and have a separate macro that does the general thing.
> The other is to design '&&' so that it supports both elegantly. But, I'm
> not sure such a design exists. For example, here's a naive version which
> works in some cases:
> [...]
> But breaks down sometimes:
> [...]
> But this version still isn't "correct" for all cases
Hehehehe. Designing general-purpose syntax can be challenging like
that. Facing this, and realizing other people might want to understand
my code, made me appreciate just using the basics more. But of course
macros absolutely rule for many things. I guess it's a balance between
what it takes to make a syntax general and how easy it is to become
familiar with and how bad it is when just using the basics.
> PS: Going back to your comment about confusing syntax, I wonder how
> you'd feel about the J programming language! ;-) Or K, Q, etc...
>From the Wikipedia for J:
quicksort=: (($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?...@#)) ^: (1<#)
I hate it :)
K looks like line noise too. Q is not line noise, but anything not Lisp
is nowadays ugly to me.
--
: Derick
----------------------------------------------------------------
