Re: Clojure's syntax design: macros vs functions
FWIW: I have thought the same thing in the past. But, in practice, this has never been a problem for me. Not once. Now I haven't written quadrillions of lines of Lisp, but it doesn't seem to have been a problem for those who have either. One thing to keep in mind is that you don't typically have tons of macros nebulously floating around all over the place. When you first learn about macros, they seem so cool and so powerful, and it seems like you will be writing as many macros as functions. But it turns out that a little goes a long way with macros. You just don't end up writing all that many. It's not really hard to keep track of which names are macros. "With functions, code is WYSIWYG". Well. Maybe. You still can't magically know what a function does just by looking at an application of it. Sure, its name and the context help, but if you're uncertain about a function you're going to have to look at the documentation or whatever anyway. It's not really any different with macros in the mix, ultimately. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure's syntax design: macros vs functions
(Warning: long post) Thank you all for the answers, especially to Konrad who suggested thinking in terms of forms instead of functions and macros. He's right that I'm a newcomer and maybe I've rushed a bit by calling it a flaw. I'll try thinking about it more. As I started to learn Lisp, the syntax's utter simplicity amazed me. I read that a lot of programmers dismiss Lisp because of parenthesis: I love Lisp because of them ;-) BTW, I started noticing that my capability to understand Lisp code was somewhat hampered by having to know beforehand when a form was a function call and when it was a macro. Of course this was orders of magnitude less than the plethora of quirks which I learned to stuff into my head when I was eye-parsing a chunk of C++ code (and Perl, which I used for scripting), but still... I started asking myself if that was just a beginning decision which nobody questioned about afterwards. I agree when Konrad writes: " Remember that Lisp has been around for 50 years and has been used by some of the most talented programmers on this planet. If Lisp programmers had discovered a need to distinguish visually between macros and functions, some Lisp dialect would already have introduced such a feature." BTW, I thought that sometimes smart people are too smart for their own good. Maybe those programmers were so smart that they could easily cope with some added complexity without being bothered. I remember Paul Graham writing something like macros do add complexity - you are adding new syntax to the language - but *in practice* that has showed not to be an issue (I hope not having misquoted him). "Not to be an issue" for a smart programmer as him, I'd like to add. I'll try to further explain my view. I stress again that I'm a skilled C/C++ programmers so my opinion relies upon my past (bad) experiences with C macros (which I agree are far behind Lisp's ones). Maybe I'll be able to show my point better with a few C examples. Consider this call: f (p, *p); were "p" is a pointer. If p is null then: - if f is a function then the program would crash, and if I can't trace a previous check on p's value then the program is obviously wrong; - if f is a macro then the program maybe right: I have to check f's definition. Thus, if I manage to distinguish a function and a macro call by sight, for instance by reserving all capitals for macros alone as I do, then I can spot such bugs without having to reach for documentation. For instance: int p = NULL; f (p, *p); // BUG! F (p, *p); // Bug? This examples are not about pointers and redundant pointer dereferencing. They are about spotting WYSIWYG code. With functions, code is WYSIWYG (you can say a lot just by looking at it); with macros and syntax forms that's not the case since the code you are seeing is going to be "massaged" into something else. That's my opinion. And you don't have to resort to unsightly naming conventions to differentiate between macros and functions in a new Lisp dialect. Let's say that parenthesis will be for functions whilst brackets will be for macros and syntax forms. For instance we can rewrite the example by Konrad like this: [if [and (odd? n) (> n 0)] n (inc n)] And a new (silly) one: (a b c [d e f g] h i) Can you spot the macro? Anyway, I've survived and become proficient with C/C++ and (less) with Perl. I can cope with having same syntax for both macros and functions ;-) I just wish to convince myself that indeed the current state of affairs is good. Thanks for your attention. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure's syntax design: macros vs functions
On 5 Mar, 02:22, Matt Revelle wrote: > Was their a situation where not knowing if a form was a macro bit > you? Considering that many frequently used built-ins > are implemented as macros, capitalizing or otherwise annotating-in- > name would be annoying. No. What bothers me is not being able to tell if a form gets evaluated just by looking at the source. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure's syntax design: macros vs functions
> expressions get evaluated and which don't, at least when you are dealing with side effects. I think that this is the key point. The Clojure syntax is built around its pure-functional core. Side effects are dangerous, and the rule there is "mutator beware." Joshua --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure's syntax design: macros vs functions
On 05.03.2009, at 02:03, Elena wrote: > I wonder if Clojure does employ the same syntax either for macros and > functions by design or it's just a remainder of Lisp. I think that a I am sure it's by design, just as for Lisp. Remember that Lisp has been around for 50 years and has been used by some of the most talented programmers on this planet. If Lisp programmers had discovered a need to distinguish visually between macros and functions, some Lisp dialect would already have introduced such a feature. > shared syntax for both macros and functions calls is a flaw in the > syntax of Lisps, because you can't tell, just by looking at a form, For how long have you been using Lisp? I don't want to sound condescending, but this sounds like a typical newcomer's remark. If something bothers you after a year of intensive use, you can call it a flaw, and even then I'd carefully add "in my experience". > Someone says that when you are reading code you are expected to know > the documentation of each form you encounter, but I don't agree. > Usually when I read code I rely heavily on good naming, so I don't > usually need to reach for the documentation. I agree as well. There is a small core set of names for which brevity and convenience outweigh readability, and which everyone should know. Beyond that, the names should hint at their meaning. Let's look at an example: (if (and (odd? n) (> n 0)) n (inc n)) To me, all these names are clear, though inc may not be obvious immediately (but it's a frequently used function). It happens that "if" is a special form, "and" is a macro, and "odd?" and "inc" are functions, as is ">". But this is not the most relevant information about these names, what matters most, to a human reader, is their meaning. Suppose this were written as (IF (And (odd? n) (> n 0)) n (inc n)) to make special forms and macros stand out. Is this better? Not to my eyes. It emphasizes something about "if" that I don't really need to know. "If" could very well be implemented as a macro, in terms of "cond", for example. Some Lisps make that choice, Clojure makes the inverse one, implementing "cond" as a macro in terms of "if". So what? "And" is a more interesting case. To the casual reader, its meaning is pretty clear. But if the details matter... Sometimes it is important to know that "and" evaluates only as many of its arguments as it needs to reach a conclusion. In other words, it stops at the first "false" value and returns false. And that feature alone mandates an implementation as a macro or a special form, a function can't do that. But the important thing I need to know is not that "and" is a macro, it's that it evaluates as few of its arguments as it can, from left to right. Making a syntactic distinction between functions and macros would highlight implementation details and turn attention away from what really matters: the meaning of a form. > Since I'm a C/C++ programmer, my convention is that macros and only > macros are all uppercase, so I can easily spot them and be aware that > they behave differently. C and Lisp are very different languages. Macros are more powerful and more fundamental in Lisp. A lot of the names you use in a Lisp program are actually macros that expand into a small number of primitive functions and special forms. Konrad. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure's syntax design: macros vs functions
Hi Elena, I thinks the Lisp convention says something about how to think about Lisp programs. Well-written macros shouldn't require you to think about the fact that they are macros. Instead of thinking about functions calls vs. macro calls, try to think of "forms". A form can be a function call (+ x y), a macro (and x y), or a special form (if x y z). The choice of function/macro is really just an implementation detail. What matters is what the form does, and what it returns. -Stuart Sierra On Mar 4, 8:03 pm, Elena wrote: > I wonder if Clojure does employ the same syntax either for macros and > functions by design or it's just a remainder of Lisp. I think that a > shared syntax for both macros and functions calls is a flaw in the > syntax of Lisps, because you can't tell, just by looking at a form, > which expressions get evaluated and which don't, at least when you are > dealing with side effects. > > Someone says that when you are reading code you are expected to know > the documentation of each form you encounter, but I don't agree. > Usually when I read code I rely heavily on good naming, so I don't > usually need to reach for the documentation. > > Since I'm a C/C++ programmer, my convention is that macros and only > macros are all uppercase, so I can easily spot them and be aware that > they behave differently. > > What do you think? > Thanks --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure's syntax design: macros vs functions
>I think that a > shared syntax for both macros and functions calls is a flaw in the > syntax of Lisps, because you can't tell, just by looking at a form, > which expressions get evaluated and which don't, at least when you are > dealing with side effects. You might want to think about macros such as 'or' and 'and', which only evaluate as many arguments as needed. A naming or case convention wouldn't help you to know what gets evaluated in these macros. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure's syntax design: macros vs functions
On Mar 4, 2009, at 8:03 PM, Elena wrote: > > I wonder if Clojure does employ the same syntax either for macros and > functions by design or it's just a remainder of Lisp. I think that a > shared syntax for both macros and functions calls is a flaw in the > syntax of Lisps, because you can't tell, just by looking at a form, > which expressions get evaluated and which don't, at least when you are > dealing with side effects. > > Someone says that when you are reading code you are expected to know > the documentation of each form you encounter, but I don't agree. > Usually when I read code I rely heavily on good naming, so I don't > usually need to reach for the documentation. > > Since I'm a C/C++ programmer, my convention is that macros and only > macros are all uppercase, so I can easily spot them and be aware that > they behave differently. > > What do you think? > Thanks Was their a situation where not knowing if a form was a macro bit you? Considering that many frequently used built-ins are implemented as macros, capitalizing or otherwise annotating-in- name would be annoying. > > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Clojure's syntax design: macros vs functions
I wonder if Clojure does employ the same syntax either for macros and functions by design or it's just a remainder of Lisp. I think that a shared syntax for both macros and functions calls is a flaw in the syntax of Lisps, because you can't tell, just by looking at a form, which expressions get evaluated and which don't, at least when you are dealing with side effects. Someone says that when you are reading code you are expected to know the documentation of each form you encounter, but I don't agree. Usually when I read code I rely heavily on good naming, so I don't usually need to reach for the documentation. Since I'm a C/C++ programmer, my convention is that macros and only macros are all uppercase, so I can easily spot them and be aware that they behave differently. What do you think? Thanks --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
