XMLRPC 0.0 for Lua

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

XMLRPC 0.0 for Lua

Jay Carlson
I've put an initial release of client/server bindings for Lua for XML-RPC at
http://www.place.org/~nop/luaxmlrpc-0.0.tar.gz . It contains my lxp expat
binding, and uses LuaSocket for client transport.

For more information on XML-RPC, see http://www.xmlrpc.org/ .

Although the packaging and documentation are scant, this package
successfully passes the validation tests at http://validator.xmlrpc.com/ .

Jay



Reply | Threaded
Open this post in threaded view
|

Re: XMLRPC 0.0 for Lua

Martin Spernau
Wow! This is great news!

two questions:
1) have you / will you add your Implementation to the list :
http://www.xmlrpc.com/directory/1568/implementations
?

2) is there a big difference in using expat as parser to using plain Lua?
Maybe one should try and make some tests...

-Martin
----- Original Message -----
From: "Jay Carlson" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, November 27, 2001 6:44 AM
Subject: XMLRPC 0.0 for Lua


> I've put an initial release of client/server bindings for Lua for XML-RPC
at
> http://www.place.org/~nop/luaxmlrpc-0.0.tar.gz . It contains my lxp expat
> binding, and uses LuaSocket for client transport.
>
> For more information on XML-RPC, see http://www.xmlrpc.org/ .
>
> Although the packaging and documentation are scant, this package
> successfully passes the validation tests at http://validator.xmlrpc.com/ .
>
> Jay
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: XMLRPC 0.0 for Lua

Jay Carlson
"Martin Spernau" <[hidden email]> writes:

[XMLRPC 0.0]

> Wow! This is great news!
>
> two questions:
> 1) have you / will you add your Implementation to the list :
> http://www.xmlrpc.com/directory/1568/implementations
> ?

After more people than me have successfully run it.  :-)  Actually the
target audience for this is one particular person, and he's not awake yet.
But sure, especially after I write more documentation.

> 2) is there a big difference in using expat as parser to using plain Lua?
> Maybe one should try and make some tests...

Go ahead, it shouldn't be that hard.

The big motivation for expat was a guarantee of correct XML tokenization.
There are lots of little annoying issues in XML, even in the XML-RPC DTD,
and I wanted to know somebody else had taken care of them.  Speed wasn't the
issue.

Right now, there is an bad dependence of XMLRPC on LxpTree because of
whitespace handling.  Lemme explain.

LxpTree normally parses

    <a>   <hello>world</hello>   </a>

as

    {"a", "   ", {"hello", "world"}, "   "}

I tried to design a mode where character data would only be reported for
certain terminals, such that whitespace wouldn't screw up the trees.  I want

    <value>
        <i4>7</i4>
    </value>

to parse as {"value", {"i4", "7"}} instead of {"value", "\n\t   ", {"i4",
"7"}, "\n\t"}.  Oh, and for my purposes, all adjacent strings should be
merged; given "<q>a&amp;b</q>", expat is allowed to return {"q", "a", "&",
"b"} when I want {"q", "a&b"}.

So LxpTree has a mode where you can specify particular tags as wanting
chardata, and it'll also merge all chardata in a node to the end.  Except
that my code is badly written, and I'm not sure why it works.

What I may do is implement a post-processor for trees to merge/eliminate
whitespace and that should improve conformance and allow other XML parsing
implementations to be dropped in.

Jay



Reply | Threaded
Open this post in threaded view
|

Re: XMLRPC 0.0 for Lua

Jay Carlson
In reply to this post by Jay Carlson
> I've put an initial release of client/server bindings for Lua for XML-RPC
at
> http://www.place.org/~nop/luaxmlrpc-0.0.tar.gz . It contains my lxp expat
> binding, and uses LuaSocket for client transport.

Argh, you knew there had to be a reason why it was version 0.0.  I just
found it.  There's a hole in the type system.

Let's say you want to transmit a struct, {early=false} which looks like this
in XML-RPC on the wire:

<struct>
  <member>
    <name>early</name>
    <value><boolean>0</boolean></value>
  </member>
</struct>

XML-RPC false is mapped to Lua nil.  There's no way to send that struct,
because the Lua table is {early=nil}, which is equal to {}.  (Similarly,
arrays with a first element of false fail the "is this an array" test.)

OK, so what can be done to fix this up?  I want to support the echo test in
Lua as function echo(v) return v end, so at the least there has to be some
kind of strict mode, such that a round trip through the type system doesn't
alter semantics.

