Propsoal: a lua dialect without nil

classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Propsoal: a lua dialect without nil

Axel Kittenberger
  In the 5th century BC Hippasus is said to have been killed by
Pythagoras, because he insisted on the fact that rational numbers do
not cover everything like sqrt(2). This is an urban lebend, sometimes
used as reference to hope to not get the same kind of response as 2500
years ago when suggesting something against the "doctrine". I won't
discuss irrational numbers but the virtue of letting go of nil. You do
not have to be convinced nor do I expect Luiz and Roberto to change
Lua. If it can be managed to be patched to the lua core it will be a
dialect. For now its just an idea I'd rather have written down once,
than letting it go to the drain immediatly.

Nil is not a first class value. It has a recurring scheme of cases
where it has a strange kind of double-meaning, nil as variable not
there, and nil as a result of something not-being there stored in a
variable, now not there. Same with recent discussions what to do if
inserting nil into a list. Or people requesting how to differ if a
function was called without a parameter or with nil as parameter. This
can be achieved in lua with select('#', ...) and only highlights more
the funky meaning of nil. This problems might exist more in heads of
the coders than the language/interpreter, since when learned all the
details how nil behaves you can work with it. However, even if so, a
good programming language should be aimed just as much to the heads to
coders than of cpus - thats all what in my opinion object oriented
programming was about - to better fit in the way we humans think
natively. The issue most directly on hand is type-safeness and let
errors happen where they occur instead of returning nil and error
later. local condition = some_function(); if conditonn then  --- will
always silently fail, even if some_function returned true.

I don't have wide-ranging experience with dynamic typed languages. Lua
is in fact the first one I used in a larger scale rather than these
small scriptles. I don't know of other examples of languages that
avoid nil. Javascript has it worse even two distinct values: null and
undefined, Python has None, Php has NULL. In static typed languages
like C or even Java the NULL pointer functions similar. But contrary
to static types, dynamics would not have to have a null type.

Removing nil has wide-ranging effects. First there is the obvious
cases of tables not having a key. Effect of nil-lessness: if the code
reads a key not there it raises an error(). Thats what be what would
be the scheme of that dialect, one wrong codelet, and immediate error.
There are yet many cases you would need to test for a table having a
key, in that case the ? operator is still free. foo.bar? is true if
foo has bar and false if it has not. (foo.bar? and foo.bar) would
become an idiom to be false if foo has not bar or the value if it has
- given you dont expect or want to differ to false as value, then you
would need a tad more code. As postfix operator it would be another
lookahead for the parser, but we humans are used for ? to be postfix.
But these are details.

Removing a table value is then table.unset(foo, bar). It may sound
less elegant than setting it to nil, but it hits the truth better to
what actually happens, and its just habit.

There are a few other places where nil-lessness would have an impact.
In Lua functions can be called with arbitrary few paramters and the
ones not given are filled with nil. Effect of nil-lessness: default
values come to rescue. If you call a function with less parameters
than it has default values, usual answer: error! You can even
differenciate in the function if you are called with a true default
value or any one given by the user.

do
  local itsdefault = {}
  function foo(a, b = isdefault)
    -- here you know if b is isdefault, or any value given by the user
  end
end

Local variables of course need to be either always initialized, or
raise an error if accessed before first initializiation. I'd prefer
first solution, as this would really allow TNIL to be removed as
primitive type from the VM.

And the last place I can think of is the next() of loop calls. These
functions use nil to signal an end of "stream". These have to be
changed to always return two values, a boolean if its on the end or
not, and the value - which can be anything if the boolean value is
false - Id use false for this.

Another simplificition or "cleanliness" modification would be, with
nil gone, you do not need implicit booleans interpretations anymore.
Only true is true and only false is false. If you need to test a value
to be anything than false, just write (value ~= false) please.

To sum it up:
pro: less confusion about nil as "second class value" (regardless if
that idiom exists)
pro: one primitive type and keyword less in a minimalistic language.
pro: errors (from typos or otherwise) are raised much closer to where
they happened than the nil value causing hickups later.
pro: while it makes the confusions for some around "arrays with holes"
not go away, they are much less likely to catch you.
neutral: the idiom about unsure keys is larger than currently, while
the ones that want to make sure the keys exist are shorter.
con: a new operator required for testing keys that are allowed to be not there.
con: a new basic function table.unset
con: double return values in some places where currently single return
sufficides.
con: something new is always fearsome and nil-lessness written modules
are incompatible with current lua.

