On Dec 30, 2007 11:08 AM, David Wheeler <[EMAIL PROTECTED]> wrote:
> Alan Manuel K. Gloria: What do you think about using "<-" instead of "="
> everywhere for assignment? It's confusing that "=" doesn't map to "=".
Oh, I quite agree with that. I'm just very lazy. Besides, all it
takes is a one-line change somewhere in the definfix defs. On the
copy on your website it's line 402, just change = to <-. You can also
change = back to the Lisp = by adding:
(definfix = :precedence 60)
By the way my nfx macro has a bug regarding mixing of associativity,
e.g. nested assigning array access:
(nfx a @ b <- c @ d <- 42)
Has to do with the fact that a <- b <- c should be (setf a (setf b c))
but a @ b @ c should be (aref (aref a b) c) and I'm just using some
flag somewhere to handle the associativity. Again, being very lazy.
I think the nfx macro needs a rewrite, really, to use more formal
methods of parsing the input stream of symbols.
On Dec 31, 2007 8:18 AM, Egil Möller <[EMAIL PROTECTED]> wrote:
>
> I was thinking about the {}-infix notation and implementation, and realized
> a rather sad side-effect - the actual parse-tree, what is fed to eval, does
> not resemble the input any longer, as it does for all other syntax sugar
> (quoting and so on).
>
> My suggestion is to simplify the reader-macro, so that it only rewrites {1
> * 2 + 4 * {5 + 6}} into (nfx 1 * 2 + 4 (nfx 5 + 6)) and do the rest with an
> ordinary macro, nfx. I guess that that would also be easier to extend, and
> generally to work with. Also, it would be easy to add a printing hook that
> rewrites anything (nfx ...) into {...}, just like it works for quotes.
This is generally the main reason why I kept suggesting adding a tag
for all infix, and why I kept suggesting that infix should not be
default. David's main concern is that other macros will see the 'nfx
macro:
(defmacro my-macro ....)
my-macro {juan + juan}
=> my-macro ends up seeing (nfx juan + juan) instead of (+ juan juan)
>
> One way to handle operator precedence would be to call a special function
> for each pair of used operators:
>
> {1 * 2 + 4 * {5 + 6}}
>
> (precedence_*_+ 1 2 4) -> *
> (precedence_+_* 2 4 11) -> *
>
> (note the parameters, to be able to use the types to differentiate
> operators, don't know if that is really needed thou...)
I don't quite understand this, is this an implementation detail or
will this be embedded into the input list?
Sincerely,
AmkG