Syntactical ugliness - does it matter?

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

Re: Syntactical ugliness - does it matter?

Sean Conner
It was thus said that the Great Dibyendu Majumdar once stated:

>
> But more interestingly suppose you have a user defined type where the
> metatable has been registered. Suppose that the name under which you
> have registered the metatable is 'Torch.Tensor'.
>
> Then you can write:
>
> local x: Torch.Tensor = ...
> function Foo (x: Torch.Tensor)
> end

  Interesting.  Can you handle the case where the user defined type has more
than just letters, digits and periods?  I ask because I also use colons in
my user defined types,  such as:

        org.conman.net:addr
        org.conman.net:sock

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Andrew Gierth
In reply to this post by Oliver Kroth
>>>>> "Oliver" == Oliver Kroth <[hidden email]> writes:

 Oliver> Hi,
 Oliver> I know that the approach is off-center; intentionally.
 Oliver> I wrote that there is a trick to transport an intent together
 Oliver> with the value returned by the function.

But that's a run-time thing, whereas whether a variable is toclose or
constant must be known at compile time.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Andrew Gierth
In reply to this post by Egor Skriptunoff-2
>>>>> "Egor" == Egor Skriptunoff <[hidden email]> writes:

 Egor> I suggest to replace "toclose" and "__close" with more expressive
 Egor> words:
 Egor>    local <resource> x = setmetatable(obj, {__release = ...})

+1

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
In reply to this post by Sean Conner
On Tue, 4 Jun 2019 at 21:24, Sean Conner <[hidden email]> wrote:

>
> It was thus said that the Great Dibyendu Majumdar once stated:
> >
> > But more interestingly suppose you have a user defined type where the
> > metatable has been registered. Suppose that the name under which you
> > have registered the metatable is 'Torch.Tensor'.
> >
> > Then you can write:
> >
> > local x: Torch.Tensor = ...
> > function Foo (x: Torch.Tensor)
> > end
>
>   Interesting.  Can you handle the case where the user defined type has more
> than just letters, digits and periods?  I ask because I also use colons in
> my user defined types,  such as:
>
>         org.conman.net:addr
>         org.conman.net:sock
>

At the moment, no. Each period separated component must be a Name -
i.e. Lua identifier. So digits can appear within a name as per Lua
rules. But ':' is problematic as I allow cast operations such as:

local v = @Torch.Tensor SomeFuncReturningTensor()

You can imagine that ':' here would cause a problem - i.e. should it
be interpreted as a self operator?

The chosen syntax is easy to handle with Lua's existing lexer and
parser with some minor enhancements.

While this is off-topic it does bring again the issue of ambiguity when parsing.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Sean Conner
It was thus said that the Great Dibyendu Majumdar once stated:

> On Tue, 4 Jun 2019 at 21:24, Sean Conner <[hidden email]> wrote:
> >
> > It was thus said that the Great Dibyendu Majumdar once stated:
> > >
> > > But more interestingly suppose you have a user defined type where the
> > > metatable has been registered. Suppose that the name under which you
> > > have registered the metatable is 'Torch.Tensor'.
> > >
> > > Then you can write:
> > >
> > > local x: Torch.Tensor = ...
> > > function Foo (x: Torch.Tensor)
> > > end
> >
> >   Interesting.  Can you handle the case where the user defined type has more
> > than just letters, digits and periods?  I ask because I also use colons in
> > my user defined types,  such as:
> >
> >         org.conman.net:addr
> >         org.conman.net:sock
> >
>
> At the moment, no. Each period separated component must be a Name -
> i.e. Lua identifier. So digits can appear within a name as per Lua
> rules. But ':' is problematic as I allow cast operations such as:
>
> local v = @Torch.Tensor SomeFuncReturningTensor()
>
> You can imagine that ':' here would cause a problem - i.e. should it
> be interpreted as a self operator?
>
> The chosen syntax is easy to handle with Lua's existing lexer and
> parser with some minor enhancements.

  This even breaks with standard Lua, because of the following metatypes:

        FILE* defined by the Lua io module
        lpeg-pattern defined by LPEG

  I suppose you could do:

        local v = @['FILE*'] SomeFuncReturningFileObject()