First option: in-band signalling.  Make an XMLRPC.false (which will have to
evaluate true in the Lua sense).  It's painless to support this outbound,
such that clients sending messages and servers returning values can use this
if they have to transmit such structs and arrays.  It's more painful to
support it inbound, where all values from the network have to be carefully
treated---"if v and v~=XMLRPC.false".

Second option: out-of-band signalling.  Add an additional (non-string,
non-numeric) key to structs and arrays that indicates which elements exist
but have false (aka nil) values.  This makes iteration less fun.

Third option: magic tables.  As above, but hide the is-present key behind a
layer of tagged "settable".

I think I'll make XMLRPC.false always available for outbound values, and
leave inbound false mapped to nil unless a "strict" flag is set.  I'll
probably make the strict flag global at first, but later it can be a
per-function flag in the registry.

Of course, XMLRPC passed the validator test and successfully interacted with
a bunch of network services even with this hole, so it's not like you can't
use it... :-)

Jay




Reply | Threaded
Open this post in threaded view
|

Re: XMLRPC 0.0 for Lua

Martin Spernau
> Of course, XMLRPC passed the validator test and successfully interacted
with
> a bunch of network services even with this hole, so it's not like you
can't
> use it... :-)
>
> Jay

I agree, Jay.
Currently using it to port some Manila-RPC code I was doing in PHP to Lua.
And I tell you, the Lua code was so simple and short, I thought I'd done
something wrong :)

Now if I find out how this bin2c binding of Lua code to an executable is
done (that is mentioned on the LuaSocket Webpage
http://www.tecgraf.puc-rio.br/~diego/luasocket/home.html#down) I'll all
happy and jumping in circles ;)

-Martin



Reply | Threaded
Open this post in threaded view
|

Re: XMLRPC 0.0 for Lua

RLak
In reply to this post by Jay Carlson
One solution I've used to problems like this is to define a table of
tables.

Instead of having the table {key1=val1, key2=val2, ... } you can use
{keys={key1=1, key2=2,...},vals={val1, val2,...}}

Then instead of writing struct[key], you can say
struct.vals[struct.keys[key]]. That's a little hard to type all the time,
but it's easy enough to provide gettable/settable methods which do it.

With this system, you can distinguish between keys which are not present
(struct.keys[key] is nil) and keys which are present but are nil
(struct.vals[struct.keys[key]] is nil).

The other advantage to this methodology is that the original ordering of
keys is preserved, although it's not preserved in a particularly useful
fashion. I have at times resorted to putting a third element in the
structure which is the inverse of the first one; i.e. it maps indices to
keys. This allows iteration to proceed in the order of insertion, which can
be extremely useful.

See my page on ExtendingForAndNext for an experiment on building
non-standard iterations into Lua.

R.



                                                                                                  
                    "Jay Carlson"                                                                 
                    <[hidden email]>               To:     Multiple recipients of list               
                    Sent by:                    <[hidden email]>                        
                    owner-lua-l@tecgraf.        cc:                                               
                    puc-rio.br                  Subject:     Re: XMLRPC 0.0 for Lua               
                                                                                                  
                                                                                                  
                    27/11/01 10.30                                                                
                    Please respond to                                                             
                    lua-l                                                                         
                                                                                                  
                                                                                                  




> I've put an initial release of client/server bindings for Lua for XML-RPC
at
> http://www.place.org/~nop/luaxmlrpc-0.0.tar.gz . It contains my lxp expat
> binding, and uses LuaSocket for client transport.

Argh, you knew there had to be a reason why it was version 0.0.  I just
found it.  There's a hole in the type system.

Let's say you want to transmit a struct, {early=false} which looks like
this
in XML-RPC on the wire:

<struct>
  <member>
    <name>early</name>
    <value><boolean>0</boolean></value>
  </member>
</struct>

XML-RPC false is mapped to Lua nil.  There's no way to send that struct,
because the Lua table is {early=nil}, which is equal to {}.  (Similarly,
arrays with a first element of false fail the "is this an array" test.)

OK, so what can be done to fix this up?  I want to support the echo test in
Lua as function echo(v) return v end, so at the least there has to be some
kind of strict mode, such that a round trip through the type system doesn't
alter semantics.

First option: in-band signalling.  Make an XMLRPC.false (which will have to
evaluate true in the Lua sense).  It's painless to support this outbound,
such that clients sending messages and servers returning values can use
this
if they have to transmit such structs and arrays.  It's more painful to
support it inbound, where all values from the network have to be carefully
treated---"if v and v~=XMLRPC.false".

