Much ado about nil

[euclidianAce]

I'll try to kick this off here with my understanding of how the current type system handles nil, and some proposed alternatives.

Currently, nil is a type in Teal, but it is almost useless since all types are "nilable", i.e. For any type T, nil <: T (where <: is the subtype relation). For those that like type theory, nil is a unit type (but not a bottom type as Teal really doesn't have those, at least, not in a meaningful way). This is one of the first things that newcomers comment on and wonder why this is.

Other than being a bit easier to implement, many Lua idioms rely on values maybe being nilable. More specifically, from the 5.4 reference manual

The notation fail means a false value representing some kind of failure. (Currently, fail is equal to nil, but that may change in future versions. The recommendation is to always test the success of these functions with (not status), instead of (status == nil).)

So any operation that can fail returns a union with whatever type fail is, which for now is nil.

A few examples from the standard library returning a nilable type/fail

• tonumber: function(value: any, radix: number): number: can return nil to signify that the input could not be converted to a number
• io.open: function(file_name: string, mode: string): FILE, string: can return nil, string to signal that Lua was unable to open the file along with the reason why
• more things like load, string.find, and many more follow this pattern of returning nil on failure
• Basically just go to the 5.4 reference manual and crtl+f for returns fail

So whats the big deal? We can just modify the stdlib type definitions to be like tonumber: function(any): number | nil and make the programmer deal with it by manually checking the result.

And, yeah, we can. I think that the issue of "make types non-nilable" is actually quite easy to solve. In fact I think we could just delete an if statement in the is_a (Basically the internal representation of the <: subtype operator) function in tl.tl to not return true if the lhs is nil. The real issue that people would then have with this is that you shouldn't be allowed to do anything with nil or any type that is a union with nil without unwrap-ing it first.

So the issue moves from "all types are nilable" to "how can we conveniently unwrap unions with nil in a way that doesn't suck?"

Some proposed solutions:

• Make assert never return a nil type, i.e. make the signature assert: function<T>(T | nil, string): T
• Introduce a unary assertion operator ! that takes a value and 'unwraps' it as described above and is compiled to a call to assert(value ~= nil and value, "Expected value to be non-nil")
• Some sort of Optional<T>, Maybe<T>, Nilable<T>, Failable<T>, etc. generic with some value()/unwrap()/just() "method" that would basically be compiled to an assert()

What are the problems with these? Well it's not in the solutions themselves, but with how often you'll have to use them.

For example, table indexing can, in general, return nil. Given a dynamic array arr of type {number} (in this scenario we treat number as non-nilable), what should the type of arr[5] be? With no other context, the best we can assume is number or nil. I think the question then becomes, if indexing, in general, is nilable, how can the programmer avoid this annoyance of having to unwrap this union every time they index into a table. (Additionally, we should also assert arr is non-nil before indexing into it, but thats not the point here)

Lua kind of expects nil to be everywhere and trying to teach the type system about that without nilable types is non-trivial and designing an experience of dealing with non-nilable types in an environment that has lots of nilable types is also non-trivial.

So any solution to this has to be very, for lack of a better word, ergonomic. Or else using Teal will just kinda suck.

If non-nilable types do happen, one consequence of that will probably be the inference of this kind of if statement

local file_handle = io.open("my_file.txt", "r")
if file_handle then
   -- the compiler should be able to deduce that file_handle is non-nil
   -- as it already narrows unions by using `is` in an if statement
   -- and this is basically just shorthand for `not (file_handle is nil)`
   print(file_handle:read())
   file_handle:close()
end

Now ideally one thing I'd like to work on is improving flow inference so we can do something like

local file_handle = io.open("my_file.txt", "r")
if not file_handle then
   return -- the compiler should be able to deduce the implication
   -- this if block happens when file_handle is nil and this if block returns unconditionally
   -- => (file_handle is nil => program/function ends here)
end
print(file_handle:read())
file_handle:close()

But this is definitely more complex

Feel free to use this as a thread to propose and (constructively) criticize solutions :D
cc @lenscas @daelvn

[lenscas]

So, first things first:
I am not convinced anymore that just providing a way to assert easily is the way to go because this would mean that teal's error reporting system starts to heavily rely on assert and thus catching errors starts to rely on pcall. This would not only be different from how lua does it, it would also defeat the point because now instead of having to know if something returns nil you need to know if you need to pcall it.

I am however not against a way to easily place asserts and have asserts change the type to strip away the nil part but it shouldn't be the only way to get rid of nil nor the recommend one.

Instead I think we need a solution that grabs all values and checks if the first indicates a fail. If it is a fail, return everything it captured (in the same order!) out of the current function. Otherwise, make the code behave as if this check never happened (Except that the nil) part of the type from the first value is gone.

The problem however is that lua (to my knowledge) can't easily return when in an expression. Nor would it be easy to check and return the value. As a result, significant code changes need to happen between teal and the generated lua.

However, I am convinced that introducing 1 character to the syntax that signals "return early if there is an fail value" is still ergonomic. This comes from writing rust which uses ? to do precisely this, and F# which uses even more |> Result.Bind (fun x -> /*your code here*/)

As a result, my suggestion is to do it like

function b(): number | nil, string
    local? a = somePossibleFailingFunction "some argument"
    return a + 10
end

Which would turn into this teal code (better transformation suggestions welcome)

function b(): number | nil, string | nil
    local _a = {somePossibleFailingFunction "some argument"}
    if not _a[1] then
        return table.unpack(_a)
    end
    local a = table.unpack(_a) as number
    return a + 10 
end

Making this operator only 1 character longer is effectively the same as introducing the an operator of 1 character. So, it passes the "is it as easy to type as Rust" test (Rust also returns errors rather than throws them and uses ? to return early).

It also makes sure that it can only be used on a location where minimal code transformations are needed.

The other suggestion I want to make is to, at least for the time being catch using T | nil as a T as a warning. Assuming that specific types of warnings can be ignored can give us an idea of what current code would break and which method to do the conversion is the least intrusive.

It also for the time being makes those happy who (like me) rather have more verbose code and know that there isn't a nil bug than the other way around. While also making the opposite group happy.

Doing it this way teal can also always fall back to "You can enable this warning or even make it a compile time error, but that is on you. Providing syntax to deal with it is out of scope" in the case that there is no good solution and have the warning be disabled by default.

[scorbiclife]

1. Just for clarification, I assume local? a = false doesn't immediately return nil.
2. Why is table packing / unpacking needed? Is there something missed with the following?

   function b(): number | nil
     local _a = somePossibleFailingFunction "some argument"
     if _a == nil then
        return nil
     end
     ...
   end

[lenscas]

nil is often used as part of returning errors. As a result, local? should handle that properly. It might be that I wrote the code to do so a bit wrong though.

[lenscas]

reading my answer back, the goal of local? was to basically be able to easily return errors rather than being strictly and only about nil. nil and false are both used to indicate failures in lua, so it handles both.

I think my code is slightly wrong though, or at least that there is a way to write it in a way that behaves closer to what people expect.

[Ruin0x11]

I wrote about this earlier. #71 (comment)

Basically, bolting on non-nullable types too late introduces breaking changes that are difficult to work around. There are also implications in Lua as to how ipairs should work and if there should be fixed size arrays.

I still think it is extremely important to have nilable types, because that means one class of extremely common error can be dealt with effectively.

[daelvn]

My opinions on this might be a bit loaded. After all, my preference is ML-like type systems, as used in Haskell, Amulet... My experience with C-like types is close to none, so I am definitely biased, but I will try to assess the problem the best I can.

To avoid an XY-type of situation, I think it's important to look at what we're trying to solve here. Operations sometimes fail, and it is natural of a language to have a way of representing this. As @euclidianAce said, in Lua, this is done by returning nil, and maybe even an error message sometimes. In other languages, you have something like Maybe or Option (Some/None, Just/Nothing), and if you want to return a value on fail, you can use something like Either (Left/Right, and I'm not sure how Rust expresses this). Other languages will surely have different solutions I'm not thinking of right now, since they probably don't apply to Lua at all. It is true for types of languages that these errors go "up the call chain". Functions return errors or empty values until a function above/called earlier can handle them, or sometimes this is left for the user to figure out altogether. Sometimes we do write functions that simply cannot produce a value, and it is up to the user of these libraries to handle these errors themselves.

I am personally not a fan of nil and any (but I understand why they are in a Lua dialect, of course), I think they hinder the type system by creating holes. In a way, it's contagious: functions that use functions that have holes may also have holes in them. When I do type checking with Teal, and I write a function signature for anything as simple as addition (function(a:number,b:number):number), I expect this function to not take any nil values. If the programmer has to handle this, something like an addition function becomes convoluted. To quote the Haskell wiki on Exceptions:

An exception denotes an unpredictable situation at runtime, like "out of disk storage", "read protected file", "user removed disk while reading", "syntax error in user input". These are situations which occur relatively seldom and thus their immediate handling would clutter the code which should describe the regular processing.

I think our goal here should be ensuring that dealing with types stays in the type system, and code stays at runtime. nil should not be a subtype of T, but we definitely should not start inserting asserts wherever something could be nil when we don't want it to be. Personally, I believe in sane error processing, which is why I love being able to express a Maybe type (although currently not possible, to be discussed). Sticking runtime checks on the type layer, to me, does not solve much.

I think we all definitely agree that nil <: T needs to go, and I'm happy to learn that this wouldn't be a particularly difficult thing to do. But if we remove nullable types, we must provide a mechanism (and not a policy) for Teal users to handle types however they believe is necessary.

Here is where things get spiky: finding a solution that not only works for everyone, but everyone likes too. Teal is still a Lua dialect, and I should not forget that. Here is my attempt at not forgetting that Lua is Lua, and not Haskell.

As is, Teal is bound to the Lua idiom of returning fail, yet if I wanted, I could represent a failure in Lua however I wish, without ever touching nil except for the standard Lua functions @euclidianAce mentioned and are specified in the Lua manual. If I wish to handle everything with tables or booleans, I should be able to. I should be able to represent my own failures. Teal doesn't have to push Lua away, but it should, in my opinion, give its users the ability to disconnect from this Lua idiom. Teal could have two ways of being used:

• As typed Lua, a way of typing your Lua code, while keeping idioms and ensuring full interoperability with Lua.
• As Teal, its own programming language, in which interacting with Lua certainly wouldn't be impossible, but where types may get more involved than simply type checking.

I would like to ensure that Teal users are able to use it both ways, or even a third way! I'm open to surprises. That being said, let's look at the proposed solutions:

Introduce a unary assertion operator ! that takes a value and 'unwraps' it as described above and is compiled to a call to assert(value ~= nil and value, "Expected value to be non-nil")

As stated in several points above, I don't think runtime checking is the way to go. Asserting is still possible without a language construct, and if that's how users wish to handle their errors, they are already able to. This is why I don't believe this is a solution at all, even we made T actually mean T and not T | nil. Teal is a language with compile-time types, and we should be encouraging users to use these, too. Of course, the problem comes with "how compatible do you want to be with Lua?". If you want full compatibility, you are already able to, it is just not comfortable, and I think that's what we're here for.

Some sort of Optional<T>, Maybe<T>, Nilable<T>, Failable<T>, etc. generic with some value()/unwrap()/just() "method" that would basically be compiled to an assert()

I have several points to make about this:

• Maybe is possibly my favorite way of handling errors, but languages that do this represent it on the type layer. Maybe is a type, and it is a typed solution to handling errors, which is why...
• To me, it makes no sense to have a special type embedded in the language compile to a runtime check. This is completely wrecking for the type system. If we want to encourage users to use an option type, it should be a fully typed solution, and it would be time for Teal to include a Prelude (a Teal module, "global" (but not really, that's just how Haskell importing works), gets automatically included in every file, embedding the constructs and functions that do get utilized to avoid a runtime require and not including anything that is not used)... or we can just let users define their own option type (currently not viable, to be discussed).

I am however not against a way to easily place asserts and have asserts change the type to strip away the nil part but it shouldn't be the only way to get rid of nil nor the recommend one.

Agree! Despite what my last points may suggest, I am not against making assert something easier to use, simply against it being a recommended way of doing it at all.

Instead I think we need a solution that grabs all values and checks if the first indicates a fail. If it is a fail, return everything it captured (in the same order!) out of the current function. Otherwise, make the code behave as if this check never happened (Except that the nil) part of the type from the first value is gone.

This solution has two very serious issues in my opinion. For starters, and as I mentioned earlier, this is just making a Lua idiom a solution to something that should remain open to every way of handling errors. For example, this would not fit my use case at all. (Remember! I still want to be able to use option types). Secondly, even for the users that do want to handle it similarly, it is completely rigid. What if I want to change the error message (assuming that we called a function that returns T | nil, string | nil)? What if I want to do something before returning again? What if I want to represent errors differently? Some more questions come to mind, but what I mean to say is that this is highly inflexible: the very minute you wish to handle your errors differently, you are already back to the beginning.

It also makes sure that it can only be used on a location where minimal code transformations are needed.

Again, what happens to the other cases? The ways in which errors can be handled in Lua are almost endless, and that's one of its strengths. If we limit the places where this can be used, not only I predict this would be quite bothersome to implement, but only apply to a minimal set of your users.

The other suggestion I want to make is to, at least for the time being catch using T | nil as a T as a warning. Assuming that specific types of warnings can be ignored can give us an idea of what current code would break and which method to do the conversion is the least intrusive.

Yes! Definitely. Languages like Haskell, for example, tell you when you have not listed out all possibilities exhaustively and covered them. This will be a point in my proposed solution (if I ever get to it, because as of the time I'm writing this sentence, I've been writing for almost two hours).

Now, before getting to my solution(s) proposal(s), I want to comment on some very real problems we could have in the implementation of this. You (reader) are getting close though, because my comments on these problems will be directly linked to my solution(s).

For example, table indexing can, in general, return nil. Given a dynamic array arr of type {number} (in this scenario we treat number as non-nilable), what should the type of arr[5] be? With no other context, the best we can assume is number or nil. I think the question then becomes, if indexing, in general, is nilable, how can the programmer avoid this annoyance of having to unwrap this union every time they index into a table. (Additionally, we should also assert arr is non-nil before indexing into it, but thats not the point here)

What a great point! This is something that honestly I would have forgotten about while drafting my comment. My opinion here is that the types should describe what the variable is without magic. If arr is {number}, inserting nil (or anything that isn't a number, really) to this array should be a type error. For tables where we want to allow the possibility to contain nils, the type should be {number | nil}. My proposed solution(s) will specifically mention how to deal with this case, too.

So any solution to this has to be very, for lack of a better word, ergonomic. Or else using Teal will just kinda suck.

Effectively, whatever the solution is, it has to be the following:

• Easy to use, not a hassle, and definitely never get in the way of the programmer.
• Concise, abstracted, it should make the user want to nil-check their functions without five extra lines for every one.
• Flexible, open, it has to not only define how Teal does it, but also be okay with how Lua does it.

Now, all of that said... let's get into the solutions I propose. I will do this by putting blocks on top of blocks. I will try to start from the core of this issue, to the final abstraction and solutions.

Our first instinct is to let Teal express T | nil explicitly, and then deal with nil. As per the many, many points I've raised before, I would like to abstract this nil away wherever possible. There is a real problem with that though, and is that correctness and interfacing with a dynamic language such as Lua don't mix together. Using an option type from Lua becomes awkward, but so is writing code in Teal that seems to "ignore" the work of the type checker.

A divide, a gap comes in. We either fill everything with asserts or we use option types and tell Lua to do the same. Both of these are extremes, but at the same time, there doesn't seem to be anything in the middle. So... why not have both extremes and map between them? The implementation won't be pretty, but here, we're guaranteeing the three things mentioned earlier: ease of use, conciseness and flexibility.

This proposed set of solution imagines a Teal that can use both option types and nullable types, map between them, and make some available to Lua.

The solution will be written in several points, so that people who reply to this can refer to these points and parts of the solution(s) easily.

1. First of all, types should be fully descriptive of the variable, no exceptions. {number} never contains nil. {number | nil} may. nil stops being a subtype of T for every case. All types express themselves uniquely. This is easier said and done, but it is something I would like to see on the roadmap. (@Ruin0x11 posted their comment while I was 2 hours into this issue, so I will reply later, but I read you!)
2. In my opinion, the solution to this problem must lie in the type system, and nowhere else. Runtime checks are not type checks (in a formal type system, anyway).
3. Completely embedded in Teal in form of a Prelude (look for a prelude mention previously in this comment), two option types should be available: Maybe and Either. A code example is not included because these option types are currently very hard to represent, and while tagged records (Tagged records #124) do help a bit, it becomes much, much more code than it should, and the functions/constructors used to create each type of tagged record have their own syntax problems. Expect me to comment on Tagged records #124 soon talking about the syntax of it. The short of it is that type constructors (like Haskell) or records which create their own functions (like Rust) would help greatly. For now, I will be asking you to imagine a type Maybe that can either hold a value a (Just/Some) or not (Nothing/None), and a type Either that can hold a value a on one side (Left) or a value b on the other (Right).
4. There should be facilities to aid conversion from the Lua idiom :nil or :nil, string to Maybe and Either. The Teal compiler can already tell when it's reading Lua or when it's reading Teal, and even add a new type (unknown) accordingly. If we can implement a function that maps, forwards and backwards, between nil/nil, string and Maybe/Either, we can also find a way to Tell teal which of these we wish to make available to Lua. Within Teal, only option types are used. Between Teal and Lua, the function that converts nil <-> Maybe (and nil, string <-> Either) will be applied to the exported functions, as a wrapper (which will only be run once for every function, at export). The specifics of this are to be discussed, but I think it's an idea worth exploring.
5. Teal users should be encouraged to use option types wherever possible, and by doing (4), we would not hinder Lua usage at all.
6. Like Haskell's -fwarn-incomplete-patterns , we would ensure that every case of Maybe and Either is exhaustive. This would be implemented as a warning that could also become an error or ignored at the user's will.
7. The shortcomings and flaws of this solution lie in the implementation and, on paper, unintuitive interfacing with Lua. While I believe the latter will be proven to be false once implemented, implementing it at all properly may be an odyssey.

If we did not want this to be the only solution, it doesn't have to be. I am favorable to adding the following, right alongside my previously proposed solution.

8. T? as syntactic sugar for T | nil.
9. @lenscas' solution is also, while not ideal in my opinion, valid if implemented alongside other ways of doing it.

But for a moment, I want to talk about the future of Teal. A point was raised in the Gitter that straying too far away from Lua may make Teal not just "typed Lua". This part is purely opinion, you can stop reading if you were only looking for my proposed solution to this.

It is true that adding things like option types, and other things in the future may create a gap between thinking in Lua and thinking in Teal, and we do not want to make a split in an already small community that is Lua. But I am of the opinion that Teal could be its own language with its own constructs, while still fully working with Lua and being similar. Maybe Teal won't be all Lua and I think that's fine. I can imagine an ecosystem where Teal modules interact with other Teal modules, Teal rocks are distributed to be used in other Teal projects. Now, imagine all of these libraries were developed with Lua in mind: we wouldn't export types, or functions that rely on types, or anything-types really. We would be limiting or even hindering Teal<->Teal interoperability in the name of Teal<->Lua interfacing. At some point, a Teal library that only makes sense to be used in Teal will come because of the types it provides. At some point, a user might want to work with Teal more than they want to work with Lua. I think the future of Teal lies in being open to using the language however we wish. If you want it to be just typed Lua, nobody will stop you, but if we have more and better features than just a typed Lua (and never splitting away from Lua), then the reasons to make the switch to Teal become more than just type checking my own code.

I don't regret spending 4 hours on this.

[lenscas]

actually, to get multiple solutions to work we could do something like F# computation expressions. Basically, you have an instance with the correct methods that tell F# how to unwrap types like Option, Async, etc. Then you can use let!, return!, for! and a few others to make it easier to work with (depending on what exact methods are implemented)

So, in F# you can do stuff like

let x = Option {
    let a = 10
    let! b = tryGetById(10)
    return b.id + 10
}

here, the let! checks if the result of tryGetById is a Some<T> and if not returns early to the x, otherwise the rest of the code runs as normal (and b is of type T rather than Option<T>)

We could have a similar system so people can use anything they want to return errors. The code that gets generated would however be rather different, needing to be split into multiple lambda's, which are being passed to a chain of methods.

https://fsharpforfunandprofit.com/posts/computation-expressions-intro/
https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions

[lenscas]

I am personally not a fan of nil and any (but I understand why they are in a Lua dialect, of course), I think they hinder the type system by creating holes. I

Coming from typescript: Teal's any is more like typescript's unknown. You don't know what it is and the compiler forces you to check first.
Because of that I don't think teal's any creates any problematic holes at least, not in itself.

nil (or rather, null and undefined) also don't create any holes in TS, at least for as long as you enable the explicit null option. You can not assign undefined to a T and you will be forced to check for undefined if you want to use a undefined | T.

Sticking runtime checks on the type layer, to me, does not solve much.

You always end up with runtime checks though? Every solution to deal with nil needs to check for that. In TS, you are always forced to write an if or similar, and rust has ? that puts a match for None or Error to return early. The question is not about run time checks (as they are guaranteed)
but what they need to look like and how to invoke them easily.

I think we all definitely agree that nil <: T needs to go, and I'm happy to learn that this wouldn't be a particularly difficult thing to do

Yep

But if we remove nullable types, we must provide a mechanism (and not a policy) for Teal users to handle types however they believe is necessary.

Lua pretty much already set a policy, "return a falseish value instead and maybe a string as error message as second argument". I don't see a benefit to teal exposing a way to do it differently especially as that will probably increase complexity in how to use it and the code generated.

As is, Teal is bound to the Lua idiom of returning fail, yet if I wanted, I could represent a failure in Lua however I wish, without ever touching nil except for the standard Lua functions @euclidianAce mentioned and are specified in the Lua manual. If I wish to handle everything with tables or booleans, I should be able to. I should be able to represent my own failures. Teal doesn't have to push Lua away, but it should, in my opinion, give its users the ability to disconnect from this Lua idiom. Teal could have two ways of being used:

However, nil would be the easiest choice, and any disconnect between lua's way and teal's way would increase the barrier between the two, which sucks as that could split lua's already small community into 2, which is not at all what we want to happen.

Right now there is already some form of disconnect, as some function's in lua libraries are a nightmare to give correct static types to and for some this is even impossible.

I would like to ensure that Teal users are able to use it both ways, or even a third way! I'm open to surprises. That being said, let's look at the proposed solutions:

We can have involved types while still relying on T | nil, again look at TS which has amazing things you can do with types and yet, the type information gets fully stripped when compiled to JS.

To me, it makes no sense to have a special type embedded in the language compile to a runtime check. This is completely wrecking for the type system. If we want to encourage users to use an option type, it should be a fully typed solution, and it would be time for Teal to include a Prelude (a Teal module, "global" (but not really, that's just how Haskell importing works), gets automatically included in every file, embedding the constructs and functions that do get utilized to avoid a runtime require and not including anything that is not used)... or we can just let users define their own option type (currently not viable, to be discussed).

The option type itself wouldn't add typechecks at run time. Its methods like unwrap which do, and that is kind of their point. They convert a Option<T> to just T. Every language that needs to deal with nil has those kind of typechecks at runtime.

This solution has two very serious issues in my opinion. For starters, and as I mentioned earlier, this is just making a Lua idiom a solution to something that should remain open to every way of handling errors. For example, this would not fit my use case at all. (Remember! I still want to be able to use option types)

A good custom option already has a way to deal with it, using stuff like map, bind,etc. T | nil however needs extra help and unless you want "methods" that are teal specific and act more like macro's we can't add methods to do this.

local a = b:someThingReturningAnOption()
    .map(function(v) return v + 1 end)
    .bind(function(x)return somethingElseThatReturnsAnOption(x) end)

Secondly, even for the users that do want to handle it similarly, it is completely rigid. What if I want to change the error message (assuming that we called a function that returns T | nil, string | nil)

technically, the syntax can be changed to

local? {name} [with {function}] = yourThing

where function is used to transform the easy return path.

What if I want to do something before returning again?
Simple, you do the if manually. The local? syntax is just syntactic sugar for those that want it. Doing it totally the lua way won't go away, it will just be less needed.

Some more questions come to mind, but what I mean to say is that this is highly inflexible: the very minute you wish to handle your errors differently, you are already back to the beginning.

If you want to handle your errors differently you presumably will be able to have your own methods like map, mapErr,etc. These will already help. Alternatively, we could extend the syntax to make use of something similar to F#'s computation expressions though this would drastically increase the amount of code changes between the generated lua and the original teal code.

Again, what happens to the other cases? The ways in which errors can be handled in Lua are almost endless, and that's one of its strengths. If we limit the places where this can be used, not only I predict this would be quite bothersome to implement, but only apply to a minimal set of your users.

I think that most of the time you want to assign to a variable anyway, I don't see a good way even in normal lua to do error checking without it, unless a big chain of or and and counts. Lua simply needs an if to check for errors and return early. That is the most common cause. If you can handle the fail case, great! don't use this syntax.

What a great point! This is something that honestly I would have forgotten about while drafting my comment. My opinion here is that the types should describe what the variable is without magic. If arr is {number}, inserting nil (or anything that isn't a number, really) to this array should be a type error. For tables where we want to allow the possibility to contain nils, the type should be {number | nil}. My proposed solution(s) will specifically mention how to deal with this case, too.

It is always possible to get a nil out of a table. Simply try to get a value out of it that does not exist. TS decided to lie about it and have indexing return T, lets not make that same mistake shall we :)

The original assert solutions actually where a result of this, as a way to basically get a IndexOutOfBounds error like many other languages do.

I need to do something else now, so I may come back and write more but for now this is probably good enough :)

[daelvn]

we wouldn't export types

We actually can just export .d.tl files next to the generated lua, that is how ts does it and that language has very little problem with ts <-> ts, and JS is even a language that has multiple ways of creating modules. So, if TS can manage good TS <-> TS usage then so can teal.

I wasn't talking so much about the possibility of doing it, but more about the attitude of "why" doing it in certain cases. I know you can export .d.tl files and that Teal can use them normally, but I mean something like the following example (which is totally not something I am currently working on /s):

Imagine a module that manipulates paths, made in Teal. In Lua, you'd traditionally just manipulate the strings, and perform any checks you need. In Teal, you can actually get the type checker to do a lot of work for you. Imagine a function that combines two paths. It's not valid to combine two absolute paths (maybe you can get away with it on Posix, certainly not on Windows). In Lua, I would have to check every time I'm taking a path, whereas in Teal, I can tell the user to properly type their paths:

local enum PathType
  "File"
  "Dir"
end
local enum PathScope
  "Abs"
  "Rel"
end
local record Path
  type:     PathType
  scope:    PathScope
  path:     string
end

Then, writing a function combine becomes something only slightly more complex than concatenation, and the type checker will ensure that you match Path Abs Dir with Path Rel x. Tagged records (#124) would help here even more. The problem becomes that the minute you take this into Lua, you're subject to undefined behavior. And that's okay. What I meant by "we wouldn't export types" is that we wouldn't make solutions like this if we expected everything to be usable from Lua, despite these solutions making sense in a typed context. If we constantly think of Lua when writing Teal modules, then less solutions like these pop up, because this, for example, doesn't translate to Lua by any means. Yes, I know records would be exported as a table, but it becomes really impractical, and you lose half of the checking (since the Teal function would only be checking that the types are correct, something that Lua can't do).

actually, to get multiple solutions to work we could do something like F# computation expressions. Basically, you have an instance with the correct methods that tell F# how to unwrap types like Option, Async, etc. Then you can use let!, return!, for! and a few others to make it easier to work with (depending on what exact methods are implemented)

After checking the two links you shared, and despite the first link trying it's best to not say the "m-word", unfortunately I have to bring it up... These are Monads. Sure, they're monads on steroids, I really like how instead of a single do-notation like in Haskell, you can customize them even more, but at the end of the day, these are monads, and I don't believe Teal is strong enough yet to be able to express these. The computation expressions are translated to a bunch of typed function calls in the end. In the end, we would still be encouraging the use of typed solutions to errors (option types), while certainly making it easier to use and express. After all, Haskell's Maybe has a Monad instance for the same application and ease-of-use.

TL;DR: I don't think it makes sense to implement this if we don't encourage option types.

Coming from typescript: Teal's any is more like typescript's unknown. You don't know what it is and the compiler forces you to check first.

Except Teal isn't forcing you to do anything yet, and that's kind of what we're discussing here. Because of this, the any type does pose a hole as it stands, and IMO it will still be the case until Teal can warn you about checks not being exhaustive enough.

Because of that I don't think teal's any creates any problematic holes at least, not in itself.

The general problem with any is that there's no real way you can treat it: you can't do things with it. As stated in the Teal tutorial, there is only equality and checking for nil, because of course you can't concat with strings or add with numbers (and if you could, that'd mean you know something about the variable's type that Teal doesn't know, and might be a better way to express it). The only justification I can think of is when you are only passing a value around (like an identity function), in which case, you should be using type variables (generics) anyway:

-- ill-typed, but sure, will work
function id(a: any):any return a end
-- strictly typed, even if it won't make a difference here (id :: a -> a)
function id<A>(a: A):A return a end

Lua pretty much already set a policy, "return a falseish value instead and maybe a string as error message as second argument". I don't see a benefit to teal exposing a way to do it differently especially as that will probably increase complexity in how to use it and the code generated.

But is this the right policy? Roberto doesn't seem to think so. Let me share some of the quotes off this interview (reading it whole is still VERY recommended):

The main problem — well, not main, but one of the problems — is that nil is already ingrained in a lot of places in the language. [...] We say: you should avoid nils in arrays, holes. But then we have functions that return nil and something after nil

But the way the libraries are built… I once thought of that — maybe the libraries should return false instead of nil — but it’s a half-cooked solution, [...]

[...] So creating a void will not solve that, unless we had a very strong rule that functions should never return nil, but then why do we need nil? Maybe we should avoid it.

No, I think a really strong static analysis tool is called… type system! If you want a really strong tool you should use a statically typed language [...]

In general, it doesn't look like Roberto is generally in favor of this "policy" that Lua set, that he regrets some of the decisions taken in regards to nil in the language, and points to a static type system a "way" of dealing with nil. Now get this: Teal is... statically typed, and a language, not a tool. Sure, it might be a dialect, but a language nonetheless. It's almost looks like it's in our hands to fix these problems with nil, when Roberto expressed these doubts about the way nil works and is used. Lua may have set a "policy". It might not be that good of a policy.

However, nil would be the easiest choice, and any disconnect between lua's way and teal's way would increase the barrier between the two, which sucks as that could split lua's already small community into 2, which is not at all what we want to happen.

Easy does not mean right nor correct. It would be easier, sure, but doesn't mean that's what we should do, because it isn't correct (as per my many points in the original hell of a comment I made). Still, to deal with this disconnect, I still defend being able to express both. The Teal user should choose the level of disconnect they want, without forcing its users to keep close to Lua even when they don't want to. It is possible to have and encourage option types while still allowing the user to work closely with Lua via T? (shorthand for T | nil). And in a point I expressed earlier, I said that covering this wide range in Teal between "still close to Lua" and "further away from Lua" can bring in users who are only interested in type analysis for Lua, but also the users interested in strong type systems that happen to be compatible with Lua (I would be one of those users). A disconnect doesn't have to happen if we don't disable users from checking errors however they wish. It's just that, in my opinion, defeats the point of a type system.

Right now there is already some form of disconnect, as some function's in lua libraries are a nightmare to give correct static types to and for some this is even impossible.

This becomes more of a problem of identifying what is being built. Teal, right now, serves both as a static analysis tool but as a static type system too, but the two aren't necessarily compatible. To quote, yet again, the Amulet dev, "you can either have correctness or interop with a dynamic language". Of course it's a nightmare to type certain Lua libraries, and that is because Lua libraries are usually not made with types in mind, and that's for a reason. We shouldn't pretend that Teal and Lua are the same language still. These are two different mindsets when it comes to writing code, and sometimes they will clash, and there will be not much we can do, because it isn't in our hands as much as it is in the hands of whoever writes the library.

The option type itself wouldn't add typechecks at run time. Its methods like unwrap which do, and that is kind of their point. They convert a Option<T> to just T. Every language that needs to deal with nil has those kind of typechecks at runtime.

Converting from Option<T> to T doesn't necessarily include runtime checks, but sure, there are instances like Haskell's fromJust (errors on Nothing) that do it. That doesn't mean that unwrapping a value from a type (a in Just a) is associated with a runtime check, which is kind of my original point. I would like to, at least, minimize how much we have to deal with nil for these reasons.

A good custom option already has a way to deal with it, using stuff like map, bind,etc. T | nil however needs extra help and unless you want "methods" that are teal specific and act more like macro's we can't add methods to do this.

local a = b:someThingReturningAnOption()
   .map(function(v) return v + 1 end)
   .bind(function(x)return somethingElseThatReturnsAnOption(x) end)

What you described there is a Functor, and there is a way to solve this without anything that looks like macros, just functions. In your code snippet, map becomes fmap:

class Functor f where
    fmap :: (a -> b) -> f a -> f b

Or, in humanspeak, fmap is a function that takes a function that converts a to b (Teal: function<A,B>(a:A):B) and a value a wrapped in a type f (is it too early to call it a burrito?), and turns it into b but wrapped in the same type f. The whole type signature in Teal comes to look like this (but I'm not sure if it's even valid?): function<M,A,B>(fn:(function(a:A):B), m:M<A>):M<B>. A bit messy, but correct. fmap can be used over anything that is a Functor, which both Maybe and Either are, but the problem would be that Teal isn't currently strong enough to represent this. The snippet would come to look something like:

local x = b:someThingReturningAnOption() -- Option<number>
local y = fmap(function(v:number):number return v + 1 end, a) -- Option<number>
local a = fromJust(y) -- number, `assert`s, would rather use `maybe`[1]

1: Haskell's maybe function.

technically, the syntax can be changed to [...]

Fair, good enough. I like this solution too.

If you want to handle your errors differently you presumably will be able to have your own methods like map, mapErr,etc. These will already help.

Definitely. My whole point isn't about making these mandatory, but rather encouraging a type-correct way to do it while still allowing people to make their own solutions. If there isn't going to be an official Prelude (see my previous points, somewhere lost in the sea of text), I'm okay with rolling my own prelude as a library.

I think that most of the time you want to assign to a variable anyway, I don't see a good way even in normal lua to do error checking without it, unless a big chain of or and and counts. Lua simply needs an if to check for errors and return early. That is the most common cause. If you can handle the fail case, great! don't use this syntax.

It would indeed cover the basic use cases, I'm not against it. I'm only against this ending up as the only solution. Blah blah openness flexibility, I've made this point many times. I'm okay with this being in the language as long as there are tools to help with other sorts of error handling too.

It is always possible to get a nil out of a table. Simply try to get a value out of it that does not exist. TS decided to lie about it and have indexing return T, lets not make that same mistake shall we :)

Definitely agree, we wouldn't want to make the same mistake. It's possible to get nil out of a table when indexing out of bounds as you mentioned. Depending on how overboard we want to go with this, we could track array size or record members. Teal, in a way, already does this when you try to cast a table into a record and you use a field that doesn't exist. That, or maybe stick an assert when we index something, but I feel like that would add a lot of runtime overhead. Without lying to the user, {number} should be exactly just that, and as long as it's within Teal I feel like we should be able to control what goes in and out of the array. When we're passing it to Lua or C, it should be {number?}. I feel like, in a way, we're also lying to the user by letting {number} ever return nil. My proposed solution isn't faking the types being returned, but rather, ensuring that the variables contain exactly what the types say.

[lenscas]

haven't read everything yet but wanted to comment on 1 sentence

What I meant by "we wouldn't export types" is that we wouldn't make solutions like this if we expected everything to be usable from Lua, despite these solutions making sense in a typed context.

I would expect the same to be true for TS in that case, but it isn't. My favorite example being https://github.com/adelsz/pgtyped which grabs sql files and creates wrapper functions for them with the full type definitions using the database. Maybe my experience is biased though, as I work at a company that heavily uses TS and has written some libraries that push TS type checking to its limits (For reference, I once had the please of dealing with a type that was so deep in generics that the TS compiler gave up and just assumed it was infinite....)

Also, just as an aside a path like /home/./lenscas/../lenscas is perfectly legal in posix, which is 1 absolute path concatenated with 2 relative paths.

And..now back to reading the rest :)

[scorbiclife]

What do you think about the current solution in the TypeScript ecosystem?
There isn't native support for monads but there's a library (fp-ts) that resolves the gap.
The only thing one would miss is the do notation this way.
(i.e. People would have to do this to add two optional numbers:

a_or_nil:flatmap(function (a)
  return b_or_nil:flatmap(function (b)
    local c = a + b
    -- do something and return result with c
  end)
end)

)
Overall I think this is a good middle ground.

[DarkWiiPlayer]

I'll jump in and add a few thoughts of my own:

nil is a very central value in Luas design. It's used everywhere and is integral to the way most of us write Lua code, so I strongly believe it needs to also fill the same role in any typed version of Lua.

I personally don't mind the idea of using union-types all over the code, if there's good enough syntax for dealing with this. Firstly, I'd appreciate some syntax to shorten (Type | Nil), maybe something like Type?. After all, reducing clutter is one important component in making a language usable and comfortable.

As for how to deal with nil values, that gets a bit more complicated. Ideally, I'd love a way to call a function in such a way that, if it returns nil, its return values just get returned further up; something like definitely_not_nil = fn_that_can_fail(foo, bar)?, but I think that would be very difficult to turn into Lua without transforming the whole function into CPS, thus greatly reducing readability, or limiting the number of return values.

A more realistic approach might be to just provide a simpler mechanism of checking for nil in a more procedural way; something like:

select(some_value)
   string
      print("It's a string")
   end
   nil
      return nil, "it failed"
   end
end

The keyword select is just the first thing that came to mind here, but I'm sure there's a bunch of more on-point words to describe that.

[daelvn]

Isn't select just one-braincell pattern matching in this case? I'm at the super so getting examples is complicated, but I'd rather do full pattern matching or guards than this, which is basically a switch statement for types, adding two levels of indentation, imo, unnecessarily.

[DarkWiiPlayer]

It's essentially a switch for types, yes. But types can be arbitrarily complex, so it technically isn't just "one-braincell". If you want to match a more complex structure, you can just define that structure as a type (maybe even do this inline?). Whether that would be easy to integrate into teals current architecture though, is another question, and I can't answer that.

[lenscas]

my problem isn't with how many indentations there are but with the fact that it has an indentation at all. If you need to call 3 functions that can fail you now need to get 3 indentations deep or write convoluted code to prevent that.

[euclidianAce]

You can kind of already do this with the is operator

if foo is string then

elseif foo is number then

else

end

[lenscas]

Ok, sorry for necro but... as no one has a good idea on how to move forward with nil I want to take another shot at it. In a way to doesn't require special syntax but would allow the type checker to make use of this knowledge (Which could enable more features)

First of: The distinction between T | nil vs just T IS useful even without checks. It acts like a bit of documentation even if the compiler doesn't help you protect from it. However, this distinction can be used by the compiler for more than just making sure that you don't forget to check for nil.

Right now, unions T | A are, rather limited in teal as they can't hold 2 or more tables, nor 2 or more userdata's. Having this distinction between T and T | nil would allow teal to make them more useful. As with this distinction every key in a table that is required AND not in the other type can now be used to distinguish between the 2.

This would make discriminated unions (like from pr #124 ) possible without it being a language feature.

Once the current std types are moved over to properly deal with optionality we have also lowered the bar for people to experiment with new ideas on how to properly warn the user that a nil check is missing. It also allows it to be implemented in small steps. So for example instead of always going "hey! you forgot the nil check." maybe it starts out to complain just when you try to get a field out of it or something along those lines.

So, to recap:
Having T | nil be an actual thing allows some features to be (more easily) possible even if it doesn't prevent you from missing nil checks just yet. From there, looking further on how to improve optionality should also be easier.

So, lets start with changing the std types to incorporate optionality and start using this difference even if due to syntax concerns it can't yet be used to block users from forgetting nil checks.

[hishamhm]

There's tons of great thoughts in this thread but I don't want it to blow up exponentially by commenting on each individual bit, so I'll just do a quick recap on my top 2(+1) concerns regarding true non-nilable types in Teal:

• how to deal with arrays without having to nil-check every a[i] access: go Typescript-like and make arrays unsound or some other solution
• how to deal with another common pattern: constructing tables that have "required" fields starting from {} (see Java's special behaviors on constructors, for example)
• bonus concern: how more complex will the implementation be once people start expecting smarter and smarter flow typing

The first two are language design issues, the bonus one is more of an implementation worry.

[scorbiclife]

Re: 1: Is soundness a goal in Teal?

Re: 2: One suggestion: using type casts like the following

local type T = record
  field: number -- assume not allowed to be nil
end
local t = {} as T
t.field = 1

[fgaz]

Isn't (1) only a problem when interfacing with existing lua code? In that case one can add manual checks or just assume that the lua code is correct and there won't be nils. Teal code would guarantee that arrays (of non-nil types) do not contain nils.

[lenscas]

Isn't (1) only a problem when interfacing with existing lua code? In that case one can add manual checks or just assume that the lua code is correct and there won't be nils. Teal code would guarantee that arrays (of non-nil types) do not contain nils.

you don't know how long the array is however unless you make the size of the array part of its type, but you would need some kind of array that can have its size change.