Re: Syntactical ugliness - does it matter?

[Oliver Kroth <oliver.kroth@...>]

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
> <lhf@tecgraf.puc-rio.br> 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