<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000066">
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 class="moz-txt-link-freetext" href="http://www.lua.org/manual/5.2/manual.html#4.8">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 class="moz-txt-link-freetext" href="http://www.lua.org/manual/5.2/manual.html#lua_load">http://www.lua.org/manual/5.2/manual.html#lua_load</a>
- <a class="moz-txt-link-freetext" href="http://www.lua.org/manual/5.2/manual.html#2.3">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 class="moz-txt-link-freetext" href="http://www.lua.org/manual/5.2/manual.html#2.3">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 class="moz-txt-link-freetext" href="http://www.lua.org/manual/5.2/manual.html#6.1">http://www.lua.org/manual/5.2/manual.html#6.1</a><br>
<br>
[5] <a class="moz-txt-link-freetext" href="http://www.lua.org/manual/5.2/manual.html#6.1">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"
type="cite">
<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>
</body>
</html>