lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I would say the reverse: Lua functions are syntaxic sugar of more general lambda functions.
Note: lambda functions are not restricted to be just mathematical functions (i.e. projections), they can be any relation. Lua functions are defined to segregate the input and ouput, but this is not true for relations that can be injective or not, and multivalued; the equations between relations may be reversed when resolving them in the reverse order : single-valued functions do not always have an inverse if they are not injective, i.e. bijective because functions are necessarily surjective. But all relations have an inverse relation, and relations are not limited to be multivalued input and single-valued output, all inputs and outputs are equally powerful: the same equation applies when you take some parameters (any one, including those that Lua's syntaxic sugar calls an "environment") as input and then take all the other ones as output.

Lambda calculus is extremely powerful and can be used to prove mathematically that an algorithm is correct, or will be computable at least for some inputs, or will not find any solution, or will have multiple solutions (i.e. the algorithm will have unpredictable results), or that it will be computable in a finite time. It also allows performing optimizations in their implementation (extremely interesting when compiling...).

Lambda calculus is an higher order language, more powerful than Lua or most other programming languages (that use imperative instructions described in time order, with assignments that are erasing and loosing what was before, something that is not necessary, but just a syntaxic sugar of the programming language).

Lambda calculus is based on mathematical quantifiers and equations over sets defined as relations, not just functions (i.e. surjections, or projections, which are information-lossy: the loss of information is formalized by a "forall" quantifier). lambda calculus also uses the "exists" quantifier over a relation, which is equivalent to the reverse of a "forall" quantifier applied over the transformed relation.

Lambda calculus has string mathematical bases from the bases of mathematics: logic and topology, which come just before arithmetic (on integers), and then all the rest of mathematical domains (on other kinds of numeric systems and "meta-"domains such as analysis, infinitesimal calculus... and finally computing which is just mathematics applied to set of functions that are computable in finite time with a Turing machine, which is defined as any device capable of doing some arithmetic on finite ranges of integers and using "n"-tuples of these ranges, with "n" also finite and representing space resources, i.e. memory).

Le lun. 19 nov. 2018 à 01:18, Tim Hill <> a écrit :

> On Nov 18, 2018, at 3:45 PM, Muh Muhten <> wrote:
> On 11/18/18, Philippe Verdy <> wrote:
>> As well the given examples are not pure lambda:
>> \x,y,z(x+(x-2)*g(x,y,z-2*(x+y))-y*z)
>> or its transformation into
>> function(x,y,z) return x+(x-2)*g(x,y,z-2*(x+y))-y*z end
>> is bound in a closure referencing "g", which is not an upvalue (an input
>> parameter) of that function.
> This is the first I've heard of a notion of a "pure" lambda which
> forbids closures.
> It would seem to be a rather *unusual* idea, since the name "lambda"
> itself refers to lambda calculus, which is not nearly as interesting
> without closed-over variables.

+1 .. it seems to me that this isn’t lambda at all … its just a discussion of pure functions. To the best of my knowledge (others jump in here!) the only difference between a Lua (anonymous) function and a lambda is syntax. That is, any “lambda” extension to Lua would just be syntactic sugar.