Thanks for reading :) Axel

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

steve donovan
On Tue, Feb 15, 2011 at 12:20 PM, Axel Kittenberger <[hidden email]> wrote:
> To sum it up:
> pro: less confusion about nil as "second class value" (regardless if
> that idiom exists)
> pro: one primitive type and keyword less in a minimalistic language.
> pro: errors (from typos or otherwise) are raised much closer to where
> they happened than the nil value causing hickups later.

I tend to like 'errors thrown early' but there are ways and means of
doing this already.

I don't doubt that such a dialect could be crafted, but it would not
really be Lua anymore. The default-arg specifier seems particularly
un-Lua-like, reminding me more of C++.  I know there are arguments for
'non-nullable types' but we are mostly used to the fact that an object
reference can be nil. Otherwise, there has to be another distinct
placeholder.

I am not yet persuaded that there is a serious problem that needs such
drastic surgery. Maybe just homoepathy?

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Steve Litt
In reply to this post by Axel Kittenberger
On Tuesday 15 February 2011 05:20:43 Axel Kittenberger wrote:

>   In the 5th century BC Hippasus is said to have been killed by
> Pythagoras, because he insisted on the fact that rational numbers do
> not cover everything like sqrt(2). This is an urban lebend, sometimes
> used as reference to hope to not get the same kind of response as 2500
> years ago when suggesting something against the "doctrine". I won't
> discuss irrational numbers but the virtue of letting go of nil. You do
> not have to be convinced nor do I expect Luiz and Roberto to change
> Lua. If it can be managed to be patched to the lua core it will be a
> dialect. For now its just an idea I'd rather have written down once,
> than letting it go to the drain immediatly.

Just speaking for myself, I like nil just the way it is. It's easy to deal
with, it makes sense in a "you know what I mean" sort of way, and makes things
easy. I sure prefer nil to the syntactic edifice you'd have to erect to
replace it.

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt


Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Peter Hickman-3
In reply to this post by steve donovan
Well, having worked with statically typed langauges such as Java I can
understand the distaste for nil in all it's forms. But beyond the
likes of Java nil is really not that much of a problem and I fail to
see how removing it from Lua would make anything better.

It would make working with databases harder (NULL == nil) for starters.

I suspect that the motivation is either religious or academic.

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Jim Whitehead II
In reply to this post by Steve Litt
On Tue, Feb 15, 2011 at 10:46 AM, Steve Litt <[hidden email]> wrote:

> On Tuesday 15 February 2011 05:20:43 Axel Kittenberger wrote:
>>   In the 5th century BC Hippasus is said to have been killed by
>> Pythagoras, because he insisted on the fact that rational numbers do
>> not cover everything like sqrt(2). This is an urban lebend, sometimes
>> used as reference to hope to not get the same kind of response as 2500
>> years ago when suggesting something against the "doctrine". I won't
>> discuss irrational numbers but the virtue of letting go of nil. You do
>> not have to be convinced nor do I expect Luiz and Roberto to change
>> Lua. If it can be managed to be patched to the lua core it will be a
>> dialect. For now its just an idea I'd rather have written down once,
>> than letting it go to the drain immediatly.
>
> Just speaking for myself, I like nil just the way it is. It's easy to deal
> with, it makes sense in a "you know what I mean" sort of way, and makes things
> easy. I sure prefer nil to the syntactic edifice you'd have to erect to
> replace it.

Although perhaps not the best model for comparison, the Go programming
language has to deal with uninitialised value, including pointers. The
decision made by the language designers was to introduce a 'zero
value' for every single type, which in the case of reference types
(arrays, slices, maps, structs) is nil.

Although this helps to 'solve' the problem and gets rid of nil other
than the zero value for pointers, you end up with bizarre
constructions like the following for maps:

someMap := make(map[string]string)
val, ok := someMap["foo"]
if ok {
  // The contents of 'val' is the value corresponding to the key "foo"
} else {
  // The contents of 'val' is the zero value for the given type, in
this case the empty string
}

And the same sort of problem occurs with removing a key/value pair
from the table:

someMap["foo"] = "", false

Certainly, you could write some wrappers around this that are
analagous to the table.unset() function you propose.. but I'm not sure
any of this solves a particular problem or are any cleaner than the
alternative, which seems to be what we already have.

Just some thoughts,

