Ethereum

[jTA]

Has anyone a clojure-based project underway (or contemplating one) within 
the Ethereum context?
Ethereum background accessible here:  http://www.ethereum.org/   
http://blog.ethereum.org/

-- 
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: map semantics

[Mars0i]

Maybe physical identity is too strong of a requirement for equality.  So 
another way to think about it is that it's 'hash-set', 'set', and '#{}' 
that are--you know--"broken", but that there's a fix, which is to always 
use 'sorted-set'.  (I'm assuming that calling 'seq' on any two sorted sets 
that are = always returns seqs that are =.)

(Don't take offense at the tone of my remarks.  I think we're all on the 
same side here.)

On Saturday, February 8, 2014 10:14:37 PM UTC-6, Mars0i wrote:
>
> Maybe another way to put it is that what is, uh, "broken" isn't 'map' or 
> 'seq', but '=', which is willing to tell you that two things (sets) are the 
> same when they're not!  We also have the non-broken predicate 'identical?', 
> however, that gets it right.  It's nice to also have a set-equal predicate, 
> which ignores differences in how sets are stored, and ... that's what '=' 
> is!  However, if we interpret '=' as implying that when the same function 
> is applied to things that are "equal" in its sense, then we are making a 
> mistake: '=' doesn't mean that.  According to this reasoning, nothing here 
> is broken, even from an extra-linguistic perspective.  '=' just shouldn't 
> be misunderstood.  (In a language with different design and style goals, it 
> might been preferable to define "=" to mean what Clojure means by 
> 'identical?', and use something else--perhaps "equivalent?"--for a 
> predicate analogous to Clojure's '='.)
>

-- 
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: What's the status of clojure for Android?

[Gary Trakhman]

if Qt supports js's eval, then it's also possible to support a repl.


On Sat, Feb 8, 2014 at 10:29 PM, Zach Oakes  wrote:

> That might work for some people, but as you mentioned, you wouldn't get to
> build your app in a REPL. Also, you'd lose access to the concurrency
> features of Clojure, and would probably also not get to use native Android
> APIs.
>
>
> On Saturday, February 8, 2014 9:57:38 PM UTC-5, curiousGuy wrote:
>>
>> Another interesting consideration regarding Clojure on Android (or any
>> other local OS)...
>>
>> As of Qt 5, Javascript is a first-class language for developing apps, and
>> Qt 5 officially supports Android, iOS, in addition to its prior support for
>> OSX, Windows, Linux, etc. You can get nearly all app logic working in JS if
>> you wish (and many do just that).
>>
>> So I see no reason you couldn't use ClojureScript to design Android apps,
>> and dump the compiled code into Qt. You'd simply need to know the Qt Quick
>> UI bindings that are accessible via Javascript. The new UI kit can
>> automatically handle fluid UI animations and other modern mobile styles.
>>
>> Of course, you still must compile in Qt before the app runs on any OS, so
>> a REPL probably wouldn't be a fit for this workflow.
>>
>> On Tuesday, February 4, 2014 11:48:55 AM UTC+8, Zach Oakes wrote:
>>>
>>> Alex put together a great website that may answer your questions:
>>>
>>> http://clojure-android.info/
>>>
>>> If you have any questions afterwards, feel free to post to the
>>> clojure-android group:
>>>
>>> https://groups.google.com/forum/#!forum/clojure-android
>>>
>>> On Monday, February 3, 2014 3:17:46 PM UTC-5, Erlis Vidal wrote:

 Hi group,

 I'll be starting a project in Android and I was wondering if I could
 use clojure as my programming language. Any update/recommendation about
 this. Will the application have acceptable performance? If not the entire
 app, can I write at least some libraries in clojure and call them from my
 java code?

 Thanks!
 Erlis

>>>  --
> 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: map semantics

[Mars0i]

Maybe another way to put it is that what is, uh, "broken" isn't 'map' or 
'seq', but '=', which is willing to tell you that two things (sets) are the 
same when they're not!  We also have the non-broken predicate 'identical?', 
however, that gets it right.  It's nice to also have a set-equal predicate, 
which ignores differences in how sets are stored, and ... that's what '=' 
is!  However, if we interpret '=' as implying that when the same function 
is applied to things that are "equal" in its sense, then we are making a 
mistake: '=' doesn't mean that.  According to this reasoning, nothing here 
is broken, even from an extra-linguistic perspective.  '=' just shouldn't 
be misunderstood.  (In a language with different design and style goals, it 
might been preferable to define "=" to mean what Clojure means by 
'identical?', and use something else--perhaps "equivalent?"--for a 
predicate analogous to Clojure's '='.)

-- 
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: What's the status of clojure for Android?

[Zach Oakes]

That might work for some people, but as you mentioned, you wouldn't get to 
build your app in a REPL. Also, you'd lose access to the concurrency 
features of Clojure, and would probably also not get to use native Android 
APIs.

On Saturday, February 8, 2014 9:57:38 PM UTC-5, curiousGuy wrote:
>
> Another interesting consideration regarding Clojure on Android (or any 
> other local OS)...
>
> As of Qt 5, Javascript is a first-class language for developing apps, and 
> Qt 5 officially supports Android, iOS, in addition to its prior support for 
> OSX, Windows, Linux, etc. You can get nearly all app logic working in JS if 
> you wish (and many do just that).
>
> So I see no reason you couldn't use ClojureScript to design Android apps, 
> and dump the compiled code into Qt. You'd simply need to know the Qt Quick 
> UI bindings that are accessible via Javascript. The new UI kit can 
> automatically handle fluid UI animations and other modern mobile styles.
>
> Of course, you still must compile in Qt before the app runs on any OS, so 
> a REPL probably wouldn't be a fit for this workflow.
>
> On Tuesday, February 4, 2014 11:48:55 AM UTC+8, Zach Oakes wrote:
>>
>> Alex put together a great website that may answer your questions:
>>
>> http://clojure-android.info/
>>
>> If you have any questions afterwards, feel free to post to the 
>> clojure-android group:
>>
>> https://groups.google.com/forum/#!forum/clojure-android
>>
>> On Monday, February 3, 2014 3:17:46 PM UTC-5, Erlis Vidal wrote:
>>>
>>> Hi group, 
>>>
>>> I'll be starting a project in Android and I was wondering if I could use 
>>> clojure as my programming language. Any update/recommendation about this. 
>>> Will the application have acceptable performance? If not the entire app, 
>>> can I write at least some libraries in clojure and call them from my java 
>>> code? 
>>>
>>> Thanks!
>>> Erlis 
>>>
>>

-- 
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: map semantics

[Andy C]

I can ensure all of you that it is very uncomfortable for a newcomer with a
goofy nick to just come in and say things are broke LOL . So at that point
I have two choices:

1) as suggested, find another programming language but that would mean that
I would have to erase my Clojure tattoo (very painful).
2) stop making enemies and pretend that seq on sets is cools and neat and
we really do not need to stick to fundeaments of FP:  a=b => f(a) = f(b) in
critical part of the language. It ain't going to happen either.

Although, the worst part about it all is that my carefully crafted piece of
software used for controlling nuclear power plants relies on Clojure set-s.
As we above some part of it is non deterministic as the calculated controls
paramters depends on the order of adding elements to set  That
literally sucks!

In any case, see you at Clojure West conference and thanks again for all
the replies,

Best regards,
Andy



-- 
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: What's the status of clojure for Android?

[curiousGuy]

Another interesting consideration regarding Clojure on Android (or any 
other local OS)...

As of Qt 5, Javascript is a first-class language for developing apps, and 
Qt 5 officially supports Android, iOS, in addition to its prior support for 
OSX, Windows, Linux, etc. You can get nearly all app logic working in JS if 
you wish (and many do just that).

So I see no reason you couldn't use ClojureScript to design Android apps, 
and dump the compiled code into Qt. You'd simply need to know the Qt Quick 
UI bindings that are accessible via Javascript. The new UI kit can 
automatically handle fluid UI animations and other modern mobile styles.

Of course, you still must compile in Qt before the app runs on any OS, so a 
REPL probably wouldn't be a fit for this workflow.

On Tuesday, February 4, 2014 11:48:55 AM UTC+8, Zach Oakes wrote:
>
> Alex put together a great website that may answer your questions:
>
> http://clojure-android.info/
>
> If you have any questions afterwards, feel free to post to the 
> clojure-android group:
>
> https://groups.google.com/forum/#!forum/clojure-android
>
> On Monday, February 3, 2014 3:17:46 PM UTC-5, Erlis Vidal wrote:
>>
>> Hi group, 
>>
>> I'll be starting a project in Android and I was wondering if I could use 
>> clojure as my programming language. Any update/recommendation about this. 
>> Will the application have acceptable performance? If not the entire app, 
>> can I write at least some libraries in clojure and call them from my java 
>> code? 
>>
>> Thanks!
>> Erlis 
>>
>

-- 
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: ANN: core.logic 0.8.6

[Plínio Balduino]

Thank you

Plinio Balduino
11 982 611 487

> On 08/02/2014, at 19:29, David Nolen  wrote:
> 
> My honest suggestion is to get a copies of The Reasoned Schemer, The Art of 
> Prolog, and Concepts Techniques & Models of Computer Programming. They cover 
> the terrain far better than any documentation or tutorial can.
> 
> David
> 
> 
>> On Sat, Feb 8, 2014 at 4:26 PM, Plínio Balduino  wrote:
>> David, first of all, congratulations for core.logic. 
>> 
>> I would like to start with logic programming, but the texts I found aren't 
>> for starters like me, even though I have a good experience as software 
>> developer and functional programming is not a mistery anymore. What would 
>> you recommend for someone who wants to try and understand core.logic?
>> 
>> Thank you
>> 
>> Plinio Balduino
>> 
>> 
>>> On Saturday, February 8, 2014, David Nolen  wrote:
>>> The main change is the introduction of a new protocol IVerifyConstraint. 
>>> Implementations of it will be called before a constraint is added to the 
>>> constraint store - this is the hook needed for detecting incompatible 
>>> constraints.
>>> 
>>> More information here: http://github.com/clojure/core.logic
>>> 
>>> Feedback welcome!
>>> -- 
>>> 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.
> 
> -- 
> 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: a problem about Redis client: com.taoensso/carmine

[tao]

after use your solution, I looked up the source code of carmine and found that:

(wcar* (car/hgetall* "yyy" true))

can get what I want.

Thank you!  

--  
tao
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Sunday, February 9, 2014 at 9:34 AM, tao wrote:

