lua-users home
lua-l archive

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

Rici Lake wrote:



On 27-Aug-05, at 9:58 AM, Chris Marrin wrote:
Couldn't you have a rule that first tried the first way and if that did not work (because there is not __tonumber metamethod for that object, for instance) you would try __add? I agree that __add is needed for things like complex numbers. I don't happen to have that issue, though.
But why should you prefer __tonumber to __add? That's an entirely problem-domain-specific preference. Put another way, if my primary concern were complex numbers but I accepted that you also had an application, I might say, try __add and then try __tonumber :)
That rule would work for me too! To be honest, tonumber is of no use to me, as long as I can override all the arithmetic instructions. __toboolean is the killer. It prevents me from saying using a bare SFBoolean in an if test. This is easy to fix by fiddling the source to add __boolean. But I have a dream of using a stock Lua distro!
In any event, I'm generally of the opinion that coercions should be explicit; I'd be happier if 3+"2" where an error. I have learned the hard way that not doing numeric conversions explicitly leads to obscure bugs...
Yes, you can never avoid obscure bugs. And I have no problem disallowing explicit type-casting. In my system I have: 

    local a = 3 + SFDouble("2")

which works today.
To be honest, Lua is tantalizing close to exactly what I need. I have already changed my source base to handle __lt, __eq and __le the way I need them to work (allowing dissimilar types). All I need to do is add __toboolean support. But as I said, I have this dream...
But for all intents and purposes an SFBoolean object IS a boolean primitive. The extra features that SFBoolean provides has nothing to do with its data type, only with how it can interact with other properties in the system. What I really want is for Lua not to judge me for how I want to coerce the object system :-)
That's fine. But presumably there are only two singleton members, SFTrue and SFFalse (or am I prejudging your Boolean system? :) Relating two enums to each other doesn't seem to me to be that painful. 

If I found this acceptable:

    local a = SFBoolean(true)
    if a == SFTrue then...

then all would be well. But I don't. Even these two:

    if a == true then...
    if a:valueOf() then...
which both work after I made my "fix" to __eq, is not acceptable to me. It has to be: 

    if a then...

so I will have to make the change to the VM.
This brings up what seems to be a dirty word here and many other language oriented places, Javascript. I say that because I see people all over the place mention the "top languages" as Python, C++, Java, event Self (which I have taken to be a codeword for Javascript).
Let me be clear that when I mention "Self" I mean "Self" :) (And I have some fondness for Javascript, but I think that Lua generally made better choices.)
No argument. But in my opinion Javascript made some better choices, too. And for me, some of those choices are things non-programmer authors really need. 


...
Anyway, many of these concepts come from The-Language-That-Must-Not-Be-Named.
Yes, I recognized them. I think they are unintuitive in javascript as well, but that's not my primary irritation with javascript. 

Since you asked (sort of), let me list them...
4) Javascript's scopes try to combine the "best of" dynamic and static scoping, and as a result require a Doctorate in Javascriptology in order to cope with corner cases. Python is even worse. Lua scopes may not be the be-all and end-all (I would like dynamic scoping once in a blue moon), but you can describe the entire semantics in a paragraph.
I could not agree with this more. I love Lua's static scoping rule for its simplicity and performance. I have written and tried to cope with many Javascript interpreters and the dynamic scoping is what has destroyed performance every time. You might be interested to know that there is an addendum for the ECMAScript spec which calls for a "compact profile", which gets rid of "with" and all the other fiddly bits which demand dynamic scoping, making it possible to create a statically scoped Javascript interpreter. But this does not make me want to run to Javascript. As you say, it is poorly implemented in all the publicly available implementations. That is why I think there is some value in putting Javascript syntax over Lua. The "compact profile" allows me to avoid worrying about some of the issues that would make a Lua implementation difficult. But would still give me the syntax I, for some reason, feel I need :-) 

--
chris marrin              ,""$, "As a general rule,don't solve puzzles
chris@marrin.com        b`    $  that open portals to Hell" ,,.
        ,.`           ,b`    ,`                            , 1$'
     ,|`             mP    ,`                              :$$'     ,mm
   ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
  m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
 b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
 ```"```'"    `"`         `""`        ""`                          ,P`