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
24 matches
Mail list logo
