A Look at the Design of Lua

[Jon Chesterfield]

Is there a draft available? I'm curious, but not curious enough to sign up
with the ACM.

Cheers

Jon

Date: Fri, 26 Oct 2018 17:38:20 -0200

Subject: A Look at the Design of Lua published in CACM
A Look at the Design of Lua
Communications of the ACM, November 2018, Vol. 61 No. 11, Pages 114-123
https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/abstract
https://doi.org/10.1145/3186277

[Andrew Starks]

On October 27, 2018 at 8:10:12 AM, Jon Chesterfield (
***@gmail.com) wrote:

Is there a draft available? I'm curious, but not curious enough to sign up
with the ACM.

Cheers

Jon

One option is to buy the article for $15 dollars.


-Andrew

[Dirk Laurie]

Post by Andrew Starks

Is there a draft available? I'm curious, but not curious enough to sign up with the ACM.

The article is aimed at computer professionals that know no Lua. It
would also be very useful to someone that has been asked to present an
introductory lecture on Lua. It has very little to offer to expert Lua
programmers.

Post by Andrew Starks
One option is to buy the article for $15 dollars.

That's $1.50 per three-column page.

Considering that the PiL 4th edition e-book (388 pages) costs less
than double that, I doubt that you will think you got value for your
money.

[Alex Mokrushyn]

It so cool to see LuaStudio app here https://vimeo.com/292779036 !
Crossed my fingers, it will not crash on this video :)

Alexander M

[Albert Chan]

I have no problem reading it ...

https://m-cacm.acm.org/magazines/2011/7/109909-passing-a-language-through-the-eye-of-a-needle/fulltext

For PDFs, go http://dx.doi.org/10.1145/1965724.1965739, then click PDF

[Luiz Henrique de Figueiredo]

Is there a draft available? I'm curious, but not curious enough to sign up with the ACM.

I'm sorry about that. I think the full article in HTML and PDF will be
freely available after a few months.

[Andrew Starks]

On Sat, Oct 27, 2018 at 09:02 Luiz Henrique de Figueiredo <

Post by Jon Chesterfield
Is there a draft available? I'm curious, but not curious enough to sign

up with the ACM.
I'm sorry about that. I think the full article in HTML and PDF will be
freely available after a few months.

I did purchase it and read it. It is as the title describes: a look at the
design of Lua.

If I have a need to present Lua for consideration in my company, I plan on
using it for that purpose.

Andrew

[Luiz Henrique de Figueiredo]

The article now seems to be freely available at
https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/fulltext

If that doesn't work for you, try the first CACM link in
http://www.inf.puc-rio.br/%7Eroberto/cvpub.html

[Hisham]

On Sun, 28 Oct 2018 at 07:38, Luiz Henrique de Figueiredo

Post by Luiz Henrique de Figueiredo
The article now seems to be freely available at
https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/fulltext

I'm slightly annoyed that basic Lua module examples often display
messy naming practices. Here, the module is written named as "M",
stored in a file called "mymodule" and required into a variable "vec".
I understand that this is to didactically showcase that the names are
not _required_ to be the same, but it promotes those practices (which
are sadly common among Lua programmers, probably due to top-down
examples like this) and IMO it makes the module system look even more
jerry-rigged. The article itself mentions that the module system is
not as elegant as it could be. The naming choices here don't do it any
favors: if everything was named "vec" in that example, programmers
coming from other languages would find it pretty straightforward. And
if the non-messy approach was common practice, I wouldn't have to
explain to coworkers why Lua module names don't match when they are
finding their way through large codebases.

Let people learn that names don't need to match when the day arrives
when they need to resolve an actual naming conflict, instead of
promoting messy naming from day one.

-- Hisham

[Dirk Laurie]

Post by Hisham
I'm slightly annoyed that basic Lua module examples often display
messy naming practices. Here, the module is written named as "M",
stored in a file called "mymodule" and required into a variable "vec".
I understand that this is to didactically showcase that the names are
not _required_ to be the same, but it promotes those practices (which
are sadly common among Lua programmers, probably due to top-down
examples like this) and IMO it makes the module system look even more
jerry-rigged.

I have no problem with what Lua programmers do. In fact local renaming
is to my mind good practice.

local json = require"org.conman.parsers.json"

Nothing wrong with that.

I do have a problem with what some Lua package writers do. The actual
name to be required is something Unixly cryptic like lfs or lom. but
the package name is longer (luafilesystem) and may even have nothing
to do with the module name (luaexpat). BTW why must the package name
start with or contain the tautological "lua"?