Second option: out-of-band signalling.  Add an additional (non-string,
non-numeric) key to structs and arrays that indicates which elements exist
but have false (aka nil) values.  This makes iteration less fun.

Third option: magic tables.  As above, but hide the is-present key behind a
layer of tagged "settable".

I think I'll make XMLRPC.false always available for outbound values, and
leave inbound false mapped to nil unless a "strict" flag is set.  I'll
probably make the strict flag global at first, but later it can be a
per-function flag in the registry.

Of course, XMLRPC passed the validator test and successfully interacted
with
a bunch of network services even with this hole, so it's not like you can't
use it... :-)

Jay







Reply | Threaded
Open this post in threaded view
|

Re: XMLRPC 0.0 for Lua

Luiz Henrique de Figueiredo
>Now if I find out how this bin2c binding of Lua code to an executable is done

See etc/README, reproduced below:

bin2c.c
        This program converts files to byte arrays that are automatically
        run with lua_dobuffer. This allows C programs to include all necessary
        Lua code, even in precompiled form. Even if the code is included in
        source form, bin2c is useful because it avoids the hassle of having to
        quote special characters in C strings.
        Example of usage: Run bin2c file1 file2 ... > init.h. Then, in your C
        program, just do #include "init.h" anywhere in the *body* of a
        function. This will be equivalent to calling
                lua_dofile(L,"file1"); lua_dofile(L,"file2"); ...
        Note that the Lua state is called "L". If you use a different name,
        say "mystate", just #define L mystate before #include "init.h".

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: XMLRPC 0.0 for Lua

Jay Carlson
In reply to this post by Martin Spernau
"Martin Spernau" <[hidden email]> writes:

> 2) is there a big difference in using expat as parser to using plain Lua?
> Maybe one should try and make some tests...

Well, I grabbed Roberto's parser and modified it to fit the LxpTree
interface.  With a few extensions it seems to be handling XML-RPC servers
well enough.  It's a long way away from full XML conformance however, so I'd
recommend that you only use it when there's no way you can use the real
parser in Lxp.

http://www.place.org/~nop/lxptree-roberto.lua

I'll ship it in the next rev of Lua XML-RPC.  I'll probably make it a
fallback when running in non-Lxp interpreters, possibly with a warning.  It
will have the nice feature of allowing CGI-based XML-RPC servers running in
the standard lua executable; you'll still need LuaSocket for clients unless
I get silly and enable my /usr/bin/POST or /usr/bin/lynx -post hacks....

Oh yes, Luiz suggested I should put up a web page with pointers to my Lua
tools.  http://www.place.org/~nop/lua/ .  I'll try to keep it updated.

Jay



Reply | Threaded
Open this post in threaded view
|

The "Is nil present in a table" problem, ExtendingForAndNext (was Re: XMLRPC 0.0 for Lua)

Jay Carlson
In reply to this post by RLak
<[hidden email]> writes:

[The "is nil present in a table" problem]

> One solution I've used to problems like this is to define a table of
> tables.
>
> Instead of having the table {key1=val1, key2=val2, ... } you can use
> {keys={key1=1, key2=2,...},vals={val1, val2,...}}
>
> Then instead of writing struct[key], you can say
> struct.vals[struct.keys[key]]. That's a little hard to type all the time,
> but it's easy enough to provide gettable/settable methods which do it.
>
> With this system, you can distinguish between keys which are not present
> (struct.keys[key] is nil) and keys which are present but are nil
> (struct.vals[struct.keys[key]] is nil).

Yeah; the trick Rob Leslie suggested was {key1={key1, value}, key2={key2,
value}} .

> The other advantage to this methodology is that the original ordering of
> keys is preserved, although it's not preserved in a particularly useful
> fashion. I have at times resorted to putting a third element in the
> structure which is the inverse of the first one; i.e. it maps indices to
> keys. This allows iteration to proceed in the order of insertion, which
can
> be extremely useful.

That's an interesting idea; thank you for describing it.

> See my page on ExtendingForAndNext for an experiment on building
> non-standard iterations into Lua.