given that foo.bar is syntactic surgar for foo['bar'].  

  -spc (Just a thought ...  )

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
In reply to this post by Egor Skriptunoff-2
On Tue, 4 Jun 2019 at 21:24, Egor Skriptunoff
<[hidden email]> wrote:
>
> I suggest to replace "toclose" and "__close" with more expressive words:
>    local <resource> x = setmetatable(obj, {__release = ...})
>

+1

Following would work too in my view:

local resource x = setmetatable(obj, {__release = ...})

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Ryan Ford-2
On Wed, 5 Jun 2019 11:26:55 +0100
Dibyendu Majumdar <[hidden email]> wrote:

> Following would work too in my view:
>
> local resource x = setmetatable(obj, {__release = ...})

I'm sure this would break the current syntax though as you would be initializing the local "resource" and assigning a new value to the global "x"

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

szbnwer@gmail.com
hi all! :)

Ryan Ford:
>  I'm sure this would break the current syntax though as you would be initializing the local "resource" and assigning a new value to the global "x"

if `resource` is a keyword, then it wont mess with anything, and no
new stuff will be usable in older versions, no matter what.
compatibility is not an issue as far as these wont actually replace
`local`. in that case, backward compatibility goes, otherwise thats
just a matter of not using these new stuffs. by replacing `local`,
that would mean 6.0 arrived.



btw this wasnt a vote for making it a keyword, only the `*toclose`
syntax creeped me to hell so far now. :D

otherwise i would think in something like `@{ ... }` or `&{ ... }` (or
whatever like), so we could hack around these with tables (but ive got
no much ideas about any usecases, take this only as a starting idea)
and the main meaning is that this binds to the "left hand side" (so
the var, but maybe(?) even `{@{...} 1, 2, @{...} 3, 4, @{...} x=1234}`
and `f(@{...} x)`).

looks ugly for me anyhow, no matter what... :D im in the group of
those, who think that 5.1 was ready for everything (maybe minor
polishing like allowing `'str':fun()`, `{}:fun()`, `#...`, `...[]`;
not trimming the paths in the backtraces; and internals could be
fine-tuned invisibly in case of anything to do there.)



somewhat off:
i only hope that backticks wont ever be used in lua, as plaintext
documentation (mostly comments :D ) wont have any nice delimiters for
code snippets, and they will become messy (like absence of any
notation), fatty (multi-char delimiters) and/or ugly...

bests! :)

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Matthew Wild
On Wed, 5 Jun 2019 at 12:53, [hidden email] <[hidden email]> wrote:
> Ryan Ford:
> >  I'm sure this would break the current syntax though as you would be initializing the local "resource" and assigning a new value to the global "x"
>
> if `resource` is a keyword, then it wont mess with anything, and no
> new stuff will be usable in older versions, no matter what.

As the maintainer of a >50k-line Lua codebase that extensively uses
local variables named "resource", I beg to differ with the "it won't
mess with anything" assertion.

It's easy to argue over the "ugliness" of the current alpha-rc1
syntax, but let's not forget that it has merits too.

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
On Wed, 5 Jun 2019 at 15:08, Matthew Wild <[hidden email]> wrote:

>
> On Wed, 5 Jun 2019 at 12:53, [hidden email] <[hidden email]> wrote:
> > Ryan Ford:
> > >  I'm sure this would break the current syntax though as you would be initializing the local "resource" and assigning a new value to the global "x"
> >
> > if `resource` is a keyword, then it wont mess with anything, and no
> > new stuff will be usable in older versions, no matter what.
>
> As the maintainer of a >50k-line Lua codebase that extensively uses
> local variables named "resource", I beg to differ with the "it won't
> mess with anything" assertion.
>

Hi as I already explained in a previous post, there is no need for a
new keyword.
The parsing of:

local <resource> x
local resource x

are the same - both utilize the fact that after local a variable name
is expected, so anything in between can be easily parsed especially if
they are just identifiers.
Hence the markers are superfluous - at least for the proposed extensions.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Coda Highland


