Re: Lua as (Matlab like) calculator

[Oscar Chinellato <oscar.chinellato@...>]

On Wed, Jun 29, 2011 at 4:05 PM, Dirk Laurie <dpl@sun.ac.za> wrote:
>> It is not (as you say) what assignment means in a mathematical
>> sense of course.
>
> Don't blame mathematics for what Fortran, Matlab, etc do.

No one is blaming math here. I'm just asking for a more flexible
semantic behind the "=" token.


> I find Lua's assignment rule simplest of all programming languages I know:
>
>> Tables, functions, threads, and (full) userdata values are objects: variables
>> do not actually contain these values, only references to them. Assignment,
>> parameter passing, and function returns always manipulate references to such
>> values; these operations do not imply any kind of copy.
>
> Two sentences, and the whole concept is fully explained.

Just because the "concept is fully explained", it doesn't make it a
good concept. Imagine that all of the above would be "by value" and
not "by reference" - the concept would still be fully explained, yet
totally opposed to the existing one. So?

> It is good that `__assign` is not a metamethod.  We'll then need a library
> function `rawassign`, and it's not worth it.  Copying recursively defined
> objects is a complicated matter, and there should be some visible reminder
> that one is invoking such a mechanism.

Most of today's programming languages (and their run-time
environments) incorporate highly complex mechanisms in a seemingly
trivial way - the intricacies are not visible and the syntax is not
reflecting the effective complexity. One such example could be Lua's
garbage collector in combination with the __gc metamethod - this
"hook" comes with similar pitfalls as in the "__assign" case. That
sort of "complexity hiding" is very desirable (actually one of the
evolutionary milestones in the programming language world), and
certainly not only to me. I agree with you that it needs to be used
judiciously, but not allowing the use of simple syntax to express a
complicated mechanism is not only (way too) restrictive but also
needlessly dogmatic.


> After all, it could be as small as a pair of parentheses.
>
> -- When object b is constructed, set its __call metamethod to make a copy
> -- of itself.  It could even take an argument indicating the desired depth.
>
> a=b     -- `a` is another name for the value of `b`
> a=b()   -- `a` is a name for a newly-made copy of `b`

Clearly, this is a question of taste.

But considering that the the programmer of the data-structure (or
userdata) is probably the one who knows best what to do with an
assignment, why not letting him/her decide, what to do in such cases?
This is exactly why I would appreciate the __assign metamethod - it's
non-intrusive (existing code would behave exactly the same) and,
assuming that the programmer does a good job, it's safe.

Cheers,
Oscar