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 in the near future?
> The abilit
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 "Clojure" group.
T
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 members are
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.
To post to thi
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" group.
To
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!
http:/
That was quick, thanks.
One Question for vector matches, I was thinking of a 'case-ex macro which
basically copies the semantics of erlangs case-expressions.
eg.
(case-ex (db/find-object some-id)
[:ok object] object
[:error :not-found] default-object)
expands to
(match [(db/find-object so
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 core.match f
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 clause an IllegalArgumentExcept
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. ClojureScript supp
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/clojure/cor
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
O
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/Fixes/Enhancements are documented here:
>> http://g
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 AOT issues as far as I k
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 core.match.
>>
>> Changes/Fixes/Enhancements
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 longer have AOT issues as far
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 ClojureScript
I just pushed a new release of core.match. The only significant change is
that you can now match single values without needing to wrap in a vector.
I was hoping to get to some of the bigger tickets but I'm tied up with
miniKanren / core.logic research at the moment. If anyone feels like taking
on
On Tue, Oct 11, 2011 at 08:46:51PM +0800, Ambrose Bonnaire-Sergeant wrote:
> (match ["asdf"]
>(["asdf"] :when (fn [a] ..)) 1) ;; <- illegal, cannot wrap
> pattern row in list
>
> If we can resolve this, it would be great!
>
> Thanks,
> Ambrose
>
I see a couple of options..
1. Sc
On Tue, Oct 11, 2011 at 4:25 PM, Stephen Wrobleski wrote:
> On Mon, Oct 10, 2011 at 09:24:09PM -0400, David Nolen wrote:
> > I'm not following. Getting accurate information about what failed to
> match
> > needs to be integrated. Given that match makes no restrictions on types
> > there's not much
On Mon, Oct 10, 2011 at 09:24:09PM -0400, David Nolen wrote:
> I'm not following. Getting accurate information about what failed to match
> needs to be integrated. Given that match makes no restrictions on types
> there's not much we can do except communicate where we were when the match
> failed v
On Mon, Oct 10, 2011 at 6:07 PM, Stephen Wrobleski wrote:
> I think a match-debug is barking up the wrong tree. If throwing an
> exception
> is the right thing to do to track down an unaccounted case, why make a
> different macro just for a slightly different default behavior that is
> easily spec
On Mon, Oct 10, 2011 at 09:08:42AM -0700, Daniel Pittman wrote:
> So, I have one other argument in favour of "just return nil", which I
> prefer:
>
> If you just return il, I can use :else to throw fairly cheaply, and
> quite visibly.
>
> If you throw then I have to wrap any non-exhaustive patte
On Mon, Oct 10, 2011 at 3:42 PM, Steve Miner wrote:
> > match-let looks good. I see that you are Clojure contributor - I'm more
> than happy to include this.
>
> Yes, I'm a registered contributor. It's all yours.
>
> I'll take a look at the code and see if I can fix things for myself
> regarding
> match-let looks good. I see that you are Clojure contributor - I'm more than
> happy to include this.
Yes, I'm a registered contributor. It's all yours.
I'll take a look at the code and see if I can fix things for myself regarding
the implied equality constraints and guard clauses.
By the w
On Mon, Oct 10, 2011 at 2:43 PM, Steve Miner wrote:
> I've just been playing around a bit with match so please forgive me if I've
> missed some prior discussions regarding issues that are considered settled.
>
> One of my first attempts was to match a vector of two of the same thing
> using a pat
I've just been playing around a bit with match so please forgive me if I've
missed some prior discussions regarding issues that are considered settled.
One of my first attempts was to match a vector of two of the same thing using a
pattern like [a a]. I naively thought that would imply an equal
On Mon, Oct 10, 2011 at 12:08 PM, Daniel Pittman wrote:
> On Mon, Oct 10, 2011 at 06:57, David Nolen wrote:
> > On Sun, Oct 9, 2011 at 11:19 PM, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
> >> On Mon, Oct 10, 2011 at 3:31 AM, David Nolen
> wrote:
> >>>
> >>> - return nil i
On Mon, Oct 10, 2011 at 06:57, David Nolen wrote:
> On Sun, Oct 9, 2011 at 11:19 PM, Ambrose Bonnaire-Sergeant
> wrote:
>> On Mon, Oct 10, 2011 at 3:31 AM, David Nolen wrote:
>>>
>>> - return nil instead of throwing if no match found to mirror the behavior
>>> of cond
>>
>> I don't like this.
>
On Mon, Oct 10, 2011 at 10:56 AM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> How about:
>
> `match` - defaults to :seq, returns nil
>
> `match-debug` - defaults to :seq, w/ error checking, w/ comprehensiveness
> check
>
> `matchv` - defaults to :vector
>
> Ambrose
>
I think
On Mon, Oct 10, 2011 at 10:28 AM, Rob Lally wrote:
> If it only makes the non-vector seq case slower, I'd certainly make that an
> available option - people are going to have to manually convert other
> sequences into vectors anyway which creates a coding overhead and also makes
> the code less l
On Mon, Oct 10, 2011 at 10:53 AM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
>
>
> On Mon, Oct 10, 2011 at 10:28 PM, Rob Lally wrote:
>
>> Would supporting other data structures make it slower when using vectors,
>> or only when using non-vector seq's?
>>
>
> If we use :seq p
How about:
`match` - defaults to :seq, returns nil
`match-debug` - defaults to :seq, w/ error checking, w/ comprehensiveness
check
`matchv` - defaults to :vector
Ambrose
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send e
On Mon, Oct 10, 2011 at 10:28 PM, Rob Lally wrote:
> Would supporting other data structures make it slower when using vectors,
> or only when using non-vector seq's?
>
If we use :seq pattern matching, it will use first/rest. This can be very
expensive. Vectors will take a performance hit.
:vect
Would supporting other data structures make it slower when using vectors, or
only when using non-vector seq's?
If it makes it substantially slower across the board, personally I'd still like
core.match to support all of clojure's built in data structures; but I could
understand why people would
On Mon, Oct 10, 2011 at 3:46 AM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
> While we're on the topic of conventions, I think the most important
> convention match is breaking
> is using the destructuring syntax to mean something less generic by default
> (only vectors).
>
>
On Sun, Oct 9, 2011 at 11:19 PM, Ambrose Bonnaire-Sergeant <
abonnaireserge...@gmail.com> wrote:
>
>
> On Mon, Oct 10, 2011 at 3:31 AM, David Nolen wrote:
>
>> - return nil instead of throwing if no match found to mirror the behavior
>> of cond
>>
>>
> I don't like this.
>
I'm definitely open to
I've come up with some better reasons to return nil.
- smaller generated code size
- cleaner implementation
of which the latter is the most significant.
While we're on the topic of conventions, I think the most important
convention match is breaking
is using the destructuring syntax to mean som
I'm just following what seemed to be a convention -
https://github.com/clojure/core.unify/blob/master/src/main/clojure/clojure/core/unify.clj
On Sun, Oct 9, 2011 at 7:17 PM, Alan Malloy wrote:
> On Oct 9, 12:31 pm, David Nolen wrote:
> > I've removed some fairly big bugs in the algorithm. This
On Mon, Oct 10, 2011 at 3:31 AM, David Nolen wrote:
> - return nil instead of throwing if no match found to mirror the behavior
> of cond
>
>
I don't like this.
Why are we emulating cond? clojure.core/case, for example, seems closer to
what `match` provides,
and that throws an IllegalArgumentExc
On Oct 9, 12:31 pm, David Nolen wrote:
> I've removed some fairly big bugs in the algorithm. This will probably the
> be the last alpha release before I cut a beta. Would love to hear any and
> all feedback.
> - clojure.core.match instead of clojure.core.match.core
Those both seem weird to me, un
On Sun, Oct 9, 2011 at 12:31, David Nolen wrote:
> I've removed some fairly big bugs in the algorithm. This will probably the
> be the last alpha release before I cut a beta. Would love to hear any and
> all feedback.
> In particular if people have strong opinions about the remaining issues, let
I've removed some fairly big bugs in the algorithm. This will probably the
be the last alpha release before I cut a beta. Would love to hear any and
all feedback.
In particular if people have strong opinions about the remaining issues, let
me know now - http://dev.clojure.org/jira/browse/MATCH
Tw
Thanks for the report. The design wiki link is now removed.
On Sun, Oct 2, 2011 at 4:35 PM, Alasdair MacLeod wrote:
> The link to Design-Wiki needs updating, it uses your personal GitHub
> account and 404s
>
> On Oct 2, 7:44 pm, David Nolen wrote:
> > The big picture is falling into place for c
The link to Design-Wiki needs updating, it uses your personal GitHub
account and 404s
On Oct 2, 7:44 pm, David Nolen wrote:
> The big picture is falling into place for core.match. The most significant
> change is that we now have two compilation schemes based on the presence of
> recur. If recur
Erg, Make that 0.2.0-alpha3.
David
On Sun, Oct 2, 2011 at 5:05 PM, David Nolen wrote:
> You can now use core.match with ClojureScript. This is far less tested than
> Clojure, feel free to open issues -
> http://dev.clojure.org/jira/browse/MATCH
>
> David
>
--
You received this message because
You can now use core.match with ClojureScript. This is far less tested than
Clojure, feel free to open issues - http://dev.clojure.org/jira/browse/MATCH
David
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojur
The big picture is falling into place for core.match. The most significant
change is that we now have two compilation schemes based on the presence of
recur. If recur is not present we use a much more efficient backtracking
strategy which results in dramatically less code generation.
There a lot o
48 matches
Mail list logo
