Thank you both, While walking the dog, it occurred to me that
( if (Some-Test) X) does near enough exactly what I was suggesting anyway... and that's already there. I take your points respectively though. Also I think this is perhaps just showing (to me) a glimpse of how powerful Lisp is. I have a lot to learn :) On Feb 13, 7:53 am, Herwig Hochleitner <hhochleit...@gmail.com> wrote: > +1 for Brandon's response > > Additionally I'd like to note that it's not strictly necessary to have IF > as a primitive. > You can build IF out of thin lambda, by defining TRUE as a function calling > its first argument and FALSE as a function calling its second argument. > In a strict language like clojure, however, this incurs having to wrap IF > branches in lambdas (thunkifying) manually. > > Also, representing bits (TRUE, FALSE) as lambdas is pretty much the exact > opposite of what our machine do ;-) > > cheers > > 2013/2/13 Brandon Bloom <snprbo...@gmail.com> > > > > > > > > > Clojure, like most Lisps, has a top-to-bottom, inside-out, left-to-right, > > eager evaluation strategy. All Clojure forms are expressions, and thus must > > return a value. Given these two design requirements, (if test then else) is > > the natural branching primitive. It implies serialize execution > > (top-to-bottom) with arguments being evaluated first (inside-out; test is > > evaluated before the parent of the 'if and it's successor siblings, but > > after it's predecessor siblings). It also enforces that no matter the value > > of 'test, the 'if will yield a value (ignoring exceptions). > > > There are other approaches out there. Haskell, for example, uses fully > > lazy evaluation with provably pure functions. That means Haskell can > > utilize pattern matching as it's primitive branching construct and get > > something akin to short circuiting "for free". Consider this boolean "and" > > function (note: not a macro): > > > -- | Boolean \"and\" > > (&&) :: Bool -> Bool -> Bool > > True && x = x > > False && _ = False > > > Back to the Lisp world, there are plenty of other schemes for primitives, > > branching, macros, etc. These include the classic cond, the fancy > > Macro-likehttp://en.wikipedia.org/wiki/Fexprand a whole lot more. > > > Clojure, however, is a language specifically designed to be hosted. The > > simple serialized evaluation strategy is one that is designed to play nice > > with the likes of the JVM, CLR, and JavaScript runtimes. The set of > > "primitive primitives" is extremely small (fewer than 10), but there are a > > couple of host/interop primitives as well (dot, new, etc) as some things > > that are primitives for convenience or performance. > > > Given the broadly understood design constraints of Clojure, you're > > unlikely to find discussion of the nuances of the fundamental branching > > operators. However, the Lisp, functional programming, and theoretical > > computer science communities have studied this problem in quite some depth. > > Maybe some folks can provide some suggested readings. > > > Cheers, > > Brandon > > > On Tuesday, February 12, 2013 9:40:45 AM UTC-5, Dies_Felices wrote: > > >> Hi there, > > >> Before I go on, I'll apologize as this might get long and vague in > >> parts. That will just be my showing where I'm even more confused than > >> I generally am. I have only recently started trying to learn Clojure > >> and by inference Lisp. > > >> Last night, I watched this video -http://blip.tv/clojure/** > >> clojure-for-java-programmers-**1-of-2-989128<http://blip.tv/clojure/clojure-for-java-programmers-1-of-2-989128>. > > >> Admittedly though there were more than a few parts which flew right > >> over my head, I took those as a prompt for further reading. This > >> morning though the question of the "IF" primitive struck me. > > >> Basically, in this video Rich Hickey tells us that if is one of only a > >> few primitive statements and it can not be a function because it is > >> composed of two functional blocks of which only one is used at a > >> time. This made sense and is reminiscent of what I've read about lisp > >> elsewhere. > > >> This part doesn't make much sense but I'm including it to build the > >> context of the actual question when I get to that, this will I hope > >> make it more straight forwards. > >> This morning I was thinking what if all your operands and data were > >> predicated and the compiler were able to see some sort of > >> environmental variable then you could build an "IF" like function or > >> macro. Armed with this different perspective I realised I'd seen it > >> before but also by itself it doesn't make much sense in a high level > >> language. > > >> First of all, operands and data by themselves don't need to be > >> predicated and it would cause everyone a lot of work. Then also the > >> compiler doesn't need to be aware of any special environmental > >> variables either for the same reason as before. > > >> However, I think there is scope for consideration of a predicated code > >> block which returns a data structure or object or function or more or > >> less what ever would be the appropriate thing for Clojure to return. > >> Using this predicated code block structure "IF", "AND", "OR", "NOT", > >> "Select Case" would all be able to be macros constructed using this > >> primitive. > > >> As I imagine it there would be two possible syntax variations that > >> might implement this. > > >> The first like the "LET" would be in the form ("Logical-Predicate- > >> Primitive" "Test-Expression" ("Scope-A") ("Scope-B") ("Scope-C")). In > >> the case of "Test-Expression" = TRUE then "Scope" is returned > >> otherwise NIL. You can have as many "Scope-s" as you like. > > >> The second is much more dramatic. At the moment in Lisps a list of > >> symbols (A B C) is read in and then A is evaluated looking for a > >> function. If A is not a function then (I think) an error is thrown > >> but either way it's not proper lisp expression by itself. Even if at > >> some point previously there had been a (def A 5), the value 5 isn't a > >> function either so nothing good happens. > >> The second case would work something like this (("Test-Expression") > >> ("Scope-A") ("Scope-B") ("Scope-C")) which as above would allow you to > >> have as many "Scope-s" as you like. In this case though with the list > >> (A B C), A is testable as an empty symbol pointing to Nil or when (def > >> A 5) has occurred it would be treated as always TRUE and then B and C > >> are evaluated normally. > > >> So basically what I'm proposing is a conditional code block which > >> would take the place of the "IF" primitive. I have briefly searched > >> for examples of where this kind of thing might have been discussed > >> before but as "IF" is a very common operator, I didn't find anything > >> illuminating. > > >> After all that my questions; > > >> Has this been discussed before? > >> If so what were the conclusions? > >> Such as the Pros and Cons of "IF" verses a predicate > >> code block? > > >> If this was an in appropriate question to address to you, do > >> you have any idea to whom I would be better addressing it? > > >> In the case that this is a new topic, what do you think? > > >> -- > >> Kind regards > > >> Stephen Feyrer. > > > -- > > -- > > 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 > > --- > > You received this message because you are subscribed to the Google Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojure+unsubscr...@googlegroups.com. > > For more options, visithttps://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
