A thought about <const>

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

A thought about <const>

Dibyendu Majumdar
I am not sure of the usefulness of the proposed <const> qualifier, but
it got me thinking whether it might be possible to implement compile
time named constants using similar annotations. That is to say the
code would be equivalent to writing directly using literals.

Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Coda Highland
On Mon, Jun 10, 2019 at 2:49 PM Dibyendu Majumdar <[hidden email]> wrote:
I am not sure of the usefulness of the proposed <const> qualifier, but
it got me thinking whether it might be possible to implement compile
time named constants using similar annotations. That is to say the
code would be equivalent to writing directly using literals.

I certainly agree that compile-time named constants would be a nice thing to have, but I'm not 100% sure if it would have a measurable impact, because upvalues are also resolved at compile-time and you still have to push the value on the stack anyway. There's also not really a good way for modules to export compile-time named constants, which puts a significant limitation on how useful they are.

However, non-assignable variables are pretty useful. There are some compiler optimizations that can happen when you know a variable is read-only, and of course asserting that something is read-only can help avoid programming mistakes.

There's also no real reason the same qualifier couldn't be used for both. It would just be part of the optimization: if a compiler can statically determine the value of an expression, it can replace it with the result of that expression, and being read-only and initialized with a literal is a good way to ensure that the value can be statically determined.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Dibyendu Majumdar
On Mon, 10 Jun 2019 at 21:21, Coda Highland <[hidden email]> wrote:
>> I am not sure of the usefulness of the proposed <const> qualifier, but
>> it got me thinking whether it might be possible to implement compile
>> time named constants using similar annotations. That is to say the
>> code would be equivalent to writing directly using literals.
>
>
> I certainly agree that compile-time named constants would be a nice thing to have, but I'm not 100% sure if it would have a measurable impact, because upvalues are also resolved at compile-time and you still have to push the value on the stack anyway. There's also not really a good way for modules to export compile-time named constants, which puts a significant limitation on how useful they are.
>

True.

> However, non-assignable variables are pretty useful. There are some compiler optimizations that can happen when you know a variable is read-only, and of course asserting that something is read-only can help avoid programming mistakes.
>
> There's also no real reason the same qualifier couldn't be used for both. It would just be part of the optimization: if a compiler can statically determine the value of an expression, it can replace it with the result of that expression, and being read-only and initialized with a literal is a good way to ensure that the value can be statically determined.
>

Which leads me to a second thought about the syntax.
If you wanted to declare a bunch of constants in one go, it might be
nicer to be able to do it with a single annotation, rather than per
variable annotation.

Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Coda Highland
On Mon, Jun 10, 2019 at 3:27 PM Dibyendu Majumdar <[hidden email]> wrote:
On Mon, 10 Jun 2019 at 21:21, Coda Highland <[hidden email]> wrote:
> However, non-assignable variables are pretty useful. There are some compiler optimizations that can happen when you know a variable is read-only, and of course asserting that something is read-only can help avoid programming mistakes.
>
> There's also no real reason the same qualifier couldn't be used for both. It would just be part of the optimization: if a compiler can statically determine the value of an expression, it can replace it with the result of that expression, and being read-only and initialized with a literal is a good way to ensure that the value can be statically determined.
>

Which leads me to a second thought about the syntax.
If you wanted to declare a bunch of constants in one go, it might be
nicer to be able to do it with a single annotation, rather than per
variable annotation.

As I mentioned in the other thread, that's sort of getting into bikeshedding. Yes, it would be nice to be able to do that, but on the other hand it would also be nice to specify a mixed set of annotations in a single statement instead of needing a separate statement for each type of annotation. Roberto had asked you how you intended to resolve that in that thread.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Dibyendu Majumdar
On Mon, 10 Jun 2019 at 21:31, Coda Highland <[hidden email]> wrote:

> Roberto had asked you how you intended to resolve that in that thread.
>

I think Roberto asked Hisham as he quoted Hisham's original message.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Coda Highland


On Mon, Jun 10, 2019 at 3:40 PM Dibyendu Majumdar <[hidden email]> wrote:
On Mon, 10 Jun 2019 at 21:31, Coda Highland <[hidden email]> wrote:

> Roberto had asked you how you intended to resolve that in that thread.
>

I think Roberto asked Hisham as he quoted Hisham's original message.


Oh, oops. You're right. He called you out by name, but he was reiterating your question instead of asking you.

Question does still stand, though. How? :P

/s/ Adam 
Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Dibyendu Majumdar
On Mon, 10 Jun 2019 at 21:42, Coda Highland <[hidden email]> wrote:
> Question does still stand, though. How? :P
>

Perhaps best to leave that question for the other thread - I didn't
mean to start a parallel conversation.

I was exploring the idea of compile time named constants here.
As you said not being able to export them is probably what kills their
usefulness.

Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

David Heiko Kolf-2
In reply to this post by Coda Highland
Coda Highland wrote:
> However, non-assignable variables are pretty useful. There are some
> compiler optimizations that can happen when you know a variable is
> read-only, and of course asserting that something is read-only can help
> avoid programming mistakes.

