Syntactical ugliness - does it matter?

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

Syntactical ugliness - does it matter?

Dibyendu Majumdar
I hate the syntax for the Rust language. It kind of spoils it for me.

Do people find anything ugly about current Lua syntax?
What about the proposed new syntax <toclose> and <const>?

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
On Sun, 2 Jun 2019 at 16:33, Dibyendu Majumdar <[hidden email]> wrote:
>
> I hate the syntax for the Rust language. It kind of spoils it for me.
>
> Do people find anything ugly about current Lua syntax?
> What about the proposed new syntax <toclose> and <const>?
>

Perhaps I should add my own thoughts on this.

Firstly it is hard to come up with a syntax that is not ugly - unless
new keywords are introduced.

I think 'toclose' as a word is odd ... it is made of two words that
are concatenated. Doesn't quite fit in with the rest of the language.
A single word might be nicer - I quite liked the original (?) proposal
'scope' or 'scoped'.

'const' is also unlike Lua, I mean Lua tends to use full words. So
'constant' might be nicer.

Syntactically new keywords are hard to beat I guess:

constant name = 'Dibyendu'
scoped file = f:open()

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

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

 Dibyendu> Do people find anything ugly about current Lua syntax?

The need to put ; before a statement starting with ( is very ugly.

The "x and y or z" workaround for the lack of a real ternary conditional
operator is ugly and dangerous. (And the popularity of this idiom shows
the need for such an operator.)

Having to use select('#',...) with all its attendant overheads just to
count the number of args to a vararg function is ugly.

 Dibyendu> What about the proposed new syntax <toclose> and <const>?

... meh. It doesn't look too bad to me and the proposed alternatives
seem worse.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Sam Pagenkopf
What about the noise produced by const-by-default style? I would likely use it often even if it's ugly, considering how nice the guarantee is.

On Sun, Jun 2, 2019 at 11:07 AM Andrew Gierth <[hidden email]> wrote:
>>>>> "Dibyendu" == Dibyendu Majumdar <[hidden email]> writes:

 Dibyendu> Do people find anything ugly about current Lua syntax?

The need to put ; before a statement starting with ( is very ugly.

The "x and y or z" workaround for the lack of a real ternary conditional
operator is ugly and dangerous. (And the popularity of this idiom shows
the need for such an operator.)

Having to use select('#',...) with all its attendant overheads just to
count the number of args to a vararg function is ugly.

 Dibyendu> What about the proposed new syntax <toclose> and <const>?

... meh. It doesn't look too bad to me and the proposed alternatives
seem worse.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Pavel
In reply to this post by Dibyendu Majumdar
Additional <>, @, ;, or whatsoever really looks ugly.
Why not just add additional reserved keywords /const/ and /toclose/?

local const x = 5
local toclose f = ...





--
Sent from: http://lua.2524044.n2.nabble.com/Lua-l-f2524044.html

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Oliver Kroth
I would even go further and skip the local in that case (as Dibyendu
Majumdar did):

constant x = 5
scoped f = ...


--
Oliver

Am 03.06.19 um 12:18 schrieb Pavel:
> Additional <>, @, ;, or whatsoever really looks ugly.
> Why not just add additional reserved keywords /const/ and /toclose/?
>
> local const x = 5
> local toclose f = ...

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Ulrich Schmidt
Am 3. Juni 2019 12:26:52 MESZ schrieb Oliver Kroth <[hidden email]>:
>I would even go further and skip the local in that case (as Dibyendu
>Majumdar did):
>
>constant x = 5
>scoped f = ...

I like this Idea, no matter what keywords we finally choose.

Ulrich Schmidt

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Sergey Zakharchenko

Hello,

Ulrich Schmidt <[hidden email]>:
> Oliver Kroth <[hidden email]>:
> >I would even go further and skip the local in that case (as Dibyendu
> >Majumdar did):
> >
> >constant x = 5
> >scoped f = ...
>
> I like this Idea, no matter what keywords we finally choose.

The extensibility of the current 5.4 syntax will then be done with, and we'll be firmly on the road to Java with 50+ reserved words:)

Best regards,

--
DoubleF

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Luiz Henrique de Figueiredo
In reply to this post by Pavel
> local const x = 5
> local toclose f = ...

The only way to make this work is to add reserved words.
Otherwise, these already have a meaning in Lua. They are equivalent to

local const ; x = 5
local toclose ; f = ...

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Rodrigo Azevedo
In reply to this post by Sergey Zakharchenko
Em seg, 3 de jun de 2019 às 08:05, Sergey Zakharchenko
<[hidden email]> escreveu:

>
> Hello,
>
> Ulrich Schmidt <[hidden email]>:
> > Oliver Kroth <[hidden email]>:
> > >I would even go further and skip the local in that case (as Dibyendu
> > >Majumdar did):
> > >
> > >constant x = 5
> > >scoped f = ...
> >
> > I like this Idea, no matter what keywords we finally choose.
>
> The extensibility of the current 5.4 syntax will then be done with, and we'll be firmly on the road to Java with 50+ reserved words:)
>
> Best regards,
>
> --
> DoubleF

Alternative, we can __band them:

local & constant = 5
local & catched = 10 -- alternative name, because all 'local' are
lexically 'scoped' and 'toclose' is ugly.

Moreover (just for fun):

We can always add more constructors with a 'syntactic sugar'-like
constructor, a new "mechanism"

sugar NAME local & constant  -- new keyword ''sugar" here to define
your own syntactic sugar keywords
NAME foo = bar

--
Rodrigo Azevedo Moreira da Silva

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
In reply to this post by Luiz Henrique de Figueiredo
On Mon, 3 Jun 2019 at 12:13, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

>
> > local const x = 5
> > local toclose f = ...
>
> The only way to make this work is to add reserved words.
> Otherwise, these already have a meaning in Lua. They are equivalent to
>
> local const ; x = 5
> local toclose ; f = ...
>

Hi Luiz,

Actually I think these can be parsed unambiguously for the same reason
that the current syntax can be parsed.

That is to say, there is no _material_ difference between:

local <toclose> f
local toclose f

In your example above:
local const
local toclose

Will be interpreted as declaring a local variables named const and toclose.
I hope you agree that the markers <> or * are superfluous in the
proposed use cases.
They only make a difference if a more complex extension was to be
introduced but without seeing examples of what these might be it is
hard to comment on the future viability of these markers. We can
however say that these markers are not unambiguous in expressions and
therefore if they are adopted then the extension mechanism cannot be
used in expressions.

Thanks and Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Tony Papadimitriou
Of all possibilities I can think of (and without introducing new reserved
words or ambiguities with other symbols), I would go with:

local @const x = 5

I believe @ is unused otherwise, can be thought as AT implying 'ATtribute',
or even as a 'decorator' (for Pythonians) in the broader sense.

It's certainly a lot less ugly in my eyes than HTML looking < > brackets.

My €0.01

-----Original Message-----
From: Dibyendu Majumdar
Sent: Monday, June 03, 2019 8:54 PM
To: Lua mailing list
Subject: Re: Syntactical ugliness - does it matter?

On Mon, 3 Jun 2019 at 12:13, Luiz Henrique de Figueiredo
<[hidden email]> wrote:

>
> > local const x = 5
> > local toclose f = ...
>
> The only way to make this work is to add reserved words.
> Otherwise, these already have a meaning in Lua. They are equivalent to
>
> local const ; x = 5
> local toclose ; f = ...
>

Hi Luiz,

Actually I think these can be parsed unambiguously for the same reason
that the current syntax can be parsed.

That is to say, there is no _material_ difference between:

local <toclose> f
local toclose f

In your example above:
local const
local toclose

Will be interpreted as declaring a local variables named const and toclose.
I hope you agree that the markers <> or * are superfluous in the
proposed use cases.
They only make a difference if a more complex extension was to be
introduced but without seeing examples of what these might be it is
hard to comment on the future viability of these markers. We can
however say that these markers are not unambiguous in expressions and
therefore if they are adopted then the extension mechanism cannot be
used in expressions.

Thanks and Regards
Dibyendu


Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Sam Putman
In reply to this post by Dibyendu Majumdar


On Sun, Jun 2, 2019 at 5:33 PM Dibyendu Majumdar <[hidden email]> wrote:
I hate the syntax for the Rust language. It kind of spoils it for me.

Do people find anything ugly about current Lua syntax?
What about the proposed new syntax <toclose> and <const>?

Regards
Dibyendu


Hi Dibyendu,

To my taste, I would prefer:

`my var : const = 12`

In more ordinary Lua:

`local var: const = 12`

You will note that an object call on the left side is invalid, and would in any case only return an assignable
value (an illogical absurdity, as only symbols may receive values only if it looked like this:

`local var:const() = 12`

which implies that it's a syntax error.

Best,
-Sam. 
Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Oliver Kroth
In reply to this post by Dibyendu Majumdar
Hi,

what about another approach to the 'no special character, but no new
keyword' problem?
We could use a function call:

local x = const( 5 )
local f = toclose( ... )

the trick would be to signal in the Lua value returned by these
functions an intention; in the first case to lock the variable after the
value has been assigned, in the second case to register it for the call
to __close() when running out of scope.
I am not sure if this is internally feasible, but I know that a few
tagging bits are coming along with each Lua value.
As this are normal function names, these can be overriden, like error,
require, etc..

Just a thought...

--
Oliver

Am 03.06.19 um 19:54 schrieb Dibyendu Majumdar:

> On Mon, 3 Jun 2019 at 12:13, Luiz Henrique de Figueiredo
> <[hidden email]> wrote:
>>> local const x = 5
>>> local toclose f = ...
>> The only way to make this work is to add reserved words.
>> Otherwise, these already have a meaning in Lua. They are equivalent to
>>
>> local const ; x = 5
>> local toclose ; f = ...
>>
> Hi Luiz,
>
> Actually I think these can be parsed unambiguously for the same reason
> that the current syntax can be parsed.
>
> That is to say, there is no _material_ difference between:
>
> local <toclose> f
> local toclose f
>
> In your example above:
> local const
> local toclose
>
> Will be interpreted as declaring a local variables named const and toclose.
> I hope you agree that the markers <> or * are superfluous in the
> proposed use cases.
> They only make a difference if a more complex extension was to be
> introduced but without seeing examples of what these might be it is
> hard to comment on the future viability of these markers. We can
> however say that these markers are not unambiguous in expressions and
> therefore if they are adopted then the extension mechanism cannot be
> used in expressions.
>
> Thanks and Regards
> Dibyendu
>


Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
On Tue, 4 Jun 2019 at 14:35, Oliver Kroth <[hidden email]> wrote:

> what about another approach to the 'no special character, but no new
> keyword' problem?
> We could use a function call:
>
> local x = const( 5 )
> local f = toclose( ... )
>

I think the toclose feature uses upvalues which are setup at compile
time, so this may not be feasible. I wish it was though as using
library functions would be nice.

Regards
Dibyendu

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> what about another approach to the 'no special character, but
 Oliver> no new keyword' problem? We could use a function call:

I think of all the proposed solutions this one is the one that most
misses the point. The constness or to-closeness is a property of the
VARIABLE, not of the value stored in it, and the syntax needs to reflect
that.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Dibyendu Majumdar
In reply to this post by Dibyendu Majumdar
TL;DR. You have been warned!

I thought it might be useful sharing my experience with Ravi where
type annotations are used.

In Ravi, I allow type annotations to appear in 'local' statements and
function parameter declarations.
So you can write:

local i: integer = 0
local n: number = 4.2
local f: closure = function() end
local s: string = 'hello'

Also you can write:

function Foo(x: number, y: number)
end

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

I point this out to say that the type name is allowed to be a sequence
of names with periods as delimiters.

Now, the issue with a dynamic language like Lua is that you don't know
the return types of functions because functions are values that may
change over time. Also interoperability with dynamic types requires
you to have the ability to sometimes convert (or assert) a type is a
particular one. When trying to implement this I found that
grammatically it was not simple to do this, unless I used a special
character to introduce the type. So then I chose to use '@' to signify
a cast operator. So you can write:

local n: number = @number math.sqrt(5.0)

The '@number' is a unary operator that binds to the right and asserts
that whatever expression is there can be converted to the required
type. Else an error is raised.

I mention all this here to illustrate that my approach to type
annotations worked fine until I needed to introduce some syntax for
type casts. At that point I was hit by the issue that ':' is ambiguous
in expressions.

Of course the Lua authors have a different goal with the new
extensions and above may be useless as an example. Maybe. Or the
lesson from above is that an extension mechanism may fall apart when
it is required in an unforeseen scenario; that is why I keep
suggesting that it may be better to choose an unambiguous character to
introduce the extension as you never know where you might want to use
the extension in future.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Oliver Kroth
In reply to this post by Andrew Gierth
Hi,

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

So it's not the *value* that is constant or to be closed; it's the
function's result, consisting of the value and the intent to modify the
variable where it shall be stored.

--
Oliver



Am 04.06.19 um 17:47 schrieb Andrew Gierth:

>>>>>> "Oliver" == Oliver Kroth <[hidden email]> writes:
>   Oliver> Hi,
>
>   Oliver> what about another approach to the 'no special character, but
>   Oliver> no new keyword' problem? We could use a function call:
>
> I think of all the proposed solutions this one is the one that most
> misses the point. The constness or to-closeness is a property of the
> VARIABLE, not of the value stored in it, and the syntax needs to reflect
> that.
>


Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Egor Skriptunoff-2
In reply to this post by Andrew Gierth
On Sun, Jun 2, 2019 at 7:07 PM Andrew Gierth wrote:

 Dibyendu> Do people find anything ugly about current Lua syntax?

The need to put ; before a statement starting with ( is very ugly.


The possible way to fix this ugliness is to change Lua syntax so that a newline before ( is considered as statement delimiter.
And probably almost none of the old code would be broken by this syntax change.
Most people write
   func(
   ...)
Almost none of programmers writes
   func
   (...)


 
The "x and y or z" workaround for the lack of a real ternary conditional
operator is ugly and dangerous. (And the popularity of this idiom shows
the need for such an operator.)



"x and y or z" is a smart feature of Lua.
It gets "almost ternary" operator without additional syntax.
If you're so pedantic (about the case when y is falsey), use the following:
({y, z})[x and 1 or 2]

 

Having to use select('#',...) with all its attendant overheads just to
count the number of args to a vararg function is ugly.



Yes, that's really ugly, especially from the performance's point of view.
Suggested fix is to introduce new Lua syntax for using vararg as a pseudo-table value.
Assuming new syntax is <vararg>:
   local k_th_arg = <vararg>[k]  -- no actual table exists, so indexing is emulated using additional VM instruction
   local num_args = #<vararg>    -- "borders" in pseudo-table are ignored, the result is the same as select('#',...)



 
 Dibyendu> What about the proposed new syntax <toclose> and <const>?

... meh. It doesn't look too bad to me and the proposed alternatives
seem worse.


The motto of Lua 5.4 is "Surprise! We have angle brackets in Lua!" :-)
 
Reply | Threaded
Open this post in threaded view
|

Re: Syntactical ugliness - does it matter?

Egor Skriptunoff-2
In reply to this post by Rodrigo Azevedo
On Mon, Jun 3, 2019 at 2:43 PM Rodrigo Azevedo wrote:

local & constant = 5
local & catched = 10 -- alternative name, because all 'local' are
lexically 'scoped' and 'toclose' is ugly.



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