On Tuesday, March 25, 2014 5:28:11 AM UTC+5:30, Ian wrote: > On Mon, Mar 24, 2014 at 3:43 PM, Mark H Harris wrote: > > On 3/24/14 4:03 AM, Ian Kelly wrote: > >> The difference does not really lie in the lambda construct per se but in > >> the binding style of closures. Functional languages tend to go one way > >> here; imperative languages tend to go the other. {snip} > >> The result may be more surprising to users accustomed to functional > >> languages, but I claim that it is *less* surprising to users of other > >> imperative languages. > > Aside from the sin of spelling out "lambda," > > should be ( \x y -> x + y ) a b ) but, neither here nor there...
> Well no, it *should* be λx y . x + y but apparently some people don't > have that character on their keyboards, so it gets written as lambda > or \ instead. Personally I dislike the \ style; it doesn't really > resemble a λ that closely, and to me the backslash denotes escape > sequences and set differences. Nor is Python alone in spelling out > lambda: Scheme and Common Lisp spell it the same way. As far as I know > the \ for λ is unique to Haskell. Yeah: Its 2014 (at least out here)... About time we started using unicode in earnest dont you think?? Id like to see the following spellings corrected: lambda to λ in to ∈ (preferably with the 'in' predicate and the 'in' in 'for' disambiguated) set([]) to ∅ And some parentheses disambiguation Internal ambiguity: Is '(...)' a paren? a function? a tuple? External ambiguity: {} in python vs in set theory [And now I hand it over to our very dear resident troll to explain the glories of the FSR] -- https://mail.python.org/mailman/listinfo/python-list