- Jim

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Dirk Laurie
In reply to this post by Axel Kittenberger
On Tue, Feb 15, 2011 at 12:20:43PM +0200, Axel Kittenberger wrote:
> Or people requesting how to differ if a function was called without
> a parameter or with nil as parameter. This can be achieved in lua
> with select('#', ...) and only highlights more the funky meaning of nil.
It is indeed a pity that this misleading distinction is possible.

As for the suggestion to design a nil-less language otherwise
reminiscent of Lua, I have after some reflection thought of something
non-negative to say about it: it does not comment snidely on the
political system prevalent in any country.

D.


Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Axel Kittenberger
In reply to this post by Peter Hickman-3
peter> It would make working with databases harder (NULL == nil) for starters.

I do not work regulary with databases and have zero experience with
databases in lua. But wouldn't be anyway a tad more elegant for a
database API to emulate a first-class nil value as a cell content,
like the NIL = {} idiom commonly seen when people need it as a first
class?

peter> I suspect that the motivation is either religious or academic.

I wonder what religous would mean in these context? But in the sense
of temporaty being detached from having to solve any particular
problem right here, right now (which I would call engineering).
Instead wondering, what would happen if...? what would it mean if... ?
What would be the further conseqeunces? In that regard it is academic.
(Altough I don't see my academic career in informatics).

A few years ago, when someone suggested, "get rid of the null
pointer", I'd say s/he is just crazy. It only recently occured to me,
for a language in which every variable is stored in a hashtable, in
which a key/value can simply be missing, it might be possible to get
away from nulled entries. Well not every variable, there are still
local variables, which would just have to be non-nulled.

dirk> As for the suggestion to design a nil-less language otherwise
dirk> reminiscent of Lua, I have after some reflection thought of something
dirk> non-negative to say about it: it does not comment snidely on the
dirk> political system prevalent in any country.

Haha, thank you dirk, I appreciate your efforts :)

Just wondering, does anyone know of any existing dynamic typed
language, that has no nulled types?

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Peter Hickman-3
On 15 February 2011 11:34, Axel Kittenberger <[hidden email]> wrote:

