Table dot number?

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

Re: Table dot number?

Rena
On Fri, Oct 21, 2011 at 10:07, Roberto Ierusalimschy
<[hidden email]> wrote:

>> >> I understand, but what is the exact rule for what is allowed after the dot? Same
>> >> rules as names for variables?
>> >
>> > That's exactly it, 1 is not a valid identifier, so you cannot use the sugar that
>> > says that t.x == t["x"].
>> >
>> [...]
>>
>> In addition, you cannot use Lua keywords after the dot, like 't.end'
>> or 't.for' - even though they *could* always be unambiguously
>> distinguished from proper keywords in this context.
>
> A detail: This is not "in addition"; it is exactly the same rule. "end"
> is not a valid identifier.
>
> -- Roberto
>
>

This has bit me a few times, when writing functions to parse other languages:
function funcs.foo(...) doThings() end --OK!
function funcs.for(...) doStuff() end --Invalid!
function funcs['for']() doStuff() end --Also invalid! (a function
can't be defined using this syntax)
The only way is to write:
funcs['for'] = function(...) doStuff() end --OK, but harder to read,
especially alongside those like the first line.

Could these restrictions not be lifted? An expression such as [[
blah.for i = 1,5 ]] wouldn't be syntactically valid, so there doesn't
appear to be any ambiguity to worry about. Especially I don't
understand why line 3 isn't acceptable.

--
Sent from my toaster.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

steve donovan
On Fri, Oct 28, 2011 at 10:09 AM, HyperHacker <[hidden email]> wrote:
> Could these restrictions not be lifted?

It complicates the rules to satisfy a special case.  For consistency,
could always write all such functions as

funcs['name] = function() ... end

The current rule is pretty straightforward; the t.sym = t['sym'] sugar
is not possible if sym isn't an identifier.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Axel Kittenberger
It complicates the rules to satisfy a special case.  For consistency,
could always write all such functions as

Would it really? The change wouldn't need to be in the grammar, but a rather simple change in the tokenizer. Everything after a . (if not part of a number) is to be tokenized as identifier and never as language construct. Then it should run through the existing parser without any changes.
Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Miles Bader-2
In reply to this post by Rena
HyperHacker <[hidden email]> writes:
> funcs['for'] = function(...) doStuff() end --OK, but harder to read,
> especially alongside those like the first line.

c'mon, that's not _that_ bad, especially given that it will only
rarely need to be used.  It's arguably even a good thing, since it
explicitly makes the point "hey this function name is a keyword, so be
careful..."

-miles

--
Alone, adj. In bad company.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Stefan Reich
On Fri, Oct 28, 2011 at 9:28 AM, Miles Bader <[hidden email]> wrote:
> HyperHacker <[hidden email]> writes:
>> funcs['for'] = function(...) doStuff() end --OK, but harder to read,
>> especially alongside those like the first line.
>
> c'mon, that's not _that_ bad, especially given that it will only
> rarely need to be used.  It's arguably even a good thing, since it
> explicitly makes the point "hey this function name is a keyword, so be
> careful..."

Yeah, it sounds really smart to use "for" as a function name in your
Lua code :-))

(Hilarity ensues!)

Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Tom N Harris
In reply to this post by Rena
On 10/28/2011 04:09 AM, HyperHacker wrote:

