On 8/24/12, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> 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.
,op is (unquote op) is (unquote . (op . ())) Unless I'm mistaken, (op
. ()) is not eqv? to another (op . ())
Adding a non-standard function we have to define ourselves to the
specifications of curly-infix looks bad to me.
Since equal? could mount a DoS, maybe we shouldn't support anything
other than stuff that can be trivially compared eq?
>
> 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?
Me, now that I brought it up. LOL.
Sufficiently modern Scheme hardly uses quasiquotation anymore anyway;
even quasisyntax unsyntaxing #,op is rare, as most sufficiently modern
macros are done using syntax-rules, and only rarely using syntax-case.
So maybe it's not such a big deal.... in Scheme.
It's different for CL though, as it is impossible to usefully add
pattern-matching macros to the standard without serious reanimation of
the dead and similar necromancy. Random small Lisplikes are also much
more likely to use quasiquotation in macros rather than
pattern-matching.
>
> 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.
Sincerely,
AmkG
------------------------------------------------------------------------------
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
