How do you cope with type-hinted vars or macros? (ok #'declare does not
work for macros neither)
With autodef, one could have to either move the definition or add a
declare just to be able to add a type hint.
Christophe
Stephen C. Gilardi a écrit :
On Mar 16, 2009, at 6:59 PM, Elena
On Mar 17, 12:15 am, Stephen C. Gilardi squee...@mac.com wrote:
If *autodef-unresolved-symbols* is true, and if a has never been
mentioned before, this interaction with Clojure:
user= a
java.lang.Exception: Unable to resolve symbol: a in this context
would become:
On Mar 17, 10:46 am, Michael Wood esiot...@gmail.com wrote:
I understand why people want to be able to do things like this:
(defn b [] (a))
(defn a [] (...))
That's what I'm asking for.
But that's completely different from the above. The above is more like:
(a)
(defn a [] (...))
Why
On Mar 17, 2009, at 4:44 AM, Christophe Grand wrote:
How do you cope with type-hinted vars or macros? (ok #'declare does
not
work for macros neither)
With autodef, one could have to either move the definition or add a
declare just to be able to add a type hint.
The class of vars you're
On Tue, Mar 17, 2009 at 1:01 PM, Elena egarr...@gmail.com wrote:
On Mar 17, 10:46 am, Michael Wood esiot...@gmail.com wrote:
I understand why people want to be able to do things like this:
(defn b [] (a))
(defn a [] (...))
That's what I'm asking for.
But that's completely different from
On Mar 17, 2009, at 7:20 AM, Elena wrote:
I wanted to say that entering:
(defn a []
(b))
should issue a warning (and I don't think an exception is the right
way to warn the user).
The autodef I described would not warn, nor throw an exception in this
case.
I think warn on autodef
Hello Rich,
2009/3/17 Rich Hickey richhic...@gmail.com
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,
2009/3/17 Stephen C. Gilardi squee...@mac.com
On Mar 16, 2009, at 8:25 PM, Laurent PETIT wrote:
Hi Laurent,
Your solution is indeed close to what I had in mind in terms of
requirements. I was currently hacking with clojure java class Compiler to
enhance Timothy's patch and add a
On Mar 17, 2009, at 5:52 PM, Laurent PETIT wrote:
I give up on this one. I've now been half convinced that it's even
less an ideal solution than I expected at first, and I prefer use
the little free time I have to enhance clojuredev.
Sounds good. Thanks for closing the loop on this.
On 17 Mar, 13:23, Rich Hickey richhic...@gmail.com wrote:
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
And of course, if somebody agrees that is a worth proposal and could
provide some directions, I'm here ready to churn out some code.
Here in Italy we say Help yourself and God will help you along the
way ^_^
Did I mention I'm Italian? I bet you guessed it already since I talk
too much for sure.
Elena a écrit :
Hi,
in this code:
(defn main []
(check-services))
(defn check-services []
1)
if I call slime-eval-defun on main before calling it on check-
services, Clojure aborts with:
java.lang.Exception: Unable to resolve symbol: check-services in this
context
On 16.03.2009, at 11:35, Elena wrote:
in this code:
(defn main []
(check-services))
(defn check-services []
1)
if I call slime-eval-defun on main before calling it on check-
services, Clojure aborts with:
java.lang.Exception: Unable to resolve symbol: check-services in
On Mar 16, 10:40 am, Christophe Grand christo...@cgrand.net wrote:
Yes, it prevents typos to go unnoticed. You can write a forward
declaration :
(declare check-services); equivalent to (def check-services)
(defn main []
(check-services))
(defn check-services []
1)
On Mar 16, 10:43 am, Konrad Hinsen konrad.hin...@laposte.net wrote:
Yes. Clojure checks that symbols are defined before they are used.
You can put
(declare check-services)
before your definition of main to define the symbol and make it clear
to the (human) reader that you indeed to
Hi,
Am 16.03.2009 um 18:36 schrieb Elena:
IMHO, this is a no-no for interactive development. I understand that
it helps avoiding undefined symbols, but such code integrity checks
could be delayed to a final compilation stage. Having them earlier
forces you to develop code in a bottom-up way.
I agree. It doesn't matter what order the compiler reads the definitions: I
can scroll up and type.
It does effect humans reading the code, however. Often when looking at
unfamiliar Clojure code, I find myself scrolling to the bottom first.
On Mon, Mar 16, 2009 at 1:58 PM, Meikel Brandmeyer
On 16 Mar, 20:14, Jeffrey Straszheim straszheimjeff...@gmail.com
wrote:
It does effect humans reading the code, however. Often when looking at
unfamiliar Clojure code, I find myself scrolling to the bottom first.
That's exactly my point: why should I scroll to the bottom? That's not
the way
This has come up before. You can actually work around this (search the
mailing list for declare)
I think that when not hacking against the REPL that the default behavior is
a good one. Having to use declare bugged me a little at first, but I now
consider it a very minor annoyance compared to the
I also agree that I keep going first to the end of the file, searching the
real function to launch or to reuse when reading new clojure code ...
What I would be happy with is a way to have clojure not complain before the
end of a unit of compiled code.
For the REPL, that would be somewhat
I may be missing something, but how does having to (declare) vars fix typos?
I don't think anyone is suggesting *creating* a var that is referenced
before it is defined. What people are asking for is that the compiler
looks-ahead to verify that the var will eventually be defined, and then go
on
On Mon, Mar 16, 2009 at 4:08 PM, Paul Stadig p...@stadig.name wrote:
I may be missing something, but how does having to (declare) vars fix
typos? I don't think anyone is suggesting *creating* a var that is
referenced before it is defined. What people are asking for is that the
compiler
On 16 Mar, 20:45, David Nolen dnolen.li...@gmail.com wrote:
This has come up before. You can actually work around this (search the
mailing list for declare)
I've searched the mailing list and I've found also an explanation by
Rich Hickey (I apologize for not having done it in the first
On 16 Mar, 20:58, Laurent PETIT laurent.pe...@gmail.com wrote:
For files, that would be wait until the end of the file before complaining
for undefined symbols, and let me arrange the defs in any order I feel most
readable without having to think about placing those (declare) calls.
I second
André Thieme splendidl...@googlemail.com writes:
But it also protects you from typos. And this can be even more
important. Imagine you have a complex program and accidently
made a typo, and this will go unnoticed for days and days, until
the program actually runs your code...
If you go days
If you go days and days without actually running your code, then you
deserve what you get. A test suite would catch this for you every time;
developing without one is irresponsible.
geeze people, i'm tired of the tests are the answer to everything.
give it a break. not every test suite will
2009/3/16 Meikel Brandmeyer m...@kotka.de
Hi,
Am 16.03.2009 um 22:19 schrieb Elena:
On 16 Mar, 21:57, Laurent PETIT laurent.pe...@gmail.com wrote:
I agree that it's not difficult. But, at least in my own experience, it's
not the second step to cleaning up my programs.
I generally try
Hi,
Am 16.03.2009 um 22:44 schrieb Laurent PETIT:
In french, we have a sentence for that, that would translate
literally into eat the banana by both ends at the same time.
I don't think top-down and bottom-up programming are antogonists. I
often do both at the same time myself.
2009/3/16 Phil Hagelberg p...@hagelb.org
André Thieme splendidl...@googlemail.com writes:
But it also protects you from typos. And this can be even more
important. Imagine you have a complex program and accidently
made a typo, and this will go unnoticed for days and days, until
the
On 16 Mar, 22:31, André Thieme splendidl...@googlemail.com wrote:
The behaviour of Clojure can be seen as a disadvantage, yes, because
you either need these forward declarations, or you need to arrange
functions different.
But it also protects you from typos. And this can be even more
On 16 Mrz., 20:45, David Nolen dnolen.li...@gmail.com wrote:
Should the REPL have an interactive mode where it won't fire an exception
on undefined symbols and instead issue compiler warnings? If compiler
warnings were issued this would be a nice hook for Emacs and other IDEs.
Yes, I was
Just FYI,
The actual patch is in the files section:
http://groups.google.com/group/clojure/web/auto-def.patch
With an example:
http://groups.google.com/group/clojure/web/lit-wc.clj
From a longer thread about 'snake' which talked about literate
programming:
Laurent PETIT laurent.pe...@gmail.com writes:
OK, so now is time for another ugly english translation of a french
proverb before saying something, roll your tongue 8 times in your
mouth before speaking. I guess this could also be applied for e-mail
Agreed, it could have been worded better.
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
On 16 Mar, 23:26, Timothy Pratley timothyprat...@gmail.com wrote:
For fully compiled code the
'checkpoint' is clear - but Clojure is dynamic... what should happen
with this code:
(defn myfun []
(another-fun 5))
(myfun)
(defn another-fun [x]
(inc x))
In a compiled language that
Laurent PETIT laurent.pe...@gmail.com writes:
2009/3/16 Phil Hagelberg p...@hagelb.org
Laurent PETIT laurent.pe...@gmail.com writes:
But please, think about it twice before saying people are
irresponsible. Unit tests are not the only answer to bug-free and
quality
On 16 Mar, 23:47, Elena egarr...@gmail.com wrote:
On 16 Mar, 23:26, Timothy Pratley timothyprat...@gmail.com wrote:
what should happen
with this code:
(defn myfun []
(another-fun 5))
(myfun)
(defn another-fun [x]
(inc x))
In a compiled language that would be valid, but in
On Mar 16, 2009, at 6:59 PM, Elena wrote:
Furthermore, if I understand Rich's opinion in that regards, this
code:
(defn myfun []
(another-fun 5))
should be rejected if definition of another-fun is missing (but I'd
say: only in code to be released).
I don't mind the current behavior of
On 16 Mrz., 22:41, Phil Hagelberg p...@hagelb.org wrote:
André Thieme splendidl...@googlemail.com writes:
But it also protects you from typos. And this can be even more
important. Imagine you have a complex program and accidently
made a typo, and this will go unnoticed for days and days,
Hello,
Thanks for taking time thinking about this idea!
Your solution is indeed close to what I had in mind in terms of
requirements. I was currently hacking with clojure java class Compiler to
enhance Timothy's patch and add a variation on what you described.
My concern is that it should also
On Mar 16, 2009, at 8:25 PM, Laurent PETIT wrote:
Hi Laurent,
Your solution is indeed close to what I had in mind in terms of
requirements. I was currently hacking with clojure java class
Compiler to enhance Timothy's patch and add a variation on what you
described.
Cool. I look
Hello again,
2009/3/17 Stephen C. Gilardi squee...@mac.com
On Mar 16, 2009, at 8:25 PM, Laurent PETIT wrote:
Hi Laurent,
Your solution is indeed close to what I had in mind in terms of
requirements. I was currently hacking with clojure java class Compiler to
enhance Timothy's patch and
On Mar 16, 2009, at 9:06 PM, Laurent PETIT wrote:
The real one was : how to correctly get the thread bound value, and
change the thread bound value of a Var instance, from within java
code ?
You can set the thread-bound value with set (defined in Var.java).
You get the thread-bound
2009/3/17 Stephen C. Gilardi squee...@mac.com
On Mar 16, 2009, at 9:06 PM, Laurent PETIT wrote:
The real one was : how to correctly get the thread bound value, and change
the thread bound value of a Var instance, from within java code ?
You can set the thread-bound value with set
44 matches
Mail list logo
