On Mar 16, 6:39 pm, Elena <egarr...@gmail.com> wrote:
> On 16 Mar, 22:55, Meikel Brandmeyer <m...@kotka.de> wrote:
>
> > My remark was pointed at the fact, that before it was
> > claimed, that the one way doesn't work in Clojure and
> > one has to go the other. And then the same person
> > goes on to contradict him(or her?)self. But be it...
>
> > To say something more constructive for the discussion:
> > here Rich's original answer on the matter:
>
> >http://groups.google.com/group/clojure/browse_frm/thread/c3418875208d...
>
> I bet it's me the "him(or her?)self" :-)
>
> I had already read Rich's opinion, after searching about old threads
> about the subject. I think he made a very reasonable decision, but he
> was talking about production code. What we are discussing here is the
> usefulness of such constraints when just playing at the REPL, a very
> different environment. Among the many answers, a (IMHO) reasonable
> solution has been proposed, which I repeat here:
>
> - the REPL could allow for an option to just warn about missing
> definitions;
> - when loading/compiling a file, Clojure could parse all definitions
> before complaining about missing ones.
>
> It seems that such a solution would offer both maximum flexibility
> when prototyping and maximum sanity checking when finalizing the code.
> What do you think?
I remain opposed, and here are some more reasons:
when you say
(def foo [x]
(bar x 42))
you are as likely to be referring to a forgot-to-require bar-lib as
you are to a to-be-defined bar.
The compiler can only default the latter, by interning bar in the
current namespace. There is no notion of compiling with a placeholder,
the name must be resolved to something. Should you really intend the
former, you end up with a mess, as you add (:require bar-lib) to your
ns call only to have it fail with a conflict - bar already defined in
your-ns.
Then you have to ns-unmap bar and retry. This is a big pain and one
you encounter all the time in Common Lisp, where the reader has auto-
interning characteristics similar to what is being discussed here.
Anything based on a unit-of-compilation concept has real problems for
Clojure, which generally treats a program as a stream of expressions.
Looking ahead is not an option, especially at the repl and other
streaming scenarios.
The biggest reason is - I'm not having the problems you are
describing, and neither are other experienced Clojure developers -
many of whom use the repl a lot.
Early on, I considered this a theoretical argument, but might have
been persuaded to reconsider if it kept coming up, but it didn't, and
doesn't.
(declare x y z foo bar baz ...)
is such a simple way to delay some decisions and sketch, I do not
consider it a serious impediment.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