> peter> I suspect that the motivation is either religious or academic.
>
> I wonder what religous would mean in these context? But in the sense
> of temporaty being detached from having to solve any particular
> problem right here, right now (which I would call engineering).
> Instead wondering, what would happen if...? what would it mean if... ?
> What would be the further conseqeunces? In that regard it is academic.
> (Altough I don't see my academic career in informatics).
>
> A few years ago, when someone suggested, "get rid of the null
> pointer", I'd say s/he is just crazy. It only recently occured to me,
> for a language in which every variable is stored in a hashtable, in
> which a key/value can simply be missing, it might be possible to get
> away from nulled entries. Well not every variable, there are still
> local variables, which would just have to be non-nulled.

Well from this your reasoning sounds academic. "What would a language
without nulls look like?"

A religious reason would be something like "I was bitten by a Null
Pointer Exception in Java. Nulls are evil and must be eradicated"

Sort of like the nonsense you get when people get riled up about

# Top/bottom posting
# Windows/Linux
# Emacs/Vi

As a practical man nil has many uses.

if person.age == nil
  -- Ask them how old they are
end

Nil means I don't know the value, I can live with that. However if I
cannot use nil then either I have to introduce another variable
person.age_is_known = {true,false} and make the logic more complicated
or use some special value to mean unknown like -1. But then -1 has
become a magic number and I don't like them at all.

For some things such as dates there is really no sensible magic
number. Given any date someone was born on that date and something
happened on that date so you can't say that any date is safe.

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Matthew Frazier
In reply to this post by Axel Kittenberger
On 02/15/2011 05:20 AM, Axel Kittenberger wrote:

> Nil is not a first class value. It has a recurring scheme of cases
> where it has a strange kind of double-meaning, nil as variable not
> there, and nil as a result of something not-being there stored in a
> variable, now not there. Same with recent discussions what to do if
> inserting nil into a list. Or people requesting how to differ if a
> function was called without a parameter or with nil as parameter. This
> can be achieved in lua with select('#', ...) and only highlights more
> the funky meaning of nil. This problems might exist more in heads of
> the coders than the language/interpreter, since when learned all the
> details how nil behaves you can work with it. However, even if so, a
> good programming language should be aimed just as much to the heads to
> coders than of cpus - thats all what in my opinion object oriented
> programming was about - to better fit in the way we humans think
> natively. The issue most directly on hand is type-safeness and let
> errors happen where they occur instead of returning nil and error
> later. local condition = some_function(); if conditonn then  --- will
> always silently fail, even if some_function returned true.

I think the source of problems with nil isn't its existence, but its
double meaning. The two senses of nil - nothing is stored here, and a
value that is unlike other values - are separate in most other
languages. For example, in Python, "nothing is stored here" is signified
by raising an exception, and "value that is unlike other values" is
signified by None. The problems with nil rise from the fact that it has
to handle both cases.

So, I don't think getting rid of nil is the answer. I think the answer
lies in a stronger way of defining which values are actually defined,
beyond "does it equal nil." I'm borrowing from Python here, but "in" and
"del" keywords for testing whether a key is actually *defined* in a
table (i.e. "3 in t") and deleting keys from a table (i.e. "del t[3]")
might be useful for this. This obviously isn't a complete solution to
the problem, but it would definitely sort out a lot of the confusion.

--
Regards, Matthew Frazier

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

steve donovan
On Tue, Feb 15, 2011 at 2:27 PM, Matthew Frazier
<[hidden email]> wrote:
> "does it equal nil." I'm borrowing from Python here, but "in" and "del"
> keywords for testing whether a key is actually *defined* in a table (i.e. "3
> in t") and deleting keys from a table (i.e. "del t[3]") might be useful for
> this.

Nah, more operators - we have enough.

It is interesting to see how Go solved the problem, in a rather
Lua-ish way: return two values, with the second indicating whether we
actually found something, and are not just getting the default value.

Ruby has a way of making hashes [1] that specify the default value if
the key is not found.

And naturally it's not difficult to do this in Lua, but then we have
to break the habit of using raw tables for everything.

steve d.

[1] honest, it was not intended as a joke..I think.

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Kristofer Karlsson
In reply to this post by Matthew Frazier
I think the source of problems with nil isn't its existence, but its double meaning. The two senses of nil - nothing is stored here, and a value that is unlike other values - are separate in most other languages. For example, in Python, "nothing is stored here" is signified by raising an exception, and "value that is unlike other values" is signified by None. The problems with nil rise from the fact that it has to handle both cases.

So, I don't think getting rid of nil is the answer. I think the answer lies in a stronger way of defining which values are actually defined, beyond "does it equal nil." I'm borrowing from Python here, but "in" and "del" keywords for testing whether a key is actually *defined* in a table (i.e. "3 in t") and deleting keys from a table (i.e. "del t[3]") might be useful for this. This obviously isn't a complete solution to the problem, but it would definitely sort out a lot of the confusion.

--
Regards, Matthew Frazier


Python does both:

x = map.get("foo") # returns None if not found
x = map["foo"] # raises error if not found

Not sure if this is good or not.

I actually think Luas map model is easier to grasp than Pythons.
In Lua, a table is simply a map from key to value, where value can be anything including nil. There is no hard coded concept of exists or not, that's up to interpretation.

In Python, I can do:
t = dict()
None in t # gives False
t["foo"] # error
t.get("foo"] # gives None
t["foo"] = None
t["foo"] # now gives None
None in t # still gives False

This makes it confusing. Python seems to use None both as a real value and as indicator of absense - since "None in t" will never give true.

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

joao lobato
In reply to this post by Matthew Frazier
On 2/15/11, Matthew Frazier <[hidden email]> wrote:

> (...)
> So, I don't think getting rid of nil is the answer. I think the answer
> lies in a stronger way of defining which values are actually defined,
> beyond "does it equal nil." I'm borrowing from Python here, but "in" and
> "del" keywords for testing whether a key is actually *defined* in a
> table (i.e. "3 in t") and deleting keys from a table (i.e. "del t[3]")
> might be useful for this. This obviously isn't a complete solution to
> the problem, but it would definitely sort out a lot of the confusion.
>
> --
> Regards, Matthew Frazier
>
>

t.key == nil is the test and t.key = nil is the delete operation. nil
is not a first-class value nor is it meant to be: you can't store nils
in tables and that's a feature, not a bug.

The case where you use an uninitialized key in a table can be solved
with a simple:

setmetatable(t,{__index = function(t,k) error('key is absent') end})

Unintended deletions are harder, but it's part of the contract that
the 'client' checks if the value (or the key) is nil. Frankly I'd
prefer if t[nil] was a noop, for consistency.

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

brandon zeeb
The presence of nil (and only nil) keeps things simple.  For the Perl programmers out there, the following will look familiar:

if (!defined $hash{'foo'})

is not the same as
if(!$hash{'foo'})

The difference between the above is lost in Lua.  As Lua keeps things rather simple, I'd prefer we keep it that way.  Luckily, Lua only has the concept of nil, and not both null and undefined like in Javascript or Perl.




--
Brandon Zeeb


Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Jim Pryor-2-3
In reply to this post by Kristofer Karlsson
On Tue, Feb 15, 2011 at 01:40:56PM +0100, Kristofer Karlsson wrote:

>    In Python, I can do:
>    t = dict()
>    None in t # gives False
>    t["foo"] # error
>    t.get("foo"] # gives None
>    t["foo"] = None
>    t["foo"] # now gives None
>    None in t # still gives False
>
>    This makes it confusing. Python seems to use None both as a real value and
>    as indicator of absense - since "None in t" will never give true.

That's because your last test was done wrongly---you assigned None as a
value, but `None in t` checks whether None is key.

t={}
t[None]="foo"
None in t # gives True


--
Jim Pryor
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Propsoal: a lua dialect without nil

Julien Duminil
In reply to this post by Kristofer Karlsson

Kristofer Karlsson wrote:

 

>    I think the source of problems with nil isn't its

>    existence, but its double meaning.

>    The two senses of nil - nothing is stored here,

>    and a value that is unlike other values - …

 

joao lobato wrote :

>    nil is not a first-class value nor is it meant to be:

>    you can't store nils in tables and that's a feature, not a bug

 

Maybe you should/could consider nil only as « a value that is unlike other values », not as « nothing is stored here ».

 

It has a type (type(nil) == "nil"), it can be assigned to a variable (local var = nil), it can be passed as a parameter (print(nil)) and it can be returned from a subroutine (function() return nil end).

(So, according to the Wikipedia definition, it is a first-class value: http://en.wikipedia.org/wiki/First-class_object)

 

It is unlike other values NOT because of its type, but because of its uses.

-          It has only one value (boolean has only two values)

-          It is the value given when we don’t know what else to give (not defined, unknown value, an error occured, …)

-          Tables don’t store nil values, and accessing an undefined table member give nil (so, as storage in lua is done with tables most of time, nil is considered as 0-sized for storage)

-         

 

You could compare nil to the character ‘\0’ in a string, which is a common typed value (char) but has a special meaning (end of string).

As strlen(some_string) give the index of the first ‘\0’ character in C, #some_table give the last non-nil value in Lua (within some conditions J).

 

But I agree that it’s easier to think (and to teach) that nil means « nothing is stored here », but it’s the same (no double meaning). ;)

 

 

Best regards, Julien Duminil

 

 

De : [hidden email] [mailto:[hidden email]] De la part de Kristofer Karlsson
Envoyé : mardi 15 février 2011 13:41
À : Lua mailing list
Objet : Re: Propsoal: a lua dialect without nil

 

I think the source of problems with nil isn't its existence, but its double meaning. The two senses of nil - nothing is stored here, and a value that is unlike other values - are separate in most other languages. For example, in Python, "nothing is stored here" is signified by raising an exception, and "value that is unlike other values" is signified by None. The problems with nil rise from the fact that it has to handle both cases.


So, I don't think getting rid of nil is the answer. I think the answer lies in a stronger way of defining which values are actually defined, beyond "does it equal nil." I'm borrowing from Python here, but "in" and "del" keywords for testing whether a key is actually *defined* in a table (i.e. "3 in t") and deleting keys from a table (i.e. "del t[3]") might be useful for this. This obviously isn't a complete solution to the problem, but it would definitely sort out a lot of the confusion.

--
Regards, Matthew Frazier


Python does both:

x = map.get("foo") # returns None if not found
x = map["foo"] # raises error if not found

Not sure if this is good or not.

I actually think Luas map model is easier to grasp than Pythons.
In Lua, a table is simply a map from key to value, where value can be anything including nil. There is no hard coded concept of exists or not, that's up to interpretation.

In Python, I can do:
t = dict()
None in t # gives False
t["foo"] # error
t.get("foo"] # gives None
t["foo"] = None
t["foo"] # now gives None
None in t # still gives False

This makes it confusing. Python seems to use None both as a real value and as indicator of absense - since "None in t" will never give true.

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Axel Kittenberger
In reply to this post by joao lobato
joao> setmetatable(t,{__index = function(t,k) error('key is absent') end})

If only there would be a possiblity to apply it to all tables, even
the ones that have a metatable already set. And if the test in
conditions unsure if the key exists would look nicer than
rawget(t, k) ]

joao> Unintended deletions are harder, but it's part of the contract that
joao> the 'client' checks if the value (or the key) is nil. Frankly I'd
joao> prefer if t[nil] was a noop, for consistency.

I understand your logic, but IMHO it would only push  error raising
further down the drain from where an error occured.

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Axel Kittenberger
In reply to this post by Julien Duminil
julien> (So, according to the Wikipedia definition, it is a first-class value:
julien> http://en.wikipedia.org/wiki/First-class_object)

Hmmm, if I look it up:

wikipedia> can be stored in variables and **data structures**
wikipedia> can be passed as a parameter to a subroutine
wikipedia>can be returned as the result of a subroutine
wikipedia> can be constructed at runtime
wikipedia> has intrinsic identity (independent of any given name)

It fails the data structures part. Nil cannot be stored in data
structures, except in "argument stacks" or how you might call it.
I dont know what is ment with "has intrinsic identity".

julien> -          It is the value given when we don’t know what else
to give (not
julien> defined, unknown value, an error occured, …)

Thank you a lot for bringing that up! In your list it has 3 meanings
already, including even an ellipsis for more! Thats whats likely the
cause the reappearing confusion around it.

I see what I've done here however. _Nobody_ was actually inspired by
the idea of non-nilness. I'm suprised that no-one pointed the "this
language you never heared of", that has non-nullable types and
non-null-pointers. BTW: what does fortran (in its many dialects use?)
I don't know what to make of it, either the idea is incredibly stupid
and a fallback or an anachronism for which we just yet fail to see its
virtue. I'm yet undecided, metaphorical some claim the invention of
the number zero the biggest leap of humanity (over the usually claimed
wheel), so it feels bad to say to any symbol of nothingness to be
suboptimal. Yet a metaphor is just a metaphor and does not necessarily
apply to nullable types. Instead I've activated the
"make-nil-a-first-class-value-crowd" which we knew preexisted, this is
not what I wanted to shoot for. But I'm very thankfull for all who
read the propsoal (yeah I just noticed the typo, a shame), and devoted
their time to share their thoughts about this.

Kind regards, Axel

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Henk Boom-2
In reply to this post by Axel Kittenberger
On 15 February 2011 06:34, Axel Kittenberger <[hidden email]> wrote:
> Just wondering, does anyone know of any existing dynamic typed
> language, that has no nulled types?

Scheme. It does have a value called 'null', but this is just a
singleton empty list, and doesn't have other special behaviour.

    henk

Reply | Threaded
Open this post in threaded view
|

Re: Propsoal: a lua dialect without nil

Doug Currie
In reply to this post by Axel Kittenberger

On Feb 15, 2011, at 10:06 AM, Axel Kittenberger wrote:

> I see what I've done here however. _Nobody_ was actually inspired by
> the idea of non-nilness. I'm suprised that no-one pointed the "this
> language you never heared of", that has non-nullable types and
> non-null-pointers.

In ML family languages (SML, OCaml, etc.) and in Haskell reference types are non-nullable. You must use an option type to represent a value that may or may not be present. [An option type is a tagged structure; the closest thing in Lua might be a table with one or two elements, the first element is true if there is a value (the second element in the table), or false if there is no value (second element in the table).]

I am not advocating a Lua dialect with no nil, despite Axel's lucid and interesting proposal.

e


Reply | Threaded
Open this post in threaded view
|

RE: Propsoal: a lua dialect without nil

Julien Duminil
In reply to this post by Axel Kittenberger
Axel> It fails the data structures part. Nil cannot be stored in data
Axel> structures, except in "argument stacks" or how you might call it.

local vector = { x = 5, y = 3, z = nil }
print(vector.x, vector.y, vector.z) -- 5 3 nil
vector.x = nil
print(vector.x, vector.y, vector.z) -- nil 3 nil

nil is actually <<stored>> in vector.x (moreover, very efficiently ^^).

Axel> Instead I've activated the "make-nil-a-first-class-value-crowd"
Axel> which we knew preexisted

So I'm in the "nil-is-already-a-first-class-value-crowd" if it exists :)
(I'm not against the non-nilness, but nil just works fine for me)


Regards, Julien


1234