lua-users home
lua-l archive

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


Hi,

a lua script

---------
if a and a~=b then
 call()
else
  call_func5(123)
end
-------------------

-- will get translated into ----------

if(js_iop_and(a, js_iop_noteq(a,b)))
{
 call() ;
}
else
{
 call_func5(123) ;
}/*end of if*/

-----------------------

meaning that js_iop_noteq will get called first

... To be honest I did not think of this. I first thought
of translating into equivalent infix operators, but that
was harder, because metalua's AST would return me first operators
and then arguments to the operators, which is how normally
expression ASTs are represented (so it was naturally fitting
to do functions).

This means that all the js_ operators need to check for argument
validity before processing them

I did not plan to do anything about this one.


As far as tables into javascript, what I planned to do
was:

create a table as string (which I already do but in pieces not as one)
then call call lua's loadstring function to evaluate that string into
a table... And then call json4lua   encode function
to make that into a javascript object.  It does a pretty good job
of converting lua tables into Javascript, does escapes correctly,UTF-8
 etc (I use it all over the place).

But I have not implemented that yet... 

by the way, the support for ~=  (noteq) was broken in the code
I submitted, so if you need to I can send a new version.

Also ~  operator does not work (but since you can invoke any
function within if expression    if my_not_nil(a) would get then
translated into javascript correctly

Vlad




On Thu, 13 Nov 2008 07:58:42 -0500, "Javier Guerra Giraldez"
<javier@guerrag.com> said:
> On Thursday 13 November 2008, V S P wrote:
> > if( js_iop_or( js_iop_lt( arr1['field1'], arr2['field1'])
> > , js_iop_lt( arr2[33][15], arr1['field2'])
> 
> 
> i see you're using functions for operators.  does that meas that operands
> are 
> evaluated?
> 
> for example, i usually do:
> 
>    if a and a.b then.....
> 
> to avoid evaluating 'a.b' until i know that 'a' is not null.  in your 
> translation, both terms would be evaluated before evaluating the 'and' 
> itself.
> 
> another shortcoming i don't see addressed is JavaScript limitation on
> table 
> keys.  in JS keys are only strings, while in Lua they can be any object 
> (except null).
> 
> do you plan to do something about these?
> 
> -- 
> Javier
-- 
  V S P
  toreason@fastmail.fm

-- 
http://www.fastmail.fm - IMAP accessible web-mail