This point currently raises some questions for me. I appreciate const
statements in an API, as they clearly document that a variable or a
parameter will not be changed.

However, in Lua locals are (as the name says) already limited to a
single file so they are not part of an API and any compiler looking at
the file could already see that it is only assigned once even without a
const statement.

So I get the impression that the proposed const statement adds very little.

I would actually prefer if the const statement is not added to Lua, as
the use cases of const and toclose would at least for me be completely
different:

E.g. I like to copy multiple dependency functions to constants at the
beginning of my libraries:

  local strsub, strrep, gmatch, strformat =
    string.sub, string.rep, string.gmatch, string.format
  local _ENV = nil

But I need a non-scoped error message:

  local <toclose> f, err = io.open("demo.txt")

Or do I miss some significant use case of a local const statement in Lua?

Best regards,

David

Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Coda Highland


On Tue, Jun 11, 2019 at 1:10 PM David Heiko Kolf <[hidden email]> wrote:
Coda Highland wrote:
> However, non-assignable variables are pretty useful. There are some
> compiler optimizations that can happen when you know a variable is
> read-only, and of course asserting that something is read-only can help
> avoid programming mistakes.

This point currently raises some questions for me. I appreciate const
statements in an API, as they clearly document that a variable or a
parameter will not be changed.

However, in Lua locals are (as the name says) already limited to a
single file so they are not part of an API and any compiler looking at
the file could already see that it is only assigned once even without a
const statement.

So I get the impression that the proposed const statement adds very little.

I would actually prefer if the const statement is not added to Lua, as
the use cases of const and toclose would at least for me be completely
different:

E.g. I like to copy multiple dependency functions to constants at the
beginning of my libraries:

  local strsub, strrep, gmatch, strformat =
    string.sub, string.rep, string.gmatch, string.format
  local _ENV = nil

But I need a non-scoped error message:

  local <toclose> f, err = io.open("demo.txt")

Or do I miss some significant use case of a local const statement in Lua?

Best regards,

David


toclose must be const, because if you want to ensure __close is called as demanded by the contract then that means you can't change out the contents of that variable.

But beyond that, the use cases of const and toclose ARE completely different.