( http://lua-users.org/wiki/ExtendingForAndNext )

I really like ExtendingForAndNext; for starters, it scratches my "for
i=1,getn(l) do local v=l[i]" itch.  It also seems very much in the current
spirit of Lua, which isn't true of all the language extensions floating
around.  For instance, unified methods significantly changes the semantics
of ":" away from being syntactic sugar, and loses some of the "everything's
a table" flavor of current Lua object programming.  I don't know if this is
good or bad, but I have to think about it; ExtendingForAndNext seems
obviously in the Lua theme.

I would like ExtendingForAndNext to show up in Lua 4.1.  I don't think I can
use it for many of my projects if it's not in the mainline language
implementation---just watch how many people use the all-lua XML tree parser
that I just posted instead of building lxp and getting something that may
actually survive future XML-RPC implementations (CDATA, anyone?)

Jay


Reply | Threaded
Open this post in threaded view
|

Re: The "Is nil present in a table" problem

John Belmonte-2
> [The "is nil present in a table" problem]

I don't think that's an adequate name for the problem.  Nil should not be
present in tables.  Nil is what you assign to a key to remove it from a
table.  The problem is that Lua uses nil to mean false, so if you assign the
result of a boolean expression to a key you might obliterate that key.

We've had a proposal on the table for dealing with this for a while.  Edgar
T. even made a patch for 4.0.  Is it worth some attention?
(http://lua-users.org/wiki/BooleanTypeProposal)

-John



Reply | Threaded
Open this post in threaded view
|

Ann: Lua XML Parser (LuaXML-0.0.0)

Paul Chakravarti
In reply to this post by Jay Carlson

I have been tinkering with a native XML parser in Lua for a
while but ended up leaving it in a 'not-quite completed' state
over the last couple of months - the recent flurry of XML
related activity on Lua-L has prompted me to get this working
and put together an initial release at least to save any
possible duplication. This is a bit rushed and not as well
documented as I would like but is relatively robust/compliant
and certainly usable. The module is available at - http://www.passtheaardvark.com/lua/LuaXML-0.0.0.tgz
The module implements a non-validating XML stream parser with a
handler based event api (conceptually similar to SAX) which can
be used to post-process the event data as required (eg into a
tree). The current functionality is -
  * Tokenises well-formed XML (relatively robustly)
  * Flexible handler based event api (
  * Parses/generates events all XML elements - ie.
      - Tags
      - Text
      - Comments
      - CDATA
      - XML Decl
      - Processing Instructions
      - DOCTYPE declarations
  * Provides limited well-formedness checking
    (checks for basic syntax & balanced tags only)
  * Flexible whitespace handling (selectable)
* Entity Handling (selectable) The limitations are -
  * Non-validating
  * No charset handling
  * No namespace support
  * Shallow well-formedness checking only (fails
to detect most semantic errors)
I believe that the parsing code is relatively robust/compliant
and I have run it (informally) against the Oasis XML validation
suite believe that it correctly tokenises all of the test data
at least at a cursory level (some of which is pretty grim!) with
the exception of local entity definitions (which arent currently
parsed).
Layered on top of the parser is the handler api (which is
defined in the distribution) - a number of standard handlers are
included in the distribution including a 'print' handler (which
just dumps an event trace) a 'dom'-like handler which creates a
tree based representation (which can support arbitary XML
content but is a bit unwieldy) and a 'simpleTree' handler which
creates a much more Lua-friendly tree structure (but which has
some limitations particularly when working with mixed-content).
(See xml.lua and handler.lua for more info)
The code is relatively well documented (in the module headers)
and it should be possible to work things out from this and
the test app (textxml.lua) which is also useful for exploring
the event parsing and tree-building handlers.
Jay's expat based parser would probably be a better choice
when available however this seems to be pretty reasonable both
in speed & compliance. It would be good to come up with a
common event & tree based API which would allow these to
be used interchangably however.
Interesting I also had a go at an XML-RPC marshaller &
unmarshaller and got this to the point of working as a CGI
server but this implementation isnt as complete as Jay's
(and quite a lot uglier from looking at the code).
Hopefully this might be useful - I am happy to take
suggestions/comments on how to merge this with Jay's
work if anyone is interested. PaulC
Reply | Threaded
Open this post in threaded view
|

Re: bin2c (was: XMLRPC 0.0 for Lua)

Martin Spernau
In reply to this post by Luiz Henrique de Figueiredo
Thank you!
I had some confusion as I searched for this tool (bin2c) on the net and
found a bin2c.com file on SimTel that does something very similar, only
without adding the do_buffer calls to actually load the code into the
lua-state..

I now compiled the bin2c.c from the Lua-distro, and everything works very
fine...
I have here a Win32 exe with all relevant libs included for XML-RPC
(luaSocket1.4 and lxp) plus all needed .lua files compiled in.
Debug version is aroung 500KB and the Release version is 272KB !

So now please excuse me as I need to do some hoppiung around in circles :)

-Martin

----- Original Message -----
From: "Luiz Henrique de Figueiredo" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, November 27, 2001 5:40 PM
Subject: Re: XMLRPC 0.0 for Lua


> >Now if I find out how this bin2c binding of Lua code to an executable is
done
>
> See etc/README, reproduced below:
>
> bin2c.c
>         This program converts files to byte arrays that are automatically
>         run with lua_dobuffer. This allows C programs to include all
necessary
>         Lua code, even in precompiled form. Even if the code is included
in
>         source form, bin2c is useful because it avoids the hassle of
having to
>         quote special characters in C strings.
>         Example of usage: Run bin2c file1 file2 ... > init.h. Then, in
your C
>         program, just do #include "init.h" anywhere in the *body* of a
>         function. This will be equivalent to calling
>                 lua_dofile(L,"file1"); lua_dofile(L,"file2"); ...
>         Note that the Lua state is called "L". If you use a different
name,
>         say "mystate", just #define L mystate before #include "init.h".
>
> --lhf
>



Reply | Threaded
Open this post in threaded view
|

Re: The "Is nil present in a table" problem, ExtendingForAndNext (was Re: XMLRPC 0.0 for Lua)

Edgar Toernig
In reply to this post by Jay Carlson
I have to defend my unified methods ;-)

Jay Carlson wrote:
>
> For instance, unified methods significantly changes the semantics
> of ":" away from being syntactic sugar,

The syntactic sugar becomes:

    x:y(a)

  is the same as:

    methods(x).y(x,a)

To keep compatibility you may choose another operator for this.
I.e. '::' or '->' but IMHO the ':' is the "method" operator and
should access the method table.

> and loses some of the "everything's a table" flavor of current Lua
> object programming.

HUH???  Why?  Everything still is a table and the tag methods become
table driven.  Maybe you misunderstood something?

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: The "Is nil present in a table" problem

Jay Carlson
In reply to this post by John Belmonte-2
"John Belmonte" <[hidden email]> writes:

> > [The "is nil present in a table" problem]
>
> I don't think that's an adequate name for the problem.  Nil should not be
> present in tables.  Nil is what you assign to a key to remove it from a
> table.  The problem is that Lua uses nil to mean false, so if you assign
the
> result of a boolean expression to a key you might obliterate that key.
>
> We've had a proposal on the table for dealing with this for a while.
Edgar
> T. even made a patch for 4.0.  Is it worth some attention?
> (http://lua-users.org/wiki/BooleanTypeProposal)

Oops, yes, you're right; solving the false==nil issue would fix the XML-RPC
problem nicely.

Jay


Reply | Threaded
Open this post in threaded view
|

Re: The "Is nil present in a table" problem, ExtendingForAndNext (was Re: XMLRPC 0.0 for Lua)

Jay Carlson
In reply to this post by Edgar Toernig
"Edgar Toernig" <[hidden email]> writes:

> I have to defend my unified methods ;-)

I understand :-)

