Re: bug in clojure.zip when calling next on empty list node?

[Cedric Greevey]

On Sun, Dec 22, 2013 at 12:26 PM, Lee Spector 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". :)

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

[Cedric Greevey]

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.

[Manuel Paccagnella]

Just a link to the Gilad Bracha post Richard Cole is referring to: Types 
Are Anti-Modular
.

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.

[Korny Sietsma]

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  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 fr

Re: How to go about 'proving' why dynamically typed languages are better.

[Jon Harrop]

Do you guys have any concrete examples?

Sent from my iPhone

On 23 Dec 2013, at 10:13, Korny Sietsma  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  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 emai

Re: How to go about 'proving' why dynamically typed languages are better.

[Luc Prefontaine]

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

Re: Implementation options for auto-complete and symbol resolution while coding

[Robert Ewald]

"juan.facorro"  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.

[Mikera]

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-Modular
> .
>
> 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

[Laurent PETIT]

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 

> 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
> pr

Re: bug in clojure.zip when calling next on empty list node?

[Lee Spector]

On Dec 23, 2013, at 3:40 AM, Cedric Greevey wrote:
> On Sun, Dec 22, 2013 at 12:26 PM, Lee Spector  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?

[juan.facorro]

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, n

Re: Implementation options for auto-complete and symbol resolution while coding

[Juan Martín]

*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 wrote:

> 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 
>
>> 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 approa

Re: How do I fix *warn-on-reflextion* warnings in 3rd party libraries?

[juan.facorro]

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/r

Re: How to go about 'proving' why dynamically typed languages are better.

[Mars0i]

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

[Stephen Cagle]

< 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.

[Mark Hamstra]

>
> 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.

[Michael Swierczek]

>
> 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.

[Mars0i]

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

[Colin Fleming]

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  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 
> wrote:
>
>>  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 y

Re: How to go about 'proving' why dynamically typed languages are better.

[Chris Zheng]

@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  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--i

Re: How to go about 'proving' why dynamically typed languages are better.

[Ben Wolfson]

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  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  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 mee

Re: How to go about 'proving' why dynamically typed languages are better.

[Angel Java Lopez]

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  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.

[Chris Zheng]

@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  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, 

Re: How to go about 'proving' why dynamically typed languages are better.

[Ben Wolfson]

On Mon, Dec 23, 2013 at 2:34 PM, Chris Zheng  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.

[Rich Morin]

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.

[Mars0i]

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?

[Michael Bradley, Jr.]

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?

[James Reeves]

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.  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?

[Michael Bradley, Jr.]

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  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.  
> 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.

[Chris Zheng]

>>  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.

[Rich Morin]

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?

[Sean Corfield]

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  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 ct

Re: How do I fix *warn-on-reflextion* warnings in 3rd party libraries?

[larry google groups]

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

[larry google groups]

> 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 
> 
> > 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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_o

Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap

[larry google groups]

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 G

Re: Library can depend on an older version of itself?

[Robert Levy]

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

[seancorfield]

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

[Michał Marczyk]

;; persistent maps only
(instance? clojure.lang.IPersistentMap %)

;; all Java maps
(instance? java.util.Map %)

On 24 December 2013 04:28, larry google groups
 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
>>>  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 wa

Re: When does clojure.lang.PersistentArrayMap become clojure.lang.PersistentHashMap

[Michał Marczyk]

On 24 December 2013 07:35, Michał Marczyk  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
>  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
  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 :whodone