>
> This has bit me a few times, when writing functions to parse other languages:
> function funcs.foo(...) doThings() end --OK!
> function funcs.for(...) doStuff() end --Invalid!
> function funcs['for']() doStuff() end --Also invalid! (a function
> can't be defined using this syntax)
> The only way is to write:
> funcs['for'] = function(...) doStuff() end --OK, but harder to read,
> especially alongside those like the first line.
>
> Could these restrictions not be lifted? An expression such as [[
> blah.for i = 1,5 ]] wouldn't be syntactically valid, so there doesn't
> appear to be any ambiguity to worry about. Especially I don't
> understand why line 3 isn't acceptable.
>

I patched the parser to read NAME as a 'namelit' which is parsed as:

     namelit -> NAME | reserved word | '[' String ']'

In my case, it was to allow illegal characters in a function name, such
as ["Check?"].

https://github.com/whoopdedo/lgscript/commit/4e3ac5b9ec5be3f3306db7f1d83bca3f36e81d8a

This is just coddling coders who don't want to type _G["Check?"] =
function(...) end. Well, you can also use it for locals, but then we're
encouraging bad habits. So I would not want to see it become part of
Lua. Or at least, don't accept reserved words.

--
- tom
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Rena
On Fri, Oct 28, 2011 at 20:02, Tom N Harris <[hidden email]> wrote:

> On 10/28/2011 04:09 AM, HyperHacker wrote:
>>
>> This has bit me a few times, when writing functions to parse other
>> languages:
>> function funcs.foo(...) doThings() end --OK!
>> function funcs.for(...) doStuff() end --Invalid!
>> function funcs['for']() doStuff() end --Also invalid! (a function
>> can't be defined using this syntax)
>> The only way is to write:
>> funcs['for'] = function(...) doStuff() end --OK, but harder to read,
>> especially alongside those like the first line.
>>
>> Could these restrictions not be lifted? An expression such as [[
>> blah.for i = 1,5 ]] wouldn't be syntactically valid, so there doesn't
>> appear to be any ambiguity to worry about. Especially I don't
>> understand why line 3 isn't acceptable.
>>
>
> I patched the parser to read NAME as a 'namelit' which is parsed as:
>
>    namelit -> NAME | reserved word | '[' String ']'
>
> In my case, it was to allow illegal characters in a function name, such as
> ["Check?"].
>
> https://github.com/whoopdedo/lgscript/commit/4e3ac5b9ec5be3f3306db7f1d83bca3f36e81d8a
>
> This is just coddling coders who don't want to type _G["Check?"] =
> function(...) end. Well, you can also use it for locals, but then we're
> encouraging bad habits. So I would not want to see it become part of Lua. Or
> at least, don't accept reserved words.
>
> --
> - tom
> [hidden email]
>
>

I did similar once to allow @ and $ in identifier names, with the
intention that they be used for special cases. I don't think I ever
submitted that patch anywhere, but it's fairly trivial to do...

--
Sent from my toaster.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

David Hollander
> In my case, it was to allow illegal characters in a function name, such as ["Check?"].
> I did similar once to allow @ and $ in identifier names,

If Lua doesn't mind taking a page from Scheme\LISP, and allowing non
syntax characters in function names, "?" and "!" are quite useful as
suffixes. Even if the number of builtin syntactical operators are
expanded in the future, one could patch their code with a quick grep.

I suppose there could be a readability counter argument, as Python
currently also disallows ! and ? in names.

-David Hollander

On Sat, Oct 29, 2011 at 12:51 AM, HyperHacker <[hidden email]> wrote:

> On Fri, Oct 28, 2011 at 20:02, Tom N Harris <[hidden email]> wrote:
>> On 10/28/2011 04:09 AM, HyperHacker wrote:
>>>
>>> This has bit me a few times, when writing functions to parse other
>>> languages:
>>> function funcs.foo(...) doThings() end --OK!
>>> function funcs.for(...) doStuff() end --Invalid!
>>> function funcs['for']() doStuff() end --Also invalid! (a function
>>> can't be defined using this syntax)
>>> The only way is to write:
>>> funcs['for'] = function(...) doStuff() end --OK, but harder to read,
>>> especially alongside those like the first line.
>>>
>>> Could these restrictions not be lifted? An expression such as [[
>>> blah.for i = 1,5 ]] wouldn't be syntactically valid, so there doesn't
>>> appear to be any ambiguity to worry about. Especially I don't
>>> understand why line 3 isn't acceptable.
>>>
>>
>> I patched the parser to read NAME as a 'namelit' which is parsed as:
>>
>>    namelit -> NAME | reserved word | '[' String ']'
>>
>> In my case, it was to allow illegal characters in a function name, such as
>> ["Check?"].
>>
>> https://github.com/whoopdedo/lgscript/commit/4e3ac5b9ec5be3f3306db7f1d83bca3f36e81d8a
>>
>> This is just coddling coders who don't want to type _G["Check?"] =
>> function(...) end. Well, you can also use it for locals, but then we're
>> encouraging bad habits. So I would not want to see it become part of Lua. Or
>> at least, don't accept reserved words.
>>
>> --
>> - tom
>> [hidden email]
>>
>>
>
> I did similar once to allow @ and $ in identifier names, with the
> intention that they be used for special cases. I don't think I ever
> submitted that patch anywhere, but it's fairly trivial to do...
>
> --
> Sent from my toaster.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Geoff Leyland
On 30/10/2011, at 4:52 PM, David Hollander wrote:

> I suppose there could be a readability counter argument, as Python
> currently also disallows ! and ? in names.

Does Python define readability?

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

David Hollander
> Does Python define readability?

No, I volunteered a strawman because I am in support of allowing
question marks :)


On Sun, Oct 30, 2011 at 1:40 AM, Geoff Leyland
<[hidden email]> wrote:
> On 30/10/2011, at 4:52 PM, David Hollander wrote:
>
>> I suppose there could be a readability counter argument, as Python
>> currently also disallows ! and ? in names.
>
> Does Python define readability?
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Miles Bader-2
David Hollander <[hidden email]> writes:
>> Does Python define readability?
>
> No, I volunteered a strawman because I am in support of allowing
> question marks :)

But to be fair, there seems a reasonable amount of consistency
amongst "algol-style" languages w/r/t identifiers -- basically
reallllly restrictive, almost no non-alphanumerics allowed
(you know, "[a-z_][a-z0-9_]*", plus "$" if you're on vms :).

There are some outliers like Dylan -- which allows much more
lispy identifiers (it's an algol-syntax language created by
lisp people though, so that makes some sense...).

[Personally I'd be totally fine with simply _requiring_ most
operators to be space-separated (except for parens), allowing
a much wider range of non-alphanumerics in identifiers ... but
since that goes against typical practice, and might cause a
lot of confusion for programmers used to the "normal way",
it's probably not going to be a popular position...]

-Miles

--
Neighbor, n. One whom we are commanded to love as ourselves, and who does all
he knows how to make us disobedient.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Ben Kelly
In reply to this post by David Hollander
On Sat, 29 Oct 2011 22:52:08 -0500
David Hollander <[hidden email]> wrote:

> > In my case, it was to allow illegal characters in a function name,
> > such as ["Check?"]. I did similar once to allow @ and $ in
> > identifier names,
>
> If Lua doesn't mind taking a page from Scheme\LISP, and allowing non
> syntax characters in function names, "?" and "!" are quite useful as
> suffixes. Even if the number of builtin syntactical operators are
> expanded in the future, one could patch their code with a quick grep.
>
I'm very much a fan of this, and realistically, I don't see much reason
to restrict identifiers to only (%a%w+) as long as the lexis remains
unambiguous. Lisp can probably get away with a bit more than Lua can in
this area (since it doesn't really distinguish between identifiers,
operators, etc), but there's no technical reason why lua couldn't
permit ?, !, ∀, and so forth. (Allowing - is probably too
problematic, though, given that it makes 'foo-bar' ambiguous.)

I do think that the 5.0 approach of allowing "anything in the alnum
category in the current locale" in identifiers was a bad idea, though.
Making the validity of source code dependent on the current system
locale is way too much of a headache.

> I suppose there could be a readability counter argument, as Python
> currently also disallows ! and ? in names.
>
Conversely, I find judicious use of punctuation in variable and
function names to be a great readability aid! There have also been a
few programs I've worked on recently where the ability to use greek
letters and/or mathematical quantifiers would have made it much more
readable in the problem domain.

        Ben Kelly

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Luiz Henrique de Figueiredo
> there's no technical reason why lua couldn't permit ?, !, ???, and so forth.

And it's pretty easy to do in Lua 5.2: just copy and edit lctype.c and
add it to your project.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Dirk Laurie-2
In reply to this post by Ben Kelly
2011/11/1 Ben Kelly <[hidden email]>:
>  there's no technical reason why lua couldn't
> permit ?, !, ∀, and so forth.

The third of your examples is locale-dependent.  On my computer it
shows the same glyph as u2200, but that will not be true for
everybody. Not a technical reason, but potentially confusing.

BTW, is there a technical reason why in Lua 5.2 "\u2200" can't mean
"the UTF-8 encoding of the Unicode symbol u2200" instead of giving
"invalid escape sequence"?  Apart from requiring an update to the `%q`
format option?

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Gavin Wraith
In reply to this post by Luiz Henrique de Figueiredo
In message <[hidden email]> you wrote:

> > there's no technical reason why lua couldn't permit ?, !, ???, and so forth.
>
> And it's pretty easy to do in Lua 5.2: just copy and edit lctype.c and
> add it to your project.

RiscLua uses ?,!,$ in a way that is intended to keep BBC BASIC users
happy. They are empty tables with metamethods, so that ?[adr],![adr],$[adr]
correspond in usage to BBC BASIC's ?adr,!adr,$adr.

--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Rob Kendrick-2
On Tue, Nov 01, 2011 at 09:20:24AM +0000, Gavin Wraith wrote:

> In message <[hidden email]> you wrote:
>
> > > there's no technical reason why lua couldn't permit ?, !, ???, and so forth.
> >
> > And it's pretty easy to do in Lua 5.2: just copy and edit lctype.c and
> > add it to your project.
>
> RiscLua uses ?,!,$ in a way that is intended to keep BBC BASIC users
> happy. They are empty tables with metamethods, so that ?[adr],![adr],$[adr]
> correspond in usage to BBC BASIC's ?adr,!adr,$adr.

Ah, but what about BBC BASIC's (incidentally, inspired by BCPL)
base!offset syntax? (Especially useful for structure manipulation.)  I
think this would actually require their use as operators.

B.

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Gavin Wraith
In message <[hidden email]> you wrote:

> On Tue, Nov 01, 2011 at 09:20:24AM +0000, Gavin Wraith wrote:
> > In message <[hidden email]> you wrote:
> >
> > > > there's no technical reason why lua couldn't permit ?, !, ???, and so forth.
...
> > RiscLua uses ?,!,$ in a way that is intended to keep BBC BASIC users
> > happy. They are empty tables with metamethods, so that ?[adr],![adr],$[adr]
> > correspond in usage to BBC BASIC's ?adr,!adr,$adr.
>
> Ah, but what about BBC BASIC's (incidentally, inspired by BCPL)
> base!offset syntax? (Especially useful for structure manipulation.)  I
> think this would actually require their use as operators.

Have a look at http://www.wra1th.plus.com/lua/book/rb10.html#syntactical_poke

for more syntactic jiggery pokery with metatables and exploitation of Lua's higher
order features. Of course, syntax, like cuisine, is often a personal matter -
one cannot expect to please all tastes :).

--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/

Reply | Threaded
Open this post in threaded view
|

Re: Table dot number?

Axel Kittenberger
In reply to this post by Ben Kelly
> but there's no technical reason why lua couldn't permit ?, !, ∀, and so forth. (Allowing - is probably too
> problematic, though, given that it makes 'foo-bar' ambiguous.)

Making now unused characters part of identifiers removes the
possibility to use them for future language constructs.

12