> Jay Carlson wrote:
> >
> > For instance, unified methods significantly changes the semantics
> > of ":" away from being syntactic sugar,
>
> The syntactic sugar becomes:
>
>     x:y(a)
>
>   is the same as:
>
>     methods(x).y(x,a)
>
> To keep compatibility you may choose another operator for this.
> I.e. '::' or '->' but IMHO the ':' is the "method" operator and
> should access the method table.
>
> > and loses some of the "everything's a table" flavor of current Lua
> > object programming.
>
> HUH???  Why?  Everything still is a table and the tag methods become
> table driven.  Maybe you misunderstood something?

It feels like the difference between LISP1/Scheme and LISP2/CL.  There are
now two namespaces you have to think about; one for use as data, and one for
use for function calls.  Moving method invocation off ":" would at least
make that syntactically apparent to current users.

Look, I haven't made up my mind yet about unified methods.  They offer a lot
of nice features that seem useful in day-to-day programming.  But it's a
significant enough change that I need to think about it, a lot---because it
*is* an interesting and thoughtful proposal.  In comparison,
ExtendingForAndNext is a very localized language change, and one that seems
like an oversight from the original language design.

Taste in language constructs is very personal.... :-)

Jay


Reply | Threaded
Open this post in threaded view
|

Re: The "Is nil present in a table" problem

Paul Chakravarti
In reply to this post by Jay Carlson
Jay Carlson writes:
of a boolean expression to a key you might obliterate that key.

