Hi Stephen, Rich,
I haven't had my tea yet either, so I'll look at this some more later.
-S
On Oct 28, 9:35 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Oct 27, 10:45 pm, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
>
> > I used Stuart Sierra's 'fcase' contrib today to good effect. Nice job,
> > Stuart!
>
> Yes, I haven't done enough poking around in contrib - fcase looks like
> a promising candidate for boot.clj.
>
> > I have an idea for another fcase variant that I think is useful:
>
> My thoughts are that there should only be fcase (discussion on name
> follows). The variants (re-case, instance-case etc) just pollute the
> namespace and add complexity without any new semantics, nor any
> significant concision. For the same reasons, we don't have specialized
> versions of filter etc. I'd much rather people understand the
> semantics of fcase and use it with any predicate they choose:
>
> (fcase instance? ...
>
> (fcase = ...
>
> (fcase re-find ...
>
> > (defmacro pred-case
> > "Case where test values are predicates to be applied to the test
> > value."
> > [test-value & clauses]
> > `(fcase (fn [pred# value#] (pred# value#)) ~test-value [EMAIL
> > PROTECTED]))
>
> That could be:
>
> (fcase #(% %2) ...
>
> > Stuart, would you please consider adding pred-case to
> > clojure.contrib.fcase?
>
> If you'd like, I think the effort would be better spent on making a
> version of fcase for the base library.
>
> The issues I have are with the name, arg ordering and default/no-match
> handling.
>
> While fcase is structurally similar to case, case is normally reserved
> for equality testing against constant, unevaluated expressions, the
> idea being the compiler could possibly leverage knowledge of the
> constant values to do something fast. They often have order of test
> promises, but I think that's wrong. I'd like to save unadorned "case"
> for this meaning.
>
> This doesn't rule out the use of "case" somewhere in the name, but is
> something to consider. Another way to look at fcase is like a
> parameterized cond.
>
> There is implicit arg ordering (pred clause-value test-value) which
> doesn't matter for some preds (=) but does for others (instance?). For
> the uses thus far, this order seems good - instance? and re-find work
> well, but there will be cases where people will want (pred test-value
> clause-value). The order of things in the macro structure might imply
> the latter:
>
> (fcase pred test-value
> clause-value ...
>
> and it might be difficult for people to remember which it is.
>
> One possibility is to make it explicit in the macro syntax with a
> placeholder (_):
>
> (fcase = x _ ;doesn't matter
> ...
>
> (fcase instance? _ x
> ...
>
> (fcase some #{x} _
> ...
>
> or maybe:
>
> (condp (= x _) ;doesn't matter
> ...
>
> (condp (instance? _ x)
> ...
>
> (condp (some #{x} _)
> ...
>
> As far as the default, providing a default value as odd last clause is
> ok, but subtle, and could use layout help, if we do that we should do
> the same for cond. When no default is provided, there should be some
> option for an exception on no match. That could either always be the
> case, or a second variant of the macro (e.g. CL has ecase)
>
> Finally there is the name, which has to follow the form and function.
> If we go with something like the last above, I like condp/econdp.
>
> I haven't finished my tea, so consider this idle, groggy speculation.
>
> Comment/discussion welcome.
>
> Rich
--~--~---------~--~----~------------~-------~--~----~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
