An optimized pattern matching library for Clojure.
Dependency: [org.clojure/core.match "0.3.0-alpha5"]
Changes since 0.3.0-alpha4:
* Removed unused dependency on tools.analyzer.jvm (reduces load time)
More info: https://github.com/clojure/core.match/blob/master/README.md
--
You rec
http://blog.klipse.tech/clojure/2016/10/25/core-match.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
firs
Okay, thanks!
On 9 December 2015 at 02:39, David Nolen wrote:
> core.match will attempt to optimize matching :when clauses in the decision
> tree.
>
> David
>
> On Tue, Dec 8, 2015 at 4:18 PM, retnuH wrote:
>
>> I can't really figure out what the deal
core.match will attempt to optimize matching :when clauses in the decision
tree.
David
On Tue, Dec 8, 2015 at 4:18 PM, retnuH wrote:
> I can't really figure out what the deal is with predicates. They're not
> mentioned in the Basic/Advanced usage wiki pages at all. The code
I can't really figure out what the deal is with predicates. They're not
mentioned in the Basic/Advanced usage wiki pages at all. The code for
Guards and Predicates is basically identical.
The only difference that I've been able to find (beyond the spelling,
obviously):
- predicates can only
ice day,
> Jon
>
>
> On 16 July 2015 at 23:06, Rastko Soskic >
> wrote:
>
>> Hi, I am getting familiar with Clojure's core.match and
>> simply starting with something simple and familar (some Scala match
>> expressions)
>> and translating that to
Hello !
I think, this branch (without :<< empty?))
(match [l prefix]
*[_ ([] :seq)] true*
is already checking that prefix is empty.
Have a nice day,
Jon
On 16 July 2015 at 23:06, Rastko Soskic wrote:
> Hi, I am getting familiar with Clojure's core.match and
> sim
Hi, I am getting familiar with Clojure's core.match and
simply starting with something simple and familar (some Scala match
expressions)
and translating that to core.match variant:
Check out this function which checks whether sequence starts with another:
def startsWith[A](l: List[A], p
This might be a bit of a strange or off-topic segue but it got me thinking.
Is there an idiomatic way to handle optional dependencies in Clojure?
Ideally, this macro would be a part of core.match itself (submit a pull
request, get it merged, and whatnot). Of course, you don't want core.
Thanks, exactly what i needed
On Monday, June 22, 2015 at 1:01:30 AM UTC+3, Sean Corfield wrote:
>
> How about this:
>
> (defmacro matches [value pattern]
> `(is (match ~value ~pattern true :else false)
>(str "(match " ~value " " '~pattern ")")))
>
> (let [a {:x 2}]
>
})
; => expected: (clojure.core.match/match a {:y _} true :else false)
; => actual: false
> On Jun 21, 2015, at 10:24 AM, whodidthis wrote:
>
> It would be fun to use core.match to have an easier time testing results that
> are hash-maps of different patterns. I'm ju
It would be fun to use core.match to have an easier time testing results
that are hash-maps of different patterns. I'm just having a difficult time
to get failing cases' input values show up in test results:
(use 'clojure.test)
(require '[clojure.core.match :refer [match]])
No, it actually compiles down to a pile of ifs, and try/catch/throws (for
backtracking). It's pretty fast, but it won't be as fast as a jump table
for complex matches, that's for sure.
Timothy
On Fri, May 15, 2015 at 5:53 PM, Surgo wrote:
> core.match compiles down to case, d
core.match compiles down to case, does it not? So the comparisons here are
similar: http://insideclojure.org/2015/04/27/poly-perf/
-- Morgon
On Friday, May 15, 2015 at 2:57:23 PM UTC-4, tbc++ wrote:
>
> One big thing to consider is that core.match is closed dispatch. If you
> write a
One big thing to consider is that core.match is closed dispatch. If you
write a function that uses core.match, I can't extend it inside my code.
This is something that is possible with both multi-methods and protocols.
Timothy
On Fri, May 15, 2015 at 12:49 PM, Sam Raker wrote:
> The di
The discussion/post-linked-to
in https://groups.google.com/d/msg/clojure/eoAp6QVimYI/iipmEJNKdrIJ have
got me thinking about protocols & multimethods, which I admittedly have
possibly never actually used, now that I think about it. I'm wondering how
they differ from core.match[1].
On Thu, Jan 29, 2015 at 10:46:45AM +, László Török wrote:
> One thing that isn't obvious to me, how it should work when matching more
> than one pattern.
I can't seem to find it anywhere in the core.match wiki, but I'm fairly
sure it tries them in order, returning the f
Hi,
I started experimenting with core.match.
One thing that isn't obvious to me, how it should work when matching more
than one pattern.
In the following example, the expression returns 3 or 4 depending on which
pattern comes first:
(require '[clojure.core.match :as cm])
(cm/matc
On Saturday, 13 December 2014 15:14:37 UTC+2, David Nolen wrote:
> Yet another quick release - core.match 0.3.0-alpha4. The only change
> is fixing a regression around the test sharing of literal patterns.
>
> On Fri, Dec 12, 2014 at 12:54 PM, David Nolen wrote:
> > core.m
Yet another quick release - core.match 0.3.0-alpha4. The only change
is fixing a regression around the test sharing of literal patterns.
On Fri, Dec 12, 2014 at 12:54 PM, David Nolen wrote:
> core.match, an efficient pattern matcher for Clojure & ClojureScript
>
> New release v
Just cut 0.3.0-alpha2, the only change is a fix for when fn
application patterns are nested in map/vector patterns.
David
On Fri, Dec 12, 2014 at 12:54 PM, David Nolen wrote:
> core.match, an efficient pattern matcher for Clojure & ClojureScript
>
> New release version:
Looks awesome. Thanks David!
Reid
On 12/12/14 12:01, David Nolen wrote:
Erg, Lein dep information should be the following of course:
Leiningen project.clj
[org.clojure/core.match "0.3.0-alpha1"]
On Fri, Dec 12, 2014 at 12:54 PM, David Nolen wrote:
core.match, an efficie
Erg, Lein dep information should be the following of course:
Leiningen project.clj
[org.clojure/core.match "0.3.0-alpha1"]
On Fri, Dec 12, 2014 at 12:54 PM, David Nolen wrote:
> core.match, an efficient pattern matcher for Clojure & ClojureScript
>
> New releas
core.match, an efficient pattern matcher for Clojure & ClojureScript
New release version: 0.3.0-alpha1
## Dependency information
Maven pom.xml
org.clojuer
core.match
0.3.0-alpha1
Leiningen project.clj
[com.cognitect.transit-cljs "0.8.161"]
This re
Mulling on this some more, I think it might be impossible.
My reasoning is: I'm trying to do this so I can determine the list of
clauses at run-time. But `core.match/match` does its magic at compile time,
so it seems unlikely that I'm going to get what I want!
Back to the dra
t; I'd like to be able to write something like the following:
>
> (def some-clauses
> '[[false _] :f
> [true _] :t])
>
> (match-clauses [[false 3]] some-clauses)
>
> but I can't figure out how to write `match-clauses`. If `core.match/match`
> were a fun
s)
but I can't figure out how to write `match-clauses`. If `core.match/match`
were a function it would be easy, but it isn't. Can someone give me a push
in the right direction?
Thanks,
Jony
--
You received this message because you are subscribed to the Google
Groups "Clojure
Does the following snippet show the intended behavior?
user=> (def not-nil? (complement nil?))
> #'user/not-nil?
> user=> (defn f [x] (match [x] [{:a (ma :guard not-nil?)}] ma :else
> :no-match))
> #'user/f
> user=> (f {:a 1})
> 1
> user=> (f {:b 1})
> nil
> user=> (f {:a nil})
> :no-match
> user
a vector
>> of occurrences, vars. Clause question-answer syntax is like `cond`.
>> Questions must be wrapped in a vector..."
>> https://github.com/clojure/core.match/blob/5429e20f5db8c398d745f15f7a85f65976f45397/src/main/clojure/clojure/core/match.clj#L1966-1976
>>
>
ed in a vector..."
> https://github.com/clojure/core.match/blob/5429e20f5db8c398d745f15f7a85f65976f45397/src/main/clojure/clojure/core/match.clj#L1966-1976
>
> However, it seems to work without wrapping the occurrences and questions
> in vectors.
>
> (match [{:a 1 :b 2}] [{
The clojure.core.match/match docstring states that it takes "...a vector of
occurrences, vars. Clause question-answer syntax is like `cond`. Questions
must be wrapped in a vector..."
https://github.com/clojure/core.match/blob/5429e20f5db8c398d745f15f7a85f65976f45397/src/main/clojure/cl
It is always matching the first clause because it is getting translated
into a `let` binding. In match, the left-hand side `get` is just a symbol,
not the `var` it resolves to, so might as well be `(let [fun assoc] (match
fun foo "foo!"))` where `foo` will just be bound to `assoc`.
Match does n
How can I match fns as values? For example:
(let [fun assoc]
(match [fun]
[get] "get"
[assoc] "assoc"
:else "other"))
The example above is not match correctly. It always matches on first clause.
Thank you.
--
You received this message because you are subscribed to the Google
G
The only significant change is the bugfix MATCH-92, keywords with dots now
supported.
http://github.com/clojure/core.match
--
--
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
If there's something specific you would like to see based on what is
already present I'm listening.
David
On Fri, Oct 18, 2013 at 11:49 AM, François De Serres <
francois.de.ser...@gmail.com> wrote:
> Hi David,
>
> any chance to see core.match expose its compiler
Hi David,
any chance to see core.match expose its compiler in the near future?
The ability to create "matchers" at runtime (like matchure/fn-match) would be
much welcome ;)
Thankies,
--
François
--
--
You received this message because you are subscribed to the Google
Groups "
ently no support for matching sets and I have no plans in the
>> > near future. Patch welcome, it could be matched and optimized similarly
>> to
>> > map matching.
>> >
>> > On Thursday, October 10, 2013, Phillip Lord wrote:
>> >
>> >>
>
>> > near future. Patch welcome, it could be matched and optimized similarly
>> to
>> > map matching.
>> >
>> > On Thursday, October 10, 2013, Phillip Lord wrote:
>> >
>> >>
>> >> I've been playing with co
map matching.
> >
> > On Thursday, October 10, 2013, Phillip Lord wrote:
> >
> >>
> >> I've been playing with core.match recently. One thing that I am confused
> >> about is, I cannot match over a set (based on membership), unless I
> >> convert into a ma
ed and optimized similarly to
> map matching.
>
> On Thursday, October 10, 2013, Phillip Lord wrote:
>
>>
>> I've been playing with core.match recently. One thing that I am confused
>> about is, I cannot match over a set (based on membership), unless I
>> convert in
There's currently no support for matching sets and I have no plans in the
near future. Patch welcome, it could be matched and optimized similarly to
map matching.
On Thursday, October 10, 2013, Phillip Lord wrote:
>
> I've been playing with core.match recently. One thing th
I've been playing with core.match recently. One thing that I am confused
about is, I cannot match over a set (based on membership), unless I
convert into a map first.
So, for example
(defn map-set [set]
(into {}
(for [k set]
[k k])))
(let [x (map-set #{:a
No change since the last release candidate.
http://github.com/clojure/core.match
Have fun!
David
--
--
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 m
I believe this release finally eliminates all the remaining bugs around
AOT. Will likely be the final release candidate.
http://github.com/clojure/core.match
Feedback welcome!
David
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
More bug fixes - this time around locals matching in ClojureScript as well
as general bugs around vector patterns with rest patterns.
http://github.com/clojure/core.match
Feedback welcome!
David
--
--
You received this message because you are subscribed to the Google
Groups "Clojure&q
This is just a bug :when should only have special meaning if it occurs in a
list not a vector. Please file a ticket in JIRA:
http://dev.clojure.org/jira/browse/MATCH
David
On Sun, Jul 21, 2013 at 8:54 PM, Yong wrote:
> I have a sequence of keywords which I want to use match on. However, :when
I have a sequence of keywords which I want to use match on. However, :when
has a special meaning, which means I cannot do something like:
(let [x [:ok :when :where]]
(match [x]
[[_ :when _]] :a0))
which gives a "clojure.lang.Compiler$CompilerException:
java.lang.AssertionError: Assert f
Yet another core.match release candidate this time addressing outstanding
ClojureScript support issues as well as some breaking changes for
ClojureScript users - I've reorganized the namespaces, documented here -
http://github.com/clojure/core.match/blob/master/CHANGES.md
Feedback welcome!
Do you have a small failing example?
On Mon, Jul 15, 2013 at 12:08 PM, Michal Till wrote:
> I'm trying to match a false value of map's key (foo.bar) , which in
> javascript effectively means also undefined,null etc... It seems to me
> that core.match matches the value exactl
I'm trying to match a false value of map's key (foo.bar) , which in
javascript effectively means also undefined,null etc... It seems to me that
core.match matches the value exactly. Is there any way to do this?
The other way would be to match "not true", but the docs don
Thanks!
On Wed, Jul 3, 2013 at 6:44 PM, David Nolen wrote:
> 0.2.0-rc3 going out with a fix.
>
>
> On Wed, Jul 3, 2013 at 9:14 PM, David Nolen wrote:
>
>> Thanks for the report, that's definitely a bug and I know the cause:
>> http://dev.clojure.org/jira/browse/MATCH-80
>>
>> David
>>
>>
>> On
0.2.0-rc3 going out with a fix.
On Wed, Jul 3, 2013 at 9:14 PM, David Nolen wrote:
> Thanks for the report, that's definitely a bug and I know the cause:
> http://dev.clojure.org/jira/browse/MATCH-80
>
> David
>
>
> On Wed, Jul 3, 2013 at 9:07 PM, Ben Wolfson wrote:
>
>> This is with 0.2.0-rc2
Thanks for the report, that's definitely a bug and I know the cause:
http://dev.clojure.org/jira/browse/MATCH-80
David
On Wed, Jul 3, 2013 at 9:07 PM, Ben Wolfson wrote:
> This is with 0.2.0-rc2.
>
> This expression evaluates as expected:
>
> user> (m/match [:r :d]
>[:s :d] nil
This is with 0.2.0-rc2.
This expression evaluates as expected:
user> (m/match [:r :d]
[:s :d] nil
[:r :t] nil
[:r :d] :x
[:s :t] nil)
:x
But this one throws an exception:
user> (m/match [:r :d]
[:r :t] nil
e
> same as `case` with respect to the no match exception.
>
> David
>
>
> On Mon, Jun 24, 2013 at 11:10 AM, Thomas Heller
>
> > wrote:
>
>> Hey David,
>>
>> I wanted to try core.match for a while and fiddled around a bit to see
>> what kind
Thanks for the report, fixed and 0.2.0-rc2 is going out.
Probably going to hold off on ex-info change, the behavior of match is the
same as `case` with respect to the no match exception.
David
On Mon, Jun 24, 2013 at 11:10 AM, Thomas Heller wrote:
> Hey David,
>
> I wanted to try c
Hey David,
I wanted to try core.match for a while and fiddled around a bit to see what
kind of code is generated by match, in doing so I found a potentially
"dangerous" bug.
See: https://gist.github.com/thheller/5850693#file-match-clj-L67
If a match has no :else
I've written up how core.match works here
http://github.com/clojure/core.match/wiki/Understanding-the-algorithm
Hopefully this is a bit more approachable than the Maranget paper :)
On Mon, Jun 24, 2013 at 7:43 AM, David Nolen wrote:
> core.match 0.2.0-rc1 going out the door. Cloju
core.match 0.2.0-rc1 going out the door. ClojureScript support now up to
date with Clojure. I've also changed the ClojureScript version to optimize
for performance over code size as the code size issues are less problematic
for ClojureScript than they are for the JVM.
http://github.com/cl
Growing documentation on the core.match wiki:
http://github.com/clojure/core.match/wiki
In particular people should find the sections on basic usage
http://github.com/clojure/core.match/wiki/Basic-usage and advanced usage
http://github.com/clojure/core.match/wiki/Advanced-usage helpful.
David
Thank you!
On Monday, June 17, 2013 8:10:19 AM UTC+3, Ambrose Bonnaire-Sergeant wrote:
>
> Fantastic news!
>
>
> On Mon, Jun 17, 2013 at 1:04 PM, David Nolen
> > wrote:
>
>> At long last I've come around to overhauling core.match.
>>
>> Changes/F
Awesome!
On Mon, Jun 17, 2013 at 1:04 AM, David Nolen wrote:
> At long last I've come around to overhauling core.match.
>
> Changes/Fixes/Enhancements are documented here:
> http://github.com/clojure/core.match/blob/master/CHANGES.md
>
> core.match should no longer have
Thank you for the AOT fixes!
On Mon, Jun 17, 2013 at 7:10 AM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> Fantastic news!
>
>
> On Mon, Jun 17, 2013 at 1:04 PM, David Nolen wrote:
>
>> At long last I've come around to overhauling
Fantastic news!
On Mon, Jun 17, 2013 at 1:04 PM, David Nolen wrote:
> At long last I've come around to overhauling core.match.
>
> Changes/Fixes/Enhancements are documented here:
> http://github.com/clojure/core.match/blob/master/CHANGES.md
>
> core.match should no lo
At long last I've come around to overhauling core.match.
Changes/Fixes/Enhancements are documented here:
http://github.com/clojure/core.match/blob/master/CHANGES.md
core.match should no longer have AOT issues as far as I know and many long
outstanding bugs have been eliminated. The ClojureS
On Tue, Jun 4, 2013 at 2:12 PM, David Nolen wrote:
> I've looked at extractors a little bit, but I would need to investigate
> further. Does this offer any more power than supporting arbitrary function
> application in patterns?
>
The only advantage to function application is that you could conc
That said feel free to add an enhancement ticket.
On Tue, Jun 4, 2013 at 5:12 PM, David Nolen wrote:
> I've looked at extractors a little bit, but I would need to investigate
> further. Does this offer any more power than supporting arbitrary function
> application in patterns?
>
> Also, I'm un
I've looked at extractors a little bit, but I would need to investigate
further. Does this offer any more power than supporting arbitrary function
application in patterns?
Also, I'm unlikely to dive into any feature addition related issues until
all these pressing bugs in JIRA are squashed.
On T
Howdy David & Co.,
One of the *really* nice things about Scala's pattern matching is the
ability to extend pattern matching using extractors. The research is
presented in
http://lampwww.epfl.ch/~emir/written/MatchingObjectsWithPatterns-TR.pdf
The practical aspects allow testing and transforming a
David,
I figured out something of a hack... in MapPattern, I just put a guard
around all the wildcard patterns. ;-)
The patch and tests are uploaded to Jira.
I look forward to helping as I can on core.match
Thanks for your excellent work!
David
On Wed, May 29, 2013 at 12:57 PM, David Nolen
e a ticket here
>>> http://dev.clojure.org/jira/browse/MATCH. Please attach any
>>> work-in-progress patch you may have there and I'll review.
>>>
>>> Before I can apply any work you've done you need to send in your
>>> Contributor Agreement
gress patch you may have there and I'll review.
>>
>> Before I can apply any work you've done you need to send in your
>> Contributor Agreement (CA) - http://clojure.org/contributing
>>
>> Thanks,
>> David
>>
>>
>> On Wed, May 29, 2013
ng
>
> Thanks,
> David
>
>
> On Wed, May 29, 2013 at 3:27 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Howdy,
>>
>> I'm looking to patch core.match. There are a couple of cases where the
>> pattern matcher eliminates rows
ng
Thanks,
David
On Wed, May 29, 2013 at 3:27 PM, David Pollak wrote:
> Howdy,
>
> I'm looking to patch core.match. There are a couple of cases where the
> pattern matcher eliminates rows (basically, if you're pattern matching
> against a Map, a row containing a map that has
Howdy,
I'm looking to patch core.match. There are a couple of cases where the
pattern matcher eliminates rows (basically, if you're pattern matching
against a Map, a row containing a map that has all wildcards will be
considered a "wildcard" row and all the subsequent
On Thu, May 16, 2013 at 11:35 PM, Mark Engelberg
wrote:
> core.match has been alpha for about two years.
>
> I've been itching to use it in real projects for a long time, but with the
> alpha status, I've been reluctant to trust that it has been vetted for
> correctn
core.match has been alpha for about two years.
I've been itching to use it in real projects for a long time, but with the
alpha status, I've been reluctant to trust that it has been vetted for
correctness.
What aspects are preventing core.match from being ready for prime-tim
en wrote:
>
> I think there are a variety of Clojure/ClojureScript projects here and
> there that use core.match. It hasn't gotten as much uptake as I would like
> as there are issues around AOT which I would like to see addressed.
>
> I agree with Ambrose that looking a
I think there are a variety of Clojure/ClojureScript projects here and
there that use core.match. It hasn't gotten as much uptake as I would like
as there are issues around AOT which I would like to see addressed.
I agree with Ambrose that looking at Racket's pattern matching facilitie
t.
Thanks,
Ambrose
On Wed, Apr 10, 2013 at 2:07 PM, wrote:
> Hello all,
>
> Can anyone point me in the right direction to contacting David Nolen about
> refactoring/documenting core.match?
>
> I've done a bit of tinkering around with Erlang and it's gotten me
> int
Hello all,
Can anyone point me in the right direction to contacting David Nolen about
refactoring/documenting core.match?
I've done a bit of tinkering around with Erlang and it's gotten me
intrigued with the implementation of pattern matching. I'm also looking
over the papers m
On Jan 6, 10:48 am, Ambrose Bonnaire-Sergeant
wrote:
> On a related note, combining a quoted symbol and a named wildcard pattern
> seems to be buggy.
>
> clojure.core.match=> (match 'my-sym a a)
> # ocr-3612 in this context, compiling:(REPL:79)>
> clojure.core.match=> (macroexpand-1 '(match 'my-sy
ust add something, it would not
have been as clear or succinct.
> Interestingly, the old design page still has some good stuff, including an
> explanation of this particular issue.
> I'm not sure how much is still relevant.
>
> https://github.com/clojure/core.match/wiki/Design-
I've recently started using core.match, which has been quite pleasant and
successful; thank you to David Nolen, and all others that have contributed.
The only hiccup I've had has been around how core.match incorporates bindings
from local scope into pattern rows. A stupid example dem
Hey Carlo,
Excellent, thank you very much! I haven't tried it yet but it looks good.
Cheers,
David
On 15 November 2012 00:20, Carlo Zancanaro wrote:
> Hey David,
>
> > I guess its got something to do with the fact that match itself is a
> macro?
>
> Correct. The match macro just takes the li
Hey David,
> I guess its got something to do with the fact that match itself is a macro?
Correct. The match macro just takes the list `(!nil? a)`, which isn't
a valid match form, so it complains about it.
> Is there some other way that I could extend match to only match when the
> variable is n
There's no way to make that work currently. Whether it should work requires
some discussion but at the moment I'm inclined to say no.
On Wednesday, November 14, 2012, David Jagoe wrote:
> Hi all,
>
> I have a core.match pattern that looks something like this:
>
> (
Hi all,
I have a core.match pattern that looks something like this:
(def !nil? (complement nil?))
(match [*a* *b*]
[(a :guard !nil?) nil] (dosomething a)
[nil (b :guard !nil?)] (dosomething b)
[(a :guard !nil?) (b :guard !nil?)] (dosomething a b)
:else (throw (Exception. &quo
G'day all,
I am building a reporting interface on top of a database with a star
schema. The star schema makes it very easy to restrict queries by various
combinations of dimension. Some combinations are legal; others are not.
Hence core.match. The number of possible combinations is large,
Hi all,
looking at core.logic on github I can see no dependencies on the
optimized pattern-matching lib 'core.match', however David implies that
does core.logic uses core.match under the hood in one of his talks [
http://www.infoq.com/presentations/The-Mapping-Dilemma]..
See http://dev.clojure.org/jira/browse/MATCH-63 for details.
Paudi
On 15 October 2012 23:21, David Nolen wrote:
> On Mon, Oct 15, 2012 at 5:09 PM, Paudi Moriarty <
> pmoria...@annadaletech.com> wrote:
>
>> It's broken since alpha10, alpha9 works fine.
>>
>> Paudi
>>
>
> That's useful to know, t
On Mon, Oct 15, 2012 at 5:09 PM, Paudi Moriarty
wrote:
> It's broken since alpha10, alpha9 works fine.
>
> Paudi
>
That's useful to know, thanks :) I suspect it may have something to do with
the predicate stuff I added.
David
--
You received this message because you are subscribed to the Googl
It's broken since alpha10, alpha9 works fine.
Paudi
On Sunday, 14 October 2012 18:19:28 UTC+1, David Nolen wrote:
>
> On Sat, Oct 13, 2012 at 6:43 PM, Michael >
> wrote:
> > core.match is alpha and has the following documentation note:
> >
> > "i
On Sat, Oct 13, 2012 at 6:43 PM, Michael wrote:
> core.match is alpha and has the following documentation note:
>
> "if your project depends on AOT do not use core.match at this time"
>
> Can somebody outline what the aot issues are? It seems that deploying a web
> a
On Sat, Oct 13, 2012 at 3:43 PM, Michael wrote:
> "if your project depends on AOT do not use core.match at this time"
>
> Can somebody outline what the aot issues are? It seems that deploying a web
> app to heroku with lein2 will compile the app first. Was interested in
core.match is alpha and has the following documentation note:
"if your project depends on AOT do not use core.match at this time"
Can somebody outline what the aot issues are? It seems that deploying a web
app to heroku with lein2 will compile the app first. Was interested in
using
On Tue, Aug 28, 2012 at 7:01 PM, Brian Marick wrote:
> Observe:
>
> user=> (defn count-sequence [& seq]
> (match [seq]
> ; [([so-far [x & xs]] :seq)] (str "1:" so-far x xs)
>[([[& sequence]] :seq)] (str "2:" sequence)))
> user=> (count-sequence [1 2 3])
> "2:[1 2 3]"
>
> Now uncomment the
This may also be relevant.
The following works:
(defn factorial [& args]
(match [args]
[([n] :seq)](factorial 1 n)
[([so-far 1] :seq)] so-far
[([so-far n] :seq)] (factorial (* n so-far) (dec n
user=> (factorial 5)
120
However, changing the order of clauses st
Observe:
user=> (defn count-sequence [& seq]
(match [seq]
; [([so-far [x & xs]] :seq)] (str "1:" so-far x xs)
[([[& sequence]] :seq)] (str "2:" sequence)))
user=> (count-sequence [1 2 3])
"2:[1 2 3]"
Now uncomment the commented line:
user=> (defn count-sequence [& seq]
(match [seq]
On Tue, Jul 24, 2012 at 6:03 AM, Simone Mosciatti wrote:
> Thanks, it was what i thought...
>
> Any other suggestion is still welcome :-)
I don't really understand your example. Can you clarify?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To pos
1 - 100 of 173 matches
Mail list logo