On Wed, Jun 5, 2019 at 9:30 AM Dibyendu Majumdar <[hidden email]> wrote:
On Wed, 5 Jun 2019 at 15:08, Matthew Wild <[hidden email]> wrote:
>
> On Wed, 5 Jun 2019 at 12:53, [hidden email] <[hidden email]> wrote:
> > Ryan Ford:
> > >  I'm sure this would break the current syntax though as you would be initializing the local "resource" and assigning a new value to the global "x"
> >
> > if `resource` is a keyword, then it wont mess with anything, and no
> > new stuff will be usable in older versions, no matter what.
>
> As the maintainer of a >50k-line Lua codebase that extensively uses
> local variables named "resource", I beg to differ with the "it won't
> mess with anything" assertion.
>

Hi as I already explained in a previous post, there is no need for a
new keyword.
The parsing of:

local <resource> x
local resource x

are the same - both utilize the fact that after local a variable name
is expected, so anything in between can be easily parsed especially if
they are just identifiers.
Hence the markers are superfluous - at least for the proposed extensions.

Regards

It's not a problem when the proposed extension is around, but it does introduce inconsistencies with past versions of Lua, and there's still one grammatical ambiguity.

local resource
x = 3

Am I declaring a resource named x with the value of 3, or am I declaring a variable named resource with no initial value, and then setting an existing variable named x to 3?

Having some sort of signifier also greatly reduces the complexity of parsers and preprocessors, so I strongly oppose doing this without any sort of syntactic indication. I prefer @ over <> but there needs to be SOMETHING.

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

Re: Syntactical ugliness - does it matter?

Matthew Wild
In reply to this post by Dibyendu Majumdar
On Wed, 5 Jun 2019 at 15:30, Dibyendu Majumdar <[hidden email]> wrote:

>
> On Wed, 5 Jun 2019 at 15:08, Matthew Wild <[hidden email]> wrote:
> >
> > On Wed, 5 Jun 2019 at 12:53, [hidden email] <[hidden email]> wrote:
> > > Ryan Ford:
> > > >  I'm sure this would break the current syntax though as you would be initializing the local "resource" and assigning a new value to the global "x"
> > >
> > > if `resource` is a keyword, then it wont mess with anything, and no
> > > new stuff will be usable in older versions, no matter what.
> >
> > As the maintainer of a >50k-line Lua codebase that extensively uses
> > local variables named "resource", I beg to differ with the "it won't
> > mess with anything" assertion.
> >
>
> Hi as I already explained in a previous post, there is no need for a
> new keyword.
> The parsing of:
>
> local <resource> x
> local resource x
>
> are the same - both utilize the fact that after local a variable name
> is expected, so anything in between can be easily parsed especially if
> they are just identifiers.
> Hence the markers are superfluous - at least for the proposed extensions.

I don't see how the parser can determine whether I mean:

  local resource x = foo()

to be interpreted as
  local <toclose> x = foo()
or
  local resource; x = foo()

Regards,
Matthew

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
On Wed, 5 Jun 2019 at 15:35, Matthew Wild <[hidden email]> wrote:
>
>   local resource x = foo()
>
> to be interpreted as
>   local <toclose> x = foo()
> or
>   local resource; x = foo()
>

The former as the latter is impossible.
So if you say:

local resource = 0

Then resource is a variable.

But if you say:

local resource x = 0

Then x is a variable, and resource is a qualifier.

Does that make sense?

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

szbnwer@gmail.com
In reply to this post by Matthew Wild
Matthew Wild:
> As the maintainer of a >50k-line Lua codebase that extensively uses
local variables named "resource", I beg to differ with the "it won't
mess with anything" assertion.

lol, sure, thx for correcting me! :) i considered only language
compatibility, not legacy codes...

> It's easy to argue over the "ugliness" of the current alpha-rc1
syntax, but let's not forget that it has merits too.

sure too, actually i didnt even want to join in the lines of those who
made suggestions. just as i finally came around, i left here the idea,
cuz one of the beauties of lua is the harmony with itself that
generally gives nice possibilities. :) like the `_ENV` var brought
that one step nearer (just the harmony, but the functions for handling
env are just as flexible, i think), or as the `{}:fun()` would be in
harmony with `fun{}` without more confusion for the interpreter than
`a=b ({}):fun()` already have, so i just followed this line, without
thinking too much where could a `@{...}`-like beast lead, but that was
not about beauty, but possibilities... :)

