new thought experiment: what would you add to Lua ?

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

Re: Exception handling (was Re: ...add to Lua...)

Ivan Krylov
On Thu, 20 Sep 2018 00:12:21 +0200
nobody <[hidden email]> wrote:

> From the user code, you call `hopefully( desc, params... )` (could also be
> hidden inside some constructor) and if the action fails, that tries
> the handlers in order (with the stack still intact – so this is a
> normal function, no language support needed etc.).

I'm not sure I understand how it's implemented -- can you somehow
protect a Lua call in such a way that your handler gets executed
at the same place in the stack where the original error() happened? --
but the R language has a similar construct: the tryCatch function.

R imitates pass-by-value semantics for all function arguments by using
lazy evaluation and copy-on-write, so an expression that gets passed to
a function isn't actually evaluated until the function uses it.
tryCatch() employs that and a few more tricks to intervene when the
expression being evaluated calls stop() and to call a matching handler
instead (if it has one supplied).

--
Best regards,
Ivan

Reply | Threaded
Open this post in threaded view
|

Re: Exception handling (was Re: ...add to Lua...)

nobody
On 2018-09-20 22:50, Ivan Krylov wrote:

> On Thu, 20 Sep 2018 00:12:21 +0200 nobody
> <[hidden email]> wrote:
>> From the user code, you call `hopefully( desc, params... )` (could
>> also be hidden inside some constructor) and if the action fails,
>> that tries the handlers in order (with the stack still intact – so
>> this is a normal function, no language support needed etc.).
>
> I'm not sure I understand how it's implemented -- can you somehow
> protect a Lua call in such a way that your handler gets executed at
> the same place in the stack where the original error() happened? --
> but the R language has a similar construct: the tryCatch function.

This doesn't (necessarily) involve pcall/error – just plain call/return.
`hopefully` is just a wrapper that iterates through ways to do the
requested thing, returns the result on success, or throws a real error
when nothing worked.  (And that wrapper just stays in the same place
until it's done, calling functions as it goes.)

A crappy diagram:

   user code
    \- hopefully
        \- default action
        / (reports failure)
        \- handler #1
            \- (does some stuff)
            /
            \- re-tries default action (and succeeds)
         /--/ (passes through the result)
    /---/ (return to user code)

You essentially take the familiar error handling if-then-else, put it in
a function (`hopefully`), and then wrap the code for the different
branches as functions and put those in a list.  This abstracts away a
repeated pattern and at the same time opens it up for later extension.
Internally (hopefully <-> handlers), you can communicate by `nil,errmsg`
or error/pcall (arbitrary choice, doesn't really matter for external
behavior).

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: new thought experiment: what would you add to Lua ?

Scott Morgan
In reply to this post by Jim
On 14/09/2018 20:57, Jim wrote:
>

Some sugar maybe but something along the lines of:

  if item = find_something() then
    item:do_stuff()
  end

With `item` being local to the if scope, and not polluting the wider
block. So effectively it translates to this

  begin
    local item = find_something()
    if item then
      item:do_stuff()
    end
  end

Could probably do with it in while loops too.

Seems to flow with the for loop syntax, so not that wild an idea :)

Scott

Reply | Threaded
Open this post in threaded view
|

Re: new thought experiment: what would you add to Lua ?

Oliver Kroth


Am 26.09.2018 um 17:46 schrieb Scott Morgan:

> On 14/09/2018 20:57, Jim wrote:
> Some sugar maybe but something along the lines of:
>
>    if item = find_something() then
>      item:do_stuff()
>    end
>
> With `item` being local to the if scope, and not polluting the wider
> block. So effectively it translates to this
>
>    begin
>      local item = find_something()
>      if item then
>        item:do_stuff()
>      end
>    end
>
> Could probably do with it in while loops too.
>
> Seems to flow with the for loop syntax, so not that wild an idea :)
>
> Scott
>
Hmmm.

To me this is to close to the = vs == discussion in Languages like C,
JavaScript, etc.
It is for a reason that in Lua an assignment is not legal in an expression.

What about:
when( find_something() ):do_stuff()

with when() being a function that returns the parameter or a table with
a do_stuff method without effect?
local function when( this ) return this or { do_stuff = function() end } end

For arbitrary do_stuff()s metatable's __index is your friend...

--
Oliver

Reply | Threaded
Open this post in threaded view
|

Re: new thought experiment: what would you add to Lua ?

Xavier Wang
In reply to this post by Jim
I hope Lua could add #line support, just as this:

local M = {}
::line("test.lua", 10)::
-- generated lua code ...
::line(current, 4)::
-- other code...

It will much help for code generating in Lua.
Jim <[hidden email]> 于2018年9月15日周六 上午3:58写道:
>
> i would add support for binary and octal integer literals like
> 0b1001011 or 0o0755 as in Python and Ruby.
>
> octal integer literals are helpful when working with unix (file)
> modes/permissions (which i do frequently).
>


--
regards,
Xavier Wang.

123