Feature request: names for constants

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

Feature request: names for constants

Dirk Laurie-2
Consider the following code:

local trim_pattern = "^%s*(.*%S)%s*$"

This pattern has been carefully debugged to do what I want
(remove leading and trailing blanks and return nil if there is
nothing else on the line). It looks very much like other patterns
also used in my application, lots of magic characters and not
much else, obscure unless carefully dissected. I give it a name
to make my program readable. I have no intention of ever
changing the value of trim_pattern.

When processed by `luac -l -l -p`, the result is

0+ params, 2 slots, 1 upvalue, 1 local, 1 constant, 0 functions
    1    [1]    LOADK        0 -1    ; "^%s*(.*%S)%s*$"
    2    [1]    RETURN       0 1
constants (1) for 0x2097840:
    1    "^%s*(.*%S)%s*$"
locals (1) for 0x2097840:
    0    trim_pattern    2    3
upvalues (1) for 0x2097840:
    0    _ENV    1    0

I.e. one local as well as one constant gets used up.

There is no need to use up a local: the value sits among the
constants anyway. The proposal is that

const trim_pattern = "^%s*(.*%S)%s*$"

should give:

0+ params, 1 slot, 1 upvalue, 0 locals, 1 constant, 0 functions
    1    [1]    RETURN       0 1
constants (1) for 0x2097840:
    1    "^%s*(.*%S)%s*$"   trim_pattern
upvalues (1) for 0x2097840:
    0    _ENV    1    0

Details:

1. New keyword const.
2. Syntax as for local, except that initialization is not optional.
3. Visibility from the line where it is declared to the end of the function.
4. Name must not equal that of any local variable in the function
or of an upvalue already referred to.
5. The use of a constant defined in a containing block implies the
creation of a new constant of the same name in this function.

Reply | Threaded
Open this post in threaded view
|

Re: Feature request: names for constants

Ignacio Burgueño-2
Point 5 is to localize access to the upvalue or is it needed for something else?​

Also, would you forbid subsequent assignments?
Reply | Threaded
Open this post in threaded view
|

Re: Feature request: names for constants

Luiz Henrique de Figueiredo
In reply to this post by Dirk Laurie-2
> local trim_pattern = "^%s*(.*%S)%s*$"

This already does exactly what you want.

The only cost is one local and one instruction, which get executed only once,
unless you have this inside a loop (in which case, you may move it out).

Almost all instructions in the Lua VM accept a register or a constant.
The few that don't but could are:

OP_SETUPVAL
        local x; function f() x=2 end

OP_UNM
        x=-"2"
        x=-true
OP_BNOT
        x=~"2"
        x=-true
OP_LEN
        x=#2
        x=#"hello"

It appears that none of these are at all common, except perhaps OP_SETUPVAL,
and OP_LEN for string constants.

Bottom line: there isn't a problem that needs to be solved by adding a syntax
for constants. The parser might be smart and use the constant's index instead
of the local's index, but they are both just an array access in the VM.

Reply | Threaded
Open this post in threaded view
|

Bad uses of patterns (was: Re: Feature request: names for constants)

Soni "They/Them" L.
In reply to this post by Dirk Laurie-2


On 24/09/15 12:39 PM, Dirk Laurie wrote:
> Consider the following code:
>
> local trim_pattern = "^%s*(.*%S)%s*$"
>
Wouldn't it be faster if you trimmed at start, reversed, then trimmed at
start again? (or maybe at start, then at end?)

--
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: Bad uses of patterns (was: Re: Feature request: names for constants)

Tim Hill

> On Sep 24, 2015, at 9:45 AM, Soni L. <[hidden email]> wrote:
>
>
>
> On 24/09/15 12:39 PM, Dirk Laurie wrote:
>> Consider the following code:
>>
>> local trim_pattern = "^%s*(.*%S)%s*$"
>>
> Wouldn't it be faster if you trimmed at start, reversed, then trimmed at start again? (or maybe at start, then at end?)
>
> --
> 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.
>
>

It would be faster (by a wide margin) to have a C function do it.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: Bad uses of patterns (was: Re: Feature request: names for constants)

Sean Conner
In reply to this post by Soni "They/Them" L.
It was thus said that the Great Soni L. once stated:
>
>
> On 24/09/15 12:39 PM, Dirk Laurie wrote:
> >Consider the following code:
> >
> >local trim_pattern = "^%s*(.*%S)%s*$"
> >
> Wouldn't it be faster if you trimmed at start, reversed, then trimmed at
> start again? (or maybe at start, then at end?)

  I think the fastest was is mentioned in this posting back in 2009:

http://lua-users.org/lists/lua-l/2009-12/msg00951.html 

but you can check the entire thread starting from:

http://lua-users.org/lists/lua-l/2009-12/msg00877.html

  -spc (I'll take Past Topics for $200, Alex!)


Reply | Threaded
Open this post in threaded view
|

Re: Feature request: names for constants

Brigham Toskin
In reply to this post by Luiz Henrique de Figueiredo
On Thu, Sep 24, 2015 at 9:11 AM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
This already does exactly what you want.
...
Bottom line: there isn't a problem that needs to be solved by adding a syntax
for constants. The parser might be smart and use the constant's index instead
of the local's index, but they are both just an array access in the VM.

A local has different semantics than a true const, though; a local can be reassigned, whereas a name is bound immutably for the lifetime of the reference, for a const. It represents a compiler-enforced safeguard against certain kinds of bugs, and adds meta-semantic information about programmer intention for subsequent readers of your code.

I'll let y'all decide if those are worth the effort and added complexity of extending the core language, but a "smart enough" compiler doesn't provide some of the user-facing benefits as true constants.

--
Brigham Toskin