Re: Fastest way to generate comma-separated list
My Question would be: why are you trying to do this? You mentioned you are
working with a database, I assume that means SQL (as almost all NoSQL
Databases support some kind of JSON which doesnt require your
"workarround"). Most SQL Database support array types natively, while
support might be a little itchy (at least in JDBC terms) it still beats a
comma seperated list.
In all other cases just use clojure.core/pr-str and the new
clojure.edn/read-string when reading it back.
Just my 2 cents,
/thomas
On Thursday, October 28, 2010 2:18:08 AM UTC+2, andrei wrote:
>
> Hi all,
>
> I work with a database and need a function, that will convert Clojure
> sequence to a string with a comma-separated elements. E.g.,
>
> (comma-separated (list 1 2 3 4 5)) ==> "1, 2, 3, 4, 5"
>
> It must work with any data type - ints, strings, other lists, etc.
> E.g. for a list of strings it must generate
>
> (comma-separated (list "1" "2" "3" "4" "5")) ==> "\"1\", \"2\",
> \"3\", \"4\", \"5\""
>
> I tried `cl-format` function from clojure.contrib.pprint package:
>
> (cl-format nil "~{~S~^, ~}" lst)
>
> It works fine, but is too slow. Next, I tried such function:
>
> (defn comma-separated [s]
> (if (= (type (first s)) String)
> (chop (chop (chop (str "\" (apply str (interleave s
> (repeatedly (fn [] "\", \"")))
> (chop (chop (apply str (interleave s (repeatedly (fn [] ",
> ")
>
> This one works much faster (~20 times), but it is ugly and still
> doesn't cover all cases.
>
> So, what is the fastest way to generate such list?
--
--
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: Fastest way to generate comma-separated list
>
> Most SQL Database support array types natively
If you are using MySQL unfortunately there isn't and the OP (including
myself) probably needs this because his RDBMS does not support the array
type.
On Wednesday, April 3, 2013 2:47:45 PM UTC+3, Thomas Heller wrote:
>
> My Question would be: why are you trying to do this? You mentioned you are
> working with a database, I assume that means SQL (as almost all NoSQL
> Databases support some kind of JSON which doesnt require your
> "workarround"). Most SQL Database support array types natively, while
> support might be a little itchy (at least in JDBC terms) it still beats a
> comma seperated list.
>
> In all other cases just use clojure.core/pr-str and the new
> clojure.edn/read-string when reading it back.
>
> Just my 2 cents,
> /thomas
>
> On Thursday, October 28, 2010 2:18:08 AM UTC+2, andrei wrote:
>>
>> Hi all,
>>
>> I work with a database and need a function, that will convert Clojure
>> sequence to a string with a comma-separated elements. E.g.,
>>
>> (comma-separated (list 1 2 3 4 5)) ==> "1, 2, 3, 4, 5"
>>
>> It must work with any data type - ints, strings, other lists, etc.
>> E.g. for a list of strings it must generate
>>
>> (comma-separated (list "1" "2" "3" "4" "5")) ==> "\"1\", \"2\",
>> \"3\", \"4\", \"5\""
>>
>> I tried `cl-format` function from clojure.contrib.pprint package:
>>
>> (cl-format nil "~{~S~^, ~}" lst)
>>
>> It works fine, but is too slow. Next, I tried such function:
>>
>> (defn comma-separated [s]
>> (if (= (type (first s)) String)
>> (chop (chop (chop (str "\" (apply str (interleave s
>> (repeatedly (fn [] "\", \"")))
>> (chop (chop (apply str (interleave s (repeatedly (fn [] ",
>> ")
>>
>> This one works much faster (~20 times), but it is ugly and still
>> doesn't cover all cases.
>>
>> So, what is the fastest way to generate such list?
>
>
--
--
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: Fastest way to generate comma-separated list
I am curious, what data store are you interacting with?
On Wednesday, April 3, 2013 2:01:33 PM UTC+2, Ryan wrote:
>
> Most SQL Database support array types natively
>
>
> If you are using MySQL unfortunately there isn't and the OP (including
> myself) probably needs this because his RDBMS does not support the array
> type.
>
> On Wednesday, April 3, 2013 2:47:45 PM UTC+3, Thomas Heller wrote:
>>
>> My Question would be: why are you trying to do this? You mentioned you
>> are working with a database, I assume that means SQL (as almost all NoSQL
>> Databases support some kind of JSON which doesnt require your
>> "workarround"). Most SQL Database support array types natively, while
>> support might be a little itchy (at least in JDBC terms) it still beats a
>> comma seperated list.
>>
>> In all other cases just use clojure.core/pr-str and the new
>> clojure.edn/read-string when reading it back.
>>
>> Just my 2 cents,
>> /thomas
>>
>> On Thursday, October 28, 2010 2:18:08 AM UTC+2, andrei wrote:
>>>
>>> Hi all,
>>>
>>> I work with a database and need a function, that will convert Clojure
>>> sequence to a string with a comma-separated elements. E.g.,
>>>
>>> (comma-separated (list 1 2 3 4 5)) ==> "1, 2, 3, 4, 5"
>>>
>>> It must work with any data type - ints, strings, other lists, etc.
>>> E.g. for a list of strings it must generate
>>>
>>> (comma-separated (list "1" "2" "3" "4" "5")) ==> "\"1\", \"2\",
>>> \"3\", \"4\", \"5\""
>>>
>>> I tried `cl-format` function from clojure.contrib.pprint package:
>>>
>>> (cl-format nil "~{~S~^, ~}" lst)
>>>
>>> It works fine, but is too slow. Next, I tried such function:
>>>
>>> (defn comma-separated [s]
>>> (if (= (type (first s)) String)
>>> (chop (chop (chop (str "\" (apply str (interleave s
>>> (repeatedly (fn [] "\", \"")))
>>> (chop (chop (apply str (interleave s (repeatedly (fn [] ",
>>> ")
>>>
>>> This one works much faster (~20 times), but it is ugly and still
>>> doesn't cover all cases.
>>>
>>> So, what is the fastest way to generate such list?
>>
>>
--
--
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: why can I re-use local variables if Clojure is immutable?
On Tuesday, April 2, 2013 1:09:25 PM UTC-6, larry google groups wrote: > > > If Clojure is suppose to emphasize immutability, why can I do this: > > kiosks-clojure.core=> (let [ > #_=> mega (+ 1 1) > #_=> mega (+ 1 mega) > #_=> mega (+ 1 mega) > #_=> mega (+ 1 mega) > #_=> mega (+ 1 mega)] > #_=> mega) > 6 > > I might as well be writing PHP code. > > Does anyone actually write Clojure code like this, or is it considered bad > form? > > It's perfectly fine. In fact, I would argue that it's bad form to invent new local names when you don't need them. As others have said, there is nothing mutable happening here. Rebinding a local shadows the previous local of the same name, but does not change it in-place, as many other languages do. I realize that seems like a hand-wavy distinction, but it has practical consequences. See here for an example: http://chrisperkins.blogspot.com/2011/04/clojure-does-not-have-variables.html -- -- 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: WAT? BigInt instead of Long?
Those are good answers and it is acceptable, but what ends up happening is that it creates objects. I just used a profiler and that operation inside of my code for a typical run is executed 1,500 million times. It makes up the lions share of self-time measurements. Each object needs construction, destruction and garbage collection even though internally it may be using a primitive type. I'm working with large data structures and doing a lot of math (mainly matrix math) and so this is where I am getting slaughtered in performance. As confirmed by Clojure Programming there is contagion afterwards where everything afterward touched by those numbers becomes BigInt. I'm working on rethinking how I am doing the math so that it doesn't produce so many objects. I think that doing it in the order that the sane looking algebra is laid out makes for readable code but the object contagion is robbing my program of speed. Since a true production run will end up being a million million of these types of operations I need to reconsider how I am going to lay this out. A couple of ideas come to mind such as delaying the use of division or pre-calculating the range of division results since there would only be a few of them. It's really interesting looking at performance for something simple that is going to be called so many times. Thanks for the information so far. -- -- 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: WAT? BigInt instead of Long?
OT: @Peter Mancini I would like to invite you, like* everybody else who is doing a lot of math and especially matrix*, to check out core.matrix ( https://github.com/mikera/matrix-api) and leave as many feedback as possible about everything, from design to implementation of library to performance. Sorry the OT On Wednesday, April 3, 2013 5:29:16 PM UTC+2, Peter Mancini wrote: > > Those are good answers and it is acceptable, but what ends up happening is > that it creates objects. I just used a profiler and that operation inside > of my code for a typical run is executed 1,500 million times. It makes up > the lions share of self-time measurements. Each object needs construction, > destruction and garbage collection even though internally it may be using a > primitive type. I'm working with large data structures and doing a lot of > math (mainly matrix math) and so this is where I am getting slaughtered in > performance. As confirmed by Clojure Programming there is contagion > afterwards where everything afterward touched by those numbers becomes > BigInt. > > I'm working on rethinking how I am doing the math so that it doesn't > produce so many objects. I think that doing it in the order that the sane > looking algebra is laid out makes for readable code but the object > contagion is robbing my program of speed. Since a true production run will > end up being a million million of these types of operations I need to > reconsider how I am going to lay this out. > > A couple of ideas come to mind such as delaying the use of division or > pre-calculating the range of division results since there would only be a > few of them. It's really interesting looking at performance for something > simple that is going to be called so many times. > > Thanks for the information so far. > -- -- 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: WAT? BigInt instead of Long?
Is there a reason for not using primitive doubles? You won't get perfect precision but you won't get slow, high-precision math or tons of objects created and garbage collected either. (* (/ 1.0 255.0) 255.0) 1.0 -- -- 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: WAT? BigInt instead of Long?
On 3 April 2013 17:53, Gary Verhaegen wrote: > Do you really need ratios ? > > Intuitively, the management of ratios should be much more of a problem > than the use of BigInts, performance-wise. You did not provide many > details on the calculations you are trying to do, but I would advise > you to really look at floating point numbers and usual ways to limit > their imprecision (avoiding subtractions etc.); that would be much > faster, as Clojure is able, under the right circumstances, to emit > native operations on native primitive types. > > Plus, with the latest version of Leiningen, you can globally set > variables such as *unchecked-math*. Clojure can be *fast* for numerics > : > http://www.learningclojure.com/2013/02/clojure-is-fast-is-clojure-still-fast.html > > On 3 April 2013 17:29, Peter Mancini wrote: >> Those are good answers and it is acceptable, but what ends up happening is >> that it creates objects. I just used a profiler and that operation inside of >> my code for a typical run is executed 1,500 million times. It makes up the >> lions share of self-time measurements. Each object needs construction, >> destruction and garbage collection even though internally it may be using a >> primitive type. I'm working with large data structures and doing a lot of >> math (mainly matrix math) and so this is where I am getting slaughtered in >> performance. As confirmed by Clojure Programming there is contagion >> afterwards where everything afterward touched by those numbers becomes >> BigInt. >> >> I'm working on rethinking how I am doing the math so that it doesn't produce >> so many objects. I think that doing it in the order that the sane looking >> algebra is laid out makes for readable code but the object contagion is >> robbing my program of speed. Since a true production run will end up being a >> million million of these types of operations I need to reconsider how I am >> going to lay this out. >> >> A couple of ideas come to mind such as delaying the use of division or >> pre-calculating the range of division results since there would only be a >> few of them. It's really interesting looking at performance for something >> simple that is going to be called so many times. >> >> Thanks for the information so far. >> >> -- >> -- >> 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.
nested reduce/reduce-kv idiom
Hi all, I 've recently come across this idiom (instead of nested reduces - from Christophe's blog post of course!) (reducef init (for[x xs, y x, z y] z)) ;;it took me a while to realise how cool this is :) I'm trying to do the same for reduce-kv (for nested maps) but doesn't quite work...has anyone done this already? It comes down to 'seq' returning a [k,v] vector when called on a map so the second nesting level will break because it will find a keyword or something similar. any ideas? Jim -- -- 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: nested reduce/reduce-kv idiom
Destructure the map entry. (for [[k vs] some-map, v vs] v) or whatever. On Wed, Apr 3, 2013 at 1:44 PM, Jim - FooBar(); wrote: > Hi all, > > I 've recently come across this idiom (instead of nested reduces - from > Christophe's blog post of course!) > > (reduce f init (for [x xs, y x, z y] z)) ;;it took me a while to realise how > cool this is :) > > > I'm trying to do the same for reduce-kv (for nested maps) but doesn't quite > work...has anyone done this already? It comes down to 'seq' returning a > [k,v] vector when called on a map so the second nesting level will break > because it will find a keyword or something similar. any ideas? > > > Jim > > > -- > -- > 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. > > -- http://elhumidor.blogspot.com/ -- -- 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: Attempt at rethrow macro
Just because there does not appear to be any logic behind a certain decision does not mean it's a bug. That being said, I've always thought of the compiler workflow in Lisp as being (conceptually): Reader / Data -> Macro Expander -> Compiler. Naturally, macros must be expanded in the macro expansion phase. Special forms, however, are not macros. And while they must participate in the macro expansion phase to some extent (to determine which subforms are subject to macro expansion), I always figured any logic (other than expansion) would be done by the Compiler. In this case, however, it seems that there is logic being applied to a special form that affects the way the form is interpreted (by the compiler) before expansion is done. While that's not necessarily wrong: 1. It doesn't fit my conceptual compilation model (is my model too simple?) 2. In general, wouldn't it make sense to apply any such logic only after all the sub-forms are expanded? Are there special forms for which that rule would not apply? 3. There seem to be compiler states that can not be trivially reached if we first walk the tree, expand all the macros (like the built-in macro expander would), and pass the expanded code into the compiler. In this case, I think we can make the two semantically equivalent by introducing a "try" pseudo-macro that scans the pre-expanded form (like the compiler would) and wraps the resulting body in a "do" form. Does this violate separation between the macro expander and the compiler? Are there states that can not be reached (i.e., the pre-expanded code is semantically different than the non-expanded code), no matter how we implement our expander? Nathan Davis On Tuesday, April 2, 2013 3:37:14 PM UTC-5, Cedric Greevey wrote: > > On Tue, Apr 2, 2013 at 12:20 AM, Bill Robertson > > > wrote: > >> While it may violate the principle of least surprise (until you >> realize/learn that try/catch is a special form), I don't think it's a bug. >> > > Since there's no good engineering reason not to permit macros like > (rethrow ...) to work, it is a bug. Also, pointing out that macros that can > break this property is something of a straw man when I'm indicating that > something *built into the language* has the problem. The latter can be a > language fault even if the former is not. > > -- -- 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.
-> operator and monads
Hi there Is it correct to say that -> operator is a kind of monad in Clojure? Thank you in advance. Plínio Balduino -- -- 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: -> operator and monads
I guess you mean the monadic bind operation, but -> is not it. The only conceptual connection between *bind* and -> is that they are both some kind of function composition operators. -marko On Wednesday, April 3, 2013 8:21:43 PM UTC+2, Plinio Balduino wrote: > > Hi there > > Is it correct to say that -> operator is a kind of monad in Clojure? > > Thank you in advance. > > Plínio Balduino > -- -- 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: -> operator and monads
Now it's clear. Thank you Plínio On Wed, Apr 3, 2013 at 4:45 PM, Marko Topolnik wrote: > I guess you mean the monadic bind operation, but -> is not it. The only > conceptual connection between *bind* and -> is that they are both some > kind of function composition operators. > > -marko > > > On Wednesday, April 3, 2013 8:21:43 PM UTC+2, Plinio Balduino wrote: >> >> Hi there >> >> Is it correct to say that -> operator is a kind of monad in Clojure? >> >> Thank you in advance. >> >> Plínio Balduino >> > -- > -- > 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.
ANN: vim-redl -- advanced fuzzy omnicompletion and VimClojure-style repl with enhanced debugging features
Although I've announced vim-redl in the past, now you can reap the benefits of all of its features without leaving fireplace behind! Just go to https://github.com/dgrnbrg/vim-redl for installation instructions, and you'll end up with advanced fuzzy omnicompletion and a full-fledged repl (accessible via :ReplHere). Redl includes a Debug Repl, which allows you to freeze a REPL and inspect local variables. See a sample session in action to understand better: https://github.com/dgrnbrg/redl#debug-repl Pull requests and feature requests 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.
Re: -> operator and monads
Not even that: -> is not a function composition operator at all, but a form-rewriting macro. You can perfectly well write (-> [x xs] (for (inc x))) to get (for [x xs] (inc x)), and that is not composing any functions. The two things are entirely separate. On Wednesday, April 3, 2013 12:45:55 PM UTC-7, Marko Topolnik wrote: > > I guess you mean the monadic bind operation, but -> is not it. The only > conceptual connection between *bind* and -> is that they are both some > kind of function composition operators. > > -marko > > On Wednesday, April 3, 2013 8:21:43 PM UTC+2, Plinio Balduino wrote: >> >> Hi there >> >> Is it correct to say that -> operator is a kind of monad in Clojure? >> >> Thank you in advance. >> >> Plínio Balduino >> > -- -- 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.