> Thank you very much!
>  
> --  
> tao
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
>  
>  
> On Sunday, February 9, 2014 at 1:06 AM, mynomoto wrote:
>  
> > You can use:
> >  
> > (into {} (map (fn [[k v]] [(keyword k) v]) {"pass" "yy", "yyy" "yyy"}))
> >  
> > On Saturday, February 8, 2014 2:34:44 PM UTC-2, Tao Zhou wrote:
> > > lein try com.taoensso/carmine ;; try is from 
> > > https://github.com/rkneufeld/lein-try  
> > >  
> > >  
> > > (def server-connection {:pool {:max-active 8}
> > >:spec {:host "localhost"  
> > >   :port 6379  
> > >   :timeout 4000}})  
> > >  
> > > (require '[taoensso.carmine :as car :refer (wcar)])  
> > >  
> > > (defmacro wcar* [& body] `(car/wcar server-connection ~@body))  
> > >  
> > > (wcar* (car/hmset* "yyy" {:yyy "yyy", :pass "yy"}))  
> > >  
> > > (wcar* (car/hgetall "yyy”))  
> > > ["pass" "yy" "yyy" "yyy”]
> > >  
> > > (wcar* (car/hgetall* "yyy”)) 
> > > {"pass" "yy", "yyy" "yyy”}
> > >  
> > >  
> > > But what I want (or expect) is what I set before:
> > > {:yyy "yyy", :pass "yy"}  
> > >  
> > > Who can help me? Thank you very much!   
> >  
> > --  
> > 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 
> > (mailto: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 
> > (mailto: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 
> > (mailto: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: a problem about Redis client: com.taoensso/carmine

[tao]

Thank you very much!

--  
tao
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Sunday, February 9, 2014 at 1:06 AM, mynomoto wrote:

> You can use:
>  
> (into {} (map (fn [[k v]] [(keyword k) v]) {"pass" "yy", "yyy" "yyy"}))
>  
> On Saturday, February 8, 2014 2:34:44 PM UTC-2, Tao Zhou wrote:
> > lein try com.taoensso/carmine ;; try is from 
> > https://github.com/rkneufeld/lein-try  
> >  
> >  
> > (def server-connection {:pool {:max-active 8}
> >:spec {:host "localhost"  
> >   :port 6379  
> >   :timeout 4000}})  
> >  
> > (require '[taoensso.carmine :as car :refer (wcar)])  
> >  
> > (defmacro wcar* [& body] `(car/wcar server-connection ~@body))  
> >  
> > (wcar* (car/hmset* "yyy" {:yyy "yyy", :pass "yy"}))  
> >  
> > (wcar* (car/hgetall "yyy”))  
> > ["pass" "yy" "yyy" "yyy”]
> >  
> > (wcar* (car/hgetall* "yyy”)) 
> > {"pass" "yy", "yyy" "yyy”}
> >  
> >  
> > But what I want (or expect) is what I set before:
> > {:yyy "yyy", :pass "yy"}  
> >  
> > Who can help me? Thank you very much!   
>  
> --  
> 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 
> (mailto: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 
> (mailto: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 
> (mailto: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: map semantics

[John Mastro]

To add just one more thing to this: Referential transparency is clearly
valuable, but it's not the *only* valuable property a function or system might
have. There are always tradeoffs to be made. Clojure has made different
tradeoffs than you expected, or would yourself have made, but that doesn't
/a priori/ mean they're wrong.

- John

John Mastro  wrote:
> Hi Andy,
>
> Andy C  wrote:
>>
>>
>>> user> (= s1 s2)
>>> true
>>> user> (= (seq s1) (seq s2))
>>> false
>>
>>
>> Thx. If a=b  then f(a) must = f(b). Something is broken here.
>
> If a seq is a sequential view of a thing, and a set is an unordered thing, 
> then
> it does not seem shocking to me that multiple sequential views of a given set,
> with different orderings, are possible.
>
> This may not be the only way to do things; and it may not be the way other
> languages do it; and it may not match your preference. But I think it's 
> clearly
> wrong to say that it's internally inconsistent or "broken".
>
> It's perhaps hard to say this without sounding condescending, but rather than
> seeking to identify all the ways in which Clojure isn't Haskell, it might be
> more useful to pursue an understanding of Clojure (including its
> definitely-not-nonexistent flaws!) on its own terms.
>
> - John

-- 
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: map semantics

[John Mastro]

Hi Andy,

Andy C  wrote:
>
>
>> user> (= s1 s2)
>> true
>> user> (= (seq s1) (seq s2))
>> false
>
>
> Thx. If a=b  then f(a) must = f(b). Something is broken here.

If a seq is a sequential view of a thing, and a set is an unordered thing, then
it does not seem shocking to me that multiple sequential views of a given set,
with different orderings, are possible.

This may not be the only way to do things; and it may not be the way other
languages do it; and it may not match your preference. But I think it's clearly
wrong to say that it's internally inconsistent or "broken".

It's perhaps hard to say this without sounding condescending, but rather than
seeking to identify all the ways in which Clojure isn't Haskell, it might be
more useful to pursue an understanding of Clojure (including its
definitely-not-nonexistent flaws!) on its own terms.

- John

-- 
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: map semantics

[Andy Fingerhut]

It is working as designed.

If you do not want this, consider using sorted sets / sorted maps, where (=
s1 s2) implies (= (seq s1) (seq s2)).

Or, perhaps another programming language would be more to your liking.

Andy


On Sat, Feb 8, 2014 at 4:10 PM, Andy C  wrote:

>
> user> (= s1 s2)
>> true
>> user> (= (seq s1) (seq s2))
>> false
>>
>
> Thx. If a=b  then f(a) must = f(b). Something is broken here.
>
>  --
> 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: map semantics

[Andy C]

> user> (= s1 s2)
> true
> user> (= (seq s1) (seq s2))
> false
>

Thx. If a=b  then f(a) must = f(b). Something is broken here.

-- 
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: map semantics

[Sean Corfield]

On Feb 8, 2014, at 7:59 AM, Andy C  wrote:
> Your assertion that I "am misunderstanding something" is wrong.

Now that you've seen everyone else's responses, perhaps you understand my 
assertion was correct? :)

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: map semantics

[Jozef Wagner]

Well it does not break referential transparency if both equalities (for 
input values and for results) are of a same kind. You would have to compare 
inputs by value and outputs by identity, if you want to percieve an 
inconsistency.

JW

On Saturday, February 8, 2014 6:49:39 PM UTC+1, Andy Fingerhut wrote:
>
> This might be too detailed a point, but I wanted to mention that while you 
> will always get the same order for the same collection (same as determined 
> by identical?, or Java ==, i.e. it is the same object in memory), you are 
> *not* guaranteed to get the same order for collections of the same type 
> that are equal to each other as determined by Clojure = or Java .equals.  
> In particular, if two values have the same hash value, then if they are 
> used as a set in a Clojure PersistentHashSet or a key in a 
> PersistentHashKey, they are put into a linear list in a hash bucket for 
> that hash value, and their order in that list can be different in different 
> sets/maps, and the order that (seq ...) returns on those sets/maps will be 
> different.
>
> I am not certain, but this might violate referential transparency 
> (replacing a value that is equals for another value in an expression will 
> always give you an equal result).
>
> I was curious whether anyone knows whether Haskell has hash-based data 
> structures like this, and do they somehow guarantee referential 
> transparency?  Perhaps by requiring the items to be sortable?
>
> Andy
>
>
> On Sat, Feb 8, 2014 at 8:19 AM, Jozef Wagner 
> > wrote:
>
>> Every persistent collection in Clojure supports conversion to the 
>> sequence of items. This is clearly documented in the official docs and 
>> there is no surprise here.
>>
>> The order or items in the resulting sequence is dependent on the 
>> collection type. As the conversion to the sequence is a referentially 
>> transparent function, you will always get the same order for the same 
>> collection. 
>>
>> JW
>>
>> On Saturday, February 8, 2014 4:59:47 PM UTC+1, Andy C wrote:
>>
>>> On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield wrote:
>>>
 But you're misunderstanding what map does: it converts its collection
 arguments to _sequences_ and then it processes those sequences. Map
 doesn't operate on sets, or vectors, or maps, only on sequences.

>>>
>>> Your assertion that I "am misunderstanding something" is wrong.
>>>
>>> One cannot convert amorphic set into linear sequence without assuming 
>>> certain order. And as with every assumption, it always comes with some less 
>>> or more pragmatic but arbitrary decision which might change over time and 
>>> ruin peoples programs. 
>>>
>>> I would expect Clojure to throw "IllegalArgumentException Don't know how 
>>> to create ISeq from: clojure.lang.PersistentHashSet" or document it 
>>> well in map somewhere.  
>>>
>>>
>>>  "Perfection is the enemy of the good."

>>>
>>> Now judging by your sig, it all does not surprise me LOL
>>>
>>>
>>>
>>>  -- 
>> 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_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: map semantics

[Jozef Wagner]

I've forgot the most interesting part :)

user> (= s1 s2)
true
user> (= (seq s1) (seq s2))
false

JW


On Sat, Feb 8, 2014 at 11:32 PM, Jozef Wagner wrote:

> Yes. Behold a Murmur3 hash collision:
>
> user> (def n1 -2023261231)
> #'user/n1
> user> (def n2 9223372036854771971)
> #'user/n2
> user> (== (hash n1) (hash n2))
> true
> user> (def s1 (conj #{} n1 n2))
> #'user/s1
> user> (def s2 (conj #{} n2 n1))
> #'user/s2
> user> (= s1 s2)
>
> But practically, I cannot think of any scenario where you will need a
> guarantee that two unordered non identical but value equivalent collections
> need to produce same ordered seq.
>
> JW
>
>
> On Sat, Feb 8, 2014 at 10:14 PM, Andy C  wrote:
>
>> On Sat, Feb 8, 2014 at 1:46 PM, Jozef Wagner wrote:
>>
>>> Two collections equivalent by their values may easily have a different
>>> order of their items.
>>>
>>
>>
>> It all boils down this:
>>   is it possible to have two clojure.lang.PersistentHashSet with
>> identical values (in mathematical sense) but producing different seqs?
>>
>> --
>> 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: map semantics

[Jozef Wagner]

Yes. Behold a Murmur3 hash collision:

user> (def n1 -2023261231)
#'user/n1
user> (def n2 9223372036854771971)
#'user/n2
user> (== (hash n1) (hash n2))
true
user> (def s1 (conj #{} n1 n2))
#'user/s1
user> (def s2 (conj #{} n2 n1))
#'user/s2
user> (= s1 s2)

But practically, I cannot think of any scenario where you will need a
guarantee that two unordered non identical but value equivalent collections
need to produce same ordered seq.

JW


On Sat, Feb 8, 2014 at 10:14 PM, Andy C  wrote:

> On Sat, Feb 8, 2014 at 1:46 PM, Jozef Wagner wrote:
>
>> Two collections equivalent by their values may easily have a different
>> order of their items.
>>
>
>
> It all boils down this:
>   is it possible to have two clojure.lang.PersistentHashSet with identical
> values (in mathematical sense) but producing different seqs?
>
> --
> 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: Refactoring as an nREPL middleware

[Curtis Gagliardi]

Thanks, I'll definitely take a look at those libraries, I actually didn't 
do too much searching for prior art, I'll have to start now. 

You're dead on with whitespace and reader macros being a problem. I know I 
heard of someone working on trying to build a clojure formatter, so maybe 
something like that will come to fruition, otherwise I was just going to 
return something formatted in a super basic way and punt that problem to 
the user.  The reader macros though is a bigger problem that I have no idea 
how to deal with.  I ran into that with the cycle-privacy refactor.  If you 
try to read '(def ^:private a), you always get back '(def a).  I ended up 
evaling the form and calling meta on it to get the privacy, but that felt 
wrong and now that you point out #_, it's clear it's not going to work in a 
lot of cases.  I'll have to take a look at clj.tools.analyzer, thought I 
was hoping there might be some way to just turn off reader macros.  I think 
I might make a separate list post and see if anyone has ideas there. 

On Friday, February 7, 2014 3:10:49 PM UTC-8, John Hume wrote:
>
> I haven't attempted any code manipulation, just analysis and indexing, but 
> I embarked on a similar idea here: 
> https://github.com/duelinmarkers/insfactor and here: 
> http://github.com/duelinmarkers/insfactor.el. (Nothing Vim-related there, 
> the similar part is trying to put as much as possible of the smarts into 
> the same JVM as the project.) It indexes a simple clojure project and 
> provides a find-usages command, the idea being that find-usages is the 
> first useful step toward rename-var and move-var commands. (I say "simple" 
> because it still barfs on some common stuff, including defprotocol, IIRC.)
>
> Focusing on what you're doing in http://github.com/cgag/nrepl-refactor, 
> the mess I came upon and backed away from when I initially played with 
> transforming code in Clojure is that the forms are easy to manipulate but 
> formatting is hard to maintain. There are also several non-whitespace bits 
> of source that the reader will hide away from you (including comments and 
> #_ forms) but that a proper refactoring tool won't clobber.
>
> If you haven't already, you might take a look at 
> https://github.com/cgrand/sjacket.
>
> I've been hoping that the new 
> https://github.com/clojure/tools.analyzer
>  work 
> will support some of what source manipulation tools are likely to need, but 
> I haven't looked into it. For example, one hassle with 
> jvm.tools.analyzer (at least the now outdated version I've been using) is 
> that the reader doesn't provide line and column metadata in many places 
> where you'd expect to find it. Another is that it can only show you the 
> post-macro-expansion view of the world.
>
>
>
> On Fri, Feb 7, 2014 at 3:51 PM, Curtis Gagliardi 
> 
> > wrote:
>
>> Hey everyone, I just wanted to get some feedback on whether or not this 
>> is a good idea.  I've seen clj-refactor.el recommended a decent amount, but 
>> as a dyed-in-the-wool take-no-prisoners vim user, I can't use it.  I've 
>> always thought it was weird that refactoring was so tightly coupled to 
>> editors and IDEs, so I thought I'd try writing some refactors as an nrepl 
>> middleware, that would ideally be able to be used across editors.  I've 
>> only re-implemented the threading and some of the cycling refactors from 
>> clj-refactor.el, but it's to the point where I'm going to investigate 
>> actually integrating with vim or light table.  I've never written any 
>> plugins for either of these editors so I might discover there are good 
>> reasons I haven't seen refactoring done as a client/server type thing.  
>> Anyway, the code is here: https://github.com/cgag/nrepl-refactor , if 
>> anyone has any has any feedback I'd love to hear it, and if anyone has 
>> vimscript or lighttable plugin experience and wants to help, that'd be 
>> great as well.
>>
>> Curtis
>>
>> -- 
>> 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_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 

Re: map semantics

[Michael Gardner]

On Feb 8, 2014, at 15:14 , Andy C  wrote:

> It all boils down this:
>   is it possible to have two clojure.lang.PersistentHashSet with identical 
> values (in mathematical sense) but producing different seqs?

Are you serious? The entire point of the email you responded to was to answer 
that question.

("But why male models?")

-- 
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: ANN: core.logic 0.8.6

[David Nolen]

My honest suggestion is to get a copies of The Reasoned Schemer, The Art of
Prolog, and Concepts Techniques & Models of Computer Programming. They
cover the terrain far better than any documentation or tutorial can.

David


On Sat, Feb 8, 2014 at 4:26 PM, Plínio Balduino  wrote:

> David, first of all, congratulations for core.logic.
>
> I would like to start with logic programming, but the texts I found aren't
> for starters like me, even though I have a good experience as software
> developer and functional programming is not a mistery anymore. What would
> you recommend for someone who wants to try and understand core.logic?
>
> Thank you
>
> Plinio Balduino
>
>
> On Saturday, February 8, 2014, David Nolen  wrote:
>
>> The main change is the introduction of a new protocol IVerifyConstraint.
>> Implementations of it will be called before a constraint is added to the
>> constraint store - this is the hook needed for detecting incompatible
>> constraints.
>>
>> More information here: http://github.com/clojure/core.logic
>>
>> Feedback welcome!
>>
>> --
>> 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.
>

-- 
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: ANN: core.logic 0.8.6

[Plínio Balduino]

David, first of all, congratulations for core.logic.

I would like to start with logic programming, but the texts I found aren't
for starters like me, even though I have a good experience as software
developer and functional programming is not a mistery anymore. What would
you recommend for someone who wants to try and understand core.logic?

Thank you

Plinio Balduino

On Saturday, February 8, 2014, David Nolen  wrote:

> The main change is the introduction of a new protocol IVerifyConstraint.
> Implementations of it will be called before a constraint is added to the
> constraint store - this is the hook needed for detecting incompatible
> constraints.
>
> More information here: http://github.com/clojure/core.logic
>
> Feedback welcome!
>
> --
> 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.

pdf.js

[t x]

Hi,

  I've looked at the first few pages of Google results for "pdf.js
cljs" and found nothing.

  Before I start hacking on my own pdf.js bindings, I wanted to ask --
does anyone have cljs bindings to pdf.js ?

Thanks!

-- 
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: map semantics

[Andy C]

On Sat, Feb 8, 2014 at 1:46 PM, Jozef Wagner  wrote:

> Two collections equivalent by their values may easily have a different
> order of their items.
>


It all boils down this:
  is it possible to have two clojure.lang.PersistentHashSet with identical
values (in mathematical sense) but producing different seqs?

-- 
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: article about namespace still current?

[John D. Hume]

It includes this update, which I'd say brings it up to date.

" *update (4/18/2012):** As of the 1.4.0 release, there's no longer a good
reason to use use. Use require :refer instead. From the Clojure 1.4.0 *
*changelog**: "require can now take a :refer option. :refer takes a list of
symbols to refer from the namespace or :all to bring in all public **vars*
*."*"
On Feb 8, 2014 2:39 PM, "Der Engel"  wrote:

> Hi, I'm finding namespaces in Clojure a bit confusion, does know someone
> if the information in this 
> article
>  (from
> 2010) is still current with today Clojure best practices and all the idioms
> are still supported today.
>
> --
> 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: map semantics

[Jozef Wagner]

By 'same' I've meant an identical :).

Two collections equivalent by their values may easily have a different
order of their items. This is because in unordered collections, their
internal order (as any other implementation detail) must not be taken into
account when comparing for value equivalence.

user=> (def s1 #{-3 2 1})
#'user/s1
user=> (def s2 (apply sorted-set s1))
#'user/s2
user=> s1
#{1 -3 2}
user=> s2
#{-3 1 2}
user=> (identical? s1 s2)
false
user=> (= s1 s2)
true
user=> (= (seq s1) (seq s2))
false
user=> (seq s1)
(1 -3 2)
user=> (seq s2)
(-3 1 2)

JW


On Sat, Feb 8, 2014 at 9:22 PM, Andy C  wrote:

> First, thanks everybody for explanations of design decision behind map and
> collections. I should in fact change subject to seq semantics ;-).
>
> For me the bottom line is that while I do not care about order so much I
> still can count on that  seq function will produce consistent sequences. Or
> wait a sec:
>
>
>
>> This might be too detailed a point, but I wanted to mention that while
>> you will always get the same order for the same collection (same as
>> determined by identical?, or Java ==, i.e. it is the same object in
>> memory), you are *not* guaranteed to get the same order for collections of
>> the same type that are equal to each other as determined by Clojure = or
>> Java .equals.  In particular, if two values have the same hash value, then
>> if they are used as a set in a Clojure PersistentHashSet or a key in a
>> PersistentHashKey, they are put into a linear list in a hash bucket for
>> that hash value, and their order in that list can be different in different
>> sets/maps, and the order that (seq ...) returns on those sets/maps will be
>> different.
>>
>> I am not certain, but this might violate referential transparency
>> (replacing a value that is equals for another value in an expression will
>> always give you an equal result).
>>
>
>  This is not too detailed. In fact this is the ultimate question. It would
> mean that two logically identical sets can produce different LazySeq's
> depending how they came to existence ...
>
>
>  --
> 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.

article about namespace still current?

[Der Engel]

Hi, I'm finding namespaces in Clojure a bit confusion, does know someone if 
the information in this 
article
 (from 
2010) is still current with today Clojure best practices and all the idioms 
are still supported today.

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

[ANN] Parkour 0.5.4, Hadoop REPL edition

[Marshall Bockrath-Vandegrift]

Parkour is a Clojure library for writing distributed programs in the
MapReduce pattern which run on the Hadoop MapReduce platform:

https://github.com/damballa/parkour

Release 0.5.4 adds significant new features for REPL integration.
Parkour now supports connecting to a live cluster, then running
local-mode jobs, mixed-mode jobs, and remote jobs, all from the same
REPL process.  This brings Clojure’s standard REPL-based workflow to
Hadoop, enabling rapid iterative development of MapReduce applications.

Complete release notes:

https://github.com/damballa/parkour/blob/master/NEWS.md#054--2014-02-08

And a blog post discussing the new features in context:

http://blog.platypope.org/2014/2/8/interactive-hadoop-with-parkour/

Artifacts are available on Clojars.

-Marshall

-- 
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: map semantics

[Andy C]

First, thanks everybody for explanations of design decision behind map and
collections. I should in fact change subject to seq semantics ;-).

For me the bottom line is that while I do not care about order so much I
still can count on that  seq function will produce consistent sequences. Or
wait a sec:



> This might be too detailed a point, but I wanted to mention that while you
> will always get the same order for the same collection (same as determined
> by identical?, or Java ==, i.e. it is the same object in memory), you are
> *not* guaranteed to get the same order for collections of the same type
> that are equal to each other as determined by Clojure = or Java .equals.
> In particular, if two values have the same hash value, then if they are
> used as a set in a Clojure PersistentHashSet or a key in a
> PersistentHashKey, they are put into a linear list in a hash bucket for
> that hash value, and their order in that list can be different in different
> sets/maps, and the order that (seq ...) returns on those sets/maps will be
> different.
>
> I am not certain, but this might violate referential transparency
> (replacing a value that is equals for another value in an expression will
> always give you an equal result).
>

This is not too detailed. In fact this is the ultimate question. It would
mean that two logically identical sets can produce different LazySeq's
depending how they came to existence ...

-- 
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: Alternative ->> macro for threading sequences?

[Korny Sietsma]

Yeah - I'm coming to the conclusion that this idle thought didn't really
have any value. The discussion was interested though.
On 8 Feb 2014 17:30, "Gary Verhaegen"  wrote:

> For multiple calls to map, you can always do:
>
> (->> things
> (map #(-> % wrangle pacify))
> (filter effable)
> (map #(aggravate % :bees :sharks))
> (reduce mapinate {})
>
> but, as others have said, I'm not sure you can meaningfully compress that
> if you have to decide between map, filter and reduce. Perhaps implement an
> embeddable J to Clojure compiler, either as a macro reading in symbols or
> as a function reading in a string? Not sure about the amount of effort
> involved, though.
>
>
> On 8 February 2014 15:18, t x  wrote:
>
>> I think the problem is as follows:
>>
>> map = 3 characters
>> filter = 6 characters
>>
>> Given that we're doing clojure not apl, to specify the function we're
>> mapping/filtering on, we have to do either:
>>   #( ... %  ) = 5 characters off the bat
>>   or provide the name of the function (atleast 1 english word)
>>
>> Thus, even if we reduced map to M and filter to F, it's very unlikely
>> that we'll ever shorten anything by more than 50% (just given the # of
>> characters required to specify the function that we are
>> mapping/filtering on.)
>>
>>
>> From this, it seems, unless we go the APL route and make the task of
>> describing the filtering/mapping function itself very short, there's
>> almost no gain in shortening map / filter.
>>
>>
>> This isn't meant to be discouraging -- in fact, I'd love to see a way
>> to mix APL + Clojure. :-) Often times, I'm looking at a multiline
>> clojure expression and thinking: "this'd be a single line of APL."
>>
>> On Fri, Feb 7, 2014 at 8:03 PM, Mars0i  wrote:
>> > Since a few of these higher order functions--map, filter, reduce,
>> etc.--are
>> > so common and useful, I wonder whether there could be sufficient
>> benefit to
>> > having some abbreviations for them.  I know that some of these
>> characters
>> > are already taken, but just to sketch the idea:
>> >
>> > (--> things  %wrangle  %pacify  |effable  %#(aggravate % :bees :sharks)
>> > \(mapinate {}) )
>> >
>> > In one sense this reduces the visual complexity of Korny's example.  In
>> > another sense it increases it.  I thought this option was worth
>> mentioning,
>> > but I don't think I like it.  It makes the syntax closer to line noise,
>> and
>> > if there are too many magical characters, no one will remember what they
>> > mean except the people who use them all of the time (like some of the
>> > options in Perl regexps).  Why not go all the way, and provide an
>> alternate
>> > APL-style syntax for Clojure?
>> >
>> >
>> > On Friday, February 7, 2014 9:14:27 AM UTC-6, t x wrote:
>> >>
>> >> I think
>> >>
>> >> (->> things
>> >> (map wrangle)
>> >> (map pacify)
>> >> (filter effable)
>> >> (map #(aggravate % :bees :sharks))
>> >> (reduce mapinate {})
>> >>
>> >>
>> >> is optimal for the following reason:
>> >>
>> >>
>> >> If you're doing "map" and "map alone", i.e.
>> >>
>> >> (->> things
>> >>   (map f1)
>> >>   (map f2)
>> >>   (map f3)
>> >>   (map f4))
>> >>
>> >> then you can do:
>> >>
>> >> (map #(f4 (f3 (f2 (f1 % things)
>> >>
>> >>
>> >> Now, if you're not doing pure maps, i.e. maps + filters
>> >>
>> >> Then for each function call, from an information theoretic
>> >> perspective, you have to, at the very least, specify:
>> >>
>> >>   (*) the function to be called
>> >>   (*) whether it's a filter or a map
>> >>
>> >> in this case,
>> >>
>> >> what you initially have is optimal.
>> >>
>> >> On Fri, Feb 7, 2014 at 6:33 AM, Korny Sietsma 
>> wrote:
>> >> > I tend to agree, I think.  I certainly can't think of a syntax that
>> >> > would
>> >> > make me happy.  It just feels like a bit of a smell that I keep using
>> >> > ->> to
>> >> > process sequences in similar ways.
>> >> >
>> >> > The data.zip "xml->" macro is an example of something like what I'm
>> >> > thinking
>> >> > about - it lets you process sequences of xml data nicely:
>> >> > http://clojure.github.io/data.zip/#clojure.data.zip.xml/xml->
>> >> >
>> >> > ... but I can't see a way to use something similar for the sort of
>> data
>> >> > I'm
>> >> > processing.  I'll let this percolate, and stick to just using lots of
>> >> > (map)
>> >> > and (filter) instead.
>> >> >
>> >> > - Korny
>> >> >
>> >> >
>> >> > On 6 February 2014 18:34, Jozef Wagner  wrote:
>> >> >>
>> >> >> I agree with Colin, the cognitive load is greater than benefits of
>> such
>> >> >> approach. BTW you can use comp to chain consecutive map
>> transformation
>> >> >> functions. (map (comp pacify wrangle) things)
>> >> >>
>> >> >> JW
>> >> >>
>> >> >>
>> >> >> On Thu, Feb 6, 2014 at 3:40 PM, Korny Sietsma 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi folks,
>> >> >>>
>> >> >>> I seem to regularly find myself writing ->> threaded code that
>> follows
>> >> >>> similar patterns:
>> >> >>>
>> >> >>> (->> things
>> >> >>> (m

Re: map semantics

[Moritz Ulrich]

On Sat, Feb 8, 2014 at 6:39 PM, Timothy Baldridge  wrote:
> First of all, you are right. Map with things like sets is a bit of iffy
> concept. Now, most of the the time, I just don't care. If I was to increment
> every value in a set I'll just do (set (map inc #{1 2 3})) and not really
> care less about data structure theory. It works and I can get work done.

(let [x #{1 2 3}]
  (into (empty x) (map inc x)))

-- 
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: map semantics

[Softaddicts]

The sequence abstraction is documented here:

http://clojure.org/sequences

Clearly map is documented as working on sequences.

A sequence is not a concrete type as explained by others on
this thread.

If you really need some specific behavior from a concrete type then
do not rely on sequences. Use the concrete type directly in all your code.

Choose the right tool to do your job. Clojure offers so many options
that this should not be difficult.

Luc P.


> On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield  wrote:
> 
> > But you're misunderstanding what map does: it converts its collection
> > arguments to _sequences_ and then it processes those sequences. Map
> > doesn't operate on sets, or vectors, or maps, only on sequences.
> >
> 
> Your assertion that I "am misunderstanding something" is wrong.
> 
> One cannot convert amorphic set into linear sequence without assuming
> certain order. And as with every assumption, it always comes with some less
> or more pragmatic but arbitrary decision which might change over time and
> ruin peoples programs.
> 
> I would expect Clojure to throw "IllegalArgumentException Don't know how to
> create ISeq from: clojure.lang.PersistentHashSet" or document it well in
> map somewhere.
> 
> 
> "Perfection is the enemy of the good."
> >
> 
> Now judging by your sig, it all does not surprise me LOL
> 
> -- 
> 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.
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
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: partial function revisited (exercise in macros)

[r]

Thanks,

Let me study this a bit. Maybe I have additional questions.
ranko

On Saturday, February 8, 2014 12:01:37 PM UTC-5, juan.facorro wrote:
>
> When you use *`~p* what you are actually doing is  using the symbol of 
> the predicate as a function. For example if you call *(partial-pbm f 
> symbol? 1 x 3)*, the quote-unquote (`~) will return the symbol *symbol?* 
> which 
> is not what you want. What you can do is use the *resolve 
> * function to 
> get the var associated with that symbol, if it exists.
>
> I haven't tried this but the following should work:
>
>
>
>
>
> *(defmacro partial-pbm  [f p & args]  (let [argseq (flatten args)
> nargs (vec (filter (resolve p) argseq))]*
> *`(fn ~nargs (~f ~@argseq*
>
> Hope it help,
>
> Juan
>
> On Monday, February 3, 2014 8:09:55 PM UTC-3, r wrote:
>>
>> Hello all,
>>
>> For various reasons, and despite the convenience of anonymous functions,
>> I'd like to have a proper positional parameter binding partial function 
>> application. (Actually,
>> I'd like to have by-name parameter binding, but that's another story.)
>>
>> For example, the following seems to work:
>>
>>
>> (defmacro partial-pbm
>> [f & args]
>> (let [argseq (flatten args)
>> nargs (vec (filter symbol? argseq))]
>> `(fn ~nargs (~f ~@argseq
>>
>>
>> and I can do my partials like:
>>
>>
>>1. tools.core=>
>>2.  
>>3. tools.core=> (defn f [a b c] (/ a (- b c)))
>>4. #'tools.core/f
>>5. tools.core=> (partial-pbm f 1 x 3)
>>6. #
>>7. tools.core=> ((partial-pbm f 1 x 3) 2)
>>8. -1
>>9. tools.core=> (f 1 2 3)
>>10. -1
>>11. tools.core=>
>>
>>
>> And it is almost ok. However, I'd like to be able to pass in the
>> predicate that should recognize what the resulting function's new formal 
>> params
>> should be. In other words I'd like "symbol?" in the macro definition 
>> above to
>> be passed in. This brings me to the first, general, question (about 
>> macros):
>>
>> This means that some of the invocation arguments to this macro should be 
>> evaluated, and some should not (e.g. the one specifying the predicate 
>> should
>> be evaluated/dereferenced to enable filtering, but the one specifying the
>> new formal parameters and constants for the rest should not, until the 
>> unbound variables in that param are safely captured in the param list of
>> the (fn ...) form). How is this, usually, resolved? Eval?
>>
>> In other words: If there is a need to do some computation _before_ the
>> quoted (template) form of the macro, how is it usually done? Most
>> macros I've seen start with the quoted form.
>>
>> Now, my various attempts to make this work have been quite confusing 
>> (and I thought I almost got this ...). 
>>
>> First, it seems that the quote must move to the beginning, because
>> I can't find a way to refer to the actual function (predicate) passed,
>> not its symbol. Something like this fails:
>>
>> (defmacro partial-pbm
>> [f p & args]
>> (let [argseq (flatten args)
>> nargs (vec (filter `~p argseq))]
>> ...)
>>
>>
>> which made me realize I don't understand the scope of `/~.
>>
>> I can calculate this properly by:
>>
>> (defmacro ppbm
>>   [f vp & argdef]
>>   `(let [argseq# (flatten '~argdef)
>>  nargs# (vec (filter ~vp argseq#))] 
>>
>> (fn nargs# (~f argseq#
>>
>> But this fails to compile with
>>
>> CompilerException java.lang.IllegalArgumentException: Parameter 
>> declaration f should be a vector, 
>> compiling:(/tmp/form-init5231854403593049721.clj:1:1) ,
>>
>> and I'm unsure why. This type of error is obtained when one forgets [] 
>> parameter list in fn form. 
>> But if I try to print or examine (class, ..) stuff passed to (fn ...) 
>> form they seem correct. Furthermore,
>> this does not look all that different from the functional version at the 
>> beginning.
>>
>> I'm going to InfoQ to re-watch all Macros talks, but if someone could 
>> kick-start me on this, it'd be much appreciated. 
>>  
>> Cheers!
>>
>

-- 
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: partial function revisited (exercise in macros)

[r]

Agreed.
What I'd like to have is something that works like this:

(partial-pbm f ?sym? 1 ?x0 3)

that would produce (given 

(defn ?sym? 

  
  [x]   

  
  (and (symbol? x) (re-find #"\?[a-z][0-9]*" (name x   

(fn [?x0] (f 1 ?x0 x)). In other words: given a predicate that would
recognize use of free variables it would extract them and bind them in
fn form.

Clearly, I need a macro because ?x0 might not be bound in the context.

In that sense, the first example I gave does the exact thing I want.
However, I can't find a way to pass the predicate in, due to my inexperience
with macros, no doubt. So, the main question stands: how to deal with macros
where some of the passed-in parameters should be resolved without 
evaluating them.

Thanks for the help,
ranko


On Saturday, February 8, 2014 12:14:14 PM UTC-5, Gary Verhaegen wrote:
>
> When writing a somewhat complex macro, it is always a good idea to start 
> by writing the code you would like to write (using the macro), rather than 
> begin with the implementation.
>
> Could you perhaps provide an example use of the macro you would like to 
> have? Not one that works, obviously, but what you would like to be able to 
> write.
>
>
> On 8 February 2014 18:01, juan.facorro  >wrote:
>
>> When you use *`~p* what you are actually doing is  using the symbol of 
>> the predicate as a function. For example if you call *(partial-pbm f 
>> symbol? 1 x 3)*, the quote-unquote (`~) will return the symbol *symbol?* 
>> which 
>> is not what you want. What you can do is use the *resolve 
>> * function to 
>> get the var associated with that symbol, if it exists.
>>
>> I haven't tried this but the following should work:
>>
>>
>>
>>
>>
>> *(defmacro partial-pbm  [f p & args]   (let [argseq (flatten args)
>> nargs (vec (filter (resolve p) argseq))]*
>> *`(fn ~nargs (~f ~@argseq*
>>
>> Hope it help,
>>
>> Juan
>>
>> On Monday, February 3, 2014 8:09:55 PM UTC-3, r wrote:
>>>
>>> Hello all,
>>>
>>> For various reasons, and despite the convenience of anonymous functions,
>>> I'd like to have a proper positional parameter binding partial function 
>>> application. (Actually,
>>> I'd like to have by-name parameter binding, but that's another story.)
>>>
>>> For example, the following seems to work:
>>>
>>>
>>> (defmacro partial-pbm
>>> [f & args]
>>> (let [argseq (flatten args)
>>> nargs (vec (filter symbol? argseq))]
>>> `(fn ~nargs (~f ~@argseq
>>>
>>>
>>> and I can do my partials like:
>>>
>>>
>>>1. tools.core=>
>>>2.  
>>>3. tools.core=> (defn f [a b c] (/ a (- b c)))
>>>4. #'tools.core/f
>>>5. tools.core=> (partial-pbm f 1 x 3)
>>>6. #
>>>7. tools.core=> ((partial-pbm f 1 x 3) 2)
>>>8. -1
>>>9. tools.core=> (f 1 2 3)
>>>10. -1
>>>11. tools.core=>
>>>
>>>
>>> And it is almost ok. However, I'd like to be able to pass in the
>>> predicate that should recognize what the resulting function's new formal 
>>> params
>>> should be. In other words I'd like "symbol?" in the macro definition 
>>> above to
>>> be passed in. This brings me to the first, general, question (about 
>>> macros):
>>>
>>> This means that some of the invocation arguments to this macro should be 
>>> evaluated, and some should not (e.g. the one specifying the predicate 
>>> should
>>> be evaluated/dereferenced to enable filtering, but the one specifying the
>>> new formal parameters and constants for the rest should not, until the 
>>> unbound variables in that param are safely captured in the param list of
>>> the (fn ...) form). How is this, usually, resolved? Eval?
>>>
>>> In other words: If there is a need to do some computation _before_ the
>>> quoted (template) form of the macro, how is it usually done? Most
>>> macros I've seen start with the quoted form.
>>>
>>> Now, my various attempts to make this work have been quite confusing 
>>> (and I thought I almost got this ...). 
>>>
>>> First, it seems that the quote must move to the beginning, because
>>> I can't find a way to refer to the actual function (predicate) passed,
>>> not its symbol. Something like this fails:
>>>
>>> (defmacro partial-pbm
>>> [f p & args]
>>> (let [argseq (flatten args)
>>> nargs (vec (filter `~p argseq))]
>>> ...)
>>>
>>>
>>> which made me realize I don't understand the scope of `/~.
>>>
>>> I can calculate this properly by:
>>>
>>> (defmacro ppbm
>>>   [f vp & argdef]
>>>   `(let [argseq# (flatten '~argdef)
>>>  nargs# (vec (filter ~vp argseq#))] 
>>>
>>> (fn nargs# (~f argseq#
>>>
>>> But this fails to compile with
>>>
>>> CompilerException java.lang.IllegalArgumentExcep

Re: map semantics

[Andy Fingerhut]

This might be too detailed a point, but I wanted to mention that while you
will always get the same order for the same collection (same as determined
by identical?, or Java ==, i.e. it is the same object in memory), you are
*not* guaranteed to get the same order for collections of the same type
that are equal to each other as determined by Clojure = or Java .equals.
In particular, if two values have the same hash value, then if they are
used as a set in a Clojure PersistentHashSet or a key in a
PersistentHashKey, they are put into a linear list in a hash bucket for
that hash value, and their order in that list can be different in different
sets/maps, and the order that (seq ...) returns on those sets/maps will be
different.

I am not certain, but this might violate referential transparency
(replacing a value that is equals for another value in an expression will
always give you an equal result).

I was curious whether anyone knows whether Haskell has hash-based data
structures like this, and do they somehow guarantee referential
transparency?  Perhaps by requiring the items to be sortable?

Andy


On Sat, Feb 8, 2014 at 8:19 AM, Jozef Wagner  wrote:

> Every persistent collection in Clojure supports conversion to the sequence
> of items. This is clearly documented in the official docs and there is no
> surprise here.
>
> The order or items in the resulting sequence is dependent on the
> collection type. As the conversion to the sequence is a referentially
> transparent function, you will always get the same order for the same
> collection.
>
> JW
>
> On Saturday, February 8, 2014 4:59:47 PM UTC+1, Andy C wrote:
>
>> On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield wrote:
>>
>>> But you're misunderstanding what map does: it converts its collection
>>> arguments to _sequences_ and then it processes those sequences. Map
>>> doesn't operate on sets, or vectors, or maps, only on sequences.
>>>
>>
>> Your assertion that I "am misunderstanding something" is wrong.
>>
>> One cannot convert amorphic set into linear sequence without assuming
>> certain order. And as with every assumption, it always comes with some less
>> or more pragmatic but arbitrary decision which might change over time and
>> ruin peoples programs.
>>
>> I would expect Clojure to throw "IllegalArgumentException Don't know how
>> to create ISeq from: clojure.lang.PersistentHashSet" or document it well
>> in map somewhere.
>>
>>
>>  "Perfection is the enemy of the good."
>>>
>>
>> Now judging by your sig, it all does not surprise me LOL
>>
>>
>>
>>  --
> 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: Is there a prettify command in emacs for clojure?

[Rodrigo B. de Oliveira]

emacs-live has a live-paredit-reindent-defun bound to M-q that gets very 
close.

On Friday, February 7, 2014 8:20:58 PM UTC-2, Taylor Sando wrote:
>
> Let us say you had this:
>
> (defn create-new-canvas-text [inputs]  
>   (let [{text-selected-id :new} (dataflow/old-and-new inputs [:design 
> :params :text :selected-id])
> {text-params :new} (dataflow/old-and-new inputs [:design :params 
> :text])
> text-value (:value text-params)
>
> ]
> ;; When there is no previous selected id and there is now non-empty 
> text in the params text
> ;; it means that a new canvas text entry should occur
> (when
> (and (nil? text-selected-id) (not (empty? text-value)))
>   ;; Get the previous text entries in canvas
>   ;; Create a new key, which will become selected-id
>   ;; Add the new text entries into canvas
> (let [{prev-text :new} (dataflow/old-and-new inputs 
> [:design :canvas :text])
>   old-keys (keys prev-text)
> new-id (if (seq old-keys) (inc (apply max (keys old-keys))) 0)
> new-text (assoc old-keys new-id (select-keys text-params 
> [:value]))]
> [
>  ^:input {msg/topic [:design :params :text :selected-id] msg/type 
> :set-value :value new-id}
>  ^:input {msg/topic [:design :canvas :text] msg/type :set-value 
> :value new-text}]))
>
>
> )
>
>   )
>
> Is there a way to get it into this:
>
> (defn create-new-canvas-text [inputs]  
>   (let [{text-selected-id :new} (dataflow/old-and-new inputs [:design 
> :params :text :selected-id])
> {text-params :new} (dataflow/old-and-new inputs [:design :params 
> :text])
> text-value (:value text-params)]
> ;; When there is no previous selected id and there is now non-empty 
> text in the params text
> ;; it means that a new canvas text entry should occur
> (when (and (nil? text-selected-id) (not (empty? text-value)))
>   ;; Get the previous text entries in canvas
>   ;; Create a new key, which will become selected-id
>   ;; Add the new text entries into canvas
>   (let [{prev-text :new} (dataflow/old-and-new inputs [:design :canvas 
> :text])
> old-keys (keys prev-text)
> new-id (if (seq old-keys) (inc (apply max (keys old-keys))) 0)
> new-text (assoc old-keys new-id (select-keys text-params 
> [:value]))]
> [^:input {msg/topic [:design :params :text :selected-id] msg/type 
> :set-value :value new-id}
>  ^:input {msg/topic [:design :canvas :text] msg/type :set-value 
> :value new-text}]
>
>
> Seems like it would be a combination of indent-sexp, and then identifying 
> unnecessary white space and deleting it.
>

-- 
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: map semantics

[Timothy Baldridge]

First of all, you are right. Map with things like sets is a bit of iffy
concept. Now, most of the the time, I just don't care. If I was to
increment every value in a set I'll just do (set (map inc #{1 2 3})) and
not really care less about data structure theory. It works and I can get
work done.

However, the bigger problem comes when we start discussing parallel
operations on these datasets. Here it makes no sense to define an order for
(pmap inc #{1 2 3}) when there is no defined order in the input collection
to begin with. This is the entire reason behind clojure's reducers, they
allow the input and output data structures to drive how processing is
handled.

http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html

And as the article states, reducers "use(s) regular data structures, not
'parallel collections' or other OO malarkey"

Timothy Baldridge


On Sat, Feb 8, 2014 at 10:10 AM, Gary Verhaegen wrote:

> The definition of map in Clojure is that it is a function on seqs. It is
> defined as operating on a seq, and returning a seq.
>
> Whereas in Scala, you hold an object and have thus access to its class (so
> you can call Set.map on a set and List.map on a map), in Clojure there is
> only one function clojure.core/map, and it is defined as taking a seq as
> argument. seq is an abstraction, for which there are many functions in the
> Clojure standard library. Whenever you are calling any one of them, you
> leave the realm of concrete collection and enter the realm of seqs.
>
> Functions that operate on seqs are listed on the following page:
> http://clojure.org/sequences.
>
> Now, these functions only accept seqs as arguments. You are right that one
> possible choice would have been to throw an expection every time you pass
> in something else than a seq, which would force you to write something
> along the lines of:
>
> (map #(mod % 3) (seq #{3 6}))
>
> The language designer has decided that all of the sequence functions in
> the standard library would, instead of throwing an exception when the
> argument is not a seq, first try to convert it to a seq (by calling the seq
> function as illustrated above).
>
> This is a design choice which could have been different. This choice in
> particular is based on the famous Perlis quote "It is better to have 100
> functions operate on one data structure than 10 functions on 10 data
> structures." So the standard library focuses on providing a lot of very
> useful functions on the sequence abstraction; what all of these functions
> have in common is that they can be described in terms of considering the
> elements of the seq one at a time.
>
> Arguably, most collections should be able to provide access to all of
> their elements one at a time. Any collection that can do that can
> participate in the seq abstraction. Practically, this means that if you
> define your own data structure (to build on the running example in this
> thread, some kind of tree), you only have to implement one function - seq -
> on your collection to enable the use of all the seq functions from the
> standard library (and many other functions from other libraries that also
> build on the seq abstraction). However, since all of these functions know
> nothing about your data structure except that they can ask for the next
> element, they have no way to keep the structure of your collection.
>
> As a general rule, in Clojure, each collection type has a small number of
> functions that are defined for that collection (and are thus
> type-preserving when it makes sense), but all basic collections support the
> seq abstraction and most of the work is done through the sequence functions.
>
> Each collection type defines how to turn itself into a seq; non-ordered
> collections in the Clojure base language (sets and maps) make no promise
> about the order of their elements when turned into a seq (if you really
> want to know, you can look at the implementation, but you cannot count on
> it not changing in the future).
>
>
>
> On 8 February 2014 17:40, Andy C  wrote:
>
>> >Every persistent collection in Clojure supports conversion to the
>> sequence of items. This is clearly documented in the official docs and
>> there is no surprise here.
>>
>> Would you mind to point me to that piece where doc describes what order
>> seq chooses when converting a set to it. (I honestly tried to find it but
>> could not.)
>>
>>
>>
>> >The order or items in the resulting sequence is dependent on the
>> collection type. As the conversion to the sequence is a referentially
>> transparent function, you will always get the same order for the same
>> collection.
>>
>> So for particularly huge sets, I understand Clojure will not attempt to
>> sort them (read be inefficient) before producing the sequence, is it
>> correct?
>>
>>
>>
>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@

Re: Alternative ->> macro for threading sequences?

[Gary Verhaegen]

For multiple calls to map, you can always do:

(->> things
(map #(-> % wrangle pacify))
(filter effable)
(map #(aggravate % :bees :sharks))
(reduce mapinate {})

but, as others have said, I'm not sure you can meaningfully compress that
if you have to decide between map, filter and reduce. Perhaps implement an
embeddable J to Clojure compiler, either as a macro reading in symbols or
as a function reading in a string? Not sure about the amount of effort
involved, though.


On 8 February 2014 15:18, t x  wrote:

> I think the problem is as follows:
>
> map = 3 characters
> filter = 6 characters
>
> Given that we're doing clojure not apl, to specify the function we're
> mapping/filtering on, we have to do either:
>   #( ... %  ) = 5 characters off the bat
>   or provide the name of the function (atleast 1 english word)
>
> Thus, even if we reduced map to M and filter to F, it's very unlikely
> that we'll ever shorten anything by more than 50% (just given the # of
> characters required to specify the function that we are
> mapping/filtering on.)
>
>
> From this, it seems, unless we go the APL route and make the task of
> describing the filtering/mapping function itself very short, there's
> almost no gain in shortening map / filter.
>
>
> This isn't meant to be discouraging -- in fact, I'd love to see a way
> to mix APL + Clojure. :-) Often times, I'm looking at a multiline
> clojure expression and thinking: "this'd be a single line of APL."
>
> On Fri, Feb 7, 2014 at 8:03 PM, Mars0i  wrote:
> > Since a few of these higher order functions--map, filter, reduce,
> etc.--are
> > so common and useful, I wonder whether there could be sufficient benefit
> to
> > having some abbreviations for them.  I know that some of these characters
> > are already taken, but just to sketch the idea:
> >
> > (--> things  %wrangle  %pacify  |effable  %#(aggravate % :bees :sharks)
> > \(mapinate {}) )
> >
> > In one sense this reduces the visual complexity of Korny's example.  In
> > another sense it increases it.  I thought this option was worth
> mentioning,
> > but I don't think I like it.  It makes the syntax closer to line noise,
> and
> > if there are too many magical characters, no one will remember what they
> > mean except the people who use them all of the time (like some of the
> > options in Perl regexps).  Why not go all the way, and provide an
> alternate
> > APL-style syntax for Clojure?
> >
> >
> > On Friday, February 7, 2014 9:14:27 AM UTC-6, t x wrote:
> >>
> >> I think
> >>
> >> (->> things
> >> (map wrangle)
> >> (map pacify)
> >> (filter effable)
> >> (map #(aggravate % :bees :sharks))
> >> (reduce mapinate {})
> >>
> >>
> >> is optimal for the following reason:
> >>
> >>
> >> If you're doing "map" and "map alone", i.e.
> >>
> >> (->> things
> >>   (map f1)
> >>   (map f2)
> >>   (map f3)
> >>   (map f4))
> >>
> >> then you can do:
> >>
> >> (map #(f4 (f3 (f2 (f1 % things)
> >>
> >>
> >> Now, if you're not doing pure maps, i.e. maps + filters
> >>
> >> Then for each function call, from an information theoretic
> >> perspective, you have to, at the very least, specify:
> >>
> >>   (*) the function to be called
> >>   (*) whether it's a filter or a map
> >>
> >> in this case,
> >>
> >> what you initially have is optimal.
> >>
> >> On Fri, Feb 7, 2014 at 6:33 AM, Korny Sietsma 
> wrote:
> >> > I tend to agree, I think.  I certainly can't think of a syntax that
> >> > would
> >> > make me happy.  It just feels like a bit of a smell that I keep using
> >> > ->> to
> >> > process sequences in similar ways.
> >> >
> >> > The data.zip "xml->" macro is an example of something like what I'm
> >> > thinking
> >> > about - it lets you process sequences of xml data nicely:
> >> > http://clojure.github.io/data.zip/#clojure.data.zip.xml/xml->
> >> >
> >> > ... but I can't see a way to use something similar for the sort of
> data
> >> > I'm
> >> > processing.  I'll let this percolate, and stick to just using lots of
> >> > (map)
> >> > and (filter) instead.
> >> >
> >> > - Korny
> >> >
> >> >
> >> > On 6 February 2014 18:34, Jozef Wagner  wrote:
> >> >>
> >> >> I agree with Colin, the cognitive load is greater than benefits of
> such
> >> >> approach. BTW you can use comp to chain consecutive map
> transformation
> >> >> functions. (map (comp pacify wrangle) things)
> >> >>
> >> >> JW
> >> >>
> >> >>
> >> >> On Thu, Feb 6, 2014 at 3:40 PM, Korny Sietsma 
> >> >> wrote:
> >> >>>
> >> >>> Hi folks,
> >> >>>
> >> >>> I seem to regularly find myself writing ->> threaded code that
> follows
> >> >>> similar patterns:
> >> >>>
> >> >>> (->> things
> >> >>> (map wrangle)
> >> >>> (map pacify)
> >> >>> (filter effable)
> >> >>> (map #(aggravate % :bees :sharks))
> >> >>> (reduce mapinate {})
> >> >>>
> >> >>> i.e. all stages of the code actually operate on a collection rather
> >> >>> than
> >> >>> a single value - usually with a call to "map" at each stage.  This
> >> >>> exam

Re: unconditional append to end

[Gary Verhaegen]

Or use vec to turn a sequence into a vector.

As a general comment, using a dynamically typed language should not be seen
as an opportunity not to think about types. You should still design your
functions, think about the types they should receive, etc. Not having the
compiler to check it for you actually places more burden on yourself and
your self-discipline. You're basically taking responsibility for type
checking in your head, in exchange for less (keyboard) typing and more
flexibility.

Generally speaking, people complaining about conj makes me wonder if they
see the above tradeoff in the same light as I do.


On 8 February 2014 10:44, mynomoto  wrote:

> Maybe you could use mapv and filterv? This way you will always get a
> vector and conj apends in the end.
>
>
> On Friday, February 7, 2014 10:20:09 PM UTC-2, t x wrote:
>>
>> Consider the following:
>>
>> (cons 1 '(2 3 4)) ==> (1 2 3 4)
>> (cons 1 [2 3 4])  ==> (1 2 3 4)
>>
>> (conj '(a b c) 1) ==> (1 a b c)
>> (conj '[a b c] 1) ==> [a b c 1]
>>
>>
>> 
>>
>> Now, I would like something that _always_
>>   * appends to the end
>>
>> cons is almost what I want, except it always appends to front.
>>
>> conj is not what I want -- in fact, I'm afraid of conj. Often times,
>> I'll run map/filter on something, and suddenly, instead of a vector, I
>> now have a list -- and conj changes the order of the item added.
>>
>> Thus, my question: is there a builtin to _unconditinoally_ append to
>> the end of a list/sequence/vector?
>>
>> Thanks!
>>
>  --
> 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: partial function revisited (exercise in macros)

[Gary Verhaegen]

When writing a somewhat complex macro, it is always a good idea to start by
writing the code you would like to write (using the macro), rather than
begin with the implementation.

Could you perhaps provide an example use of the macro you would like to
have? Not one that works, obviously, but what you would like to be able to
write.


On 8 February 2014 18:01, juan.facorro  wrote:

> When you use *`~p* what you are actually doing is  using the symbol of
> the predicate as a function. For example if you call *(partial-pbm f
> symbol? 1 x 3)*, the quote-unquote (`~) will return the symbol *symbol?* which
> is not what you want. What you can do is use the *resolve
> * function to
> get the var associated with that symbol, if it exists.
>
> I haven't tried this but the following should work:
>
>
>
>
>
> *(defmacro partial-pbm  [f p & args]  (let [argseq (flatten args)
> nargs (vec (filter (resolve p) argseq))]*
> *`(fn ~nargs (~f ~@argseq*
>
> Hope it help,
>
> Juan
>
> On Monday, February 3, 2014 8:09:55 PM UTC-3, r wrote:
>>
>> Hello all,
>>
>> For various reasons, and despite the convenience of anonymous functions,
>> I'd like to have a proper positional parameter binding partial function
>> application. (Actually,
>> I'd like to have by-name parameter binding, but that's another story.)
>>
>> For example, the following seems to work:
>>
>>
>> (defmacro partial-pbm
>> [f & args]
>> (let [argseq (flatten args)
>> nargs (vec (filter symbol? argseq))]
>> `(fn ~nargs (~f ~@argseq
>>
>>
>> and I can do my partials like:
>>
>>
>>1. tools.core=>
>>2.
>>3. tools.core=> (defn f [a b c] (/ a (- b c)))
>>4. #'tools.core/f
>>5. tools.core=> (partial-pbm f 1 x 3)
>>6. #
>>7. tools.core=> ((partial-pbm f 1 x 3) 2)
>>8. -1
>>9. tools.core=> (f 1 2 3)
>>10. -1
>>11. tools.core=>
>>
>>
>> And it is almost ok. However, I'd like to be able to pass in the
>> predicate that should recognize what the resulting function's new formal
>> params
>> should be. In other words I'd like "symbol?" in the macro definition
>> above to
>> be passed in. This brings me to the first, general, question (about
>> macros):
>>
>> This means that some of the invocation arguments to this macro should be
>> evaluated, and some should not (e.g. the one specifying the predicate
>> should
>> be evaluated/dereferenced to enable filtering, but the one specifying the
>> new formal parameters and constants for the rest should not, until the
>> unbound variables in that param are safely captured in the param list of
>> the (fn ...) form). How is this, usually, resolved? Eval?
>>
>> In other words: If there is a need to do some computation _before_ the
>> quoted (template) form of the macro, how is it usually done? Most
>> macros I've seen start with the quoted form.
>>
>> Now, my various attempts to make this work have been quite confusing
>> (and I thought I almost got this ...).
>>
>> First, it seems that the quote must move to the beginning, because
>> I can't find a way to refer to the actual function (predicate) passed,
>> not its symbol. Something like this fails:
>>
>> (defmacro partial-pbm
>> [f p & args]
>> (let [argseq (flatten args)
>> nargs (vec (filter `~p argseq))]
>> ...)
>>
>>
>> which made me realize I don't understand the scope of `/~.
>>
>> I can calculate this properly by:
>>
>> (defmacro ppbm
>>   [f vp & argdef]
>>   `(let [argseq# (flatten '~argdef)
>>  nargs# (vec (filter ~vp argseq#))]
>>
>> (fn nargs# (~f argseq#
>>
>> But this fails to compile with
>>
>> CompilerException java.lang.IllegalArgumentException: Parameter
>> declaration f should be a vector, compiling:(/tmp/form-
>> init5231854403593049721.clj:1:1) ,
>>
>> and I'm unsure why. This type of error is obtained when one forgets []
>> parameter list in fn form.
>> But if I try to print or examine (class, ..) stuff passed to (fn ...)
>> form they seem correct. Furthermore,
>> this does not look all that different from the functional version at the
>> beginning.
>>
>> I'm going to InfoQ to re-watch all Macros talks, but if someone could
>> kick-start me on this, it'd be much appreciated.
>>
>> Cheers!
>>
>  --
> 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 messag

Re: map semantics

[Gary Verhaegen]

The definition of map in Clojure is that it is a function on seqs. It is
defined as operating on a seq, and returning a seq.

Whereas in Scala, you hold an object and have thus access to its class (so
you can call Set.map on a set and List.map on a map), in Clojure there is
only one function clojure.core/map, and it is defined as taking a seq as
argument. seq is an abstraction, for which there are many functions in the
Clojure standard library. Whenever you are calling any one of them, you
leave the realm of concrete collection and enter the realm of seqs.

Functions that operate on seqs are listed on the following page:
http://clojure.org/sequences.

Now, these functions only accept seqs as arguments. You are right that one
possible choice would have been to throw an expection every time you pass
in something else than a seq, which would force you to write something
along the lines of:

(map #(mod % 3) (seq #{3 6}))

The language designer has decided that all of the sequence functions in the
standard library would, instead of throwing an exception when the argument
is not a seq, first try to convert it to a seq (by calling the seq function
as illustrated above).

This is a design choice which could have been different. This choice in
particular is based on the famous Perlis quote "It is better to have 100
functions operate on one data structure than 10 functions on 10 data
structures." So the standard library focuses on providing a lot of very
useful functions on the sequence abstraction; what all of these functions
have in common is that they can be described in terms of considering the
elements of the seq one at a time.

Arguably, most collections should be able to provide access to all of their
elements one at a time. Any collection that can do that can participate in
the seq abstraction. Practically, this means that if you define your own
data structure (to build on the running example in this thread, some kind
of tree), you only have to implement one function - seq - on your
collection to enable the use of all the seq functions from the standard
library (and many other functions from other libraries that also build on
the seq abstraction). However, since all of these functions know nothing
about your data structure except that they can ask for the next element,
they have no way to keep the structure of your collection.

As a general rule, in Clojure, each collection type has a small number of
functions that are defined for that collection (and are thus
type-preserving when it makes sense), but all basic collections support the
seq abstraction and most of the work is done through the sequence functions.

Each collection type defines how to turn itself into a seq; non-ordered
collections in the Clojure base language (sets and maps) make no promise
about the order of their elements when turned into a seq (if you really
want to know, you can look at the implementation, but you cannot count on
it not changing in the future).



On 8 February 2014 17:40, Andy C  wrote:

> >Every persistent collection in Clojure supports conversion to the
> sequence of items. This is clearly documented in the official docs and
> there is no surprise here.
>
> Would you mind to point me to that piece where doc describes what order
> seq chooses when converting a set to it. (I honestly tried to find it but
> could not.)
>
>
>
> >The order or items in the resulting sequence is dependent on the
> collection type. As the conversion to the sequence is a referentially
> transparent function, you will always get the same order for the same
> collection.
>
> So for particularly huge sets, I understand Clojure will not attempt to
> sort them (read be inefficient) before producing the sequence, is it
> correct?
>
>
>
>
>  --
> 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.

Re: a problem about Redis client: com.taoensso/carmine

[mynomoto]

You can use:

(into {} (map (fn [[k v]] [(keyword k) v]) {"pass" "yy", "yyy" "yyy"}))

On Saturday, February 8, 2014 2:34:44 PM UTC-2, Tao Zhou wrote:
>
> lein try com.taoensso/carmine ;; try is from 
> https://github.com/rkneufeld/lein-try 
>
>
> (def server-connection {:pool {:max-active 8}
>:spec {:host "localhost" 
>   :port 6379 
>   :timeout 4000}}) 
>
> (require '[taoensso.carmine :as car :refer (wcar)]) 
>
> (defmacro wcar* [& body] `(car/wcar server-connection ~@body)) 
>
> (wcar* (car/hmset* "yyy" {:yyy "yyy", :pass "yy"})) 
>
> (wcar* (car/hgetall "yyy”)) 
> *["pass" "yy" "yyy" "yyy”]*
>
> (wcar* (car/hgetall* "yyy”))
> *{"pass" "yy", "yyy" "yyy”}*
>
>
> But what I want (or expect) is what I set before:
> *{:yyy "yyy", :pass "yy"} *
>
> Who can help me? Thank you very much! 
>

-- 
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: map semantics

[Ambrose Bonnaire-Sergeant]

On Sun, Feb 9, 2014 at 12:40 AM, Andy C  wrote:

> >Every persistent collection in Clojure supports conversion to the
> sequence of items. This is clearly documented in the official docs and
> there is no surprise here.
>
> Would you mind to point me to that piece where doc describes what order
> seq chooses when converting a set to it. (I honestly tried to find it but
> could not.)
>
>
The seq order is undefined for non-sequential, unsorted collections like
clojure.lang.PersistentHashSet (the result of clojure.core/{hash-,}set).

Thanks,
Ambrose

-- 
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: partial function revisited (exercise in macros)

[juan.facorro]

When you use *`~p* what you are actually doing is  using the symbol of the 
predicate as a function. For example if you call *(partial-pbm f symbol? 1 
x 3)*, the quote-unquote (`~) will return the symbol *symbol?* which is not 
what you want. What you can do is use the *resolve 
* function to get 
the var associated with that symbol, if it exists.

I haven't tried this but the following should work:





*(defmacro partial-pbm  [f p & args]  (let [argseq (flatten args)
nargs (vec (filter (resolve p) argseq))]*
*`(fn ~nargs (~f ~@argseq*

Hope it help,

Juan

On Monday, February 3, 2014 8:09:55 PM UTC-3, r wrote:
>
> Hello all,
>
> For various reasons, and despite the convenience of anonymous functions,
> I'd like to have a proper positional parameter binding partial function 
> application. (Actually,
> I'd like to have by-name parameter binding, but that's another story.)
>
> For example, the following seems to work:
>
>
> (defmacro partial-pbm
> [f & args]
> (let [argseq (flatten args)
> nargs (vec (filter symbol? argseq))]
> `(fn ~nargs (~f ~@argseq
>
>
> and I can do my partials like:
>
>
>1. tools.core=>
>2.  
>3. tools.core=> (defn f [a b c] (/ a (- b c)))
>4. #'tools.core/f
>5. tools.core=> (partial-pbm f 1 x 3)
>6. #
>7. tools.core=> ((partial-pbm f 1 x 3) 2)
>8. -1
>9. tools.core=> (f 1 2 3)
>10. -1
>11. tools.core=>
>
>
> And it is almost ok. However, I'd like to be able to pass in the
> predicate that should recognize what the resulting function's new formal 
> params
> should be. In other words I'd like "symbol?" in the macro definition above 
> to
> be passed in. This brings me to the first, general, question (about 
> macros):
>
> This means that some of the invocation arguments to this macro should be 
> evaluated, and some should not (e.g. the one specifying the predicate 
> should
> be evaluated/dereferenced to enable filtering, but the one specifying the
> new formal parameters and constants for the rest should not, until the 
> unbound variables in that param are safely captured in the param list of
> the (fn ...) form). How is this, usually, resolved? Eval?
>
> In other words: If there is a need to do some computation _before_ the
> quoted (template) form of the macro, how is it usually done? Most
> macros I've seen start with the quoted form.
>
> Now, my various attempts to make this work have been quite confusing 
> (and I thought I almost got this ...). 
>
> First, it seems that the quote must move to the beginning, because
> I can't find a way to refer to the actual function (predicate) passed,
> not its symbol. Something like this fails:
>
> (defmacro partial-pbm
> [f p & args]
> (let [argseq (flatten args)
> nargs (vec (filter `~p argseq))]
> ...)
>
>
> which made me realize I don't understand the scope of `/~.
>
> I can calculate this properly by:
>
> (defmacro ppbm
>   [f vp & argdef]
>   `(let [argseq# (flatten '~argdef)
>  nargs# (vec (filter ~vp argseq#))] 
>
> (fn nargs# (~f argseq#
>
> But this fails to compile with
>
> CompilerException java.lang.IllegalArgumentException: Parameter 
> declaration f should be a vector, 
> compiling:(/tmp/form-init5231854403593049721.clj:1:1) ,
>
> and I'm unsure why. This type of error is obtained when one forgets [] 
> parameter list in fn form. 
> But if I try to print or examine (class, ..) stuff passed to (fn ...) form 
> they seem correct. Furthermore,
> this does not look all that different from the functional version at the 
> beginning.
>
> I'm going to InfoQ to re-watch all Macros talks, but if someone could 
> kick-start me on this, it'd be much appreciated. 
>  
> Cheers!
>

-- 
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: a problem about Redis client: com.taoensso/carmine

[tao]

Repost: fix some quotation mark problem in the code.


lein try com.taoensso/carmine ;; try is from 
https://github.com/rkneufeld/lein-try  


(def server-connection {:pool {:max-active 8}
   :spec {:host "localhost"  
  :port 6379  
  :timeout 4000}})  

(require '[taoensso.carmine :as car :refer (wcar)])  

(defmacro wcar* [& body] `(car/wcar server-connection ~@body))  

(wcar* (car/hmset* "yyy" {:yyy "yyy", :pass "yy"}))  

(wcar* (car/hgetall "yyy"))  
["pass" "yy" "yyy" "yyy"]

(wcar* (car/hgetall* "yyy"))  
{"pass" "yy", "yyy" "yyy"}


But what I want (or expect) is what I set before:  

{:yyy "yyy", :pass "yy"}  



Who can help me? Thank you very much!


   

--  
tao
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Sunday, February 9, 2014 at 12:34 AM, tao wrote:

> lein try com.taoensso/carmine ;; try is from 
> https://github.com/rkneufeld/lein-try  
>  
>  
> (def server-connection {:pool {:max-active 8}
>:spec {:host "localhost"  
>   :port 6379  
>   :timeout 4000}})  
>  
> (require '[taoensso.carmine :as car :refer (wcar)])  
>  
> (defmacro wcar* [& body] `(car/wcar server-connection ~@body))  
>  
> (wcar* (car/hmset* "yyy" {:yyy "yyy", :pass "yy"}))  
>  
> (wcar* (car/hgetall "yyy”))  
> ["pass" "yy" "yyy" "yyy”]
>  
> (wcar* (car/hgetall* "yyy”)) 
> {"pass" "yy", "yyy" "yyy”}
>  
>  
> But what I want (or expect) is what I set before:
> {:yyy "yyy", :pass "yy"}  
>  
> Who can help me? Thank you very much!   

-- 
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: map semantics

[Andy C]

>Every persistent collection in Clojure supports conversion to the sequence
of items. This is clearly documented in the official docs and there is no
surprise here.

Would you mind to point me to that piece where doc describes what order seq
chooses when converting a set to it. (I honestly tried to find it but could
not.)


>The order or items in the resulting sequence is dependent on the
collection type. As the conversion to the sequence is a referentially
transparent function, you will always get the same order for the same
collection.

So for particularly huge sets, I understand Clojure will not attempt to
sort them (read be inefficient) before producing the sequence, is it
correct?

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

a problem about Redis client: com.taoensso/carmine

[tao]

lein try com.taoensso/carmine ;; try is from 
https://github.com/rkneufeld/lein-try  


(def server-connection {:pool {:max-active 8}
   :spec {:host "localhost"  
  :port 6379  
  :timeout 4000}})  

(require '[taoensso.carmine :as car :refer (wcar)])  

(defmacro wcar* [& body] `(car/wcar server-connection ~@body))  

(wcar* (car/hmset* "yyy" {:yyy "yyy", :pass "yy"}))  

(wcar* (car/hgetall "yyy”))  
["pass" "yy" "yyy" "yyy”]

(wcar* (car/hgetall* "yyy”)) 
{"pass" "yy", "yyy" "yyy”}


But what I want (or expect) is what I set before:
{:yyy "yyy", :pass "yy"}  

Who can help me? Thank you very much! 

-- 
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: map semantics

[Jozef Wagner]

Every persistent collection in Clojure supports conversion to the sequence 
of items. This is clearly documented in the official docs and there is no 
surprise here.

The order or items in the resulting sequence is dependent on the collection 
type. As the conversion to the sequence is a referentially 
transparent function, you will always get the same order for the same 
collection. 

JW

On Saturday, February 8, 2014 4:59:47 PM UTC+1, Andy C wrote:
>
> On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield 
> 
> > wrote:
>
>> But you're misunderstanding what map does: it converts its collection
>> arguments to _sequences_ and then it processes those sequences. Map
>> doesn't operate on sets, or vectors, or maps, only on sequences.
>>
>
> Your assertion that I "am misunderstanding something" is wrong.
>
> One cannot convert amorphic set into linear sequence without assuming 
> certain order. And as with every assumption, it always comes with some less 
> or more pragmatic but arbitrary decision which might change over time and 
> ruin peoples programs. 
>
> I would expect Clojure to throw "IllegalArgumentException Don't know how 
> to create ISeq from: clojure.lang.PersistentHashSet" or document it well in 
> map somewhere.  
>
>
>  "Perfection is the enemy of the good."
>>
>
> Now judging by your sig, it all does not surprise me LOL
>
>
>
>

-- 
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: map semantics

[Andy C]

On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield  wrote:

> But you're misunderstanding what map does: it converts its collection
> arguments to _sequences_ and then it processes those sequences. Map
> doesn't operate on sets, or vectors, or maps, only on sequences.
>

Your assertion that I "am misunderstanding something" is wrong.

One cannot convert amorphic set into linear sequence without assuming
certain order. And as with every assumption, it always comes with some less
or more pragmatic but arbitrary decision which might change over time and
ruin peoples programs.

I would expect Clojure to throw "IllegalArgumentException Don't know how to
create ISeq from: clojure.lang.PersistentHashSet" or document it well in
map somewhere.


"Perfection is the enemy of the good."
>

Now judging by your sig, it all does not surprise me LOL

-- 
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: GSoC 2014: org applications now open

[Alex Ott]

Hi Avram

There is discussion in Incanter's issue about this:
https://github.com/liebke/incanter/issues/193 - maybe it would be possible
to implement support for different chart backends - like, D3.js, JavaFX,
etc.



On Sat, Feb 8, 2014 at 12:02 AM, A  wrote:

>
> A couple ideas put forth:
>
> 1. Incanter charts with d3 (http://d3js.org/) ?  Perhaps facilitated by
> Dribnet's Strokes library (https://github.com/dribnet/strokes).
>
> 2. Finding ways to integrate Incanter and Clojurescript.
>
> Thoughts?
>
> -Avram
>
>
>
>
>
> On Monday, February 3, 2014 11:59:24 AM UTC-8, Daniel Solano Gómez wrote:
>>
>> Hello, all,
>>
>> Apparently, it's already time for organisations to apply for Google
>> Summer of Coder 2014 [1].   This is a great program, and there have been
>> several notable projects that have benefited as a result.  For example,
>> last year's successful projects included:
>>
>> * Enhance Neko for Android, Alexander Yakushev
>> * core.typed: Extensions and Documentation, Ambrose Bonnaire-Sergeant
>> * Clojure Compiler port to Clojure (CinC), Bronsa
>> * Implementation of core.matrix-compatible multidimensional array in
>> Clojure, Dmitry Groshev
>> * Algebraic Expressions, Maik Schünemann
>> * ClojureScript optimization and source maps support, Michal Marczyk
>>
>> I would love to see Clojure participate again this year.  In order to do
>> so, we need to start our application which is due in less than two weeks.
>>  We need volunteers to help prepare our application, and in particular it
>> would be great to have administrators that can help lead the process.  I am
>> certainly willing to help out, but if there is someone who wants to lead up
>> this effort, I would happy to assist.
>>
>> Ideally, we could have multiple administrators to spread out the
>> following duties:
>>
>> * Updating the community wiki for the year [2]
>> * Recruiting potential mentors
>> * Raising the profile of GSoC within the community
>>
>> If we are accepted as a GSoC organisation, administrator duties include:
>>
>> * Ensuring we meet the deadlines
>> * Arranging for travel to the mentor submit
>> * Arranging for students' travel to conferences
>> * If necessary, solve problems
>>
>> I am afraid that last year I let the ball drop a bit with the mentor
>> summit and getting students to conferences.  With multiple administrators
>> to help spread the work around, I am sure we can make GSoC an even better
>> experience for everyone involved.
>>
>> If you are interested in helping out in this effort, please set up a
>> profile on Melange [3] and e-mail me your profile name.
>>
>> Thanks for your help.
>>
>> Sincerely,
>>
>> Daniel
>>
>>
>> [1]: http://google-opensource.blogspot.com/2014/02/
>> mentoring-organization-applications-now.html
>> [2]: http://dev.clojure.org/display/community/Google+Summer+of+Code+2013
>> [3]: http://en.flossmanuals.net/melange/
>>
>  --
> 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.
>



-- 
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott

-- 
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: Alternative ->> macro for threading sequences?

[t x]

I think the problem is as follows:

map = 3 characters
filter = 6 characters

Given that we're doing clojure not apl, to specify the function we're
mapping/filtering on, we have to do either:
  #( ... %  ) = 5 characters off the bat
  or provide the name of the function (atleast 1 english word)

Thus, even if we reduced map to M and filter to F, it's very unlikely
that we'll ever shorten anything by more than 50% (just given the # of
characters required to specify the function that we are
mapping/filtering on.)


>From this, it seems, unless we go the APL route and make the task of
describing the filtering/mapping function itself very short, there's
almost no gain in shortening map / filter.


This isn't meant to be discouraging -- in fact, I'd love to see a way
to mix APL + Clojure. :-) Often times, I'm looking at a multiline
clojure expression and thinking: "this'd be a single line of APL."

On Fri, Feb 7, 2014 at 8:03 PM, Mars0i  wrote:
> Since a few of these higher order functions--map, filter, reduce, etc.--are
> so common and useful, I wonder whether there could be sufficient benefit to
> having some abbreviations for them.  I know that some of these characters
> are already taken, but just to sketch the idea:
>
> (--> things  %wrangle  %pacify  |effable  %#(aggravate % :bees :sharks)
> \(mapinate {}) )
>
> In one sense this reduces the visual complexity of Korny's example.  In
> another sense it increases it.  I thought this option was worth mentioning,
> but I don't think I like it.  It makes the syntax closer to line noise, and
> if there are too many magical characters, no one will remember what they
> mean except the people who use them all of the time (like some of the
> options in Perl regexps).  Why not go all the way, and provide an alternate
> APL-style syntax for Clojure?
>
>
> On Friday, February 7, 2014 9:14:27 AM UTC-6, t x wrote:
>>
>> I think
>>
>> (->> things
>> (map wrangle)
>> (map pacify)
>> (filter effable)
>> (map #(aggravate % :bees :sharks))
>> (reduce mapinate {})
>>
>>
>> is optimal for the following reason:
>>
>>
>> If you're doing "map" and "map alone", i.e.
>>
>> (->> things
>>   (map f1)
>>   (map f2)
>>   (map f3)
>>   (map f4))
>>
>> then you can do:
>>
>> (map #(f4 (f3 (f2 (f1 % things)
>>
>>
>> Now, if you're not doing pure maps, i.e. maps + filters
>>
>> Then for each function call, from an information theoretic
>> perspective, you have to, at the very least, specify:
>>
>>   (*) the function to be called
>>   (*) whether it's a filter or a map
>>
>> in this case,
>>
>> what you initially have is optimal.
>>
>> On Fri, Feb 7, 2014 at 6:33 AM, Korny Sietsma  wrote:
>> > I tend to agree, I think.  I certainly can't think of a syntax that
>> > would
>> > make me happy.  It just feels like a bit of a smell that I keep using
>> > ->> to
>> > process sequences in similar ways.
>> >
>> > The data.zip "xml->" macro is an example of something like what I'm
>> > thinking
>> > about - it lets you process sequences of xml data nicely:
>> > http://clojure.github.io/data.zip/#clojure.data.zip.xml/xml->
>> >
>> > ... but I can't see a way to use something similar for the sort of data
>> > I'm
>> > processing.  I'll let this percolate, and stick to just using lots of
>> > (map)
>> > and (filter) instead.
>> >
>> > - Korny
>> >
>> >
>> > On 6 February 2014 18:34, Jozef Wagner  wrote:
>> >>
>> >> I agree with Colin, the cognitive load is greater than benefits of such
>> >> approach. BTW you can use comp to chain consecutive map transformation
>> >> functions. (map (comp pacify wrangle) things)
>> >>
>> >> JW
>> >>
>> >>
>> >> On Thu, Feb 6, 2014 at 3:40 PM, Korny Sietsma 
>> >> wrote:
>> >>>
>> >>> Hi folks,
>> >>>
>> >>> I seem to regularly find myself writing ->> threaded code that follows
>> >>> similar patterns:
>> >>>
>> >>> (->> things
>> >>> (map wrangle)
>> >>> (map pacify)
>> >>> (filter effable)
>> >>> (map #(aggravate % :bees :sharks))
>> >>> (reduce mapinate {})
>> >>>
>> >>> i.e. all stages of the code actually operate on a collection rather
>> >>> than
>> >>> a single value - usually with a call to "map" at each stage.  This
>> >>> example
>> >>> is over simplified - often many of the calls to map are inline
>> >>> functions,
>> >>> which makes this even more verbose.
>> >>>
>> >>> I wonder if there would be value in (yet another) variant on '->' that
>> >>> assumes you are threading a collection and calling 'map' by default.
>> >>> I'm
>> >>> not sure of the syntax that would work though.  Something like:
>> >>>
>> >>> ([]-> things
>> >>> wrangle
>> >>> pacify
>> >>> [:filter effable]
>> >>> (aggravate :bees :sharks)
>> >>> [:reduce mapinate {}])
>> >>>
>> >>> I'm not sure about the syntax for non-map functions, I'm not even sure
>> >>> if
>> >>> this is worthwhile.  Thoughts?
>> >>>
>> >>> - Korny
>> >>>
>> >>> --
>> >>> Kornelis Sietsma  korny at my surname dot com http://korny.info
>

Clojure tutorial for Light Table

[mynomoto]

Hello,

I ported the Light Table ClojureScript Tutorial [1] by David Nolen to 
Clojure.

Also added sections about refs and agents. You can see it 
on https://github.com/mynomoto/lt-clojure-tutorial

If you find some mistake, typo or want to contribute let me know or open an 
issue or pull request.

[1] https://github.com/swannodette/lt-cljs-tutorial

Best,

Marcelo

-- 
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: unconditional append to end

[mynomoto]

Maybe you could use mapv and filterv? This way you will always get a vector 
and conj apends in the end.

On Friday, February 7, 2014 10:20:09 PM UTC-2, t x wrote:
>
> Consider the following: 
>
> (cons 1 '(2 3 4)) ==> (1 2 3 4) 
> (cons 1 [2 3 4])  ==> (1 2 3 4) 
>
> (conj '(a b c) 1) ==> (1 a b c) 
> (conj '[a b c] 1) ==> [a b c 1] 
>
>
>  
>
> Now, I would like something that _always_ 
>   * appends to the end 
>
> cons is almost what I want, except it always appends to front. 
>
> conj is not what I want -- in fact, I'm afraid of conj. Often times, 
> I'll run map/filter on something, and suddenly, instead of a vector, I 
> now have a list -- and conj changes the order of the item added. 
>
> Thus, my question: is there a builtin to _unconditinoally_ append to 
> the end of a list/sequence/vector? 
>
> Thanks! 
>

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