We've had a proposal on the table for dealing with this for a while.
Edgar
T. even made a patch for 4.0.  Is it worth some attention?
(http://lua-users.org/wiki/BooleanTypeProposal)


I had a slight question/concern with the following -
-- Relational operators return false for false and a value other than
-- false/nil for true
Although this solves the unmarshalling problem it doesnt solve the
marshalling problem for boolean values (it isnt possible to distinguish
a 'true' value as a boolean without explicitly casting it)
For orthogonality I would be useful to also have a 'true' type such
that -- Relational operators return 'false' for false and 'true' for true
Assuming 'true' was a non-nil value I dont believe this changes the
semantics of any relational operators PaulC
Reply | Threaded
Open this post in threaded view
|

Re: unified methods

John Belmonte-2
In reply to this post by Jay Carlson
Jay Carlson wrote:

> Look, I haven't made up my mind yet about unified methods.  They
> offer a lot of nice features that seem useful in day-to-day
> programming.  But it's a significant enough change that I need to
> think about it, a lot---because it *is* an interesting and thoughtful
> proposal.

Actually unified methods doesn't offer many features at all.  It's just
taking Lua's internal tag method system an exposing it as tables (this is
why Edgar was shocked by your comment about everything-as-tables).  Lua's
tag method interface is spotty and hard to follow, so unified methods just
make you think you're getting a whole lot more.  It's an illusion.

-John



Reply | Threaded
Open this post in threaded view
|

Re: unified methods

Matt Holmes-2
Yes, but illusions that make parts of a language that are hard to follow,
easier to follow and to use, are not really illusions, they do add alot of
value. They may be an illusion above the internals of how something works,
but they make the language as a whole easier to use. A good example, C++
overloading schemes. In C++, for overloaded methods to work, they have to be
decorated in their symbols. We don't actually have to do the decoration
ourselves, because that would be difficult and hard to follow. Instead, we
program in a more natural way (in the context of C++ at least), and the
compiler does the decoration for us behind the scenes.

The same thing applies here to unified methods. Sure, its just a face lift
of the current tag method system, but as you stated yourself, the current
tag method system is spotty and hard to follow. Unified methods gives the
tag method system a more consistant and easy to follow interface. If that is
the type of "illusion" you are speaking of, I see no problem with them.

Matt

----- Original Message -----
From: "John Belmonte" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, November 28, 2001 10:26 AM
Subject: Re: unified methods


> Jay Carlson wrote:
>
> > Look, I haven't made up my mind yet about unified methods.  They
> > offer a lot of nice features that seem useful in day-to-day
> > programming.  But it's a significant enough change that I need to
> > think about it, a lot---because it *is* an interesting and thoughtful
> > proposal.
>
> Actually unified methods doesn't offer many features at all.  It's just
> taking Lua's internal tag method system an exposing it as tables (this is
> why Edgar was shocked by your comment about everything-as-tables).  Lua's
> tag method interface is spotty and hard to follow, so unified methods just
> make you think you're getting a whole lot more.  It's an illusion.
>
> -John
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: false [was: The "Is nil present in a table" problem}

Edgar Toernig
In reply to this post by Paul Chakravarti
Paul Chakravarti wrote:
> 
> >> (http://lua-users.org/wiki/BooleanTypeProposal)
> >
> 
> I had a slight question/concern with the following -
> 
>  -- Relational operators return false for false and a value other than
>  -- false/nil for true

In fact, they always return the number 1 for true.  Maybe it's better
to say that explicitely (and define true to be 1).  That way

   (a==b) == (c==d)

and alike becomes valid.

> For orthogonality I would be useful to also have a 'true' type such
> that
> 
>  -- Relational operators return 'false' for false and 'true' for true
> 
> Assuming 'true' was a non-nil value I dont believe this changes the
> semantics of any relational operators

And then define that if/while/not/... only accept 'false' and 'true'?
I thought about it myself but IMHO it complicates things more than
it would help.

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: The "Is nil present in a table" problem, ExtendingForAndNext (was Re: XMLRPC 0.0 for Lua)

Jay Carlson
In reply to this post by Jay Carlson
"Jay Carlson" <[hidden email]> writes:

> Look, I haven't made up my mind yet about unified methods.  They offer a
lot
> of nice features that seem useful in day-to-day programming.  But it's a
> significant enough change that I need to think about it, a lot---because
it
> *is* an interesting and thoughtful proposal.

In other words, my opinion evaluates to nil, not false.  :-)

Jay


123