Add drafts of condp, if-not, when-not and not=

lfe-deprecated / clj

MERGED to LFE - Clojure-inspired macros and functions for use in LFE

28 stars 2 forks source link

Add drafts of condp, if-not, when-not and not= #19

Closed yurrriq closed 8 years ago

yurrriq commented 8 years ago

Per #15, #10, #11 and #12

For better or for worse, this definition of condp allows for various invocations:

(condp {{(lambda ...)}} x
  y z
  q {{module:function | function | (lambda ...)}}
  {{optional default}})

I'm very open to alternate strategies/decisions here, but I wanted to get an initial version written.

It would be great if not= weren't a macro, but this way it can be variadic like its Clojure analog.

oubiwann commented 8 years ago

Keep in mind that these tickets aren't for merging code into clj -- we're using the add-clojure-lib branch of the oubiwann/lfe repo. (Didn't want to create a new "lfe" issue tracker in oubiwann/lfe, and this work will essentially deprecate the clj library in favor of using LFE's new built-in Clojure support).

When you submit the PR to that branch, be sure to rename your macros to clj:condp, etc. (to match the function prefixes for the modules).

I'm going to close this PR...

yurrriq commented 8 years ago

Oops. Will do!

yurrriq commented 8 years ago

What are your thoughts on "raw" f | m:f vs #'f/a | #'m:f/a? The former is more Clojurian but the latter is more Liffy. I'm pretty on the fence.

rvirding commented 8 years ago

Some points:

LFE is lisp-2 while clojure is lisp-1. So taking the value of a variable is different from getting the function binding from the name of a function. f and m:f take the value which is the function while #'f/1 and #'m:f/a are need to get the function binding (actually the create a function which calls the named function). It is same as the difference between (let ((f (lambda ...))) ...) and (flet ((f (a b) ...)) ...). What ever we may think of this it is something erlang imposes on us which we can not avoid.
When referring to a function you have include the arity as you can have functions with the same name but different arities.
My reason for going the "flet way" was to make things more consistent. Why should there only be one local function per name while I can have multiple top functions with the same name?

Again this basic handling of functions and references to functions is what erlang gives us which we can't do anything about.

yurrriq commented 8 years ago

Right. The way I've written this (there's a small bug atm but I'll fix it before submitting a PR to oubiwann/lfe) allows users to pass in function names "Clojure style," for better or for worse.

I guess my real question is, should we enable such unidiomatic invocation by way of sugar since this is a Clojure-inspired macro, or stick with LFE conventions when porting?

yurrriq commented 8 years ago

I'm picking this up again and going to favor Erlang Lisper† idioms over Clojurian.

† What's the best word like Clojurian, Erlanger, Lisper, Schemer, etc for LFE?

oubiwann commented 8 years ago

I would go for "Lffers" (as in "lifer" e.g., "life-long service" ;-)) or "Liffian" :-D