btw even something like `<a_table>` could do the same trick (in case
of whatever need), just not that relevantly... otherwise maybe the
angle brackets are still the best in the name of beauty, but i was
more about harmony and possibilities, as maybe anyone could come up
with something in the name of usefulness. :)

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
In reply to this post by Coda Highland
On Wed, 5 Jun 2019 at 15:35, Coda Highland <[hidden email]> wrote:
> It's not a problem when the proposed extension is around, but it does introduce inconsistencies with past versions of Lua, and there's still one grammatical ambiguity.
>
> local resource
> x = 3
>
> Am I declaring a resource named x with the value of 3, or am I declaring a variable named resource with no initial value, and then setting an existing variable named x to 3?

Here you are declaring a variable named resource just as you would in
existing versions of Lua. I don't see an ambiguity.

>
> Having some sort of signifier also greatly reduces the complexity of parsers and preprocessors, so I strongly oppose doing this without any sort of syntactic indication. I prefer @ over <> but there needs to be SOMETHING.

Okay that is a different concern. Making a resource declaration ugly
and therefore visible is not necessarily a bad thing.

local @resource x

Makes it very visible.

But overuse of @ in a program can make it very hard to read.
Imagine

local @constant ...
a few times.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Matthew Wild
In reply to this post by Dibyendu Majumdar
On Wed, 5 Jun 2019 at 15:42, Dibyendu Majumdar <[hidden email]> wrote:
> But if you say:
>
> local resource x = 0
>
> Then x is a variable, and resource is a qualifier.
>
> Does that make sense?

No, because that's a valid statement in Lua 5.3 that means something
different. So my point stands: this proposal is a
backwards-incompatible change that affects existing code.

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
On Wed, 5 Jun 2019 at 15:47, Matthew Wild <[hidden email]> wrote:

>
> On Wed, 5 Jun 2019 at 15:42, Dibyendu Majumdar <[hidden email]> wrote:
> > But if you say:
> >
> > local resource x = 0
> >
> > Then x is a variable, and resource is a qualifier.
> >
> > Does that make sense?
>
> No, because that's a valid statement in Lua 5.3 that means something
> different. So my point stands: this proposal is a
> backwards-incompatible change that affects existing code.
>

How is it a valid statement?

local resource x = 0

is invalid in Lua.

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Matthew Wild
On Wed, 5 Jun 2019 at 15:49, Dibyendu Majumdar <[hidden email]> wrote:
> How is it a valid statement?
>
> local resource x = 0
>
> is invalid in Lua.

$ cat resource.lua
local resource x = 5
print(resource, x)

$ lua5.3 resource.lua
nil        5

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
On Wed, 5 Jun 2019 at 15:53, Matthew Wild <[hidden email]> wrote:
> $ cat resource.lua
> local resource x = 5
> print(resource, x)
>
> $ lua5.3 resource.lua
> nil        5
>

Okay, I am a bit puzzled. The grammar says:

local namelist [‘=’ explist]

namelist ::= Name {‘,’ Name}

So what you showed appears invalid grammatically ... but the parser allows it?

But I agree that if above statement is currently accepted then there
is a compatibility issue.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Paul K-2
>> local resource x = 5
> So what you showed appears invalid grammatically ... but the parser allows it?

It's interpreted as `local resource; x = 5`, which is valid.

Paul.

On Wed, Jun 5, 2019 at 7:59 AM Dibyendu Majumdar <[hidden email]> wrote:

>
> On Wed, 5 Jun 2019 at 15:53, Matthew Wild <[hidden email]> wrote:
> > $ cat resource.lua
> > local resource x = 5
> > print(resource, x)
> >
> > $ lua5.3 resource.lua
> > nil        5
> >
>
> Okay, I am a bit puzzled. The grammar says:
>
> local namelist [‘=’ explist]
>
> namelist ::= Name {‘,’ Name}
>
> So what you showed appears invalid grammatically ... but the parser allows it?
>
> But I agree that if above statement is currently accepted then there
> is a compatibility issue.
>
> Regards
>

1234