explicit mode

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

explicit mode

Viacheslav Usov
I would guess this must have been discussed, so pointers to prior discussions will be appreciated.

Still: what speaks against implementing a new Lua compilation mode where everything must be explicitly declared to be either local or global, and anything not so declared would result in a compilation error?

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

steve donovan
On Tue, May 10, 2016 at 3:27 PM, Viacheslav Usov <[hidden email]> wrote:
> Still: what speaks against implementing a new Lua compilation mode where
> everything must be explicitly declared to be either local or global, and
> anything not so declared would result in a compilation error?

Ah, but if it isn't backward-compatible, there's the inevitable
problem...I suppose we've all learned not to rely on modules exporting
globals, then 'error on global set/get' is not unreasonable.

That being said, static checkers like luacheck or lglob are pretty
good at finding these kinds of errors...

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Viacheslav Usov
On Tue, May 10, 2016 at 3:34 PM, steve donovan <[hidden email]> wrote:
On Tue, May 10, 2016 at 3:27 PM, Viacheslav Usov <[hidden email]> wrote:
> Still: what speaks against implementing a new Lua compilation mode where
> everything must be explicitly declared to be either local or global, and
> anything not so declared would result in a compilation error?

Ah, but if it isn't backward-compatible, there's the inevitable
problem...


We will need some new syntax, invalid today, which will mean "past this line, globals must be explicit". Because it is invalid today, it will not break any existing code.

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Ulrich Schmidt

Am 10.05.2016 um 15:58 schrieb Viacheslav Usov:

> On Tue, May 10, 2016 at 3:34 PM, steve donovan
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On Tue, May 10, 2016 at 3:27 PM, Viacheslav Usov <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     > Still: what speaks against implementing a new Lua compilation mode
>     where
>     > everything must be explicitly declared to be either local or
>     global, and
>     > anything not so declared would result in a compilation error?
>
>     Ah, but if it isn't backward-compatible, there's the inevitable
>     problem...
>
>
>
> We will need some new syntax, invalid today, which will mean "past this
> line, globals must be explicit". Because it is invalid today, it will
> not break any existing code.
>
> Cheers,
> V.
>

Meanwhile i like the untyped parameters. If i want variable parameters,
I throw the values in a table with named fields and hand over the table
to the subroutine. If i need to check the custom type of a value i use
oop/classes and check the class type. - works great and is much more
flexible than strict typing.

If i would need strict typing, i would use a different language.
It took some time to get familiar with the lua philosophy, but meanwhile
i like it. And i like the very conservative way, Roberto implement new
features - even he throw away my wishes. ;P

Ulrich.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Viacheslav Usov
On Tue, May 10, 2016 at 4:21 PM, Ulrich Schmidt <[hidden email]> wrote:

> Meanwhile i like the untyped parameters.

> If i would need strict typing, i would use a different language.

I do not see how this is relevant. My question was not about types.

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Luiz Henrique de Figueiredo
In reply to this post by Viacheslav Usov
> I would guess this must have been discussed, so pointers to prior
> discussions will be appreciated.

See http://lua-users.org/lists/lua-l/2011-09/msg00684.html .

For a tool, see http://lua-users.org/lists/lua-l/2012-12/msg00397.html .

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Ulrich Schmidt
In reply to this post by Viacheslav Usov


Am 10.05.2016 um 16:25 schrieb Viacheslav Usov:
>
> I do not see how this is relevant. My question was not about types.
>
My fault.
You are sure, you need a new compile mode? Why not simply use strict.lua
to find unwanted globals?
> Cheers,
> V.
>
Ulrich.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Viacheslav Usov
On Tue, May 10, 2016 at 4:32 PM, Ulrich Schmidt <[hidden email]> wrote:

> You are sure, you need a new compile mode? Why not simply use strict.lua to find unwanted globals?

I do not mean to be offensive here, yet I think you need to re-read my question more carefully. I asked "what speaks against". I want to understand what reasons we really have for not having that mode.

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Viacheslav Usov
In reply to this post by Luiz Henrique de Figueiredo
On Tue, May 10, 2016 at 4:31 PM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> I would guess this must have been discussed, so pointers to prior
> discussions will be appreciated.

See http://lua-users.org/lists/lua-l/2011-09/msg00684.html .

Thank you. However, I have not found in that and referenced threads any explanation at all why such a mode cannot be part of the language. Have I missed something obvious?

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Chris Berardi-2

On May 10, 2016, at 10:45 AM, Viacheslav Usov <[hidden email]> wrote:

On Tue, May 10, 2016 at 4:31 PM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> I would guess this must have been discussed, so pointers to prior
> discussions will be appreciated.

