Yes, to be exactly, the simple change in the reader is after parsing a
symbol, if the following char separating the symbol is '(', the symbol
become the leading item of the following list, otherwise it is a
regular item in the current list context.Louis On Dec 27, 4:16 pm, Softaddicts <lprefonta...@softaddicts.ca> wrote: > So if I understand correctly, your proposal makes the absence/presence of > space pivotal > in making the decision about parsing infix/postfix notation ? > > Luc > > > > > > > > > > > Luc, > > I see you and other people put great points on this subject, that is > > exactly what I wanted to know about the 'dark corner' in my initial > > post. > > Just for your info, I have tried on the modified reader, the following > > alternatives all works: > > > Clojure 1.4.0-master-SNAPSHOT > > user=> (map first [[1] [2]]) > > (1 2) > > user=> map(first [[1] [2]]) > > (1 2) > > user=> (defmacro mymac [func] > > (let [args (rest func)] > > `(- ~@args))) > > #'user/mymac > > user=> (mymac (+ 1 2 3)) > > -4 > > user=> mymac((+ 1 2 3)) > > -4 > > user=> mymac(+(1 2 3)) > > -4 > > > Thanks, > > Louis > > > On Dec 27, 1:40 pm, Luc Prefontaine <lprefonta...@softaddicts.ca> > > wrote: > > > Louis, obviously there's a problem here, the REPL should return > > > > user=> (map first [[1] [2]]) > > > (1 2) > > > > As for my point about macros, it's not about the calls, it's about macro > > > processing before > > > spitting out the code that will be compiled, what would this return ? > > > > user=> (defmacro mymac [func] > > > (let [args (rest func)] > > > `(- ~@args))) > > > #'user/mymac > > > > Presently: > > > > user=> (mymac (+ 1 2 3)) > > > -4 > > > > What about (mymac + (1 2 3)) ? Would + (1 2 3) be considered as one > > > argument ? Why ? How the compiler achieve this grouping ? > > > If the macro argument involves a list ([&body] being a common example) > > > how do you decide what is a real > > > list versus a call using your new syntax in the variable list of > > > arguments ? > > > > If you cannot deal with this and have to force (mymac (+ 1 2 3)) when a > > > macro is involved then what's the use > > > of this new syntax ? > > > > What about embedded calls involving a mix of fns and macros ? > > > I cannot see people having to dig to find out if some of these calls are > > > macros versus fns and change the shape according to > > > what is being called. > > > > You missed the point that I made about the fact that code is data and can > > > be modified accordingly either through macros > > > or runtime evaluations. > > > > Luc > > > > On Wed, 28 Dec 2011 01:59:12 +0800 > > > > Ambrose Bonnaire-Sergeant <abonnaireserge...@gmail.com> wrote: > > > > On Wed, Dec 28, 2011 at 1:46 AM, Louis Yu Lu <louisy...@gmail.com> > > > > wrote: > > > > > > The proposed syntax sugar does not break the existing code > > > > > clojure.core=> map(first [[1] [2]]) > > > > #<core$map clojure.core$map@5ec3d2> > > > > [1] > > > > > Ambrose > > > > -- > > > Luc P. > > > > ================ > > > The rabid Muppet > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en > > -- > Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
