Alan Manuel Gloria:
> Consider the following syntax:
> {x ,op y}
>
> The "simple" curly-infix rules require that the even parameter be a
> *symbol*. So the above syntax becomes (nfx x ,op y).
>
> But a user might consider {<x> <y> <z>} to be (<y> <x> <z>),
> regardless of what our specs says, simply because every '{<x> <y> <z>}
> he or she reasonably tries turns into '(<y> <x> <z>).
>
> Thus, the user *might* reasonably expect {x ,op y} to be (,op x y)
Hmm. I intentionally didn't go there, but that doesn't mean I was *right*. I
had presumed that if you wanted a more complex operation, you'd switch to
prefix notation. But I hadn't thought about ,op... which is actually plausible.
> This approach gets problems though.
>
> 1. Is this "special" case reserved only for 3-element lists (i.e. we
> have a "binary" curly-infix notation where {x y z} is (y x z) for all
> y)? Then the case, when extended {x ,op y ,op z} suddenly becomes
> (nfx x ,op y ,op z)
If we do this at all, we should *NOT* limit it to 3-element cases. It'd be
confusing, and there's no reason to limit it.
> 2. Is this special case an extension for "simple" curly-infix
> notation, where we drop the "symbol" requirement and compare with....
> what? equal? Then it seems to invite abuse of the form {x (lambda (x
> y) (+ x y)) y (lambda (x y) (+ x y)) z}
Yes, I think "equal?" is the only reasonable equality test. Neither "eq?" nor
"eqv?" will do what you want if you want to allow ",op".
I don't think we have to worry about abuse. Any general construct can be
abused. I do worry about error detection - it's nice to automatically detect
errors when you can. But it's not clear that allowing ,op as an operator is an
error.
> Hmm....
>
> Maybe this is just an edge case we're better off not wasting our time with....
Maybe. I had thought about lambda, etc., and couldn't imagine anyone wanting
to do that. But ",op" is actually reasonable.
One problem I see is that "equal?" can fail to terminate if its arguments are
circular data structures. If a user provides data structures to a reader that
are circular data structures, and then invokes a 5+ parameter curly-infix list,
they can cause the reader to hang when reading data (not just programs).
That's a potential denial-of-service attack that is not very nice.. programs
use read() for data, not just for programs. R7RS is even creating ways for
users to provide circular data structures to the reader (!).
Other than that, it's more general, it makes the spec slightly simpler (we
don't have to check for the symbol), it's trivial to do in the implementation,
and it won't really matter performance-wise. It's a crazy idea that seems less
crazy on a second glance.
How about another equality operator? Let's call it it "eqop?". For non-pairs,
it's eqv?. We then decide what it means for pairs; the easy one is that their
car and cdr must be eqv?. That won't let you do lambda, but it'll allow ,op.
We could even allow for some bound (say, 4 levels deep) if that's not enough.
I'm game. It doesn't prevent anything we already do, and it allows some
generalizations that make sense. It also allows some crazy things, but it
would be the developer who did the crazy things :-).
Anyone screaming in horror?
Let's wait a day or two to discuss this through. If we're going to do this at
all, I'd like to put them in both the curly-infix SRFI and for version 0.5.
--- David A. Wheeler
------------------------------------------------------------------------------
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
