[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lightweight function syntax (again) Re: [ANN] Lua 5.2.0 (alpha-rc2) now available
- From: David Kastrup <dak@...>
- Date: Mon, 22 Nov 2010 17:06:40 +0100
Gavin Wraith <email@example.com> writes:
> In message <7F497979-DBC0-481E-BF32-18C4BC76D1FE@grubmah.com> you wrote:
>> I agree that the pressure tends to have to do with what sort of
>> programming one is trying to engage in with more functional styles
>> being more challenged by Lua's otherwise very pleasant syntax
> What we are seeing here are the ripples from the clash, in the early
> 1920s, between traditional mathematical notation [ f(x,y,...) ] and
> that of the new logicians, Schoenfinkel, Curry et al, [f x y ... ]
> whom the mathematical community tended to cold-shoulder till well
> after the coming of computers, Lisp, etc. I love Haskell notation,
> myself, but I can well understand that is not to the taste of others.
Sigh. It is not a matter of liking Haskell notation or not. Lua _has_
a syntax already, and that is rooted in the Algol family.
In a similar manner, liking the use of Ada's constraint syntax for
parametrizing generics does not mean it is a good idea to drag that
particular part of Ada's syntax into C++ where it does not really fit
all too well.
Liking Fortran's automatic arithmetic type conversion grid does not mean
that is a good idea to figure out how to make all user-defined types
behave like "complex" with regard to arithmetic type conversions so that
one can implement Fortran in C++, at the cost of being unable to
sensibly define and use _any_ user-defined arithmetic type apart from
complex, in particular not arithmetic types that have nothing do to with
floating point arithmetic.
Again: language design is not about building the largest incongruous
heap of cool syntagmas.