+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-like http://en.wikipedia.org/wiki/Fexpr and 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, visit https://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.
