Re: General subsequence function
Warren,
I would ask myself (quite seriously, no snark intended) whether or not a
fixation on ordered collections or sub-collections woven throughout a program
(as you seem to be describing) is a language feature, or the responsibility of
the programmer.
Larry, Ulises, and Michael have all offered options. It seems that they had no
problem defining this sort of thing on their own; No macros involved or
anything. Your assertion that it is "ugly" is wildly subjective and
superficial. Moreover, it has been pointed out (and I agree) that behavior like
this is rare. If this is common, one would expect other people on the list to
agree, or at the very least make additional suggestions to nudge the idea
along. I'm not seeing that in this thread.
Doesn't that shake your confidence in this being a language-level feature of
Clojure? If not, what does?
'(Devin Walters)
On Wednesday, June 27, 2012 at 7:35 PM, Warren Lynn wrote:
>
> Again, everything I wrote here is "in my view". (think of :injection ("In my
> view")).
>
> Thanks. I am certainly sure it is doable with Clojure, as you just did it.
> The unpleasant thing is Clojure does not provide a built-in function for that
> (which might be much more efficient), and the "sequence abstraction" is less
> of a abstraction if I still need to keep a watchful eye what is the
> underlying concrete type with functions like "into". The unfortunate thing is
> this has nothing to do with whether the language is functional or not. Adding
> a "subseqx" like what you did into the language, or let "into" always return
> results in the same order won't change the fact that Clojure is functional.
> What we see seems just like unnecessary nuance.
>
> On the other hand, those nuances are not beyond fix. Maybe next version
> Clojure will have a function similar to subseqx. Although changing "into"
> will break compatibility, we can add another function. But the bigger the
> code base out in the wild, the more difficult it will be.
>
> I like Lisp in general but it frustrated me (before also with Common Lisp)
> that it seems Lispers often claim the language can help you fly higher while
> in reality it actually makes your walking more difficult. Even it can help
> you fly higher, that will still turn off many people because we walk much
> more than fly. And there is no REAL reason that you need to walk slower when
> trying to fly higher. All those nuances are self imposed without any true
> substantial reason.
>
> Again, just my views and feelings. No scientific proofs of any. Still, I am
> glad that at least there is one more Lisp to play with (and put my hope on).
>
> On Wednesday, June 27, 2012 5:51:57 PM UTC-4, Larry Travis wrote:
> > Something like this will give you what you want:
> >
> > (defn subseqx
> > [s start end]
> > (cond
> > (instance? clojure.lang.IPersistentVector s)
> > (subvec s start end)
> >
> > (instance? java.lang.String s)
> > (subs s start end)
> >
> > :else
> > (let [slice (drop start (take end s))]
> > (cond
> > (instance? clojure.lang.IPersistentList s)
> > (apply list slice)
> >
> > (instance? clojure.lang.PersistentTreeSet s)
> > (apply sorted-set slice)
> >
> > (instance? clojure.lang.PersistentTreeMap s)
> > (apply sorted-map (concat slice))
> >
> > :else
> > slice
> >
> > And you can add conditions for other kinds of ordered collections if and
> > when a need arises. This is neither simple nor pretty, but an advantage of
> > no-side-effects functional programming is that when you call a pure
> > function you don't need to worry about how simple or pretty might be its
> > internal details.
> > --Larry
> >
> > On 6/27/12 3:24 PM, Warren Lynn wrote:
> > > Thanks, but this does not keep the concrete type.
> > >
> > > On Wednesday, June 27, 2012 3:42:25 PM UTC-4, Ulises wrote:
> > > > > I'd forgotten that 'into adds things in the "default" place for
> > > > > whatever type you're using, hence the reversal on lists. I'm not sure
> > > > > if there's a simple way to get the same type out again while
> > > > > preserving order.
> > > >
> > > > How about:
> > > >
> > > > (defn sub-seq [start end coll]
> > > > (take (- end start) (drop start coll)))
> > > >
> > > > U
> > > --
> > > 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.goo
Re: [ANN] C2 v0.2.0: now with cljs data binding
Of course, you may want a link to the library itself: https://github.com/lynaghk/c2 As always, to use from Clojure/ClojureScript just add this to your `project.clj`: [com.keminglabs/c2 "0.2.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
[ANN] C2 v0.2.0: now with cljs data binding
This release contains backwards-incompatible changes in the both the API
and philosophy.
The primary change is that the imperative `unify!` function has been
removed in favor of a `unify` datatype that represents the same idea:
"these children should match up with this template function run across
these data".
Changing from a procedure call to a value buys composability; you can now,
e.g., build static elements at the same time as mapping some dataset to DOM
elements:
```clojure
(bind! "#barchart"
[:div#barchart
[:h2 "Rad barchart!"]
[:div.bars
(unify {"A" 1, "B" 2, "C" 4, "D" 3}
(fn [[label val]]
[:div.bar
[:div.bar-fill {:style {:width (x-scale val)}}]
[:span.label label]]))]])
```
This new `bind!` macro also takes into account mutable state: any atoms
dereferenced within the body (or indirectly via a function called in the
body) are noted, and watchers added so that when any of those atoms change
state the body will be re-run and the DOM automatically updated.
The `bind!` macro itself returns a `computed-observable`, which implements
IWatchable and an IDisposable protocol (so you can remove watchers from the
dereferenced atoms).
We've found that this `bind!` macro makes C2 suitable for general DOM
manipulation and clientside application development.
For a full sample application built using this "data-driven-view" approach,
see this C2-implementation of TodoMVC:
https://github.com/lynaghk/c2-demos/tree/master/todoMVC
Since fast Hiccup rendering and state-manipulation macros aren't exactly
data visualization, they've been split out into two separate libraries.
Hiccup rendering and DOM walking/merging code is now in Singult:
https://github.com/lynaghk/singult
which is actually a CoffeeScript library (for pure speed).
There are ClojureScript bindings, and it is fully compatible with Closure
advanced mode compilation.
The JavaScript deps and externs you need will automatically get picked up
by latest (0.2.1) lein cljsbuild, so you can just pull in via `project.clj`
as usual.
The computed-observables macros are in Reflex:
https://github.com/lynaghk/reflex
which detects dereferenced atoms within the macro body.
This is useful for adding watches to multiple atoms.
Personally, I can't wait to depreciate the hell out of this one as soon as
we get a nice reactive streams framework for cljs = )
Finally, I've created a C2 mailing list here:
https://groups.google.com/forum/#!forum/c2-cljs
for questions about data visualization and app development in
Clojure(Script).
--
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
Re: Reducers
On Wed, Jun 27, 2012 at 4:57 PM, Leif wrote: > Min, like intersection, has a noncomputable "identity" value -- infinity. > And max and min are used in many more algorithms than intersection, so maybe > this will start some discussion. It seems to me the reducers framework is clearly documented to either need a computable identity or to have an initial value. Given that, it seems reasonable that for such functions that don't have a computable identity you would need: (r/reduce func (first coll) (rest coll)) [perhaps that's why there was no response in this thread?] -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Reducers
Christian: Thank you for asking for additional reading material. Nicolas: Thank you for providing additional reading material. On Thursday, May 10, 2012 at 7:02 AM, nicolas.o...@gmail.com wrote: > I can describe the background to understand my last email. > > From the programming point of view, I have been told since yesterday > that what I explained has already been explained better in "Stream > Fusion From Lists to Streams to Nothing at All" from Coutts > Leschinskiy and Stewart: > > metagraph.org/papers/stream_fusion.pdf > (http://metagraph.org/papers/stream_fusion.pdf) > > The article is very clear if you can get used to the strange Haskell > syntax and its lack of brackets. > > > From the cultural/theoritical point of view, there is quite well > understood link between data-structures and > some categorical structures. > ( I try stay informal and put fancy names and link to definitions > inside brackets ) > > Types of finite recursive data structures (think of a list) are > defined by being the smallest solution to an > equation like List = 1 + Any x List. Here 1 means the type that > contains only nil, Any means the type of anything, x corresponds to a > pair and + to a choice. So this reads: a list is either nil or a pair > of anything and another list. > Being the smallest solution means that it contains only finite > data-structures. > ( http://en.wikipedia.org/wiki/Initial_algebra ) > > An element of such a type is characterised by how they can be reduced/folded. > ( http://en.wikipedia.org/wiki/Catamorphism ) > fold: forall A, List -> ((1 + Any x Acc) -> Acc) -> Acc > Meaning that there is a one to one mapping between lists and functions of > type: > forall Acc, ((1 + Any x Acc) -> Acc) -> Acc > This is the type of #(reduce _ l): you give it a function that takes > either no arguments and give you > an initial Accumulator or take an element of the list and and the last > Accumulator and returns a new Accumulator, and it returns the last > Accumulators. > > This one to one correspondence can be seen as (reduce _ l) in one > direction and #(_ (fn [p] (and p (apply cons p))) in the other > direction. > > This definition of lists (as functions) has been used in programming > languages without data constructors. > ( System F for example, http://en.wikipedia.org/wiki/System_F ). > > If you look to infinite data structures, like Streams, they are the > biggest solutions of similar equations: > Stream = 1 + Any x Stream (if you accept a Stream can finish early) > > They are dual (which means you invert all arrows in all definitions) to Lists. > ( see Final Coalgebra in http://en.wikipedia.org/wiki/Initial_algebra ) > > A stream is characterised as how it is unfolded/generated. > unfold : forall B, (B -> 1 + Any x B) -> B -> Stream > (See how the arrows are reversed with respect to fold) > And so they are in one to one correspondence with : > exists Seed, (Seed x (Seed -> 1 + Any x Seed)) > > Which means any Stream can be defined as a Seed, of a given type Seed > that you can choose freely, > and a way to grow from the seed, a function grow that takes a Seed and > tells you: > - either that the Stream is finished > - or the first element of the Stream and the Seed for the rest of the Stream. > > For example the stream of even natural numbers can be seen as the seed > 0 together with a function > grow = (fn [ seed ] [ seed (+ seed 2) ]), saying that first element > is equal to the seed and the rest of the stream > is the one defined by a seed = seed + 2 . > > A very good paper showing this style of programming, and more, is : > > http://eprints.eemcs.utwente.nl/7281/01/db-utwente-40501F46.pdf > > > Sorry for the long off-topic. > > Best regards, > > Nicolas. > > -- > 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 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
Re: General subsequence function
It seems the name "append" has not yet been taken. How about we do this with Clojure: 1. add a new function "append", which splices multiple ordered collection together and always returns the result in the concrete type of its first argument. So: (append [1] '(2 3)) => [1 2 3] (append '(1) [2 3])) => (1 2 3) It is different from "concat" because it keeps the original concrete type. This will solve the "into" problem. and "into" still has its value because it works on non ordered collections too. 2. add another function "slice", which will return a segment of an ordered collection in its original concrete type. Something like this: (slice [1 2 3] 1 3) => [2 3] it may also take an optional "step" argument (like take-nth). If a post like this will get no attention from the Clojure gods, where should I submit the idea? 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
Re: General subsequence function
Again, everything I wrote here is "in my view". (think of :injection ("In
my view")).
Thanks. I am certainly sure it is doable with Clojure, as you just did it.
The unpleasant thing is Clojure does not provide a built-in function for
that (which might be much more efficient), and the "sequence abstraction"
is less of a abstraction if I still need to keep a watchful eye what is the
underlying concrete type with functions like "into". The unfortunate thing
is this has nothing to do with whether the language is functional or not.
Adding a "subseqx" like what you did into the language, or let "into"
always return results in the same order won't change the fact that Clojure
is functional. What we see seems just like unnecessary nuance.
On the other hand, those nuances are not beyond fix. Maybe next version
Clojure will have a function similar to subseqx. Although changing "into"
will break compatibility, we can add another function. But the bigger the
code base out in the wild, the more difficult it will be.
I like Lisp in general but it frustrated me (before also with Common Lisp)
that it seems Lispers often claim the language can help you fly higher
while in reality it actually makes your walking more difficult. Even it can
help you fly higher, that will still turn off many people because we walk
much more than fly. And there is no REAL reason that you need to walk
slower when trying to fly higher. All those nuances are self imposed
without any true substantial reason.
Again, just my views and feelings. No scientific proofs of any. Still, I am
glad that at least there is one more Lisp to play with (and put my hope on).
On Wednesday, June 27, 2012 5:51:57 PM UTC-4, Larry Travis wrote:
>
> Something like this will give you what you want:
>
> (defn subseqx
> [s start end]
> (cond
> (instance? clojure.lang.IPersistentVector s)
> (subvec s start end)
>
> (instance? java.lang.String s)
> (subs s start end)
>
> :else
> (let [slice (drop start (take end s))]
> (cond
> (instance? clojure.lang.IPersistentList s)
> (apply list slice)
>
> (instance? clojure.lang.PersistentTreeSet s)
> (apply sorted-set slice)
>
> (instance? clojure.lang.PersistentTreeMap s)
> (apply sorted-map (concat slice))
>
> :else
> slice
>
> And you can add conditions for other kinds of ordered collections if and
> when a need arises. This is neither simple nor pretty, but an advantage of
> no-side-effects functional programming is that when you call a pure
> function you don't need to worry about how simple or pretty might be its
> internal details.
> --Larry
>
> On 6/27/12 3:24 PM, Warren Lynn wrote:
>
> Thanks, but this does not keep the concrete type.
>
> On Wednesday, June 27, 2012 3:42:25 PM UTC-4, Ulises wrote:
>>
>> > I'd forgotten that 'into adds things in the "default" place for
>> whatever type you're using, hence the reversal on lists. I'm not sure if
>> there's a simple way to get the same type out again while preserving order.
>>
>> How about:
>>
>> (defn sub-seq [start end coll]
>> (take (- end start) (drop start coll)))
>>
>> U
>>
> --
> 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 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
[ANN] Leiningen 2.0.0-preview7
I'm happy to announce the release of Leiningen version 2.0.0-preview7. This release introduces mirror support as well as the ability to sign deployments and verify signatures and changes to credentials. ## 2.0.0-preview7 / 2012-06-27 * Fix a bug where failed javac wouldn't abort. (Michael Klishin) * Check task aliases everywhere tasks are invoked. * Sign jars and poms of releases upon deploy by default. * Don't decrypt `credentials.clj.gpg` for every request. * Support setting `:mirrors` in project.clj. (Chas Emerick, Nelson Morris) * Allow aliases shadowing task names to invoke shadowed tasks. * Emit `doc/intro.md` in new project templates. * Allow `:scm` to be set in project.clj for pom inclusion. (Florian Anderiasch) * Fix a bug where dependency `:classifier` and `:extension` would be ignored. * Speed up subprocess launches when `:bootclasspath` is set. * Set user agent for HTTP requests. (Bruce Adams) * Verify signatures of dependencies with `lein deps :verify`. * Move task chaining to `do` task in order to allow for higher-order use. There are two breaking changes in this release. The first is rearranging the implementation of task chaining so that it's just another task. This means that chains can be run inside other higher-order tasks. This is done in the `do` task: `lein clean, test, deploy` becomes `lein do clean, test, deploy`. It also makes things like this possible: `lein with-profile production do check, uberjar`. Previously `with-profile` could not apply across task chains. Use of the old style will emit a warning explaining the change, so hopefully this is straightforward to fix. Details are at http://groups.google.com/group/leiningen/browse_thread/thread/164a9982eb45e528 The other breaking change is making credential decryption explicit. Rather than making the presence of ~/.lein/credentials.clj.gpg cause decryption every time, now you must place `:gpg` in the repository settings to indicate that the given repository needs to have the credentials file decrypted. This allows for a streamlined experience for users who do not have a GPG agent configured. Details are at http://groups.google.com/group/leiningen/browse_thread/thread/1e7e902cc87360da Launch times may be sped up by adding `:bootclasspath true` to project.clj or a profile. This causes the project's JVM to put its dependencies on the bootstrap classpath, causing them to skip bytecode verification and speeding up boot times considerably. However, there are compatibility issues with some libraries, so this is not enabled by default. It's my hope that this is the last 2.x preview release and that the next release will be 2.0.0 final. However, there are still a few big steps to be taken surrounding Clojars[1] for which this preview paves the way. Thanks, Phil [1] - http://groups.google.com/group/clojars-maintainers/browse_thread/thread/77c1cd77e478bb0f -- 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
Re: Reducers
OK, the complete silence leads me to believe that not many people reduce
with set/intersection.
However, I thought of a couple of other functions that don't work with the
new framework: max and min.
user> (require '[clojure.core.reducers :as r])
user=> (reduce min [1 2])
1
user=> (r/reduce min [1 2])
ArityException Wrong number of args (0) passed to: core$min
clojure.lang.AFn.throwArity (AFn.java:437)
Min, like intersection, has a noncomputable "identity" value -- infinity.
And max and min are used in many more algorithms than intersection, so
maybe this will start some discussion.
I really think that single elements are the place to bottom out the
recursion.
On Sunday, May 20, 2012 3:24:57 PM UTC-4, Leif wrote:
>
> From the article: "The combining fn must supply an identity value when
> called with no arguments" This means that you can't use combining
> functions whose identity value can't be computed, but satisfies the proper
> rules. E.g. set intersection:
>
> (intersection) == e == the set of all possible elements of a set
>
> Of course this arity doesn't exist, but the arity-1 could be viewed as
> shorthand for:
> (intersection s) == s
> ; == (intersection s e) == (intersection e s) ; if e could actually be
> computed
>
> So, the new lib behaves slightly differently than core/reduce here:
> (use 'clojure.set)
> (require '(clojure.core [reducers :as r]))
> (reduce intersection [#{1 2} #{2 3}]) ;==> #{2}
> (r/reduce intersection [#{1 2} #{2 3}]) ;==> throws ArityException
> ; for completeness
> (reduce intersection []) ;==> throws ArityException
> (r/reduce intersection []) ;==> throws ArityException
>
> It might fix things to special-case empty collections and make the
> "leaves" of the recursion single elements, but maybe functions with these
> weird non-computable identity elements, like set intersection, are too rare
> to bother. I can't think of another one off the top of my head.
>
> --Leif
>
> On Tuesday, May 8, 2012 11:20:37 AM UTC-4, Rich Hickey wrote:
>>
>> I'm happy to have pushed [1] today the beginnings of a new Clojure
>> library for higher-order manipulation of collections, based upon *reduce*
>> and *fold*. Of course, Clojure already has Lisp's *reduce*, which
>> corresponds to the traditional *foldl* of functional programming. *reduce*
>> is based upon sequences, as are many of the core functions of Clojure, like
>> *map*, *filter* etc. So, what could be better? It's a long story, so I'll
>> give you the ending first:
>>
>> * There is a new namespace: clojure.core.reducers
>> * It contains new versions of *map*, *filter* etc based upon transforming
>> reducing functions - reducers
>> * It contains a new function, **fold**, which is a parallel
>> reduce+combine
>> * *fold* uses **fork/join** when working with (the existing!) Clojure
>> vectors and maps
>> * Your new parallel code has exactly the same shape as your existing
>> seq-based code
>> * The reducers are composable
>> * Reducer implementations are primarily functional - no iterators
>> * The model uses regular data structures, not 'parallel collections' or
>> other OO malarkey
>> * It's fast, and can become faster still
>> * This is work-in-progress
>>
>> I've described the library in more detail here:
>>
>>
>> http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html
>>
>>
>> Rich
>>
>> [1]
>> https://github.com/clojure/clojure/commit/89e5dce0fdfec4bc09fa956512af08d8b14004f6
>>
>>
>>
--
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
Re: General subsequence function
Something like this will give you what you want: (defn subseqx [s start end] (cond (instance? clojure.lang.IPersistentVector s) (subvec s start end) (instance? java.lang.String s) (subs s start end) :else (let [slice (drop start (take end s))] (cond (instance? clojure.lang.IPersistentList s) (apply list slice) (instance? clojure.lang.PersistentTreeSet s) (apply sorted-set slice) (instance? clojure.lang.PersistentTreeMap s) (apply sorted-map (concat slice)) :else slice And you can add conditions for other kinds of ordered collections if and when a need arises. This is neither simple nor pretty, but an advantage of no-side-effects functional programming is that when you call a pure function you don't need to worry about how simple or pretty might be its internal details. --Larry On 6/27/12 3:24 PM, Warren Lynn wrote: Thanks, but this does not keep the concrete type. On Wednesday, June 27, 2012 3:42:25 PM UTC-4, Ulises wrote: > I'd forgotten that 'into adds things in the "default" place for whatever type you're using, hence the reversal on lists. I'm not sure if there's a simple way to get the same type out again while preserving order. How about: (defn sub-seq [start end coll] (take (- end start) (drop start coll))) U -- 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 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
Re: [ANN] clojure.java.jdbc 0.2.3 available on Maven Central
that is very interesting, I've played around with generating sql from datalog queries, but stopped when I ran up against generating queries for recursive datalog rules because I wasn't aware of WITH RECURSIVE On Tue, Jun 26, 2012 at 6:29 PM, Chas Emerick wrote: > Random thought: recursive queries are possible in SQL using recursive common > table expressions. The PostgreSQL manual has a good introduction to them: > > http://www.postgresql.org/docs/9.1/static/queries-with.html > > And another introduction to them, in the particular area of querying > hierarchical data using recursive CTEs: > > http://explainextended.com/2009/07/17/postgresql-8-4-preserving-order-for-hierarchical-query/ > > Cheers, > > - Chas > > On Jun 26, 2012, at 8:26 AM, Niels van Klaveren wrote: > > Yeah, it's a pain to include Datomic's Datalog implementation through Maven > dependencies, since you need to install the jar by hand. Afaik > clojure.contrib.datalog didn't compile to SQL. Theoretically it should be > possible to do so, since Datalog is a superset of SQL. However, the extra > functionality in Datalog would be hard to implement in SQL (for instance, > recursive queries), and result in a lot of not very optimal SQL queries. > > On Tuesday, June 26, 2012 11:45:15 AM UTC+2, mnicky wrote: >> >> Thanks! However it'd be nice if it was released as a separate library. >> >> Also, I thought that clojure.contrib.datalog worked for SQL queries... >> That would be even better ;) >> >> On Monday, June 25, 2012 1:50:19 PM UTC+2, Niels van Klaveren wrote: >>> >>> You can use the Datomic datalog implementation to query Clojure >>> collections. I think this is the same use clojure.contrib.datalog had. >>> >>> On Monday, June 25, 2012 12:47:29 PM UTC+2, mnicky wrote: On Saturday, June 23, 2012 1:20:30 AM UTC+2, Niels van Klaveren wrote: > > > I was thinking if an SQL generation DSL / library could be based on > core.logic ? > Something like revival of clojure.contrib.datalog would be great. > > > -- > 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
Re: General subsequence function
Thanks, but this does not keep the concrete type. On Wednesday, June 27, 2012 3:42:25 PM UTC-4, Ulises wrote: > > > I'd forgotten that 'into adds things in the "default" place for whatever > type you're using, hence the reversal on lists. I'm not sure if there's a > simple way to get the same type out again while preserving order. > > How about: > > (defn sub-seq [start end coll] > (take (- end start) (drop start coll))) > > U > -- 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
Re: General subsequence function
> > Ordering problem aside, I'd argue this is not an unreasonable amount of > code for what seems to me a pretty rare set of requirements. Most people > who want a same-type segment from the middle of an ordered collection > (which is already uncommon in my experience) are probably either using > vectors already or at least know what type they're operating on. > > > If I cannot keep the type of an ordered collection (OD for short later. thanks for the name), that makes generic treatment of an OD really difficult, because functions like "conj" and "into" will have different behaviors on different concrete types. I really cannot "keep ordering problem aside" (why we call them "ordered collection", right?). I have to say, for me certain things in Clojure are really weird and do not feel right. I hope it will get better before it is too late, because I do want to use it for the aspects I like (a practically usable LISP). Of course, needless to say, to avoid a flame, these are all my OPINIONS, not a verdict (I don't have the least authority for that) -- 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
Re: General subsequence function
> I'd forgotten that 'into adds things in the "default" place for whatever type > you're using, hence the reversal on lists. I'm not sure if there's a simple > way to get the same type out again while preserving order. How about: (defn sub-seq [start end coll] (take (- end start) (drop start coll))) U -- 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
Re: General subsequence function
On Jun 27, 2012, at 1:02 PM, Warren Lynn wrote: > Do you mean something like this: > > (defn subseqx [s start end] (into (empty s) (drop-last (- (count s) end) > (drop start s > > Two things I don't like it: > > 1. It does not work > (subseqx [1 2 3] 1 3) => [2 3] > (subseqx '(1 2 3) 1 3) => (3 2) > because "into" will reverse the order on sequence. I'd forgotten that 'into adds things in the "default" place for whatever type you're using, hence the reversal on lists. I'm not sure if there's a simple way to get the same type out again while preserving order. > 2. kind of ugly for such a simple thing, and may not be efficient either. > > Any SIMPLE way to do it? I need concrete type unchanged. I don't think that > is a rare need/use case. Ordering problem aside, I'd argue this is not an unreasonable amount of code for what seems to me a pretty rare set of requirements. Most people who want a same-type segment from the middle of an ordered collection (which is already uncommon in my experience) are probably either using vectors already or at least know what type they're operating on. > PS: when I say "sequences", how should I distinguish between general sequence > and concrete sequences? Any conventions for the wording? "Ordered collection" is the preferred term for the general concept, I think. -- 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
Re: General subsequence function
You can combine 'drop and 'drop-last to get a seq version of subvec (but > lazy and O(n)). As for the issue of concrete types: in general, clojure's > sequence functions return seqs, not instances of whatever concrete type you > gave them. If you need a specific type, you normally just pour the result > through 'into or one of the specific collection creation functions. Do you mean something like this: (defn subseqx [s start end] (into (empty s) (drop-last (- (count s) end) (drop start s Two things I don't like it: 1. It does not work (subseqx [1 2 3] 1 3) => [2 3] (subseqx '(1 2 3) 1 3) => (3 2) because "into" will reverse the order on sequence. 2. kind of ugly for such a simple thing, and may not be efficient either. Any SIMPLE way to do it? I need concrete type unchanged. I don't think that is a rare need/use case. PS: when I say "sequences", how should I distinguish between general sequence and concrete sequences? Any conventions for the wording? -- 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
Re: General subsequence function
On Jun 27, 2012, at 9:39 AM, Warren Lynn wrote: > I am surprised that there seems to be no general sub-sequence function that > will return a segment of a sequence without changing the underlying concrete > type. I found "subvec", but it works only on vectors. "subseq" is not what I > thought it is. Did I miss anything? Or is there a simple idiomatic way to do > it so there is no need for such a function? Thank you. You can combine 'drop and 'drop-last to get a seq version of subvec (but lazy and O(n)). As for the issue of concrete types: in general, clojure's sequence functions return seqs, not instances of whatever concrete type you gave them. If you need a specific type, you normally just pour the result through 'into or one of the specific collection creation functions. -- 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
Re: Anyone using Sublime Text 2 + SumblimeREPL with Windows?
On Wednesday, June 27, 2012 5:07:05 PM UTC+2, Niels van Klaveren wrote: > > This combination of Sublime -text & -REPL looks pretty useful, with little > extra configuration (except that decommenting part :) ). > When I have the REPL launched, when returning values I get a lot of lines > with BS..BS sequences. Any idea how to get rid of those ? > I'm just new using Clojure and Sublime but don't seem to have those lines. Does it always happend to you? Can you provide some code that does? 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
Re: Anyone using Sublime Text 2 + SumblimeREPL with Windows?
On Wednesday, June 27, 2012 2:38:39 PM UTC+2, Lapcjonak wrote:
>
> On Jun 24, 9:20 pm, Jacobo Polavieja
> wrote:
>
> > My current development environment is that: Sublime Text 2 editor with
> > the fabulous SublimeREPL plugin to be able to copy code into the Clojure
> > REPL.
> >
> > As absurd as it may seem... I can't find the combination of keys to send
> > functions or selected code to the REPL.
>
> I just googled:
> http://tomschenkjr.net/using-sublime-text-2-for-r/
>
> There is the solution: add the following
> // Executes a selection of text in REPL, latter only displays code and
> does not execute
> { "keys": ["ctrl+shift+r"], "command": "repl_transfer_current",
> "args": {"scope": "selection"}},
>
> into your "Preferences / Key Bindings - User"
>
> (verified: works in Sublime 2 for Windows)
>
> --
> Zmi La
Hi Zmitro,
With my last uploaded keybinding file that works although I left it as the
default which is/was F2 + s. It seems the SublimeText team commented those
lines and all because those bindings interfere with other bindings (which I
stated previously with the "bookmarks" binding). I've been using F2+l
(lowercase "L") to send a line to the REPL, F2+f to send a complete file,
and F2+s to send what's selected.
I think I have to find a better and more appropiate keybinding, but this is
ok for now. I tried putting the default F# one (Alt+Enter to send the
selected code), but had no success on the first attempt and haven't
actually tried again.
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
Re: Anyone using Sublime Text 2 + SumblimeREPL with Windows?
This combination of Sublime -text & -REPL looks pretty useful, with little extra configuration (except that decommenting part :) ). When I have the REPL launched, when returning values I get a lot of lines with BS..BS sequences. Any idea how to get rid of those ? On Monday, June 25, 2012 4:09:00 PM UTC+2, Jacobo Polavieja wrote: > > Well, I thought I had specified in the title my problem with sending > commands to SublimeREPL, but as I did it badly and wasn't so specific, I > guess I can put my las "problem" in this very thread. > > As we know, Sublime saves the session you're in and restores it everytime > you open Sublime again. The thing is that when I have a ClojureREPL in the > session and close Sublime, the Clojure REPL tab appears again but it really > doesn't spawn a process to call to the REPL again. So, in short, I have to > close that and open a new REPL for each session. > > Do you know of any way to force to open a new REPL everytime we fire up > Sublime? > > 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
General subsequence function
I am surprised that there seems to be no general sub-sequence function that will return a segment of a sequence without changing the underlying concrete type. I found "subvec", but it works only on vectors. "subseq" is not what I thought it is. Did I miss anything? Or is there a simple idiomatic way to do it so there is no need for such a function? Thank you. -- 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
Re: Anyone using Sublime Text 2 + SumblimeREPL with Windows?
On Jun 24, 9:20 pm, Jacobo Polavieja
wrote:
> My current development environment is that: Sublime Text 2 editor with
> the fabulous SublimeREPL plugin to be able to copy code into the Clojure
> REPL.
>
> As absurd as it may seem... I can't find the combination of keys to send
> functions or selected code to the REPL.
I just googled:
http://tomschenkjr.net/using-sublime-text-2-for-r/
There is the solution: add the following
// Executes a selection of text in REPL, latter only displays code and
does not execute
{ "keys": ["ctrl+shift+r"], "command": "repl_transfer_current",
"args": {"scope": "selection"}},
into your "Preferences / Key Bindings - User"
(verified: works in Sublime 2 for Windows)
--
Zmi La
--
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