See http://lua-users.org/lists/lua-l/2011-09/msg00684.html .

Thank you. However, I have not found in that and referenced threads any explanation at all why such a mode cannot be part of the language. Have I missed something obvious?

Cheers,
V.


Are you looking for technical reasons or explanations why it may not be in keeping with the general philosophy of the language?
Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Viacheslav Usov
On Tue, May 10, 2016 at 4:54 PM, Chris Berardi <[hidden email]> wrote:

> Are you looking for technical reasons or explanations why it may not be in keeping with the general philosophy of the language?

Let's put it this way: I am looking for some major reasons why it is not there. I know that technically it can be implemented, so that must be philosophical, but I also know that major technical difficulties cannot be ignored.

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Michal Kottman-2
On 10 May 2016 at 16:58, Viacheslav Usov <[hidden email]> wrote:
>
> On Tue, May 10, 2016 at 4:54 PM, Chris Berardi <[hidden email]> wrote:
>
> > Are you looking for technical reasons or explanations why it may not be in keeping with the general philosophy of the language?
>
> Let's put it this way: I am looking for some major reasons why it is not there. I know that technically it can be implemented, so that must be philosophical, but I also know that major technical difficulties cannot be ignored.

The main philosophical reason of not having it as part of the language is the philosophy of Lua itself, as written nicely in the book Programming in Lua: "Usually, Lua does not set policies. Instead, Lua provides mechanisms that are powerful enough for groups of developers to implement the policies that best suit them." (http://www.inf.puc-rio.br/~roberto/pil2/chapter15.pdf)

The "mechanism" for your "policy" is strict.lua or any other implementation thereof. If you really really need it to be part of the language, feel free to fork (and rename) your Lua implementation, as has been done with RiscLua [1] (short function syntactic sugar, etc.), Ravi [2] (adding static typing), or just create a language that compiles to Lua like Moonscript [3].

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Dirk Laurie-2
In reply to this post by Viacheslav Usov
2016-05-10 16:58 GMT+02:00 Viacheslav Usov <[hidden email]>:

> Let's put it this way: I am looking for some major reasons why it is not
> there. I know that technically it can be implemented, so that must be
> philosophical, but I also know that major technical difficulties cannot be
> ignored.

This is like asking a famous chef: Is there a major reason why there
is no eggplant in your Casserole à la Maison? I know you have it
available in the kitchen, since your Ratatouille Provençal does
include eggplant, so your reason must be philosophical.

And the chef might answer: I like my Casserole à la Maison the way
it is. If you want eggplant, please order the Ratatouille Provençal.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Viacheslav Usov
In reply to this post by Michal Kottman-2
On Tue, May 10, 2016 at 5:54 PM, Michal Kottman <[hidden email]> wrote:

> The "mechanism" for your "policy" is strict.lua or any other implementation thereof.

Not really.

My policy is to guarantee that there are no problems related to mistyped identifiers. Not just this time I run my program, but every time I run it.

As far as I can tell, I cannot represent that as a user-defined "policy", so your justification is not valid.

I know that I could achieve that by using a language different from Lua. But I'd like to achieve that in Lua, and so I want to to understand why it is not possible.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Sean Conner
In reply to this post by Viacheslav Usov
It was thus said that the Great Viacheslav Usov once stated:
> I would guess this must have been discussed, so pointers to prior
> discussions will be appreciated.
>
> Still: what speaks against implementing a new Lua compilation mode where
> everything must be explicitly declared to be either local or global, and
> anything not so declared would result in a compilation error?

  The major stumbling block I see is how to declare globals.  There already
exists explicit syntax to declare locals but no explicit syntax to declare
globals.  Things like "strict.lua" exist to hack around this limitation, and
some might say this does exactly what you want (or close enough to it).

  Something else that speaks out against this:  a change in syntax, either a
new keyword, which may clash with existing code or operator,which can cause
problems in compiling code that doesn't understand it---I have had this
issue with multi version code:

        if _VERSION == "Lua 5.3" then
          function bor(a,b) return a | b end
        elseif _VERSION == "Lua 5.2" then
          bor = bit32.bor
        else
          function bor(a,b) return a + b end
        end

won't work as intended in Lua 5.1 or 5.2 because of the new | operator in
Lua 5.3.  This may not be an issue for you, but for other people, it may be.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Soni "They/Them" L.
In reply to this post by Viacheslav Usov


On 10/05/16 01:44 PM, Viacheslav Usov wrote:

> On Tue, May 10, 2016 at 5:54 PM, Michal Kottman
> <[hidden email] <mailto:[hidden email]>> wrote:
>
> > The "mechanism" for your "policy" is strict.lua or any other
> implementation thereof.
>
> Not really.
>
> My policy is to guarantee that there are /no/ problems related to
> mistyped identifiers. Not just /this/ time I run my program, but
> /every/ time I run it.
>
> As far as I can tell, I /cannot/ represent that as a user-defined
> "policy", so your justification is not valid.
>
> I know that I could achieve that by using a language /different /from
> Lua. But I'd like to achieve that in Lua, and so I want to to
> understand why it is not possible.
>
> Cheers,
> V.
So in other words you want explicit upvalue syntax? Upvalues as part of
function signatures? Yeah me too! But I want it with defined order so my
loadx lib[1] becomes more useful.

[1]: https://github.com/SoniEx2/loadx

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Sean Conner
In reply to this post by Viacheslav Usov
It was thus said that the Great Viacheslav Usov once stated:

> On Tue, May 10, 2016 at 5:54 PM, Michal Kottman <[hidden email]>
> wrote:
>
> > The "mechanism" for your "policy" is strict.lua or any other
> implementation thereof.
>
> Not really.
>
> My policy is to guarantee that there are *no* problems related to mistyped
> identifiers. Not just *this* time I run my program, but *every* time I run
> it.

  The stock Lua interpeter checks for the environment variable LUA_INIT (and
LUA_INIT_5_2 or LUA_INIT_5_3) and will run that (or the file given) before
anything else.  There you can run "strict.lua" to ensure your given policy
exists.

> I know that I could achieve that by using a language *different *from Lua.
> But I'd like to achieve that in Lua, and so I want to to understand why it
> is not possible.

  Technically, it is possible.  Would it still be Lua?  Depends on how it's
done.  

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Viacheslav Usov
In reply to this post by Dirk Laurie-2
On Tue, May 10, 2016 at 6:32 PM, Dirk Laurie <[hidden email]> wrote:

> This is like asking a famous chef

If you use Lua for fun, that might be a valid comparison.

I use Lua to get things done. So in my case the comparison would be more like asking the manager of my plant's canteen: is there a major reason our plant needs to suffer from massive outbursts of profuse diarrhea every so often? Why can't we have basic food safety measures in place?

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Ulrich Schmidt
In reply to this post by Viacheslav Usov

Am 10.05.2016 um 18:44 schrieb Viacheslav Usov:

> On Tue, May 10, 2016 at 5:54 PM, Michal Kottman
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>> The "mechanism" for your "policy" is strict.lua or any other
> implementation thereof.
>
> Not really.
>
> My policy is to guarantee that there are /no/ problems related to
> mistyped identifiers. Not just /this/ time I run my program, but
> /every/ time I run it.

I understand your wish for development time. That's what strict.lua is for.
When i ship my final program, i want to avoid any unnecessary checks for
speed reasons. In case the final program may execute untested lua
scripts, i use a sandbox environment for the untrusted script. So from
my point of view, i cant understand what you want to make better with
some new compiling mode. It does not make code execution faster, and
much more worse, my program may error out, what should not happen on a
user site.
Let's stick on the KISS principle. :)

Ulrich.

Reply | Threaded
Open this post in threaded view
|

Re: explicit mode

Sean Conner
In reply to this post by Soni "They/Them" L.
It was thus said that the Great Soni L. once stated:

>
>
> On 10/05/16 01:44 PM, Viacheslav Usov wrote:
> >On Tue, May 10, 2016 at 5:54 PM, Michal Kottman
> ><[hidden email] <mailto:[hidden email]>> wrote:
> >
> >> The "mechanism" for your "policy" is strict.lua or any other
> >implementation thereof.
> >
> >Not really.
> >
> >My policy is to guarantee that there are /no/ problems related to
> >mistyped identifiers. Not just /this/ time I run my program, but
> >/every/ time I run it.
> >
> >As far as I can tell, I /cannot/ represent that as a user-defined
> >"policy", so your justification is not valid.
> >
> >I know that I could achieve that by using a language /different /from
> >Lua. But I'd like to achieve that in Lua, and so I want to to
> >understand why it is not possible.
> >
> >Cheers,
> >V.
> So in other words you want explicit upvalue syntax? Upvalues as part of
> function signatures? Yeah me too! But I want it with defined order so my
> loadx lib[1] becomes more useful.

  I think he wants something like:

        global x -- define a global x
        function foo(a,b)
          local c -- define a local variable
          c = a * b + y -- compile time error---y not defined
        end

  To me, upvalues as part of a function signature reminds me of making
exceptions part of the function signature in Java---it may be a nice idea to
be explicit about such things, but it gets annoying quite fast (and you get
aorund it by subclassing RuntypeException).  It would also seem to be
repeating yourself in code quite often.

  -spc



123