[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: I wish function execution continued past `return'
- From: Majic <majic.one@...>
- Date: Tue, 16 Mar 2010 12:16:55 +0000
I guess as I wrote out this hypothetical argument further, it turned
into a post wishing for an explicit stack container type that did not
rely on the implied metadata of a fully-fledged table (from the C
structure of one). What I had started out writing this post with
could have been easily accomplished by:
function whatever()
local tmp
if conditional1 then
if conditional2 then
if conditional3 then
tmp = 2
end
end
end
return tmp, 'whatever'
end
I think I'm just really wanting to a stack container type instead of a
dictionary to avoid pitfalls of things like tables with holes in them
when you call the length operator. I wish there were a container type
where it was an array of ...lua object references? So that you could
iterate through the array, even storing nil in it, and append or
prepend the array with elements. Every return would be an implicit
array which is just a Lua stack, it would just allow for more control
over what is returned and when from the Lua side of things. (CAPI is
more fun, in my opinion) And you would be able to store this
stack-like type with the syntax I suggested (above/below--depending on
how your mail reader arranges previous messages) like so:
local whatever = | function() |
for x in whatever do
print(x)
end
whatever = 1 + whatever
= whatever -- 1, 2, 'whatever'
= whatever + {} -- 1, 2, 'whatever', {}
Now I hope this has at least been thought-provoking if you absolutely
disagree but if you don't I believe this would make for certain
optimizations on tables and stacks/arrays to be possible that weren't
possible with tables mascuerading as arrays. One being you have the
possibility of allocating for these arrays sequentially (at the CAPI
core) which would be more memory-efficient if you know that the array
is never grown or shrunken so it's only one malloc() and one free().
>From the table side of things you wouldn't have to allocate for the
key label, like say `something = { 1, 2, 3 }'. You know that the
elements have the keys [1], [2], and [3] but we could pretend from the
CAPI that they have no keys since tables have no order anyway. If
there were an actual stack/array datatype we wouldn't be in need of
ipairs(). Of course, you would have to explicitly label those keys.
I guess it's mostly an argument for saving on memory where possible,
and I don't think a new stack/array datatype that also is implied to
be the returned Lua stack would obfuscate code.
Oh well, off to the nuthouse I go... my head really does hurt tonight >.<
whatever = { [1] =
On Tue, Mar 16, 2010 at 11:46 AM, Pan Shi Zhu <pan.shizhu@gmail.com> wrote:
>> function whatever()
>> if conditional1 then
>> if conditional 2 then
>> if conditional3 then
>> return 2
>> else
>> return 4
>> end
>> end
>> end
>> return 'whatever'
>> end
>
> what do you want exactly? continuing the function after return does no
> help for your code IMO.
>