You use a const local to make sure you don't accidentally overwrite something. It's a matter of code hygiene. Modern JS programmers use it all the time because it helps you avoid (or if you've failed to avoid it, track down) accidentally changing out a value or reference that you need.

Can you write correct software without const locals? Of course you can. Is this a game-changing feature that's going to impact how everyone writes Lua code? No, it's not. You can still use Lua 5.4 without ever touching <const>. But since it's a feature that needed to be introduced to support <toclose>, there's no reason NOT to expose it to other uses as well, for the people who do want to make use of it.

As an aside, it also enables the possibility of some optimizations. I don't know if Lua is going to incorporate those right away, but when you can be certain that something isn't going to change, the compiler can make better decisions about how to generate code around it.

/s/ Adam


Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

David Heiko Kolf-2
Coda Highland wrote:
> Can you write correct software without const locals? Of course you can.
> Is this a game-changing feature that's going to impact how everyone
> writes Lua code? No, it's not. You can still use Lua 5.4 without ever
> touching <const>. But since it's a feature that needed to be introduced
> to support <toclose>, there's no reason NOT to expose it to other uses
> as well, for the people who do want to make use of it.

I do see a reason not to expose it: to keep the core language as plain
as possible.

If constant variables are desired, I would wish for a language feature
specifically designed for them and not just some by-product of another
feature.

As Egor Skriptunoff already wrote in a separate thread, what would be
really useful would be constant global variables and table entries.

If I mess up a local variable the error would probably be rather local,
too. If I mess up a global variable (e.g. math.pi = 4) I create an error
in some random module.

So I got the impression that a new language feature is added just
because it appears to be "cheap" but in this case it reminds me of the
sentence "you've caught the kitten and let the cat escape".

Best regards,

David

Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Coda Highland


On Wed, Jun 12, 2019 at 12:46 PM David Heiko Kolf <[hidden email]> wrote:
Coda Highland wrote:
> Can you write correct software without const locals? Of course you can.
> Is this a game-changing feature that's going to impact how everyone
> writes Lua code? No, it's not. You can still use Lua 5.4 without ever
> touching <const>. But since it's a feature that needed to be introduced
> to support <toclose>, there's no reason NOT to expose it to other uses
> as well, for the people who do want to make use of it.

I do see a reason not to expose it: to keep the core language as plain
as possible.

If constant variables are desired, I would wish for a language feature
specifically designed for them and not just some by-product of another
feature.

As Egor Skriptunoff already wrote in a separate thread, what would be
really useful would be constant global variables and table entries.

If I mess up a local variable the error would probably be rather local,
too. If I mess up a global variable (e.g. math.pi = 4) I create an error
in some random module.

So I got the impression that a new language feature is added just
because it appears to be "cheap" but in this case it reminds me of the
sentence "you've caught the kitten and let the cat escape".

Best regards,

David


That's a fair enough argument. However, in this case, it really IS cheap, in every sense. Not only does it require minimal effort to provide it, but it requires no additional cognitive effort on the user's part, it has no impact on the syntax of the language, and its semantic impact is wholly contained within its scope of use.

If this were C++-style const, where constness is a first-class element of the type system, then that would be different. Introducing it would have far-reaching repercussions that would require everyone to pay attention if it's used anywhere.

If it required introducing a new reserved word or new syntax, that would have had a cost. But because <toclose> was already committed to, <const> doesn't add any new syntactic requirements, and the annotation syntax is unambiguous existing structures and allows for additional annotation types to be added without introducing new limitations on user code.

So it really is a trivial thing to add with no drawbacks that I can see.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Sean Conner
It was thus said that the Great Coda Highland once stated:

>
> That's a fair enough argument. However, in this case, it really IS cheap,
> in every sense. Not only does it require minimal effort to provide it, but
> it requires no additional cognitive effort on the user's part, it has no
> impact on the syntax of the language, and its semantic impact is wholly
> contained within its scope of use.
>
> If this were C++-style const, where constness is a first-class element of
> the type system, then that would be different. Introducing it would have
> far-reaching repercussions that would require everyone to pay attention if
> it's used anywhere.
>
> If it required introducing a new reserved word or new syntax, that would
> have had a cost. But because <toclose> was already committed to, <const>
> doesn't add any new syntactic requirements, and the annotation syntax is
> unambiguous existing structures and allows for additional annotation types
> to be added without introducing new limitations on user code.
>
> So it really is a trivial thing to add with no drawbacks that I can see.

  The only downside I see is that it marks the *variable* as constant, not
the *value*.  For everything aide from tables, there's no difference.  But
it might be surprising behavior for tables.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Coda Highland


On Wed, Jun 12, 2019 at 4:40 PM Sean Conner <[hidden email]> wrote:
It was thus said that the Great Coda Highland once stated:
>
> That's a fair enough argument. However, in this case, it really IS cheap,
> in every sense. Not only does it require minimal effort to provide it, but
> it requires no additional cognitive effort on the user's part, it has no
> impact on the syntax of the language, and its semantic impact is wholly
> contained within its scope of use.
>
> If this were C++-style const, where constness is a first-class element of
> the type system, then that would be different. Introducing it would have
> far-reaching repercussions that would require everyone to pay attention if
> it's used anywhere.
>
> If it required introducing a new reserved word or new syntax, that would
> have had a cost. But because <toclose> was already committed to, <const>
> doesn't add any new syntactic requirements, and the annotation syntax is
> unambiguous existing structures and allows for additional annotation types
> to be added without introducing new limitations on user code.
>
> So it really is a trivial thing to add with no drawbacks that I can see.

  The only downside I see is that it marks the *variable* as constant, not
the *value*.  For everything aide from tables, there's no difference.  But
it might be surprising behavior for tables.

  -spc


While this is true, it's got precedent. Javascript const works the same way, as does Java final.

/s/ Adam 
Reply | Threaded
Open this post in threaded view
|

Re: A thought about <const>

Sergey Kovalev
In reply to this post by Dibyendu Majumdar
function const(c)
    return setmetatable({},{__index=c,
        __newindex=function(t,n,v) error "read only" end
    })
end

local my = const { pi=3.14, e=2.71 }
print(my.pi,my.e)
my.pi=3 -- error

пн, 10 июн. 2019 г. в 23:27, Dibyendu Majumdar <[hidden email]>:

>
> On Mon, 10 Jun 2019 at 21:21, Coda Highland <[hidden email]> wrote:
> >> I am not sure of the usefulness of the proposed <const> qualifier, but
> >> it got me thinking whether it might be possible to implement compile
> >> time named constants using similar annotations. That is to say the
> >> code would be equivalent to writing directly using literals.
> >
> >
> > I certainly agree that compile-time named constants would be a nice thing to have, but I'm not 100% sure if it would have a measurable impact, because upvalues are also resolved at compile-time and you still have to push the value on the stack anyway. There's also not really a good way for modules to export compile-time named constants, which puts a significant limitation on how useful they are.
> >
>
> True.
>
> > However, non-assignable variables are pretty useful. There are some compiler optimizations that can happen when you know a variable is read-only, and of course asserting that something is read-only can help avoid programming mistakes.
> >
> > There's also no real reason the same qualifier couldn't be used for both. It would just be part of the optimization: if a compiler can statically determine the value of an expression, it can replace it with the result of that expression, and being read-only and initialized with a literal is a good way to ensure that the value can be statically determined.
> >
>
> Which leads me to a second thought about the syntax.
> If you wanted to declare a bunch of constants in one go, it might be
> nicer to be able to do it with a single annotation, rather than per
> variable annotation.
>