(Sorry for split post). So I'am not against let? macro of whatever you might need. That why we have a lisp here. But be sure you really need it/use it. And it is designed to be intuitive as possible.
On 9 mar, 23:05, Nicolas <bousque...@gmail.com> wrote: > Well maybe the problem of the let? macro is that it is not standard. > If you use standard constructs and I'am proeficient with clojure I'll > understand your code fast. I'll concentrate on understanding your code > relevant for your application and domain. But just adding a few new > constructs specific to ypur libr can make code really complex to read, > even to experimented clojurians. > > That the power of macros (or even functions). Abstract things away. > But you also need to know the function/macro. And if it is not > standard, we end up with many different version of let? depending of > the library, author... > > By all means I'm not against let? macro or > > On 9 mar, 19:04, Evan Gamble <solar.f...@gmail.com> wrote: > > > > > > > > > I find let? useful and readable, as do others. There's a bit of brain- > > training necessary to read it, but not a lot. Probably no more than > > the keyword clauses of the "for" comprehension. The argument that > > decades of Lisp programmers haven't invented this particular > > "chucklehead" macro is a bit weak, since there have been many other > > similar macros. > > > ...and I have learned to love nil, even the :else nil clause that > > repels you. > > > - Evan > > > On Mar 9, 9:26 am, Craig Brozefsky <cr...@red-bean.com> wrote: > > > > Evan Gamble <solar.f...@gmail.com> writes: > > > > (let? [a foo :else nil > > > > b bar :is even? > > > > c baz :when (> b c) > > > > d qux] > > > > (f a b c d)) > > > > Macros like that just make your code so much LESS readable. I now have > > > to understand the semantics of a bunch of keywords specific to the > > > macro, their order of operations within the macro, as well as > > > recognizing the little ? on the end of the let as I'm scanning. I also > > > have to see if that's a keyword or the start of another binding! > > > > :else nil? really? > > > > :is ... Geezus christ > > > > :when !?!?! Put down that nailgun, kid > > > > ;; This maintains the same logic (unless I fucked up transcoding) > > > ;; and also the same err, complexity, in that forms are not exeuted if > > > ;; they don't need to be, as your initial example, without nesting all > > > ;; the way over to the side, or using some weird keyword language. > > > > (when-let [a foo] > > > (let [b bar > > > c (when (even? b) baz)] > > > (when (and c (> b c)) > > > (f a b c qux)))) > > > > ;; or > > > > (when-let [a foo] > > > (let [b bar > > > c (when (even? b) baz) > > > d (when (and c (> b c)) qux)] > > > (when d (f a b c d)))) > > > > Keep your constructs simple, and learn to love the nil. > > > > Also, people have been writing lisp for a real long time, and they > > > haven't invented a chucklehead macro like let? yet, so prolly not really > > > needed to improve the readability... > > > > -- > > > Craig Brozefsky <cr...@red-bean.com> > > > Premature reification is the root of all evil -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