[Sean Conner]

Post by Dirk Laurie

Post by Hisham
I'm slightly annoyed that basic Lua module examples often display
messy naming practices. Here, the module is written named as "M",
stored in a file called "mymodule" and required into a variable "vec".
I understand that this is to didactically showcase that the names are
not _required_ to be the same, but it promotes those practices (which
are sadly common among Lua programmers, probably due to top-down
examples like this) and IMO it makes the module system look even more
jerry-rigged.

I have no problem with what Lua programmers do. In fact local renaming
is to my mind good practice.

The package name is "lua-xml". The file is "LuaXml.lua". The resulting
module name is "xml". Annoying as hell.

Post by Dirk Laurie
local json = require"org.conman.parsers.json"
Nothing wrong with that.

No. But there, the package name is 'org.connman.parsers.json'. The file
is 'org/conman/parsers/json.lua'. And the resulting module is named ...
well, in this case, it would be a local variable named 'json'. There's a
logical progression one can follow.

Post by Dirk Laurie
I do have a problem with what some Lua package writers do. The actual
name to be required is something Unixly cryptic like lfs or lom. but
the package name is longer (luafilesystem) and may even have nothing
to do with the module name (luaexpat). BTW why must the package name
start with or contain the tautological "lua"?

Because otherwise someone might mistake it for JavaScript.

-spc

[Thijs Schreijer]

On 31 Oct 2018, at 21:40, Sean Conner <***@conman.org<mailto:***@conman.org>> wrote:

It was thus said that the Great Dirk Laurie once stated:
Op Wo., 31 Okt. 2018 om 16:38 het Hisham <***@hisham.hm<mailto:***@hisham.hm>> geskryf:

I'm slightly annoyed that basic Lua module examples often display
messy naming practices. Here, the module is written named as "M",
stored in a file called "mymodule" and required into a variable "vec".
I understand that this is to didactically showcase that the names are
not _required_ to be the same, but it promotes those practices (which
are sadly common among Lua programmers, probably due to top-down
examples like this) and IMO it makes the module system look even more
jerry-rigged.

I have no problem with what Lua programmers do. In fact local renaming
is to my mind good practice.

The package name is "lua-xml". The file is "LuaXml.lua". The resulting
module name is "xml". Annoying as hell.

local json = require"org.conman.parsers.json"

Nothing wrong with that.

No. But there, the package name is 'org.connman.parsers.json'. The file
is 'org/conman/parsers/json.lua'. And the resulting module is named ...
well, in this case, it would be a local variable named 'json'. There's a
logical progression one can follow.

I do have a problem with what some Lua package writers do. The actual
name to be required is something Unixly cryptic like lfs or lom. but
the package name is longer (luafilesystem) and may even have nothing
to do with the module name (luaexpat). BTW why must the package name
start with or contain the tautological "lua"?

Because otherwise someone might mistake it for JavaScript.

That’s why I name modules and packages the same way, yet in the repo I add a `.lua`.

Repo: https://github.com/Tieske/binaryheap.lua

luarocks install binaryheap

$ local binaryheap = require “binaryheap”

So far it has been very clean (unfortunately my older stuff doesn’t follow this convention)

Thijs

[Pierre Chapuis]

Post by Hisham
I'm slightly annoyed that basic Lua module examples often display
messy naming practices. Here, the module is written named as "M",
stored in a file called "mymodule" and required into a variable "vec".

For what it's worth, I like the "M" part. It's even part of the internal style
guide at my company. It makes modules easier to rename for one thing.
Also works when you overload existing libraries (e.g. you define
`mycompany.json` that depends on luajson...).

The file being named "mymodule" is a bit weird outside of an example
but like Dirk said we frequently do require something called "xxx.foo"
as "foo". That's not unique to Lua either, for instance Python has the
`import xxx as yyy` syntax to do the same thing.

I also agree with Dirk that the main issue is the name of the LuaRocks
package, not the name of the file. Often with large modules the file
name will be `init.lua` anyway.

[Luiz Henrique de Figueiredo]

The article seems to be freely available at
https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/fulltext

Does anyone have a problem reading the full article at that URL?

[Zhao Han]

Reading fine.

Thanks.

Post by Luiz Henrique de Figueiredo
The article seems to be freely available at
https://cacm.acm.org/magazines/2018/11/232214-a-look-at-the-design-of-lua/fulltext
Does anyone have a problem reading the full article at that URL?