Re: Syntactical ugliness - does it matter?

[Dibyendu Majumdar <mobile@...>]

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