Re: bug in clojure.zip when calling next on empty list node?
On Sun, Dec 22, 2013 at 12:26 PM, Lee Spector lspec...@hampshire.eduwrote: The issue I was rasing is that, when traversing '(() 0) with zip/next, one should first visit the root, then (), and then 0. But what actually happens is that between then () and the 0 one lands on a non-existent nil node. So one ends up visiting 4 nodes when there are only 3, and the extra one is a nil. As I mentioned previously this leads to null pointer exceptions in my application, and the only ways around it that I see are recoding everything without zippers or some nasty special case hackery. Point of order: I'm somewhat dubious of the contention that wrapping the output of the traversal in (filter identity ...) before passing it to whatever's throwing the NPEs quite qualifies as nasty special case hackery. :) -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap
The two classes have essentially the same semantics, but performance
differences, which is why Clojure sometimes uses one and sometimes the
other. If you want to enforce that a map is returned, enforce that the
return is a subtype of java.util.Map rather than checking for a specific
concrete class of map.
On Sun, Dec 22, 2013 at 3:07 PM, larry google groups
lawrencecloj...@gmail.com wrote:
Hmm, I see. get-distinct was returning an empty lazyseq, which apparently
made the difference.
On Sunday, December 22, 2013 2:56:01 PM UTC-5, larry google groups wrote:
Hmm, the different return types seem tied to the 2 different functions
being called, but both functions have the same return type, which is a
lazyseq. I am using Monger to get data from MongoDb. These functions are
private:
(defn- get-distinct [request]
{:pre [(= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/get-distinct (:item-type request)))
(defn- paginate-results [request]
{:pre [ (= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/paginate-results (:item-type request) (if (:which-page request)
(:which-page request)
0)))
Both of these functions return lazyseqs, as expected. The results from
both get run through a (reduce) function that does some minor filtering.
Yet in one case the return type (from the reduce function) is
clojure.lang.PersistentArrayMap
and in the other it is clojure.lang.PersistentHashMap. I'd like to be
able to write a :post condition that enforces strictness, but that seems
impossible because I can not figure out what the rule is that handles the
conversion. I don't care if the return type is
clojure.lang.PersistentArrayMap
or clojure.lang.PersistentHashMap, all I want is it for it be
consistently one or the other.
On Sunday, December 22, 2013 2:31:45 PM UTC-5, larry google groups wrote:
I am surprised that a map literal is clojure.lang.PersistentArrayMap
but as soon as I assign it to a var, it becomes
clojure.lang.PersistentHashMap.
Are there any rules for being able to predict when these conversions occur?
user (type {})
clojure.lang.PersistentArrayMap
user (type {:what why?})
clojure.lang.PersistentArrayMap
user (def curious {:what why?})
#'user/curious
user (type curious)
clojure.lang.PersistentHashMap
user (def sug (assoc curious :whodoneit mikey))
#'user/sug
user (type sug)
clojure.lang.PersistentHashMap
I am curious because I wrote a (reduce) function which mostly just
builds a map:
(assoc map-of-data (:item-name next-item) next-item))
Since I was using assoc I was certain I would get
clojure.lang.PersistentHashMap
back, but instead I got clojure.lang.PersistentArrayMap.
--
--
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
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
Just a link to the Gilad Bracha post Richard Cole is referring to: Types Are Anti-Modularhttp://gbracha.blogspot.it/2011/06/types-are-anti-modular.html . Il giorno lunedì 23 dicembre 2013 02:24:08 UTC+1, Richard Cole ha scritto: The things is that dynamically typed languages are easier to implement than statically typed languages. Static typing comes down to making statements about the program and deriving other statements from them. It leads to all sorts of interesting work including I think into systems like Z. However theorem provers are limited in what they can do, and it can be both limiting and a big distraction to you as programmer to get into a dialogue with the theorem prover about your program. It can distract you from your original intention which was to write a program to do something in particular. So simply put, dynamic languages are better than static ones because they don't distract you with type discussions that can end up being unprofitable or limiting. Static languages are better because sometimes the type discussions lead to early and convenient detection of bugs and can also in some cases make it easier for other people to understand you program or how to use your library. Static types I think also help refactoring tools. Having optional typing in clojure is very nice. It allows for a lot of experimentation and research on type systems and for them to be used to the extent that people find them useful in their work. It is why I guess Alan Kay said that lisp is not a language, it's a building material. If you want to know what are the current problems in static typing you going to have to start learning what people are doing in that field, e.g. is their foreign function interface from Haskel to Java? Why not? Can a well typed program still exhibit bugs? If the type checking is so powerful why do bugs persist? You might also look at what Gilhad Brakka was attempting to do with newspeak and his notions of types being anti-modular. You are not going to find a proof that that line of enquirely is fruitless, you'll instead find what people can do today in that field and where they're pushing the bounds. regards, Richard. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
This ties in nicely to my summary of how I feel about static typing: Static typing is a premature optimisation. Like most optimisations, it has genuine value, but if you apply it globally and too early, you end up causing more pain than you gain. sometime type discussions lead to lead to early and convenient detection of bugs - I'd agree with this; but in my experience, most of the bugs caught by type systems are relatively simple and straightforward, and not the sort of bugs that make it into production. I've almost never seen a _serious_ bug caused by dynamic typing - and I've seen plenty of serious bugs that type systems would not have caught. Static types also help with rapid IDE/compiler feedback of errors - but you often pay for this with slow compilation, especially when you need global type inferencing; and with complex (and often buggy) IDEs/compilers. I had huge pain getting the Scala IDEs to work reliably, last time I worked in Scala (admittedly this was a few years ago) - and they are still having lots of pain with performance, even though Scala doesn't have global type inference. Statically typed code generally performs better - but if there's one major rule I've learned in 25 years in IT, it's that code performance is not your real problem, 99% of the time. Your real problem is more likely to be IO, or poor algorithm design, or inefficient scalability, or slow speed of development, or difficulty diagnosing bugs, or unreadable unmaintainable code. I had people telling me that C++ was too slow, I should stick to C. Then, that Java was too slow, I should stick to C++. Then, that Ruby/JavaScript was too slow, I should stick to Java. None of these people were right. These days, I'd generally optimise first for expressive code so it's fast to develop and maintain; then for powerful flexible languages that can do anything I need them to do, and last for raw performance. I'm quite attracted by optional static typing, because it means I can rapidly code in a flexible dynamic language, and if I get to the point where I really need types, I can add them. But I suspect that most of the time, I'll never get to that point - or I'll use something like Prismatic Schema to define constraints at my external interfaces only, which is where I generally find I need them. - Korny On 23 December 2013 12:24, Richard Cole richard.j.c...@gmail.com wrote: The things is that dynamically typed languages are easier to implement than statically typed languages. Static typing comes down to making statements about the program and deriving other statements from them. It leads to all sorts of interesting work including I think into systems like Z. However theorem provers are limited in what they can do, and it can be both limiting and a big distraction to you as programmer to get into a dialogue with the theorem prover about your program. It can distract you from your original intention which was to write a program to do something in particular. So simply put, dynamic languages are better than static ones because they don't distract you with type discussions that can end up being unprofitable or limiting. Static languages are better because sometimes the type discussions lead to early and convenient detection of bugs and can also in some cases make it easier for other people to understand you program or how to use your library. Static types I think also help refactoring tools. Having optional typing in clojure is very nice. It allows for a lot of experimentation and research on type systems and for them to be used to the extent that people find them useful in their work. It is why I guess Alan Kay said that lisp is not a language, it's a building material. If you want to know what are the current problems in static typing you going to have to start learning what people are doing in that field, e.g. is their foreign function interface from Haskel to Java? Why not? Can a well typed program still exhibit bugs? If the type checking is so powerful why do bugs persist? You might also look at what Gilhad Brakka was attempting to do with newspeak and his notions of types being anti-modular. You are not going to find a proof that that line of enquirely is fruitless, you'll instead find what people can do today in that field and where they're pushing the bounds. regards, Richard. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: How to go about 'proving' why dynamically typed languages are better.
Do you guys have any concrete examples? Sent from my iPhone On 23 Dec 2013, at 10:13, Korny Sietsma ko...@sietsma.com wrote: This ties in nicely to my summary of how I feel about static typing: Static typing is a premature optimisation. Like most optimisations, it has genuine value, but if you apply it globally and too early, you end up causing more pain than you gain. sometime type discussions lead to lead to early and convenient detection of bugs - I'd agree with this; but in my experience, most of the bugs caught by type systems are relatively simple and straightforward, and not the sort of bugs that make it into production. I've almost never seen a _serious_ bug caused by dynamic typing - and I've seen plenty of serious bugs that type systems would not have caught. Static types also help with rapid IDE/compiler feedback of errors - but you often pay for this with slow compilation, especially when you need global type inferencing; and with complex (and often buggy) IDEs/compilers. I had huge pain getting the Scala IDEs to work reliably, last time I worked in Scala (admittedly this was a few years ago) - and they are still having lots of pain with performance, even though Scala doesn't have global type inference. Statically typed code generally performs better - but if there's one major rule I've learned in 25 years in IT, it's that code performance is not your real problem, 99% of the time. Your real problem is more likely to be IO, or poor algorithm design, or inefficient scalability, or slow speed of development, or difficulty diagnosing bugs, or unreadable unmaintainable code. I had people telling me that C++ was too slow, I should stick to C. Then, that Java was too slow, I should stick to C++. Then, that Ruby/JavaScript was too slow, I should stick to Java. None of these people were right. These days, I'd generally optimise first for expressive code so it's fast to develop and maintain; then for powerful flexible languages that can do anything I need them to do, and last for raw performance. I'm quite attracted by optional static typing, because it means I can rapidly code in a flexible dynamic language, and if I get to the point where I really need types, I can add them. But I suspect that most of the time, I'll never get to that point - or I'll use something like Prismatic Schema to define constraints at my external interfaces only, which is where I generally find I need them. - Korny On 23 December 2013 12:24, Richard Cole richard.j.c...@gmail.com wrote: The things is that dynamically typed languages are easier to implement than statically typed languages. Static typing comes down to making statements about the program and deriving other statements from them. It leads to all sorts of interesting work including I think into systems like Z. However theorem provers are limited in what they can do, and it can be both limiting and a big distraction to you as programmer to get into a dialogue with the theorem prover about your program. It can distract you from your original intention which was to write a program to do something in particular. So simply put, dynamic languages are better than static ones because they don't distract you with type discussions that can end up being unprofitable or limiting. Static languages are better because sometimes the type discussions lead to early and convenient detection of bugs and can also in some cases make it easier for other people to understand you program or how to use your library. Static types I think also help refactoring tools. Having optional typing in clojure is very nice. It allows for a lot of experimentation and research on type systems and for them to be used to the extent that people find them useful in their work. It is why I guess Alan Kay said that lisp is not a language, it's a building material. If you want to know what are the current problems in static typing you going to have to start learning what people are doing in that field, e.g. is their foreign function interface from Haskel to Java? Why not? Can a well typed program still exhibit bugs? If the type checking is so powerful why do bugs persist? You might also look at what Gilhad Brakka was attempting to do with newspeak and his notions of types being anti-modular. You are not going to find a proof that that line of enquirely is fruitless, you'll instead find what people can do today in that field and where they're pushing the bounds. regards, Richard. -- -- 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
Re: How to go about 'proving' why dynamically typed languages are better.
I agree entirely with Korny's statements. As for concrete examples ? Hard to enumerate some, I can only say I agree after more than 30 years coding in various languages and finally getting out of Java hell. When I started there were a variety of dynamic languages used in the industry and given the kind of hardware we had at our disposal (more or less the power of today's cheap pocket calculator) the so-called Performance hit was rarely a problem. With the hardware available today, this is not a bigger issue than 25 years ago, except maybe for some highly specific problems. I saw enough typed language driven systems performing poorly to say that statically typed languages are not bullet proof performance wise. As for discovering significant errors, that's a false claim. So good a compiler may be, nothing can replace your brain. If the language and its related tools make your job so complex that your brain overloads then you are shooting yourself in the foot. Luc P. Do you guys have any concrete examples? Sent from my iPhone On 23 Dec 2013, at 10:13, Korny Sietsma ko...@sietsma.com wrote: This ties in nicely to my summary of how I feel about static typing: Static typing is a premature optimisation. Like most optimisations, it has genuine value, but if you apply it globally and too early, you end up causing more pain than you gain. sometime type discussions lead to lead to early and convenient detection of bugs - I'd agree with this; but in my experience, most of the bugs caught by type systems are relatively simple and straightforward, and not the sort of bugs that make it into production. I've almost never seen a _serious_ bug caused by dynamic typing - and I've seen plenty of serious bugs that type systems would not have caught. Static types also help with rapid IDE/compiler feedback of errors - but you often pay for this with slow compilation, especially when you need global type inferencing; and with complex (and often buggy) IDEs/compilers. I had huge pain getting the Scala IDEs to work reliably, last time I worked in Scala (admittedly this was a few years ago) - and they are still having lots of pain with performance, even though Scala doesn't have global type inference. Statically typed code generally performs better - but if there's one major rule I've learned in 25 years in IT, it's that code performance is not your real problem, 99% of the time. Your real problem is more likely to be IO, or poor algorithm design, or inefficient scalability, or slow speed of development, or difficulty diagnosing bugs, or unreadable unmaintainable code. I had people telling me that C++ was too slow, I should stick to C. Then, that Java was too slow, I should stick to C++. Then, that Ruby/JavaScript was too slow, I should stick to Java. None of these people were right. These days, I'd generally optimise first for expressive code so it's fast to develop and maintain; then for powerful flexible languages that can do anything I need them to do, and last for raw performance. I'm quite attracted by optional static typing, because it means I can rapidly code in a flexible dynamic language, and if I get to the point where I really need types, I can add them. But I suspect that most of the time, I'll never get to that point - or I'll use something like Prismatic Schema to define constraints at my external interfaces only, which is where I generally find I need them. - Korny On 23 December 2013 12:24, Richard Cole richard.j.c...@gmail.com wrote: The things is that dynamically typed languages are easier to implement than statically typed languages. Static typing comes down to making statements about the program and deriving other statements from them. It leads to all sorts of interesting work including I think into systems like Z. However theorem provers are limited in what they can do, and it can be both limiting and a big distraction to you as programmer to get into a dialogue with the theorem prover about your program. It can distract you from your original intention which was to write a program to do something in particular. So simply put, dynamic languages are better than static ones because they don't distract you with type discussions that can end up being unprofitable or limiting. Static languages are better because sometimes the type discussions lead to early and convenient detection of bugs and can also in some cases make it easier for other people to understand you program or how to use your library. Static types I think also help refactoring tools. Having optional typing in clojure is very nice. It allows for a lot of experimentation and research on type systems and for them to be used to the extent that people find them useful in their work. It is why I guess Alan Kay said that lisp is not a
Re: Implementation options for auto-complete and symbol resolution while coding
juan.facorro juan.faco...@gmail.com writes: Hi Clojurers, [snip] There are parsing libraries which provide good parse trees (i.e. Parsley, Instaparse), but my understanding is that what needs to be mantained is a full abstract syntax tree for the whole code base and although clojure.tools.analyzer [4] does the job of creating an AST, generating and mantaining all these trees sounds very costly and not the right way to do it. Just an idea. Maybe you should just use the parse tree for locals and the repl for globals. That shouldn't be too costly. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
This article makes some interesting points, but it seems to draw the wrong conclusions. The thing that is anti-modular isn't the types: it is depending on the internal implementation details of another module. If you expose too much of the implementation details in your interface declaration, that's not the fault of types: it's just bad API design. You have exactly the same problem with dynamic typing, e.g. if you place too many implicit requirements on the specific contents of a nested map data structure in your API contract. Except now your dependency on the internal implementation just blows up at runtime rather than being enforced at compile time. Ever had to debug a NullPointerException because you forgot to include some specific key in a parameter map? The obvious solution (in the static typing case at least): Use a well defined interface at the module boundaries that uses types from common/standard libraries (like, say, clojure.lang.IFn, java.lang.List etc). This removes the compilation cross-dependencies between modules, while still providing enough static type information to be practically useful (i.e. checking you aren't passing a String when the parameter should have been a List of characters.) On Monday, 23 December 2013 08:47:07 UTC, Manuel Paccagnella wrote: Just a link to the Gilad Bracha post Richard Cole is referring to: Types Are Anti-Modularhttp://gbracha.blogspot.it/2011/06/types-are-anti-modular.html . Il giorno lunedì 23 dicembre 2013 02:24:08 UTC+1, Richard Cole ha scritto: The things is that dynamically typed languages are easier to implement than statically typed languages. Static typing comes down to making statements about the program and deriving other statements from them. It leads to all sorts of interesting work including I think into systems like Z. However theorem provers are limited in what they can do, and it can be both limiting and a big distraction to you as programmer to get into a dialogue with the theorem prover about your program. It can distract you from your original intention which was to write a program to do something in particular. So simply put, dynamic languages are better than static ones because they don't distract you with type discussions that can end up being unprofitable or limiting. Static languages are better because sometimes the type discussions lead to early and convenient detection of bugs and can also in some cases make it easier for other people to understand you program or how to use your library. Static types I think also help refactoring tools. Having optional typing in clojure is very nice. It allows for a lot of experimentation and research on type systems and for them to be used to the extent that people find them useful in their work. It is why I guess Alan Kay said that lisp is not a language, it's a building material. If you want to know what are the current problems in static typing you going to have to start learning what people are doing in that field, e.g. is their foreign function interface from Haskel to Java? Why not? Can a well typed program still exhibit bugs? If the type checking is so powerful why do bugs persist? You might also look at what Gilhad Brakka was attempting to do with newspeak and his notions of types being anti-modular. You are not going to find a proof that that line of enquirely is fruitless, you'll instead find what people can do today in that field and where they're pushing the bounds. regards, Richard. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Implementation options for auto-complete and symbol resolution while coding
Hello, Food for thought: Currently Counterclockwise does 2 things: - it has an up-to-date list of symbols / keywords derived from the current editor. This of course does not need a running REPL, works as an heuristic for locals, and that's all. It won't go beyond the current file, won't show docstring or arglist of vars. - it tries to use the last active REPL View, if there's one, and use it for either code completion or symbol resolution+metadata (for showing docstring, hyperlinks to other parts of source code). Both these approaches rely on synchronized calls: - in the first case, it asks for the parse tree synchronously. Since Counterclockwise uses Parsley, which is an incremental parser, it works well 99% of the time. But there's still this 1% where you work with a big file, e.g. clojure/core.clj, and you can feel the editor lag behind you. - in the second case, any lag/problem with the network layer can affect your typing experience. This has been reported to me in the scariest way by a user the previous week: a corner case where the out of the box nrepl client will just hang forever because the remote connection was lost. So I'm thinking more and more these days about another design: totally decoupling the gathering of symbols dictionary from the usage of this dictionary. A true temporal decoupling. This means that the editor will never feel sluggish again. Maybe the information presented will be a little bit out of date, in a few percentage, but that would generally be for the greater good. My idea so far will be to : - have an atom on the Editor side containing a symbols dictionary. Updates to this dictionary will be done by background threads based on various events ( manual text change(s) to the editor - static analysis -, user interaction with a REPL - dynamic gathering of namespaces+vars -, updates of the project classpath - static analysis of jar dependencies - ). - This will allow Counterclockwise to have an always responsive editor. Only background threads may be blocked by problematic parses, problematic nrepl connections, etc. - This temporal decoupling also neatly decouples the production from the consumption of the symbols dictionary. This will be an overall better design to enable additional contributions to the symbols dictionary without direct impact on the consumers. So this is going a little bit agains the grain of what people are doing currently by overloading the server-side of things with knowledge, but I think it's the right direction to go, and the one I'll experiment with in the next weeks. Cheers, -- Laurent 2013/12/18 juan.facorro juan.faco...@gmail.com Hi Clojurers, I'm building a tool for Clojure and I've been hitting the same bump for quite some time now, namely auto-completion and finding the definition of a symbol. After doing some research I've found that some tools rely on a running REPL to figure out where a symbol might be coming from; these include emacs [1], Counter-Clockwise, clooj and maybe others I don't know about (like Nightcode or Cursive). This seems the natural thing to do since while developing we always have a REPL running to try out what we code, after all this is one of the best LISP features. This approach results in very accurate locations for global symbol definitions, but locals are not found since they are not accesible form the REPL. Another approach I've seen used for auto-completion in Clojure is the token-based, which involves looking for tokens in the code base associated with the current project and then providing the nearest match regardless of context; these include J Editor [2], Light Table (which I think uses inter-buffer token matching [3]) and emacs when it uses dictionary files (maybe not specifically in existing Clojure modes but it's something that emacs can do). Although this approach resolves the auto-completion, it is not very accurate when locating symbol definitions. From what I've read this is not a trivial problem so I was wondering if there's some implementation that actually resolves symbols statically (I mean without having a running REPL) in an accurate way or, if there's no implementation, maybe someone could point me in the right direction (or any direction) as to what would ease the pain to accomplish such a task. Building something on my own to do this static symbol resolution is out of the question, since that sounds like a whole project on its own and I'm currently trying to build something else entirely. There are parsing libraries which provide good parse trees (i.e. Parsley, Instaparse), but my understanding is that what needs to be mantained is a full abstract syntax tree for the whole code base and although clojure.tools.analyzer [4] does the job of creating an AST, generating and mantaining all these trees sounds very costly and not the right way to do it. If the running REPL approach is the saner one, then I would have no problem with going down
Re: bug in clojure.zip when calling next on empty list node?
On Dec 23, 2013, at 3:40 AM, Cedric Greevey wrote: On Sun, Dec 22, 2013 at 12:26 PM, Lee Spector lspec...@hampshire.edu wrote: The issue I was rasing is that, when traversing '(() 0) with zip/next, one should first visit the root, then (), and then 0. But what actually happens is that between then () and the 0 one lands on a non-existent nil node. So one ends up visiting 4 nodes when there are only 3, and the extra one is a nil. As I mentioned previously this leads to null pointer exceptions in my application, and the only ways around it that I see are recoding everything without zippers or some nasty special case hackery. Point of order: I'm somewhat dubious of the contention that wrapping the output of the traversal in (filter identity ...) before passing it to whatever's throwing the NPEs quite qualifies as nasty special case hackery. :) For one thing it wouldn't be quite that simple because in my application I'm not just collecting all of the nodes (from which I could indeed easily filter out nils), but rather doing things like getting or operating on the nth element of the tree, which I reach via n applications of zip/next, and I'd have to add a condition to check each result along the way and not count it if it's nil. And if I have legitimate nils in the tree somewhere then I'd have to do something more complicated to distinguish those (which should be counted) from the phantom nils that zip/next is inserting in certain circumstances. The bigger point, though, is that if I'm right that this is a bug then I think it's a pretty fundamental one in a core Clojure data structure, and it shouldn't be something that one has to discover and work around. -Lee -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How do I fix *warn-on-reflextion* warnings in 3rd party libraries?
Hi Larry, You can use *lein check* which *Check[s] syntax and warn[s] on reflection.* only for the *.clj files in your project's soure files. HTH, Juan On Sunday, December 22, 2013 7:33:56 PM UTC-3, larry google groups wrote: I know this has been discussed before but I could not find anything like a canonical answer via Google. I just set to :warn-on-reflection true in my project.clj and now I get the following warnings. How do I fix the warnings that are in 3rd party libraries? How do I add type hints to code I :use or :require? lein uberjar Compiling admin.core Reflection warning, admin/monitoring.clj:15:5 - call to enumerate can't be resolved. Reflection warning, admin/monitoring.clj:22:27 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:27:25 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:34:50 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:37:26 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:37:39 - reference to field getId can't be resolved. Reflection warning, clj_time/core.clj:577:10 - reference to field getDayOfMonth can't be resolved. Reflection warning, monger/joda_time.clj:32:19 - reference to field toDate can't be resolved. Reflection warning, monger/joda_time.clj:64:14 - reference to field toDate can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field getClass can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field isArray can't be resolved. Reflection warning, lamina/trace/timer.clj:173:7 - call to enqueue can't be resolved. Reflection warning, lamina/trace/timer.clj:302:5 - call to enqueue can't be resolved. Reflection warning, formative/util.clj:37:9 - call to valueOf can't be resolved. Reflection warning, jkkramer/verily.clj:304:15 - call to digit can't be resolved. Reflection warning, formative/parse.clj:45:9 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:49:15 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:55:13 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:74:13 - call to java.math.BigDecimal ctor can't be resolved. Reflection warning, formative/parse.clj:87:21 - call to java.math.BigInteger ctor can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, net/cgrand/xml.clj:85:4 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:15:3 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:32:18 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, net/cgrand/enlive_html.clj:54:16 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:175:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:220:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader.clj:71:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:77:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:89:24 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:214:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:218:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:78:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:84:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:96:24 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:205:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:209:23 - call to digit can't be resolved. Reflection warning, ns_tracker/core.clj:20:28 - reference to field lastModified can't be resolved. Reflection warning,
Re: Implementation options for auto-complete and symbol resolution while coding
*John:* I had watched that talk a while ago, not sure how I got to it. The work he describes is really interesting and sounds quite herculean, something that a company like Google can do. Unluckily the project hasn't seen the public light of day yet, at least not that I know of. *Zack*: Thanks for sharing the library NightCode uses for auto-completion and docstrings, I will certainly take a look at it. *Tim*: This approach certainly doesn't sound too costly. I had thought of a similar one but didn't get to implement it yet, the fact that you suggested it and that Laurent's response mentions multiple sources as well, makes me think that this is the way to go. *Laurent*: I've used CounterClockwise and I think it's one of the strongest development tools for Clojure out there. Decoupling the producer(s) from the consumer(s) of the symbol dictionary seems like a good idea. Large files are certainly an issue when dealing with this subject, since the whole file needs to be parsed and processed, even while it is being edited. I think have enough for a little more hammock time and an implementation attempt. My partial conclusion so far (which may not be spot on so feel free to contribute) is that since this is a really hard problem, it is reasonable to expect sub-optimal (but usable in almost all scenarios) symbol resolution results from any tool, which means to me that there is always room for improvement and this actually makes the problem interesting :) Thanks to all those who replied, all the comments and thoughts you shared have been really useful! Juan On Mon, Dec 23, 2013 at 10:01 AM, Laurent PETIT laurent.pe...@gmail.comwrote: Hello, Food for thought: Currently Counterclockwise does 2 things: - it has an up-to-date list of symbols / keywords derived from the current editor. This of course does not need a running REPL, works as an heuristic for locals, and that's all. It won't go beyond the current file, won't show docstring or arglist of vars. - it tries to use the last active REPL View, if there's one, and use it for either code completion or symbol resolution+metadata (for showing docstring, hyperlinks to other parts of source code). Both these approaches rely on synchronized calls: - in the first case, it asks for the parse tree synchronously. Since Counterclockwise uses Parsley, which is an incremental parser, it works well 99% of the time. But there's still this 1% where you work with a big file, e.g. clojure/core.clj, and you can feel the editor lag behind you. - in the second case, any lag/problem with the network layer can affect your typing experience. This has been reported to me in the scariest way by a user the previous week: a corner case where the out of the box nrepl client will just hang forever because the remote connection was lost. So I'm thinking more and more these days about another design: totally decoupling the gathering of symbols dictionary from the usage of this dictionary. A true temporal decoupling. This means that the editor will never feel sluggish again. Maybe the information presented will be a little bit out of date, in a few percentage, but that would generally be for the greater good. My idea so far will be to : - have an atom on the Editor side containing a symbols dictionary. Updates to this dictionary will be done by background threads based on various events ( manual text change(s) to the editor - static analysis -, user interaction with a REPL - dynamic gathering of namespaces+vars -, updates of the project classpath - static analysis of jar dependencies - ). - This will allow Counterclockwise to have an always responsive editor. Only background threads may be blocked by problematic parses, problematic nrepl connections, etc. - This temporal decoupling also neatly decouples the production from the consumption of the symbols dictionary. This will be an overall better design to enable additional contributions to the symbols dictionary without direct impact on the consumers. So this is going a little bit agains the grain of what people are doing currently by overloading the server-side of things with knowledge, but I think it's the right direction to go, and the one I'll experiment with in the next weeks. Cheers, -- Laurent 2013/12/18 juan.facorro juan.faco...@gmail.com Hi Clojurers, I'm building a tool for Clojure and I've been hitting the same bump for quite some time now, namely auto-completion and finding the definition of a symbol. After doing some research I've found that some tools rely on a running REPL to figure out where a symbol might be coming from; these include emacs [1], Counter-Clockwise, clooj and maybe others I don't know about (like Nightcode or Cursive). This seems the natural thing to do since while developing we always have a REPL running to try out what we code, after all this is one of the best LISP features. This approach results in very accurate locations for
Re: How do I fix *warn-on-reflextion* warnings in 3rd party libraries?
Hi Larry, This is not exactly what you asked but it might be helpful. There's a *check *command in *leiningen* wich *Check[s] syntax and warn[s] on reflection.* only for the **.clj* files in your project's source files. This doesn't really resolve the reflection warnings for the libraries you are using, but makes identifying the warning in your project a lot easier than whan they are mixed with the others. HTH, Juan On Sunday, December 22, 2013 7:33:56 PM UTC-3, larry google groups wrote: I know this has been discussed before but I could not find anything like a canonical answer via Google. I just set to :warn-on-reflection true in my project.clj and now I get the following warnings. How do I fix the warnings that are in 3rd party libraries? How do I add type hints to code I :use or :require? lein uberjar Compiling admin.core Reflection warning, admin/monitoring.clj:15:5 - call to enumerate can't be resolved. Reflection warning, admin/monitoring.clj:22:27 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:27:25 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:34:50 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:37:26 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:37:39 - reference to field getId can't be resolved. Reflection warning, clj_time/core.clj:577:10 - reference to field getDayOfMonth can't be resolved. Reflection warning, monger/joda_time.clj:32:19 - reference to field toDate can't be resolved. Reflection warning, monger/joda_time.clj:64:14 - reference to field toDate can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field getClass can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field isArray can't be resolved. Reflection warning, lamina/trace/timer.clj:173:7 - call to enqueue can't be resolved. Reflection warning, lamina/trace/timer.clj:302:5 - call to enqueue can't be resolved. Reflection warning, formative/util.clj:37:9 - call to valueOf can't be resolved. Reflection warning, jkkramer/verily.clj:304:15 - call to digit can't be resolved. Reflection warning, formative/parse.clj:45:9 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:49:15 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:55:13 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:74:13 - call to java.math.BigDecimal ctor can't be resolved. Reflection warning, formative/parse.clj:87:21 - call to java.math.BigInteger ctor can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, admin/controller.clj:159:29 - reference to field toString can't be resolved. Reflection warning, net/cgrand/xml.clj:85:4 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:15:3 - call to parse can't be resolved. Reflection warning, net/cgrand/tagsoup.clj:32:18 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, net/cgrand/enlive_html.clj:54:16 - call to org.xml.sax.InputSource ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, admin/supervisor.clj:54:5 - call to java.lang.Thread ctor can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:175:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:177:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:220:20 - reference to field get can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:15 - call to format can't be resolved. Reflection warning, clojure/tools/reader/default_data_readers.clj:222:5 - call to write can't be resolved. Reflection warning, clojure/tools/reader.clj:71:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:77:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:89:24 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:214:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader.clj:218:23 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:78:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:84:20 - call to digit can't be resolved. Reflection warning, clojure/tools/reader/edn.clj:96:24 - call to digit can't be resolved. Reflection warning,
Re: How to go about 'proving' why dynamically typed languages are better.
I came to this thread late, and have only skimmed some of the answers, but I think that the following, somewhat oblique, opinion hasn't yet been expressed about the, I don't know, maybe ... harassment by type weenies that zcaudate feels. Apologies in advance if I've missed a similar point. First, I'll note that I agree with many of the comments so far. To everything there's a season. That goes for type systems. In what I say next, I'm not trying to offend anyone. I'm expressing half-baked opinions about what I feel are general tendencies. I am certain that there are exceptions to *every* generalization I make. My personal opinion: Many of us who like programming like it partly because we like order, systematicity, and elegance, at least in our thinking. We like things to make sense. Some people have a greater need for this than others, at least at certain stages of their life. So things that seem more clean and neat are attractive. Full-fledged static typing has this character. It's appealing because it's orderly in a very, well, strict sense. I think it's probably easier to be religious about static typing and provable correctness as a universal goal if you don't have to deal with a lot of pragmatic concerns. So I suspect that many type zealots are students or were recently, and that they'll end up lightening up in several years, after they've got more experience with meeting the demands of practical coding. (That's not to imply they'll necessarily give up affection for static typing, but it's hard to be a zealot after you've freely chosen, many times, to compromise on formerly rigid principles.) Dynamical languages are above all oriented toward practical programming needs *in certain contexts*--in other contexts, static typing is more practical. Maybe some of the hard core static type advocates will see the potential benefits dynamic typing when they get more experience. But you can't *prove*, mathematically, that dynamical typing is better sometimes. Its advantage comes out in actual *practice* in real-world situations. (Real world doesn't mean business. I'm an academic coding solely for research purposes (and fun!).) My 2c. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Good resources on dataflow based programming
Cross posted from pedestal-users group, as many people who are not using pedestal may still know about dataflow, terms like effect are used in the context of pedestal Pedestal seems strongly based on dataflow based programming. The gigantic tutorial just sort of jumps in on it. Based on my usage thus far, dataflow seems really good at modeling problems that are self contained. In their pure forms (no external inputs or internal effects), dataflow seems almost like a circuit diagram. However, I quickly get confused once we start dealing with effects. Seems that there is a large Here be Dragons area of code in that region (services.cljs). I feel that this may not be dataflow's fault; I just haven't got my head around it. When I look at dataflow, I feel like it is constraining me to a particular way of solving a problem. The upside of this is that I have made my logic declarative and potentially easier to reason about. This is a trade-offs that seems similar to the trade-offs one makes when moving from a mutable procedural programming model to a immutable functional model. I have yet to personally get substantial benefit from dataflow, but that does not mean I will not with more mastery. I am wondering if there are any any getting started guides for dataflow programming that you (the community) would recommend. I would be especially interested in recipe books for dataflow based programming. How do you really do asynchronous processing with dataflow? What if your asyncs may return in a random order but must be processed in a specified order? A few books/articles/whatever on how experts think through these problems could be quite beneficial. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
Dynamical languages are above all oriented toward practical programming needs *in certain contexts*--in other contexts, static typing is more practical. Agreed -- which is why I find your speculation about lightening up with more experience ... meeting the demands of practical coding to be unsound. For those of us whose practical programming context includes a high cost associated with most any runtime bug, greater embrace of static typing, not lightening up, comes with more practical experience. I can be happy using a dynamically typed language when the price to be paid for getting it wrong isn't as high; but all of my experience goes against lightening up in the demanding programming context where I work every day. On Monday, December 23, 2013 10:04:52 AM UTC-8, Mars0i wrote: I came to this thread late, and have only skimmed some of the answers, but I think that the following, somewhat oblique, opinion hasn't yet been expressed about the, I don't know, maybe ... harassment by type weenies that zcaudate feels. Apologies in advance if I've missed a similar point. First, I'll note that I agree with many of the comments so far. To everything there's a season. That goes for type systems. In what I say next, I'm not trying to offend anyone. I'm expressing half-baked opinions about what I feel are general tendencies. I am certain that there are exceptions to *every* generalization I make. My personal opinion: Many of us who like programming like it partly because we like order, systematicity, and elegance, at least in our thinking. We like things to make sense. Some people have a greater need for this than others, at least at certain stages of their life. So things that seem more clean and neat are attractive. Full-fledged static typing has this character. It's appealing because it's orderly in a very, well, strict sense. I think it's probably easier to be religious about static typing and provable correctness as a universal goal if you don't have to deal with a lot of pragmatic concerns. So I suspect that many type zealots are students or were recently, and that they'll end up lightening up in several years, after they've got more experience with meeting the demands of practical coding. (That's not to imply they'll necessarily give up affection for static typing, but it's hard to be a zealot after you've freely chosen, many times, to compromise on formerly rigid principles.) Dynamical languages are above all oriented toward practical programming needs *in certain contexts*--in other contexts, static typing is more practical. Maybe some of the hard core static type advocates will see the potential benefits dynamic typing when they get more experience. But you can't *prove*, mathematically, that dynamical typing is better sometimes. Its advantage comes out in actual *practice* in real-world situations. (Real world doesn't mean business. I'm an academic coding solely for research purposes (and fun!).) My 2c. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
Agreed -- which is why I find your speculation about lightening up with more experience ... meeting the demands of practical coding to be unsound. For those of us whose practical programming context includes a high cost associated with most any runtime bug, greater embrace of static typing, not lightening up, comes with more practical experience. I can be happy using a dynamically typed language when the price to be paid for getting it wrong isn't as high; but all of my experience goes against lightening up in the demanding programming context where I work every day We're arguing in circles. I think the fundamental question is between two issues. On the potential drawback of strong static types, you have trying to model all of the complex interlocking concepts in a static type system and possibly dealing with long compile times. On the potential drawback of dynamic typing, you have the risk of a runtime type error. The question, then, is whether the flexibility of dynamic types lets you develop, test, unit test, and system test code so much faster than you would in a language with strong static types that you are able to prevent all runtime type errors anyway. The difficulty in deciding the question is that the benefits and drawbacks of either approach don't really manifest until your project is huge. It's relatively straightforward to get your dynamic typing right in a 500 line program, and it's relatively straightforward to not have any issues modeling your logic and data with static types in a 500 line program, and the speed difference in development between the two isn't significant. Once you get to hundreds of thousands of lines of code, things get interesting - and it also gets much harder to compare between the two. If you look at Youtube, Reddit, Twitter, Github, Tumblr, and Facebook, they were written in languages with dynamic types. A lot of them switched partly or totally to languages with static types for performance reasons once they got big enough. But I really think they stand as testimonial to the fact that dynamic types allow for faster development than static types. If you're guiding a rocket or controlling medical equipment, stay static. But for other use cases, that's a pretty compelling case. -Mike -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
I don't think we disagree. The guesses I gave in my post only concerned people like those who frustrated zcaudate, and who, from what was said, seemed to feel that anything other than strict static typing was wrong in all contexts. Maybe I'm reading too much into zcaudate's post, though. (Also, so no one will misunderstand, when I said 'real world' doesn't mean business, I of course meant not *just* business. A lot of my programming experience was in the business world, actually.) On Monday, December 23, 2013 2:57:43 PM UTC-6, Mark Hamstra wrote: Dynamical languages are above all oriented toward practical programming needs *in certain contexts*--in other contexts, static typing is more practical. Agreed -- which is why I find your speculation about lightening up with more experience ... meeting the demands of practical coding to be unsound. For those of us whose practical programming context includes a high cost associated with most any runtime bug, greater embrace of static typing, not lightening up, comes with more practical experience. I can be happy using a dynamically typed language when the price to be paid for getting it wrong isn't as high; but all of my experience goes against lightening up in the demanding programming context where I work every day. On Monday, December 23, 2013 10:04:52 AM UTC-8, Mars0i wrote: I came to this thread late, and have only skimmed some of the answers, but I think that the following, somewhat oblique, opinion hasn't yet been expressed about the, I don't know, maybe ... harassment by type weenies that zcaudate feels. Apologies in advance if I've missed a similar point. First, I'll note that I agree with many of the comments so far. To everything there's a season. That goes for type systems. In what I say next, I'm not trying to offend anyone. I'm expressing half-baked opinions about what I feel are general tendencies. I am certain that there are exceptions to *every* generalization I make. My personal opinion: Many of us who like programming like it partly because we like order, systematicity, and elegance, at least in our thinking. We like things to make sense. Some people have a greater need for this than others, at least at certain stages of their life. So things that seem more clean and neat are attractive. Full-fledged static typing has this character. It's appealing because it's orderly in a very, well, strict sense. I think it's probably easier to be religious about static typing and provable correctness as a universal goal if you don't have to deal with a lot of pragmatic concerns. So I suspect that many type zealots are students or were recently, and that they'll end up lightening up in several years, after they've got more experience with meeting the demands of practical coding. (That's not to imply they'll necessarily give up affection for static typing, but it's hard to be a zealot after you've freely chosen, many times, to compromise on formerly rigid principles.) Dynamical languages are above all oriented toward practical programming needs *in certain contexts*--in other contexts, static typing is more practical. Maybe some of the hard core static type advocates will see the potential benefits dynamic typing when they get more experience. But you can't *prove*, mathematically, that dynamical typing is better sometimes. Its advantage comes out in actual *practice* in real-world situations. (Real world doesn't mean business. I'm an academic coding solely for research purposes (and fun!).) My 2c. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Implementation options for auto-complete and symbol resolution while coding
As another data point, Cursive's symbol resolution in normal code editing is totally static - it doesn't use the REPL at all. When typing in the REPL window, local resolution is used for the code in the editor and the REPL is used for everything else, so that local symbols can be completed and so forth but everything else comes from the running system. I'm lucky to be building on the IntelliJ infrastructure, which provides a fantastic architecture for static resolution out of the box. It's fully asynchronous already and is the basic building block for all IDE functionality. It also provides automatic indexing for various types of indices. Static resolution is definitely a trade-off in the presence of macros, since in the general case it's computationally undecidable to determine what a macro does without actually executing it. By far the biggest downside of static resolution is this one - that until the editor is told which symbols are declared by a particular macro form, it cannot resolve them. This means that essentially nothing works - navigation, symbol rename, find usages, refactorings, etc etc. I'm working on an API (which I already use internally) which will hopefully make adding support for new libraries relatively trivial - I plan to release that API when it's more stable so anyone can add support for public libraries or for their internal libs. The advantages are pretty huge though. Cross-project resolution, completion, and navigation are all possible whether you have the REPL running or not. Local bindings are treated identically to global vars. Find usages type functionality is possible, which apart from being an essential navigation tool in large projects (or indeed in any project) is also the basis of many refactorings. The indices backing all this are transparently updated continuously in the background and the editor is very responsive, even when editing clojure/core.clj. Only time will tell if this approach is better or worse than REPL-based resolution, but for the moment I'm very happy with the tradeoff. The infrastructure is very complicated to implement, though, it's more stable now but for a long time it took most of my development time and I'm still planning a few more fairly major changes as I encounter more crazy things people do with macros. Cheers, Colin On 24 December 2013 04:49, Juan Martín juan.faco...@gmail.com wrote: *John:* I had watched that talk a while ago, not sure how I got to it. The work he describes is really interesting and sounds quite herculean, something that a company like Google can do. Unluckily the project hasn't seen the public light of day yet, at least not that I know of. *Zack*: Thanks for sharing the library NightCode uses for auto-completion and docstrings, I will certainly take a look at it. *Tim*: This approach certainly doesn't sound too costly. I had thought of a similar one but didn't get to implement it yet, the fact that you suggested it and that Laurent's response mentions multiple sources as well, makes me think that this is the way to go. *Laurent*: I've used CounterClockwise and I think it's one of the strongest development tools for Clojure out there. Decoupling the producer(s) from the consumer(s) of the symbol dictionary seems like a good idea. Large files are certainly an issue when dealing with this subject, since the whole file needs to be parsed and processed, even while it is being edited. I think have enough for a little more hammock time and an implementation attempt. My partial conclusion so far (which may not be spot on so feel free to contribute) is that since this is a really hard problem, it is reasonable to expect sub-optimal (but usable in almost all scenarios) symbol resolution results from any tool, which means to me that there is always room for improvement and this actually makes the problem interesting :) Thanks to all those who replied, all the comments and thoughts you shared have been really useful! Juan On Mon, Dec 23, 2013 at 10:01 AM, Laurent PETIT laurent.pe...@gmail.comwrote: Hello, Food for thought: Currently Counterclockwise does 2 things: - it has an up-to-date list of symbols / keywords derived from the current editor. This of course does not need a running REPL, works as an heuristic for locals, and that's all. It won't go beyond the current file, won't show docstring or arglist of vars. - it tries to use the last active REPL View, if there's one, and use it for either code completion or symbol resolution+metadata (for showing docstring, hyperlinks to other parts of source code). Both these approaches rely on synchronized calls: - in the first case, it asks for the parse tree synchronously. Since Counterclockwise uses Parsley, which is an incremental parser, it works well 99% of the time. But there's still this 1% where you work with a big file, e.g. clojure/core.clj, and you can feel the editor lag behind you. - in the second case, any
Re: How to go about 'proving' why dynamically typed languages are better.
@Richard. I would have said the same as you before I joined a relatively large organisation heavily influenced by scala and the Coursera FP lecture series. We are slowly moving into Clojure code but there now seems to be a huge misconception that FP and Type Systems are joined at the hips. My conversations with one or two scala fanboys goes something like this: Them: What's so good about clojure anyways? I'm really worried that it's going to fail in large projects. Me: Well.. Here is a large project. Check out this macro I wrote. it abstracts out all these underlying complexities and it would be really hard to this write the code with a type system. Them: But you need types because types are mathematically provable... You can't write correct programs if you don't have types. After a couple of these conversations. I find it useful to avoid them. However, when push comes to shove, I have a list of examples where having type systems are not natural to solving the underlying problem - modelling relationships, querying databases, translating JSON, classifying elements in non-treelike structures, dealing with change in specifications, dealing with uncertainty in specifications... All very 'real world' problems that are an unnatural fit with the type system. In those examples - there are ways of wrangling the type system to deal with the problems, but they end up using an existential type - http://www.haskell.org/haskellwiki/Existential_type , or a type of types - http://ktoso.github.io/scala-types-of-types, or something meta like template haskell. It seems quite silly to have the 'any' type when it is probably best to not use types at all. Doesn't this remind you of the story of 'the emperor's new clothes'? I completely agree with Korny that types are a premature optimisation. Therefore understand why and how it is a premature optimisation is really important to convince organisations to firstly understand, trust and then use clojure in production. Sometimes, writing good programs and having good use cases are not enough. We don't need a complete mathematical proof, but we still need something to substantiate design decisions to those that may not be as clojure friendly. On 24/12/2013, at 7:57, Mark Hamstra markhams...@gmail.com wrote: Dynamical languages are above all oriented toward practical programming needs in certain contexts--in other contexts, static typing is more practical. Agreed -- which is why I find your speculation about lightening up with more experience ... meeting the demands of practical coding to be unsound. For those of us whose practical programming context includes a high cost associated with most any runtime bug, greater embrace of static typing, not lightening up, comes with more practical experience. I can be happy using a dynamically typed language when the price to be paid for getting it wrong isn't as high; but all of my experience goes against lightening up in the demanding programming context where I work every day. On Monday, December 23, 2013 10:04:52 AM UTC-8, Mars0i wrote: I came to this thread late, and have only skimmed some of the answers, but I think that the following, somewhat oblique, opinion hasn't yet been expressed about the, I don't know, maybe ... harassment by type weenies that zcaudate feels. Apologies in advance if I've missed a similar point. First, I'll note that I agree with many of the comments so far. To everything there's a season. That goes for type systems. In what I say next, I'm not trying to offend anyone. I'm expressing half-baked opinions about what I feel are general tendencies. I am certain that there are exceptions to every generalization I make. My personal opinion: Many of us who like programming like it partly because we like order, systematicity, and elegance, at least in our thinking. We like things to make sense. Some people have a greater need for this than others, at least at certain stages of their life. So things that seem more clean and neat are attractive. Full-fledged static typing has this character. It's appealing because it's orderly in a very, well, strict sense. I think it's probably easier to be religious about static typing and provable correctness as a universal goal if you don't have to deal with a lot of pragmatic concerns. So I suspect that many type zealots are students or were recently, and that they'll end up lightening up in several years, after they've got more experience with meeting the demands of practical coding. (That's not to imply they'll necessarily give up affection for static typing, but it's hard to be a zealot after you've freely chosen, many times, to compromise on formerly rigid principles.) Dynamical languages are above all oriented toward practical programming needs in certain contexts--in other contexts, static typing is more practical. Maybe some of the
Re: How to go about 'proving' why dynamically typed languages are better.
I'm not sure what you mean by invoking the putative silliness of an any type, but existential types aren't just a way of saying anything goes here, typewise---they do enable further substantive static guarantees (such as those used by e.g. Haskell's ST system). On Mon, Dec 23, 2013 at 2:16 PM, Chris Zheng z...@caudate.me wrote: @Richard. I would have said the same as you before I joined a relatively large organisation heavily influenced by scala and the Coursera FP lecture series. We are slowly moving into Clojure code but there now seems to be a huge misconception that FP and Type Systems are joined at the hips. My conversations with one or two scala fanboys goes something like this: Them: What's so good about clojure anyways? I'm really worried that it's going to fail in large projects. Me: Well.. Here is a large project. Check out this macro I wrote. it abstracts out all these underlying complexities and it would be really hard to this write the code with a type system. Them: But you need types because types are mathematically provable... You can't write correct programs if you don't have types. After a couple of these conversations. I find it useful to avoid them. However, when push comes to shove, I have a list of examples where having type systems are not natural to solving the underlying problem - modelling relationships, querying databases, translating JSON, classifying elements in non-treelike structures, dealing with change in specifications, dealing with uncertainty in specifications... All very 'real world' problems that are an unnatural fit with the type system. In those examples - there are ways of wrangling the type system to deal with the problems, but they end up using an existential type - http://www.haskell.org/haskellwiki/Existential_type , or a type of types - http://ktoso.github.io/scala-types-of-types, or something meta like template haskell. It seems quite silly to have the 'any' type when it is probably best to not use types at all. Doesn't this remind you of the story of 'the emperor's new clothes'? I completely agree with Korny that types are a premature optimisation. Therefore understand why and how it is a premature optimisation is really important to convince organisations to firstly understand, trust and then use clojure in production. Sometimes, writing good programs and having good use cases are not enough. We don't need a complete mathematical proof, but we still need something to substantiate design decisions to those that may not be as clojure friendly. On 24/12/2013, at 7:57, Mark Hamstra markhams...@gmail.com wrote: Dynamical languages are above all oriented toward practical programming needs *in certain contexts*--in other contexts, static typing is more practical. Agreed -- which is why I find your speculation about lightening up with more experience ... meeting the demands of practical coding to be unsound. For those of us whose practical programming context includes a high cost associated with most any runtime bug, greater embrace of static typing, not lightening up, comes with more practical experience. I can be happy using a dynamically typed language when the price to be paid for getting it wrong isn't as high; but all of my experience goes against lightening up in the demanding programming context where I work every day. On Monday, December 23, 2013 10:04:52 AM UTC-8, Mars0i wrote: I came to this thread late, and have only skimmed some of the answers, but I think that the following, somewhat oblique, opinion hasn't yet been expressed about the, I don't know, maybe ... harassment by type weenies that zcaudate feels. Apologies in advance if I've missed a similar point. First, I'll note that I agree with many of the comments so far. To everything there's a season. That goes for type systems. In what I say next, I'm not trying to offend anyone. I'm expressing half-baked opinions about what I feel are general tendencies. I am certain that there are exceptions to *every* generalization I make. My personal opinion: Many of us who like programming like it partly because we like order, systematicity, and elegance, at least in our thinking. We like things to make sense. Some people have a greater need for this than others, at least at certain stages of their life. So things that seem more clean and neat are attractive. Full-fledged static typing has this character. It's appealing because it's orderly in a very, well, strict sense. I think it's probably easier to be religious about static typing and provable correctness as a universal goal if you don't have to deal with a lot of pragmatic concerns. So I suspect that many type zealots are students or were recently, and that they'll end up lightening up in several years, after they've got more experience with meeting the demands of practical coding. (That's not to imply they'll necessarily give up affection for
Re: How to go about 'proving' why dynamically typed languages are better.
About: The question, then, is whether the flexibility of dynamic types lets you develop, test, unit test, and system test code so much faster than you would in a language with strong static types that you are able to prevent all runtime type errors anyway. Yes! In the past years, I coded in typed languages (Java, C#), and in dynamic language (JavaScript). And dynamic language (using TDD) is faster and more solid, in my experience. The key part is TDD: it is the new compiler. It catch the errors, but not the type errors, but the behavior errors. And to me, this feature is more important. I only would switch to typed language for efficiency reasons, or some specialized domain. On Mon, Dec 23, 2013 at 6:40 PM, Michael Swierczek mike.swierc...@gmail.com wrote: Agreed -- which is why I find your speculation about lightening up with more experience ... meeting the demands of practical coding to be unsound. For those of us whose practical programming context includes a high cost associated with most any runtime bug, greater embrace of static typing, not lightening up, comes with more practical experience. I can be happy using a dynamically typed language when the price to be paid for getting it wrong isn't as high; but all of my experience goes against lightening up in the demanding programming context where I work every day We're arguing in circles. I think the fundamental question is between two issues. On the potential drawback of strong static types, you have trying to model all of the complex interlocking concepts in a static type system and possibly dealing with long compile times. On the potential drawback of dynamic typing, you have the risk of a runtime type error. The question, then, is whether the flexibility of dynamic types lets you develop, test, unit test, and system test code so much faster than you would in a language with strong static types that you are able to prevent all runtime type errors anyway. The difficulty in deciding the question is that the benefits and drawbacks of either approach don't really manifest until your project is huge. It's relatively straightforward to get your dynamic typing right in a 500 line program, and it's relatively straightforward to not have any issues modeling your logic and data with static types in a 500 line program, and the speed difference in development between the two isn't significant. Once you get to hundreds of thousands of lines of code, things get interesting - and it also gets much harder to compare between the two. If you look at Youtube, Reddit, Twitter, Github, Tumblr, and Facebook, they were written in languages with dynamic types. A lot of them switched partly or totally to languages with static types for performance reasons once they got big enough. But I really think they stand as testimonial to the fact that dynamic types allow for faster development than static types. If you're guiding a rocket or controlling medical equipment, stay static. But for other use cases, that's a pretty compelling case. -Mike -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
@mars0i That is how I feel. Of course static typing has its use. For starters, it makes my programs go faster. However, the more i write lisp code, the more i realise that types has its drawbacks. I'm not sure of the answer here but I have my suspicions: Can typed clojure be written in typed clojure? Anyways... the caption of this thread is slightly misleading... it was a bit of an attention seeking title :) On 24/12/2013, at 8:46, Mars0i marsh...@logical.net wrote: I don't think we disagree. The guesses I gave in my post only concerned people like those who frustrated zcaudate, and who, from what was said, seemed to feel that anything other than strict static typing was wrong in all contexts. Maybe I'm reading too much into zcaudate's post, though. (Also, so no one will misunderstand, when I said 'real world' doesn't mean business, I of course meant not just business. A lot of my programming experience was in the business world, actually.) On Monday, December 23, 2013 2:57:43 PM UTC-6, Mark Hamstra wrote: Dynamical languages are above all oriented toward practical programming needs in certain contexts--in other contexts, static typing is more practical. Agreed -- which is why I find your speculation about lightening up with more experience ... meeting the demands of practical coding to be unsound. For those of us whose practical programming context includes a high cost associated with most any runtime bug, greater embrace of static typing, not lightening up, comes with more practical experience. I can be happy using a dynamically typed language when the price to be paid for getting it wrong isn't as high; but all of my experience goes against lightening up in the demanding programming context where I work every day. On Monday, December 23, 2013 10:04:52 AM UTC-8, Mars0i wrote: I came to this thread late, and have only skimmed some of the answers, but I think that the following, somewhat oblique, opinion hasn't yet been expressed about the, I don't know, maybe ... harassment by type weenies that zcaudate feels. Apologies in advance if I've missed a similar point. First, I'll note that I agree with many of the comments so far. To everything there's a season. That goes for type systems. In what I say next, I'm not trying to offend anyone. I'm expressing half-baked opinions about what I feel are general tendencies. I am certain that there are exceptions to every generalization I make. My personal opinion: Many of us who like programming like it partly because we like order, systematicity, and elegance, at least in our thinking. We like things to make sense. Some people have a greater need for this than others, at least at certain stages of their life. So things that seem more clean and neat are attractive. Full-fledged static typing has this character. It's appealing because it's orderly in a very, well, strict sense. I think it's probably easier to be religious about static typing and provable correctness as a universal goal if you don't have to deal with a lot of pragmatic concerns. So I suspect that many type zealots are students or were recently, and that they'll end up lightening up in several years, after they've got more experience with meeting the demands of practical coding. (That's not to imply they'll necessarily give up affection for static typing, but it's hard to be a zealot after you've freely chosen, many times, to compromise on formerly rigid principles.) Dynamical languages are above all oriented toward practical programming needs in certain contexts--in other contexts, static typing is more practical. Maybe some of the hard core static type advocates will see the potential benefits dynamic typing when they get more experience. But you can't prove, mathematically, that dynamical typing is better sometimes. Its advantage comes out in actual practice in real-world situations. (Real world doesn't mean business. I'm an academic coding solely for research purposes (and fun!).) My 2c. -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/0I7u5yn01qU/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are
Re: How to go about 'proving' why dynamically typed languages are better.
On Mon, Dec 23, 2013 at 2:34 PM, Chris Zheng z...@caudate.me wrote: However, the more i write lisp code, the more i realise that types has its drawbacks. I'm not sure of the answer here but I have my suspicions: Can typed clojure be written in typed clojure? Why in the world couldn't it be? At the most boring level, if there were some difficulty, one could just project everything into some universal type, then do case analysis based on what sort of thing you had. (Which is the nub of Bob Harper's claim that dynamically typed languages are just a special case of statically typed languages, if I understand it.) -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
On Dec 23, 2013, at 14:16, Chris Zheng wrote: I completely agree with Korny that types are a premature optimisation. My take is that required types may force premature optimization and may inhibit the creative process. So, I like dynamic languages. However, optional types (preferably with type inference) give me the choice to add typing if, when, and how I think it will be worthwhile. So, I may still premature, but at least it's my mistake to make... Any time that a function is going to be distributed beyond its initial project, I would assert that appropriate forms of typing (eg, schema, Typed Clojure) should be evaluated (and probably used). Going a bit further, I'd like to assert that every publicly-distributed function (etc) in the Clojure ecosystem should have appropriate use of typing. This should be integrated into the online documentation and testing support, to make it readily and usefully available. And a pony. -r -- http://www.cfcl.com/rdm Rich Morin r...@cfcl.com http://www.cfcl.com/rdm/resumeSan Bruno, CA, USA +1 650-873-7841 Software system design, development, and documentation -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
On Monday, December 23, 2013 5:39:54 PM UTC-6, Rich Morin wrote: My take is that required types may force premature optimization and may inhibit the creative process. That's an interesting point. I like it. Kind of off topic, but my earlier remark about psychological factors that might contribute to static type zealotry made me think about one static type fan (zealot, maybe) I knew who, I think, at one time endeavored to avoid thought processes that couldn't be made rigorous. I keep thinking I should have said that I think creativity often requires a intermediate stage of messiness. Then you have to clean it up to get something interesting, in many cases, but you wouldn't have gotten to some place new and interesting if you only went via purely rational, rigorous steps. Maybe this is the argument that zcaudate should use: Static typing is the death of creativity. Just kidding. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Library can depend on an older version of itself?
Is there a straightforward way to setup a Clojure library so that it can depend on an older version of itself? I can think of a couple of ways to do this that seem clunky, but was wondering what approaches (if any) have worked well for other folks. Something involving pomegranate and clojure.tools.namespace? -- Michael Bradley @michaelsbradley -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Library can depend on an older version of itself?
I don't have any suggestions as to how this might be achieved, I'm afraid, but I am very curious as to *why* you'd want to do this. - James On 24 December 2013 00:07, Michael Bradley, Jr. michaelsbradle...@gmail.com wrote: Is there a straightforward way to setup a Clojure library so that it can depend on an older version of itself? I can think of a couple of ways to do this that seem clunky, but was wondering what approaches (if any) have worked well for other folks. Something involving pomegranate and clojure.tools.namespace? -- Michael Bradley @michaelsbradley -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Library can depend on an older version of itself?
I’m writing a parser that will be easier to write with itself, but I want to be able to “freeze” an earlier version that’s passing all the tests (for features implemented so far) and which is implemented quite differently. The older version can then be used as the basis for the next version, and that version in turn as the basis for the version after next, and so on. -- Michael Bradley, Jr. @michaelsbradley On Dec 23, 2013, at 18:12, James Reeves ja...@booleanknot.com wrote: I don't have any suggestions as to how this might be achieved, I'm afraid, but I am very curious as to why you'd want to do this. - James On 24 December 2013 00:07, Michael Bradley, Jr. michaelsbradle...@gmail.com wrote: Is there a straightforward way to setup a Clojure library so that it can depend on an older version of itself? I can think of a couple of ways to do this that seem clunky, but was wondering what approaches (if any) have worked well for other folks. Something involving pomegranate and clojure.tools.namespace? -- Michael Bradley @michaelsbradley -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/OFwMQ5apN0Y/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
Can typed clojure be written in typed clojure? could just project everything into some universal type, then do case analysis based on what sort of thing you had. (Which is the nub of Bob Harper's claim that dynamically typed languages are just a special case of statically typed languages, if I understand it.) I'm confused... was that supposed to be taken seriously? It was very dry if it was meant to be a joke :-) -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to go about 'proving' why dynamically typed languages are better.
On Dec 23, 2013, at 16:03, Mars0i wrote: ... creativity often requires a intermediate stage of messiness. Then you have to clean it up to get something interesting, in many cases, but you wouldn't have gotten to some place new and interesting if you only went via purely rational, rigorous steps. If you haven't seen Bret Victor's talks on computers and creativity, I strongly recommend doing so. The most recent one is probably the best place to start; you can go back to the earlier ones if you get hooked... Media for Thinking the Unthinkable: Designing a new medium for science and engineering http://worrydream.com/MediaForThinkingTheUnthinkable/ -r -- http://www.cfcl.com/rdm Rich Morin r...@cfcl.com http://www.cfcl.com/rdm/resumeSan Bruno, CA, USA +1 650-873-7841 Software system design, development, and documentation -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How do I fix *warn-on-reflextion* warnings in 3rd party libraries?
No, lein check will give you reflection warnings on 3rd party libraries... (sean)-(jobs:0)-(/Developer/workspace/worldsingles/ws/model/clojure/worldsingles) (! 505)- lein check Compiling namespace worldsingles.activity Reflection warning, clojure/core/incubator.clj:84:7 - reference to field getClass can't be resolved. Reflection warning, clojure/core/incubator.clj:84:7 - reference to field isArray can't be resolved. Reflection warning, somnium/congomongo.clj:60:38 - reference to field getModifiers can't be resolved. Reflection warning, somnium/congomongo.clj:63:67 - reference to field getReturnType can't be resolved. ... many others omitted ... Reflection warning, clojure/tools/nrepl/ack.clj:47:3 - reference to field close can't be resolved. Reflection warning, clojure/tools/nrepl/middleware.clj:135:3 - call to replaceAll can't be resolved. Reflection warning, clojure/tools/nrepl/middleware/interruptible_eval.clj:53:52 - reference to field iterator can't be resolved. Reflection warning, clojure/tools/nrepl/middleware/interruptible_eval.clj:109:3 - call to java.util.concurrent.ThreadPoolExecutor ctor can't be resolved. Reflection warning, clojure/tools/nrepl/middleware/session.clj:41:54 - call to append can't be resolved. Reflection warning, clojure/tools/nrepl/middleware/session.clj:230:30 - call to put can't be resolved. Reflection warning, clojure/tools/nrepl/middleware/session.clj:230:30 - call to put can't be resolved. Reflection warning, clojure/tools/nrepl/server.clj:42:21 - reference to field close can't be resolved. Reflection warning, clojure/tools/nrepl/server.clj:133:28 - call to java.net.InetSocketAddress ctor can't be resolved. Reflection warning, clj_time/core.clj:577:10 - reference to field getDayOfMonth can't be resolved. Compiling namespace worldsingles.admin.email Compiling namespace worldsingles.admin.permissions Compiling namespace worldsingles.admin.photos Reflection warning, image_resizer/util.clj:10:5 - call to read can't be resolved. Reflection warning, image_resizer/util.clj:13:4 - reference to field getWidth can't be resolved. Reflection warning, image_resizer/util.clj:13:22 - reference to field getHeight can't be resolved. ... and on and on for many pages ... On Mon, Dec 23, 2013 at 7:57 AM, juan.facorro juan.faco...@gmail.com wrote: Hi Larry, This is not exactly what you asked but it might be helpful. There's a check command in leiningen wich Check[s] syntax and warn[s] on reflection. only for the *.clj files in your project's source files. This doesn't really resolve the reflection warnings for the libraries you are using, but makes identifying the warning in your project a lot easier than whan they are mixed with the others. HTH, Juan On Sunday, December 22, 2013 7:33:56 PM UTC-3, larry google groups wrote: I know this has been discussed before but I could not find anything like a canonical answer via Google. I just set to :warn-on-reflection true in my project.clj and now I get the following warnings. How do I fix the warnings that are in 3rd party libraries? How do I add type hints to code I :use or :require? lein uberjar Compiling admin.core Reflection warning, admin/monitoring.clj:15:5 - call to enumerate can't be resolved. Reflection warning, admin/monitoring.clj:22:27 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:27:25 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:34:50 - reference to field getId can't be resolved. Reflection warning, admin/monitoring.clj:37:26 - reference to field getName can't be resolved. Reflection warning, admin/monitoring.clj:37:39 - reference to field getId can't be resolved. Reflection warning, clj_time/core.clj:577:10 - reference to field getDayOfMonth can't be resolved. Reflection warning, monger/joda_time.clj:32:19 - reference to field toDate can't be resolved. Reflection warning, monger/joda_time.clj:64:14 - reference to field toDate can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field getClass can't be resolved. Reflection warning, clojure/core/incubator.clj:90:7 - reference to field isArray can't be resolved. Reflection warning, lamina/trace/timer.clj:173:7 - call to enqueue can't be resolved. Reflection warning, lamina/trace/timer.clj:302:5 - call to enqueue can't be resolved. Reflection warning, formative/util.clj:37:9 - call to valueOf can't be resolved. Reflection warning, jkkramer/verily.clj:304:15 - call to digit can't be resolved. Reflection warning, formative/parse.clj:45:9 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:49:15 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:55:13 - call to valueOf can't be resolved. Reflection warning, formative/parse.clj:74:13 - call to java.math.BigDecimal ctor can't be resolved. Reflection warning, formative/parse.clj:87:21 - call to
Re: How do I fix *warn-on-reflextion* warnings in 3rd party libraries?
Sean, Thank you much. I do understand that Clojure is not a *statically typed language, *but it seems like it should be possible to deal with these reflexion issues when someone needs to. In my company we had a Scala versus Clojure debate and there was a vocal crowd that felt we should use Scala for performance issues. But I have the impression that, with some effort, Clojure is reasonably good, relative to Scala, in real-world performance. Having said that, I realize part of the advantage of a dynamically typed language is that it can use 3rd party libraries that might be highly flexible exactly because they take a wide range of types, and this makes it impossible to eliminate reflexion warnings, so there is a trade off between the universalness of the 3rd party libraries versus their performance characteristics. larry On Sunday, December 22, 2013 5:57:32 PM UTC-5, Sean Corfield wrote: On Sun, Dec 22, 2013 at 2:55 PM, Sean Corfield seanco...@gmail.comjavascript: wrote: For clj-time I'm happy to just see an issue opened on Github (when it's back from its current 503 woes!) and happier to see a Pull Request. https://github.com/clj-time/clj-time/issues/100 -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap
enforce that the return is a subtype of java.util.Map rather than
checking for a specific concrete class of map.
Thank you. I'll do that. All the same, can anyone tell me why this function
changes the type of the value? All it does is call fetch. The fetch
function has this post condition:
:post [(= (type %) clojure.lang.PersistentHashMap)]}
And get-distinct has the same restriction, but in get-distinct I get this
error:
java.lang.AssertionError: Assert failed: (= (type %)
clojure.lang.PersistentHashMap)
at admin.controller$get_distinct.invoke(controller.clj:40)
The :post condition of fetch does not throw an error, so I know that
fetch is returning clojure.lang.PersistentHashMap. However, when I print
the return type of get-distinct, I am amazed to see that it is
now clojure.lang.PersistentArrayMap. This function does almost nothing, so
I am surprised it changes the concrete implementation type of the return
value.
On Monday, December 23, 2013 3:43:09 AM UTC-5, Cedric Greevey wrote:
The two classes have essentially the same semantics, but performance
differences, which is why Clojure sometimes uses one and sometimes the
other. If you want to enforce that a map is returned, enforce that the
return is a subtype of java.util.Map rather than checking for a specific
concrete class of map.
On Sun, Dec 22, 2013 at 3:07 PM, larry google groups
lawrenc...@gmail.comjavascript:
wrote:
Hmm, I see. get-distinct was returning an empty lazyseq, which apparently
made the difference.
On Sunday, December 22, 2013 2:56:01 PM UTC-5, larry google groups wrote:
Hmm, the different return types seem tied to the 2 different functions
being called, but both functions have the same return type, which is a
lazyseq. I am using Monger to get data from MongoDb. These functions are
private:
(defn- get-distinct [request]
{:pre [(= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/get-distinct (:item-type request)))
(defn- paginate-results [request]
{:pre [ (= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/paginate-results (:item-type request) (if (:which-page request)
(:which-page request)
0)))
Both of these functions return lazyseqs, as expected. The results from
both get run through a (reduce) function that does some minor filtering.
Yet in one case the return type (from the reduce function) is
clojure.lang.PersistentArrayMap
and in the other it is clojure.lang.PersistentHashMap. I'd like to be
able to write a :post condition that enforces strictness, but that seems
impossible because I can not figure out what the rule is that handles the
conversion. I don't care if the return type is
clojure.lang.PersistentArrayMap
or clojure.lang.PersistentHashMap, all I want is it for it be
consistently one or the other.
On Sunday, December 22, 2013 2:31:45 PM UTC-5, larry google groups wrote:
I am surprised that a map literal is clojure.lang.PersistentArrayMap
but as soon as I assign it to a var, it becomes
clojure.lang.PersistentHashMap.
Are there any rules for being able to predict when these conversions
occur?
user (type {})
clojure.lang.PersistentArrayMap
user (type {:what why?})
clojure.lang.PersistentArrayMap
user (def curious {:what why?})
#'user/curious
user (type curious)
clojure.lang.PersistentHashMap
user (def sug (assoc curious :whodoneit mikey))
#'user/sug
user (type sug)
clojure.lang.PersistentHashMap
I am curious because I wrote a (reduce) function which mostly just
builds a map:
(assoc map-of-data (:item-name next-item) next-item))
Since I was using assoc I was certain I would get
clojure.lang.PersistentHashMap
back, but instead I got clojure.lang.PersistentArrayMap.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+u...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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
Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap
I find this surprising. I do this:
(supers %)
inside of my :post condition, and I get:
java.lang.ClassCastException: clojure.lang.PersistentHashMap cannot be cast
to java.lang.Class
at clojure.core$bases.invoke(core.clj:4985)
at clojure.core$supers.invoke(core.clj:4994)
at admin.secretary$fetch.invoke(secretary.clj:327)
How else do I find what interfaces the return value might be implementing?
On Monday, December 23, 2013 10:04:54 PM UTC-5, larry google groups wrote:
enforce that the return is a subtype of java.util.Map rather than
checking for a specific concrete class of map.
Thank you. I'll do that. All the same, can anyone tell me why this
function changes the type of the value? All it does is call fetch. The
fetch function has this post condition:
:post [(= (type %) clojure.lang.PersistentHashMap)]}
And get-distinct has the same restriction, but in get-distinct I get
this error:
java.lang.AssertionError: Assert failed: (= (type %)
clojure.lang.PersistentHashMap)
at admin.controller$get_distinct.invoke(controller.clj:40)
The :post condition of fetch does not throw an error, so I know that
fetch is returning clojure.lang.PersistentHashMap. However, when I print
the return type of get-distinct, I am amazed to see that it is
now clojure.lang.PersistentArrayMap. This function does almost nothing, so
I am surprised it changes the concrete implementation type of the return
value.
On Monday, December 23, 2013 3:43:09 AM UTC-5, Cedric Greevey wrote:
The two classes have essentially the same semantics, but performance
differences, which is why Clojure sometimes uses one and sometimes the
other. If you want to enforce that a map is returned, enforce that the
return is a subtype of java.util.Map rather than checking for a specific
concrete class of map.
On Sun, Dec 22, 2013 at 3:07 PM, larry google groups
lawrenc...@gmail.com wrote:
Hmm, I see. get-distinct was returning an empty lazyseq, which
apparently made the difference.
On Sunday, December 22, 2013 2:56:01 PM UTC-5, larry google groups wrote:
Hmm, the different return types seem tied to the 2 different functions
being called, but both functions have the same return type, which is a
lazyseq. I am using Monger to get data from MongoDb. These functions are
private:
(defn- get-distinct [request]
{:pre [(= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/get-distinct (:item-type request)))
(defn- paginate-results [request]
{:pre [ (= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/paginate-results (:item-type request) (if (:which-page
request)
(:which-page request)
0)))
Both of these functions return lazyseqs, as expected. The results from
both get run through a (reduce) function that does some minor filtering.
Yet in one case the return type (from the reduce function) is
clojure.lang.PersistentArrayMap
and in the other it is clojure.lang.PersistentHashMap. I'd like to be
able to write a :post condition that enforces strictness, but that seems
impossible because I can not figure out what the rule is that handles the
conversion. I don't care if the return type is
clojure.lang.PersistentArrayMap
or clojure.lang.PersistentHashMap, all I want is it for it be
consistently one or the other.
On Sunday, December 22, 2013 2:31:45 PM UTC-5, larry google groups
wrote:
I am surprised that a map literal is clojure.lang.PersistentArrayMap
but as soon as I assign it to a var, it becomes
clojure.lang.PersistentHashMap.
Are there any rules for being able to predict when these conversions
occur?
user (type {})
clojure.lang.PersistentArrayMap
user (type {:what why?})
clojure.lang.PersistentArrayMap
user (def curious {:what why?})
#'user/curious
user (type curious)
clojure.lang.PersistentHashMap
user (def sug (assoc curious :whodoneit mikey))
#'user/sug
user (type sug)
clojure.lang.PersistentHashMap
I am curious because I wrote a (reduce) function which mostly just
builds a map:
(assoc map-of-data (:item-name next-item) next-item))
Since I was using assoc I was certain I would get
clojure.lang.PersistentHashMap
back, but instead I got clojure.lang.PersistentArrayMap.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups Clojure group.
To
Re: Library can depend on an older version of itself?
Since it's just temporary, maybe create a temporary namespace hierarchy with the old version of the compiler. This would be a terrible sin if you intended for that code to stick around but if you promise you will throw away the older version once you don't need it anymore... On Mon, Dec 23, 2013 at 4:18 PM, Michael Bradley, Jr. michaelsbradle...@gmail.com wrote: I’m writing a parser that will be easier to write with itself, but I want to be able to “freeze” an earlier version that’s passing all the tests (for features implemented so far) and which is implemented quite differently. The older version can then be used as the basis for the next version, and that version in turn as the basis for the version after next, and so on. -- Michael Bradley, Jr. @michaelsbradley On Dec 23, 2013, at 18:12, James Reeves ja...@booleanknot.com wrote: I don't have any suggestions as to how this might be achieved, I'm afraid, but I am very curious as to *why* you'd want to do this. - James On 24 December 2013 00:07, Michael Bradley, Jr. michaelsbradle...@gmail.com wrote: Is there a straightforward way to setup a Clojure library so that it can depend on an older version of itself? I can think of a couple of ways to do this that seem clunky, but was wondering what approaches (if any) have worked well for other folks. Something involving pomegranate and clojure.tools.namespace? -- Michael Bradley @michaelsbradley -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/OFwMQ5apN0Y/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap
You mean (supers (type %)) ?
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org
From: larry google groups
Sent: Monday, December 23, 2013 7:28 PM
To: clojure@googlegroups.com
I find this surprising. I do this:
(supers %)
inside of my :post condition, and I get:
java.lang.ClassCastException: clojure.lang.PersistentHashMap cannot be cast to
java.lang.Class
at clojure.core$bases.invoke(core.clj:4985)
at clojure.core$supers.invoke(core.clj:4994)
at admin.secretary$fetch.invoke(secretary.clj:327)
How else do I find what interfaces the return value might be implementing?
On Monday, December 23, 2013 10:04:54 PM UTC-5, larry google groups wrote:
enforce that the return is a subtype of java.util.Map rather than checking
for a specific concrete class of map.
Thank you. I'll do that. All the same, can anyone tell me why this function
changes the type of the value? All it does is call fetch. The fetch function
has this post condition:
:post [(= (type %) clojure.lang.PersistentHashMap)]}
And get-distinct has the same restriction, but in get-distinct I get this
error:
java.lang.AssertionError: Assert failed: (= (type %)
clojure.lang.PersistentHashMap)
at admin.controller$get_distinct.invoke(controller.clj:40)
The :post condition of fetch does not throw an error, so I know that fetch
is returning clojure.lang.PersistentHashMap. However, when I print the return
type of get-distinct, I am amazed to see that it is now
clojure.lang.PersistentArrayMap. This function does almost nothing, so I am
surprised it changes the concrete implementation type of the return value.
On Monday, December 23, 2013 3:43:09 AM UTC-5, Cedric Greevey wrote:
The two classes have essentially the same semantics, but performance
differences, which is why Clojure sometimes uses one and sometimes the other.
If you want to enforce that a map is returned, enforce that the return is a
subtype of java.util.Map rather than checking for a specific concrete class of
map.
On Sun, Dec 22, 2013 at 3:07 PM, larry google groups lawrenc...@gmail.com
wrote:
Hmm, I see. get-distinct was returning an empty lazyseq, which apparently made
the difference.
On Sunday, December 22, 2013 2:56:01 PM UTC-5, larry google groups wrote:
Hmm, the different return types seem tied to the 2 different functions being
called, but both functions have the same return type, which is a lazyseq. I am
using Monger to get data from MongoDb. These functions are private:
(defn- get-distinct [request]
{:pre [(= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/get-distinct (:item-type request)))
(defn- paginate-results [request]
{:pre [ (= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/paginate-results (:item-type request) (if (:which-page request)
(:which-page request)
0)))
Both of these functions return lazyseqs, as expected. The results from both get
run through a (reduce) function that does some minor filtering. Yet in one case
the return type (from the reduce function) is clojure.lang.PersistentArrayMap
and in the other it is clojure.lang.PersistentHashMap. I'd like to be able to
write a :post condition that enforces strictness, but that seems impossible
because I can not figure out what the rule is that handles the conversion. I
don't care if the return type is clojure.lang.PersistentArrayMap or
clojure.lang.PersistentHashMap, all I want is it for it be consistently one or
the other.
On Sunday, December 22, 2013 2:31:45 PM UTC-5, larry google groups wrote:
I am surprised that a map literal is clojure.lang.PersistentArrayMap but as
soon as I assign it to a var, it becomes clojure.lang.PersistentHashMap. Are
there any rules for being able to predict when these conversions occur?
user (type {})
clojure.lang.PersistentArrayMap
user (type {:what why?})
clojure.lang.PersistentArrayMap
user (def curious {:what why?})
#'user/curious
user (type curious)
clojure.lang.PersistentHashMap
user (def sug (assoc curious :whodoneit mikey))
#'user/sug
user (type sug)
clojure.lang.PersistentHashMap
I am curious because I wrote a (reduce) function which mostly just builds a
map:
(assoc map-of-data (:item-name next-item) next-item))
Since I was using assoc I was certain I would get
clojure.lang.PersistentHashMap back, but instead I got
clojure.lang.PersistentArrayMap.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient
Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap
;; persistent maps only
(instance? clojure.lang.IPersistentMap %)
;; all Java maps
(instance? java.util.Map %)
On 24 December 2013 04:28, larry google groups
lawrencecloj...@gmail.com wrote:
I find this surprising. I do this:
(supers %)
inside of my :post condition, and I get:
java.lang.ClassCastException: clojure.lang.PersistentHashMap cannot be cast
to java.lang.Class
at clojure.core$bases.invoke(core.clj:4985)
at clojure.core$supers.invoke(core.clj:4994)
at admin.secretary$fetch.invoke(secretary.clj:327)
How else do I find what interfaces the return value might be implementing?
On Monday, December 23, 2013 10:04:54 PM UTC-5, larry google groups wrote:
enforce that the return is a subtype of java.util.Map rather than
checking for a specific concrete class of map.
Thank you. I'll do that. All the same, can anyone tell me why this
function changes the type of the value? All it does is call fetch. The
fetch function has this post condition:
:post [(= (type %) clojure.lang.PersistentHashMap)]}
And get-distinct has the same restriction, but in get-distinct I get
this error:
java.lang.AssertionError: Assert failed: (= (type %)
clojure.lang.PersistentHashMap)
at admin.controller$get_distinct.invoke(controller.clj:40)
The :post condition of fetch does not throw an error, so I know that
fetch is returning clojure.lang.PersistentHashMap. However, when I print
the return type of get-distinct, I am amazed to see that it is now
clojure.lang.PersistentArrayMap. This function does almost nothing, so I am
surprised it changes the concrete implementation type of the return value.
On Monday, December 23, 2013 3:43:09 AM UTC-5, Cedric Greevey wrote:
The two classes have essentially the same semantics, but performance
differences, which is why Clojure sometimes uses one and sometimes the
other. If you want to enforce that a map is returned, enforce that the
return is a subtype of java.util.Map rather than checking for a specific
concrete class of map.
On Sun, Dec 22, 2013 at 3:07 PM, larry google groups
lawrenc...@gmail.com wrote:
Hmm, I see. get-distinct was returning an empty lazyseq, which
apparently made the difference.
On Sunday, December 22, 2013 2:56:01 PM UTC-5, larry google groups
wrote:
Hmm, the different return types seem tied to the 2 different functions
being called, but both functions have the same return type, which is a
lazyseq. I am using Monger to get data from MongoDb. These functions are
private:
(defn- get-distinct [request]
{:pre [(= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/get-distinct (:item-type request)))
(defn- paginate-results [request]
{:pre [ (= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/paginate-results (:item-type request) (if (:which-page
request)
(:which-page request)
0)))
Both of these functions return lazyseqs, as expected. The results from
both get run through a (reduce) function that does some minor filtering.
Yet
in one case the return type (from the reduce function) is
clojure.lang.PersistentArrayMap and in the other it is
clojure.lang.PersistentHashMap. I'd like to be able to write a :post
condition that enforces strictness, but that seems impossible because I
can
not figure out what the rule is that handles the conversion. I don't care
if
the return type is clojure.lang.PersistentArrayMap or
clojure.lang.PersistentHashMap, all I want is it for it be consistently
one
or the other.
On Sunday, December 22, 2013 2:31:45 PM UTC-5, larry google groups
wrote:
I am surprised that a map literal is clojure.lang.PersistentArrayMap
but as soon as I assign it to a var, it becomes
clojure.lang.PersistentHashMap. Are there any rules for being able to
predict when these conversions occur?
user (type {})
clojure.lang.PersistentArrayMap
user (type {:what why?})
clojure.lang.PersistentArrayMap
user (def curious {:what why?})
#'user/curious
user (type curious)
clojure.lang.PersistentHashMap
user (def sug (assoc curious :whodoneit mikey))
#'user/sug
user (type sug)
clojure.lang.PersistentHashMap
I am curious because I wrote a (reduce) function which mostly just
builds a map:
(assoc map-of-data (:item-name next-item) next-item))
Since I was using assoc I was certain I would get
clojure.lang.PersistentHashMap back, but instead I got
clojure.lang.PersistentArrayMap.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this
Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap
On 24 December 2013 07:35, Michał Marczyk michal.marc...@gmail.com wrote:
;; persistent maps only
(instance? clojure.lang.IPersistentMap %)
Additionally, this one's better written
(map? %)
(map? is in fact defined as instance? IPM.)
Cheers,
M.
;; all Java maps
(instance? java.util.Map %)
On 24 December 2013 04:28, larry google groups
lawrencecloj...@gmail.com wrote:
I find this surprising. I do this:
(supers %)
inside of my :post condition, and I get:
java.lang.ClassCastException: clojure.lang.PersistentHashMap cannot be cast
to java.lang.Class
at clojure.core$bases.invoke(core.clj:4985)
at clojure.core$supers.invoke(core.clj:4994)
at admin.secretary$fetch.invoke(secretary.clj:327)
How else do I find what interfaces the return value might be implementing?
On Monday, December 23, 2013 10:04:54 PM UTC-5, larry google groups wrote:
enforce that the return is a subtype of java.util.Map rather than
checking for a specific concrete class of map.
Thank you. I'll do that. All the same, can anyone tell me why this
function changes the type of the value? All it does is call fetch. The
fetch function has this post condition:
:post [(= (type %) clojure.lang.PersistentHashMap)]}
And get-distinct has the same restriction, but in get-distinct I get
this error:
java.lang.AssertionError: Assert failed: (= (type %)
clojure.lang.PersistentHashMap)
at admin.controller$get_distinct.invoke(controller.clj:40)
The :post condition of fetch does not throw an error, so I know that
fetch is returning clojure.lang.PersistentHashMap. However, when I print
the return type of get-distinct, I am amazed to see that it is now
clojure.lang.PersistentArrayMap. This function does almost nothing, so I am
surprised it changes the concrete implementation type of the return value.
On Monday, December 23, 2013 3:43:09 AM UTC-5, Cedric Greevey wrote:
The two classes have essentially the same semantics, but performance
differences, which is why Clojure sometimes uses one and sometimes the
other. If you want to enforce that a map is returned, enforce that the
return is a subtype of java.util.Map rather than checking for a specific
concrete class of map.
On Sun, Dec 22, 2013 at 3:07 PM, larry google groups
lawrenc...@gmail.com wrote:
Hmm, I see. get-distinct was returning an empty lazyseq, which
apparently made the difference.
On Sunday, December 22, 2013 2:56:01 PM UTC-5, larry google groups
wrote:
Hmm, the different return types seem tied to the 2 different functions
being called, but both functions have the same return type, which is a
lazyseq. I am using Monger to get data from MongoDb. These functions are
private:
(defn- get-distinct [request]
{:pre [(= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/get-distinct (:item-type request)))
(defn- paginate-results [request]
{:pre [ (= (type request) clojure.lang.PersistentHashMap)]
:post [(= (type %) clojure.lang.LazySeq)]}
(monger/paginate-results (:item-type request) (if (:which-page
request)
(:which-page request)
0)))
Both of these functions return lazyseqs, as expected. The results from
both get run through a (reduce) function that does some minor filtering.
Yet
in one case the return type (from the reduce function) is
clojure.lang.PersistentArrayMap and in the other it is
clojure.lang.PersistentHashMap. I'd like to be able to write a :post
condition that enforces strictness, but that seems impossible because I
can
not figure out what the rule is that handles the conversion. I don't
care if
the return type is clojure.lang.PersistentArrayMap or
clojure.lang.PersistentHashMap, all I want is it for it be consistently
one
or the other.
On Sunday, December 22, 2013 2:31:45 PM UTC-5, larry google groups
wrote:
I am surprised that a map literal is clojure.lang.PersistentArrayMap
but as soon as I assign it to a var, it becomes
clojure.lang.PersistentHashMap. Are there any rules for being able to
predict when these conversions occur?
user (type {})
clojure.lang.PersistentArrayMap
user (type {:what why?})
clojure.lang.PersistentArrayMap
user (def curious {:what why?})
#'user/curious
user (type curious)
clojure.lang.PersistentHashMap
user (def sug (assoc curious :whodoneit mikey))
#'user/sug
user (type sug)
clojure.lang.PersistentHashMap
I am curious because I wrote a (reduce) function which mostly just
builds a map:
(assoc map-of-data (:item-name next-item) next-item))
Since I was using assoc I was certain I would get
clojure.lang.PersistentHashMap back, but instead I got
clojure.lang.PersistentArrayMap.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
Note that
