<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000066">
<font face="Calibri">Hi Robert,<br>
<br>
Thanks for the feedback. Yes, it's a matter of viewpoint, from
Erlang or Lua. <br>
<br>
If you feel the audience for Luerl would be people who did work
with Lua before, many of them would know the C interface and thus,
it could be helpful for them to stick to these names. <br>
<br>
Since I work with Lua, embedded Lua and Erlang, I would treasure
consistency between the C and Erlang underside of Lua.<br>
<br>
Lua is so much for embedding that the C interface functions are
actually listed in the manual earlier than the language functions
(or at least once it was so).<br>
<br>
I'll agree that 'load' is not intuitively right. But it would
increase consistency.<br>
<br>
'dofile' is a staple of Lua proper, also exists in the C interface
and again would probably be what somebody coming from Lua would
look for, so would be --- nice to have in my view. 'evalfile'
exists for symmetry.<br>
<br>
As I wrote, my interface proposal is bloated, but the differences
between 'do' and 'call' would be that 'call' only takes
pre-compiled chunks and crashes with anything else. While "do" is
more careless and can be fed anything: Lua code in Strings,
Binaries, or pre-compiled chunks.<br>
<br>
"eval" - for easiest use, in place, returns pure Result<br>
"do" - same as eval but returns Result and State*<br>
"call" - takes only precompiled chunks, returns </font><font
face="Calibri">Result and State</font><br>
<font face="Calibri"><br>
* </font><font face="Calibri">(in Erlang, you can't just <i>not</i>
fetch the second return value, as is possible in Lua)<br>
<br>
My two cents on: "encode" and "decode" I find them better but
still not perfect. It's really again the perspective from Erlang.
"wrap"/ "unwrap"? "stage"/"unstage"? (Looks like no difference to
"encode" at first sight -- but I do think there is one.)<br>
<br>
As for error handling: I came to think that a try-catch wrap in
eval as standard service would be nice. So using eval you'd be
sure it will always return, of with an error message. While that
may in fact be too much Lua thinking, and too alien to Erlang,
it's what comes to mind for how I would like "eval" to be a
carefree, fast thing to use. </font><font face="Calibri">(Erlang
has a "let it crash" philosophy where errors are usually handled
but a process automatically restarted.)<br>
</font><br>
<font face="Calibri"> The whole point of "pcall" is to be a
protected version of "call". Using "pcall" in Lua/C interface one
can be sure that errors don't crash the program and can be
handled. Specifically by a handler function which has access to
the state before the stack is discarded. <br>
<br>
I think it may make sense to treat errors that originate in Lua
(or even in the Luerl VM itself, while in development) differently
from errors that originate in the Erlang source. <br>
</font> <br>
Best,<br>
Henning<br>
<br>
<div class="moz-signature">-- <br>
<div style="font-family:Calibri, Verdana, Arial, sans-serif"> <span
style="color:navy;"><b>Henning Diedrich</b><br>
CEO<br>
</span> <br>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td valign="top"> <img moz-do-not-send="false"
src="cid:part1.08030505.09010703@eonblast.com" alt=""
style="margin-bottom:5px"><br>
</td>
<td width="10px"><br>
</td>
<td valign="top"><span style="font-size:9.0pt;color:gray">
Eonblast Corporation<br>
<a class="moz-txt-link-abbreviated"
href="mailto:hdiedrich@eonblast.com">hdiedrich@eonblast.com</a><br>
+1.404.418.5002 w<br>
<a class="moz-txt-link-abbreviated"
href="http://www.eonblast.com">www.eonblast.com</a></span>
</td>
</tr>
</tbody>
</table>
<br>
<small>This email contains confidential and/or privileged
information. If you are not the intended recipient (or have
received this email in error) please notify the sender
immediately and destroy this email. Any unauthorized copying,
disclosure or distribution of the material in this email is
prohibited.</small> </div>
</div>
<br>
<br>
On 2/22/12 3:04 AM, Robert Virding wrote:
<blockquote cite="mid:aeb64036-52d8-45a0-a0c5-1f736b497d14@knuth"
type="cite">
<style type="text/css">p { margin: 0; }</style>
<div style="font-family: Times New Roman; font-size: 12pt; color:
#000000"><font size="3">Hi,<br>
<br>
</font><font size="3">Most of the difference is just in
terminology and from which side you view it, from erlang or
Lua. For example, for me loading means actually getting it
into the sytem not just compiling it into a runnable form. And
I view these functions from the erlang side. I will also admit
that I am a bit hazy as to how the C-side functions work, it
seems easier within the language.<br>
<br>
'eval' and 'do' work well for me, though I do wonder if we
need 'evalfile' and 'dofile'. I prefer 'compile' instead of
'load' as this is what is does. 'call' is fine. What is the
difference between 'call' and 'do'? For creating and
destroying state I would prefer either 'new' / 'delete' or
'start' / 'stop' depending on whether you want to view the
state as just data or as some form of concurrent activity, a
separate process in Erlang.<br>
<br>
I would use 'encode' / 'decode' for converting between an
Erlang representation and an internal luerl representation.
So:<br>
<br>
luerl:encode(Erlang, State) -> {Luerl,State}.<br>
luerl:decode(Luerl, State) -> Erlang.</font><br>
<br>
<div style="text-align: left;">Encoding will modify the state as
tables only exist within that state. If it not done this way
then there is no need of these functions as the representation
is the same and this conversion will be done in the other
interface functions. So for example a Lua strings are Erlang
binaries and tables will are a list of tuple pairs,<br>
<br>
Lua {['a']=97,['b']=98,10,20,30} <==> Erlang
[{1.0,10.0},{2.0,20.0},{3.0,30.0},{<<"a">>,97.0},{<<"b">>,98.0}]<br>
<br>
Putting Lua tables into the state is also the only way to
handle the difference in the meaning of equality between Lua
and Erlang.<br>
<br>
For errors I have been thinking in the Erlang way. The only
function to actually return an error value would be 'compile'
(or 'load') which would become<br>
<br>
luerl:compile(String) -> {ok,Chunk} | {error,Reason}.<br>
<br>
All errors during the Lua execution, unless they are caught
internally, would result in Erlang exceptions which would
handled in the normal Erlang way, either by catching it or
having the Erlang process die.<br>
<br>
The result returned from Lua and the arguments to a call would
be a list of Erlang values. If no values are returned the list
is empty otherwise it would contain same number of elements as
in the 'return' statement.<br>
<br>
Those are my thoughts for the moment. Now I will go back and
try and code the idiosyncrasies of string.sub.<br>
<br>
Robert <br>
</div>
<br>
<hr id="zwchr">
<blockquote style="border-left:2px solid rgb(16, 16,
255);margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
Hi Robert,<br>
<br>
To allow for String|Chunk, the chunks returned from ps/1 would
have to be wrapped to be distinguishable from the Strings. I
think 'functiondef' could be the right choice.<br>
<br>
For the names, I'd propose to maybe stay closer to the Lua
language function names and its C interface [1]. <br>
<br>
But at any rate, to maybe decide for one of "do" and "eval" to
1) return bare results 2) return {Result, State}. Rather than
making this dependent on whether State was handed in or not as
a parameter?<br>
<br>
Since Lua uses dofile() both in the Lua language and the C
interface, (and since of course neither case returns state),
the "do" functions look earmarked for returning the simple,
bare bones Result. However ... somehow "eval" is a better fit
for a function that is expected to return something.<br>
<br>
Lua's C interface uses "load" for parsing-only: load,
loadfile, lua_load [2], lua_loadfile, lua_loadstring,
lua_loadbuffer.<br>
<br>
This could be an alternative to wrapping the chunks: for load,
in Lua <i>"the string mode controls whether the chunk can be
text or binary (that is, a precompiled chunk). It may be the
string "b" (only binary chunks), "t" (only text chunks), or
"bt" (both binary and text). The default is "bt". </i>[5]<br>
<br>
The type that the loads return is 'function': <i>"If there
are no syntactic errors, returns the compiled chunk as a
function; otherwise, returns nil plus the error message."
--- </i>therefore, the right chunk wrapper could be {
functiondef, ... }, instead of compiled chunks being lists as
outermost type.<br>
<br>
Execution of pre-parsed/compiled chunks is "call": pcall,
xpcall, lua_call, lua_pcall [3], and lua_pcallk. <br>
<br>
State is created and destroyed by lua_newstate and lua_close.<br>
<br>
There is no "eval" in Lua. <br>
<br>
So here's my proposal:<br>
<br>
luerl:eval(String|Chunk[, State]) -> Result.<br>
luerl:evalfile(PathString[, State]) -> Result.<br>
<br>
luerl:do(String|Chunk[, State]) -> {Result, NewState}.<br>
luerl:dofile(PathString[, State]) -> {Result, NewState}.<br>
<br>
luerl:newstate() -> State.<br>
luerl:close(State) -> ok.<br>
<br>
luerl:load(String) -> {ok, Chunk}.<br>
luerl:loadfile(PathString) -> {ok, Chunk}.<br>
luerl:call(Chunk[, State][, ErlParamList()]) -> {Result,
NewState}.<br>
<br>
luerl:tolua(list()) -> LuerlTermsList().<br>
luerl:toerlang(LuerlTermsList()) -> list().<br>
<br>
This would be somewhat in keeping with Lua's naming.<br>
<br>
I am unclear about error state returns. Simply in the Result I
guess?<br>
<br>
Relative to your proposal that is:<br>
luerl:eval(String|Chunk) -> Result. =>
luerl:eval(String|Chunk[, State]) -> Result.<br>
luerl:dofile(String) -> Result. =>
luerl:dofile(PathString[, State]) -> {Result,State}.<br>
luerl:new() -> State. (currently luerl:init() -> State.)
=>luerl:newstate() -> State.<br>
luerl:eval(String|Chunk, State) -> {Result,NewState}. =>
luerl:eval(String|Chunk, State) -> {Result,NewState}.
<div style="text-align: left;">luerl:dofile(String, State)
-> {Result,NewState}. => same<br>
</div>
luerl:compile(String) -> {ok,Chunk}. =>
luerl:load(String) -> {ok,Chunk}.<br>
<br>
Beyond that, I had thought with 'interface' you would be
addressing the direct interchange of values between Erlang and
Lua. I'd be all for making the collection of tables in the Lua
state accessible and writable, directly, somehow navigating
into it using a key structure. And if possible, vice versa:
giving Lua direct access to Erlang state.<br>
<br>
Best,<br>
Henning<br>
<br>
<br>
[1] <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.lua.org/manual/5.2/manual.html#4.8"
target="_blank">http://www.lua.org/manual/5.2/manual.html#4.8</a><br>
<br>
[2] <i>One note I like, in the description of the C function
lua_load : "The source argument gives a name to the chunk,
which is used for error messages and in debug information
(see §4.9)." </i><a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.lua.org/manual/5.2/manual.html#lua_load"
target="_blank">http://www.lua.org/manual/5.2/manual.html#lua_load</a>
- <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.lua.org/manual/5.2/manual.html#2.3"
target="_blank">http://www.lua.org/manual/5.2/manual.html#2.3</a><br>
<br>
[3] <i>When you use xpcall or lua_pcall, you may give a
message handler to be called in case of errors. This
function is called with the original error message and
returns a new error message. It is called before the error
unwinds the stack, so that it can gather more information
about the error, for instance by inspecting the stack and
creating a stack traceback. This message handler is still
protected by the protected call; so, an error inside the
message handler will call the message handler again. If this
loop goes on, Lua breaks it and returns an appropriate
message.</i> - <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.lua.org/manual/5.2/manual.html#2.3"
target="_blank">http://www.lua.org/manual/5.2/manual.html#2.3</a><br>
<br>
[4] In Lua (not the C interface), dofile does not run in
protected mode. <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.lua.org/manual/5.2/manual.html#6.1"
target="_blank">http://www.lua.org/manual/5.2/manual.html#6.1</a><br>
<br>
[5] <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.lua.org/manual/5.2/manual.html#6.1"
target="_blank">http://www.lua.org/manual/5.2/manual.html#6.1</a><br>
<br>
<br>
<br>
On 2/20/12 10:59 PM, Robert Virding wrote:<br>
<blockquote
cite="mid:a6f24fc1-9075-4a31-bebd-5bc8812ac444@knuth">
<div style="font-family: Times New Roman; font-size: 12pt;
color: #000000">[snip] I had planned something along the
lines of:<br>
<br>
luerl:eval(String|Chunk) -> Result.<br>
luerl:dofile(String) -> Result.<br>
<br>
Basic simple interface which initialises a state and
evaluates the chunk String in it returning a list of
return values (if any). For example luer:eval("local
t={'a','b'} return t[1],t[2]") will return
[<<"a">>,<<"b">>]. luerl:dofile/1
is not really necessary.<br>
<br>
luerl:new() -> State.<br>
luerl:eval(String|Chunk, State) -> {Result,NewState}.<br>
<div style="text-align: left;">luerl:dofile(String, State)
-> {Result,NewState}.<br>
</div>
luerl:compile(String) -> {ok,Chunk}.<br>
<br>
A more complex interface. luerl:new/0 creates an initial
state. luerl:eval/2 will evaluate a chunk in a state and
return the values and the updated state. This state can be
reused to evaluate new chunks. Again luerl:dofile/2 is not
really necessary. luerl:compile(String) compiles the
string into an internal form ready to run in eval/1/2.<br>
<br>
Result is always a list of return values which may be
empty if the chunk does not do a return with values. For
data types:<br>
<br>
Lua strings are binaries<br>
Lua numbers are floats<br>
Lua tables are orddicts (property lists) of key-value
tuples<br>
Lua true, false, nil are just the atoms true, false, nil<br>
<br>
Anyway something along those lines. It might be nice to
have a function call wrapper which would allow you a more
erlang like way of calling a luerl function.<br>
<br>
Robert<br>
<br>
<hr id="zwchr">
<blockquote style="border-left:2px solid rgb(16, 16,
255);margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
Regarding interface function names:<br>
<br>
I wonder what logic Luerl's names of do and eval follow:<br>
<br>
dofile/1, like eval/1, returns a pragmatic Ret <br>
<br>
while do/2 returns {String, State}<br>
<br>
Since you are exporting ps/1, there should maybe be a
dochunk/2? <br>
<br>
And /1, too? <br>
<br>
Or should it maybe be evalchunk/1, dochunk/2 (the /2s
with State as second parameter)?<br>
<br>
Here are some relevant functions from Lua's C interface.<br>
<br>
<blockquote><b>luaL_dofile</b><br>
<br>
[-0, +?, m]<br>
int luaL_dofile (lua_State *L, const char *filename);<br>
Loads and runs the given file. It is defined as the
following macro:<br>
<br>
(luaL_loadfile(L, filename) || lua_pcall(L, 0,
LUA_MULTRET, 0))<br>
It returns false if there are no errors or true in
case of errors.<br>
<br>
<b>luaL_dostring</b><br>
<br>
[-0, +?, –]<br>
int luaL_dostring (lua_State *L, const char *str);<br>
Loads and runs the given string. It is defined as the
following macro:<br>
<br>
(luaL_loadstring(L, str) || lua_pcall(L, 0,
LUA_MULTRET, 0))<br>
It returns false if there are no errors or true in
case of errors.<br>
<br>
<b>luaL_loadstring</b><br>
<br>
[-0, +1, –]<br>
int luaL_loadstring (lua_State *L, const char *s);<br>
Loads a string as a Lua chunk. This function uses
lua_load to load the chunk in the zero-terminated
string s.<br>
<br>
This function returns the same results as lua_load.<br>
<br>
Also as lua_load, this function only loads the chunk;
it does not run it.<br>
<br>
<b>luaL_newstate</b><br>
<br>
[-0, +0, –]<br>
lua_State *luaL_newstate (void);<br>
Creates a new Lua state. It calls lua_newstate with an
allocator based on the standard C realloc function and
then sets a panic function (see §4.6) that prints an
error message to the standard error output in case of
fatal errors.<br>
<br>
Returns the new state, or NULL if there is a memory
allocation error.<br>
</blockquote>
<br>
Source: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.lua.org/manual/5.2/manual.html"
target="_blank">http://www.lua.org/manual/5.2/manual.html</a><br>
</blockquote>
<br>
</div>
</blockquote>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote>
<br>
</div>
</blockquote>
</body>
</html>