Re: Why a : (colon) operator?

[David Olofson <david@...>]

On Thursday 14 September 2006 07:50, Oemii wrote:
[...]
>  > My guess would be that the cost of doing so is not insignificant
> I can't see why: if we call either a.b.c.f() or a.b.c:f(), then
> a.b.c must have been resolved
> anyway - so, if I have it right, the only cost would be to push an  
> available reference onto the stack, wouldn't it?

Correct; you have to resolve the object the function is in anyway. 
Even so, pushing something onto the stack is not free. There is the 
actual work of doing it, of course, and for something that has a 
global impact like this, you also have to consider the increased 
memory footprint of function calls.

Not saying the cost is guaranteed to be significant to every user, as 
I have no benchmarks to back that up - but I am saying there is a 
cost.


>  > Also, using : instead of . at least serves as a hint that you're
>  > not *only* indexing something to get your function, which I
>  > believe is a good thing.
> Why should it be to be more true for methods than for functions?

I would say it's pretty symmetric; . means you just call the function, 
whereas : means you pass the "container" object as the first argument 
as well.


> In the contrary, IMHO it would be even more natural for methods,
> as we are used to consider calling a method as a kind of
> "indexing something" (namely an object or class).

Well, yes, but the fact that you index the function out of something 
doesn't *have* to mean it's a method - and there is a distinct 
difference between methods and functions, in that methods expect an 
extra argument 'self', whereas functions do not.

Of course, it doesn't *have* to be that way, which gives me an idea... 
Not sure this applies to Lua, but hardwiring 'self' into the language 
might make it as simple as just putting the "container" object 
pointer some place the callie can access if desired.

So, no stack push, and you don't have this implicit 'self' argument 
that may or may not be there, depending on how you call and/or 
declare or define the function. Still not completely without global 
impact, but maybe it's possible to get close?


>  > Languages with lots of implicit side effects, default actions
>  > and whatnot tend to be very easy to misread, especially for
>  > programmers dealing with multiple languages. IMNSHO, it's just
>  > not worth it to save a few keystrokes here and there.
> My purpose is not to save a few keystrokes. It is mainly to get a  
> cleaner, more straightforward syntax, as it saves the need for an
> extra operator (the : would simply disappear). A more generic syntax
> too, because it generalizes the use of only one concept. This in
> favor of a simplicity principle (a.k.a. Occam's "do not multiply
> things beyond necessity") 
> -- and the design of Lua seems to extensively rely upon this
> principle.

Well, you do have a point.

However, there are side effects that may not be all that obvious. For 
example, if you make method calls look and feel like normal function 
calls, how do you explain that you cannot use an intermediate 
variable to store a reference to a method, whereas you *can* with a 
function? (Just like in Object Pascal, you'd need a different type of 
function "pointer", which actually contains an object pointer as 
well.)

I suppose that can be solved by automatically grabbing the indexed 
object as well, when grabbing a function reference, but that would 
mean even more overhead that impacts all code, but benefits only OO 
code. (Besides, you can't fit two pointers in a 16 byte type tagged 
struct on a 64 bit platform. From what I remember of Lua VM code, 
this would be an issue, just like it would be in the EEL VM.)


> It would also allow to stick to a more standard usage: most
> languages use a "." notation to invoke a method -- see
> http://merd.sourceforge.net/pixel/language-study/syntax-across- 
> languages.html#bjcrntRflMthdnvct
> The same usage in Lua would be more comfortable for those
> "programmers dealing with multiple languages" you're talking about
> (and what programmer isn't nowadays?)

Like I said, you do have a point, but there's no such thing as a free 
lunch. I like the idea of avoiding this special : operator, but when 
I try to see it from the implementation POV (considering both Lua and 
my own EEL), I see more problems, overhead and side effects than I'd 
like to deal with, so it quickly starts to feel like a bad idea.

I'm not saying there is no nice, clean and effective solution. I'm 
just saying I haven't figured it out yet. ;-)


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'