Not / lambda calculus / :)

|> Anyway, trying to follow XenoLiz's sentences is hard enough
|> already, come to think of it, I truthfully am not sure any more
|> what XenoLiz was trying to do with all those 'lambda' bits in his
|> example syntax. 

In this thread?
I want call anonym function(and method) himself only. Higher I am get
interesting proxy method, I must think.

Re: Alternative (better?) __index implementation

On 28-Nov-07, at 12:25 PM, alex.mania <at> iinet.net.au wrote:

> It seems correct when I think about it, because I cannot envision a 
> scenario where
> you have:
>
> Table1.__index = Table2; Table2.__index = function()
>
> Yet would prefer Table2 do be passed to the function then Table1, 
> should Table1 be
> the object being indexed.

Suppose Table2 were created with Memoize:

function Memoize(func)
   return setmetatable({}, {
     __index = function(self, key)
                 local rv = func(key)
                 self[key] = rv
                 return rv
               end,
     __call = function(self, key) return self[key] end
   }
end

This is going to act very oddly if self is wrong. (In particular,
the __call metamethod will fail.)

Here's another real-life example. While Memoize above relies on closures

Re: Alternative (better?) __index implementation

On Sat Dec  1 14:34 , Rici Lake <lua <at> ricilake.net> sent:
>
>Suppose Table2 were created with Memoize:
>
>function Memoize(func)
>   return setmetatable({}, {
>     __index = function(self, key)
>                 local rv = func(key)
>                 self[key] = rv
>                 return rv
>               end,
>     __call = function(self, key) return self[key] end
>   }
>end
>
>This is going to act very oddly if self is wrong. (In particular,
>the __call metamethod will fail.)

>The basic problem with special-casing the __index chaining is that it 
>becomes
>non-composable. The behaviour of a functable changes if it is the 
>target of
>an __index metamethod, in a way which is hard to predict. 

I can see this would be a problem with particular, but still rare contexts. Eg 
trying to memoize a tables __index function would break, as you say. Similarly 
trying to use an already memoized function as a tables __index would break.

>The putative savings (one function call) 
> are just not worth the breaking of orthogonality.

Why is "then" required in the if statement?

Perhaps this is a FAQ, but why does the if statement require the "then" 
keyword after the condition?  Does requiring this keyword eliminate some 
ambiguity?

Thanks,
Matt

Re: Why is "then" required in the if statement?

I think because the if statement doesn't need parentheses:

if p < 8 then p = 9  end

if no then then how would you interpret this:

if p < 8 p = 9 end

wes

On Dec 1, 2007 12:01 PM, Matt Campbell <mattcampbell <at> pobox.com> wrote:
> Perhaps this is a FAQ, but why does the if statement require the "then"
> keyword after the condition?  Does requiring this keyword eliminate some
> ambiguity?
>
> Thanks,
> Matt
>

Re: Why is "then" required in the if statement?

> if p < 8 p = 9 end

Seems unambiguous to me.  In Lua, "p < 8" is an expression that's not a 
function call, so it can't be a statement.  Likewise, "p = 9" is an 
assignment, so it can't be an expression.  Moreover, Lua never allows 
two expressions next to each other, except in the case of a function 
call whose sole argument is a string literal or table constructor; in 
that case, the second expression (the function argument) could not be 
mistaken for a statement.

Matt

Re: Why is "then" required in the if statement?

Re: Why is "then" required in the if statement?

> I'd guess most people would find "if foo then bar end" more readable 
> than "if foo bar end".

If readability of one-liners is that important, then I suggest that "if 
(foo) bar end" is better than either.  Of course, I'm not suggesting 
that Lua require parentheses around the condition; it's up to the 
programmer to decide where parentheses would be helpful.  Anyway, while 
a language design can encourage readability, it shouldn't attempt to 
force readability; that's the programmer's job.  Rather, a language 
design should encourage both readability and succinctness.  For 
multi-line if statements, I think that:

if foo
   bar
end

is quite readable, and less cluttered than

if foo then
   bar
end

albeit by just one keyword.

Besides, sometimes I forget the "then" keyword.

Matt

Re: Why is "then" required in the if statement?

On Saturday 01 December 2007, Wesley Smith wrote:
> I think because the if statement doesn't need parentheses:
> 
> if p < 8 then p = 9  end
> 
> if no then then how would you interpret this:
> 
> if p < 8 p = 9 end

Easy: The rule that looks for the condition expression just gives up 
when it sees the second "p", as it would need and operator or 
something there in order to continue the expression. So, it 
returns "p < 8" (well, not literally, but you'll know what I mean, if 
you've implemented a parser), and then the "if" rule statement asks 
for a body statement, and gets "p = 9". There!

The general problem with removing things like this is that it can 
sometimes drastically increase the risk of little typos generating 
very weird compile errors, or worse, code that accidentally compiles 
but doesn't do what you intend. Basically, the parser knows less 
about what you *mean*, and thus, tends to give more confusing error 
messages when things go wrong.

Debugging is where most people spend most of their time. Saving a few 
keystrokes on things like this can be a very bad trade-off. Don't get 
me wrong; I strongly dislike overly verbose languages - but reality 
is not all black and white. Good solutions are all about balance.

That said, I use pretty much exactly this suggested syntax in EEL (I 
just use ';' instead of 'end', and '{'/'}' are optional for a single 
statement body), and I haven't managed to shoot my leg off with it. 
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  --'

Re: Alternative (better?) __index implementation

On 1-Dec-07, at 5:53 AM, alex.mania <at> iinet.net.au wrote:

>
> I can see this would be a problem with particular, but still rare 
> contexts. Eg
> trying to memoize a tables __index function would break, as you say. 
> Similarly
> trying to use an already memoized function as a tables __index would 
> break.
>

It may be rare in your code. It's common in mine. Styles vary, of 
course.

> Again, not so sure I agree with putting redundant in demeaning quotes 
> there ;)

It's no more demeaning than the use of the word "rare", surely? But it 
was
actually just a quote. I'd say the function call is not so much 
redundant as
optimizable, much like the extra function call in a curried closure, or
indeed any function call which could be inlined. That is, it is 
semantically
a function call but a cleverer compiler (or runtime) might well be able 
to
optimize it away.

> What in your opinion
> would be the best way to handle __newindex regarding proxys?

__newindex should certainly ignore __proxy. It would be possible to 
define
a __newproxy as well, although I don't know how much it would be used. 
The
advantage would be the separation of call from (set)index, as I 
mentioned
earlier.

It's very common to want __index to retrieve from a backup table but not
want __newindex to write into it. In fact, having __newindex respect
__proxy would make __proxy unusable for the common case of inheritance.

>
> And it is a shame that not providing the compatibility would break so 
> many existing
> apps. Maybe make it #definable, but defined in by default; similar to 
> a few things
> in the current Lua 5.1 implementation.

Yes. The compatibility implementation I'd recommend would be to try the 
call
first, and back up to the table index only if (1) there was no __proxy 
method,
and (2) the self object is not callable. However, this is not 100% 
compatible.