(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
-~----------~----~----~----~------~----~------~--~---
