Idea. Removing nils from the language.

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

Re: Idea. Removing nils from the language.

Udo Schroeter
On Saturday, January 10, 2015, Kevin Clancy <[hidden email]> wrote:
If that's the definition of nil, then what is the definition of null? They seem like the same thing to me.

I think most people associate null with C null pointers. They're different from (and more dangerous than) high level scrpting nils. In a dynamically typed language, nil can be an exceptionally useful concept. I'm far less sure about the role of C null in a statically typed language (which, I believe is conceptually closer to what he refers to as the huge mistake).
 

On Fri, Jan 9, 2015 at 5:43 PM, Erik Hougaard <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;erik@hougaard.com&#39;);" target="_blank">erik@...> wrote:
On 09-01-2015 09:08, Enrique Arizón Benito wrote:
the invention of null (nil) references

"nil" is not null. I think you're trying to solve the right problem in the wrong place.

To quote the manual: "Nil is the type of the value nil, whose main property is to be different from any other value; it usually represents the absence of a useful value."

/Erik

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Erik Hougaard
In reply to this post by Kevin Clancy
On 09-01-2015 15:04, Kevin Clancy wrote:
> If that's the definition of nil, then what is the definition of null?
> They seem like the same thing to me.
>

NULL is just a macro to either 0 or (void*)0 depending on your flavor of C

define NULL (0L)
or
#define NULL (void*)0

/Erik




Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Luiz Henrique de Figueiredo
In reply to this post by Enrique Arizón Benito
> In practice, it all consist in removing the "nil" from the language syntax
> and the virtual machine.

Removing "nil" from the language syntax does not affect the behaviour of
any programs, unless you define a global variable named "nil"...

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Tim Hill
In reply to this post by Enrique Arizón Benito

On Jan 9, 2015, at 12:44 PM, Enrique Arizón Benito <[hidden email]> wrote:

Hi,

The idea is to remove from the syntax and from the virtual machine. Since nil doesn't exists, mathematically it's not possible to have nil errors. nil must be replaced, but are replaced with default sensible (from the program point of view) values. Looks strange but it's always possible to replace a nil with a default value. Actually the program is always trying to solve an algorithm and nil, being and undefined variable that can not even be read (just compared), will not help at all to solve the problem. Some algorithms can not have a solution for a given set of input values (for example searching the value of a non-existing key in an array). In such case exceptions are raised. It's the way the code has to indicate "Sorry, I can't continue since I don't know what to do next".

Regards,

Enrique


nil in Lua really has nothing to do with NULL in C. Although nil is somewhat overloaded in Lua, one common usage is as an out-of-band sentinel value. You state that “it is always possible to replace a nil with a default value”, but what would that value be? Sentinel values cannot be in-band, as they are then ambiguous (indistinguishable from a valid in-band value). So you either have to have magical kinda-sorta out-of-band values that are hacked (like -1 for EOF in C APIs) or you need a value that is out-of-band because it’s specific purpose is just that .. in other words .. nil!

And nil is NOT “an undefined variable that cannot even be read” .. it’s a perfectly respectable literal value which happens to be the only value of the nil type. I think you will find if you try to remove nil you will end up with a language that is far less concise and elegant.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Tim Hill
In reply to this post by Enrique Arizón Benito

> On Jan 9, 2015, at 12:45 PM, Enrique Arizón Benito <[hidden email]> wrote:
>
> Hi,
>
> as Rob Kendrick indicated, replacing nil and raising an exception is the only possibility. (and it's a good thing to do, since this avoid the program to continue with an un-initialized variable).
>
> Regards,
>
> Enrique
>

But there is no such thing as an uninitialized variable in Lua. In Lua, all variables always contain a value at all times, and sometimes that value happens to be nil, be it a local variable, global, upvalue or function argument. In fact, one way to conceptualize a Lua table is that every table has ALL possible keys defined (an infinite number of keys), the vast majority of which just happen to contain nil.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Rob Kendrick-2
In reply to this post by Enrique Arizón Benito
On Fri, Jan 09, 2015 at 09:45:40PM +0100, Enrique Arizón Benito wrote:
> Hi,
>
> as Rob Kendrick indicated, replacing nil and raising an exception is the
> only possibility. (and it's a good thing to do, since this avoid the
> program to continue with an un-initialized variable).

But I actually indicated that it was a horrible thing to do :)

B.

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

steve donovan
On Sat, Jan 10, 2015 at 12:43 PM, Rob Kendrick <[hidden email]> wrote:
> But I actually indicated that it was a horrible thing to do :)

And so it is!  To reiterate what was mentioned in the comments, the
'billion dollar mistake' is a static language problem - that something
with type Foo* could actually be NULL.  nil in Lua is both unique
*and* has a unique type.  It does not appear to be a major source of
bugs in Lua code.

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Enrique Arizón Benito
In reply to this post by Dirk Laurie-2
Hi Dirk, Scott, Hao Wu, "All"

About Dirk comment:

> It seems appropriate to read `always` as a synonym for `IMHO`.

The "always" was not expressing an "IMHO", but actually a mathematical fact. But since mathematical facts must be probed, let's probe it! (mathematics is what makes of programming a science vs an art)

- Suppose we have an algorithm consisting of a set of input values, some code processing the value and a final set of output values. Let's probe the next statement:

  "nil values can always be replaced in the processing code"

- To probe that the previous statement is >>always<< true I will show that the opposite statement is >>always<< false:

 "nil values can NOT always be replaced".

- If "nil" values can NOT be replaced there are certain algorithms that need a "nil" to complete.

- "nil" can not be read, but just compared, and so it can only appear inside conditional comparisons similar to:

 if myVar == nil then ... end

- The result of this comparison is always true if myVar is nil or false if myVar is not nil.

- There exists many different combinations of values that can be used to obtain a similar behavior replacing the nil. For example we can use the integer 0 or the string "0" to create a similar algebra.

  if myVar == 0 then ... end
  if myVar == "0" then ... end

- That probes that our previous statement "nil values can NOT always be replaced" is false, and so the opposite "nil values can always be replaced" is true.


About Scott comment:
> "you may end up replacing nil with explicit type-specific sentinel values or option types that have similar semantics."

You are completely and absolutely right! The problem with nil is that there are two scenarios in which comparing a variable with nil can be true.
- The first one is that we, ON PURPOSE, have set that variable to nil as a sentinel value. This is correct. No problem with it.
- The second one is that we, BY MISTAKE, have forgot to initialize the variable and just declared it. This is part of the "billion dolar mistake", as Tony Hoare named it.

About Hao Wu comment:
> "the immediate reaction from my head is how you would approach this?

> local foo
> local bar = function() foo = 1 end
> bar()
> print(foo)"

Thanks for this question since it makes it clear why nil is so dangerous. The simple solution is:

local bar = function()
   local result=1
   return result
end
local foo = bar()

Removing nil forces to provide a value at variable declaration, so the line "local foo" is not valid anymore. Since the algorithm used to initialize the variable is in bar, we just change the API for bar to return the result that will be used to initialize foo.
Your example is really good to probe the "madness" of nil.
Imagine that we are working with a complex 10k lines of code and later on we have some code looking like:

if foo == nil then
    remove_My_Back_Account()
else
   I_won_the_lottery()
end

With the first version of the code (nil allowed), if we forgot by mistake to invoke bar() we will be much poorer now :( .
In the second version of the code, If we remove the nil, we are forced to initialize foo before using it. If we forget to execute " foo  = bar()" the line "if foo == nil" will fail with an error similar to   "foo is undefined".
A very illustrative example of the billion-dolar-mistake.


I will try to find some time to create a nil-free implementation based on the existing code, and publish it on GitHub. Anyone curious is welcome to participate. Since I don't have much free time I can not promise anything in the coming month/s.

Regards!
Enrique

P.S.:
(Sorry if I do not reply to all your comments, but I don't have time enough to do it, even if some are really interesting)


On Fri, Jan 9, 2015 at 10:17 PM, Dirk Laurie <[hidden email]> wrote:
2015-01-09 22:44 GMT+02:00 Enrique Arizón Benito
<[hidden email]>:




But given that Lua is a dynamically typed language, the concept
of a value that is so nonexistent that it does not even have a type
is a very useful abstraction.


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Dirk Laurie-2
2015-01-10 19:09 GMT+02:00 Enrique Arizón Benito
<[hidden email]>:

> Your example is really good to probe the "madness" of nil.

Lua has lived with that madness for over 20 years.
Though it be madness, yet there is method in it.

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Mike Nelson
In reply to this post by Enrique Arizón Benito
On 1/10/2015 9:09 AM, Enrique Arizón Benito wrote:


(various statements about 'nil' I will not quote)


My take on what Enrique is saying is not that he objects to the
existence of the Lua value nil as such, but to the implicit
initialization of variables to nil when no other value is specified.
Then what is being asked for is to require all variables to be
explicitly initialized (even to nil, if the programmer explicitly codes
the intention to do so).

So,
     local x
     do_something() -- function which may use x

would no longer be legal Lua code, but

     local x=nil
    do_something() -- function which may use x

will continue to be legal.

This is a change I would have supported if we were hashing out the
specifications for Lua 1.0, but version 5.3 is much too late to make
such a severely breaking change, IMHO.

Enrique, is my understanding of what you are saying anything like what
you are trying to say?

-- Mike Nelson

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Javier Guerra Giraldez
In reply to this post by Dirk Laurie-2
On Sat, Jan 10, 2015 at 3:36 PM, Dirk Laurie <[hidden email]> wrote:
> 2015-01-10 19:09 GMT+02:00 Enrique Arizón Benito
> <[hidden email]>:
>
>> Your example is really good to probe the "madness" of nil.
>
> Lua has lived with that madness for over 20 years.
> Though it be madness, yet there is method in it.


while i'm typicall a conservative in the common "change Lua" threads,
this one has a slightly different take, more like "imagine a language
with this uncommon trait... Lua seems a good platform to experiment".
In that light, the "we've always done things like this" argument isn't
so valid... maybe not even "i like it like it is".

unfortunately, the premise "imagine a nil-less Lua" is flawed on several points:

- the "NULL is a bug" rant is a very specific rant on a very specific
set of languages.  maybe not even full languages, more like the common
practices on those languages

- a big part of the "NULL problem" is that it's a value that can be
assigned to every pointer type, breaking type safety, or at least
making it harder to have strong types on static type systems.   but on
dynamic type systems, where the type is in the value and not in the
variable, there's no problem with nil (or None, or null), it's a
different type with a single value.  that's why some of the strongest
type systems are seen in dynamic type languages (or those with very
sophisticated type inference and automatic types).   in short: even if
NULL is a problem, it doesn't imply that nil is too.

- neither type statics nor type strength is a value on itself.

- the "removing nil would allow Lua to have static types!" argument
seems a non-sequitur, and a drawback if you happen to like dynamic
types.

- the original post ended in something like "i've done the easy part,
and i don't have time to do the rest", which is ok if somebody else
sees any value in the proposal... if not, then that should be the end
of it until the author finds time to either advance the code or to
draft a more consistent language design.


--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

szbnwer@gmail.com
hint 4 readin: imagination keep going foreward and dont skip stuff wich still izn undestood in the whole

sorry 1st i didn read all the messages but my logic gave theze 4 this problem:

- math containz 0 and it made the life better than previously it was, cause we can handle the empty and dead-end thingz not just the existent and continuous thingz, if u name sumtin uve grab it and later u can uze it, if we make a taboo from 0 its okhay 4 us humanz we will kno how to handle stuff without say any zero, but if u dont build it for a comp it wont kno, first u shud delete it from the life science from the end twice of a hundred and from a bit also

- if you want to make a system more abstract u gonna go farer from the platform and go nearer to the ppl. for a programmer its okhay to kno how to handle a 0 and anyway we shud get something for it even if its not a 0 but its eyecandy, the computer gonna work with it in the background anyway and u can define it with any word but its 4 u, but for a computer any longer stuff for the shortest eaziest and most uzed stuff (all the endings, and it can be farer and more only but it will b there...) it wudnt b a good thing to implement it in a longer form. 4 the user give nice rounded colorful buttons and well declared informationz, when u cant go anywhere as far as the program has done its job

- my main concept is if therez a default exit door from anywhere, then we wont stuck and we can terminate to the origin, like orderingz and the uzer, as i thinx its the main goal 4 programming to give the ppl what they wanted, or we still can say we kudnt got it sorry and not stay and wait for a miracle. the other end of the story is we didnt get the end of the road - we are building from the funds and from 0 to be sumthin and not organizing the whole which we can reach by default cuz we dont... <--herez a 0-end 4 u :D

- this exit door is for terminate and give the stuff for the orderer, its the way to the 'outside the box' wich is the main goal for everything, the terminatin. as we dont like infinite cuz its a boring repetitive loop or an undone idle task or a random stuff wich is alwayz different but these endless stuffz makes ppl insane in long term and take their life, or they shud leave it behind without getting or knowing its end and mainly is not what they like. its only good for the reality wherez not needed the magical red button under our hand :) anyway life gonna push it a thouzend times hopefully to give place for our future and chill - slavery is flowering without exit inside any loop!

- in programming every single endin of a tree graph (even if there are circles inside it - but their end can b a 1 for eg) are zeros as i mentioned earlier, wich is the point we shudn make more (longer) stuffz, why would we pollute the codes then with anything else? we also can go forward with a default if its needed to be handled automatized or stuff like, but why we shud build a construction for the ends if we have a default separated, wich gonna be called and wich we are more than abled to do in programming because therefore we have reusable parts namespaces functions circular and callable stuffz, and in Lua where we can make metatables and its so easy for us (poor other programmers ... sigh). thats why programming is for the machines to automatize raw math is for a piece of paper for make a single stuff and every leaf are for the tree for work together parallel - the reason for they are exists is the main angle

- why wud i put anything there, where i dont kno what gonna b or where is actually/still nothing? if theres the possibility to continue a chain we have everything we may need and the comp has no junk. you can put the stuff behind a 0 to the uzerz screen, u can alias it for urself, and u can make ur stuff better if u compile ur stuff and the computer filter ur junk behind the procedures, but i think the perfect way would be if all of us make the valuable info 4 the human and the valuable procedures for the computers strictly separated and linked only (hint: linked root with the same tree and namespaces would b enough 4 make it) - the reazonz behind it are theze mainly: programs dont need our junk at execute, but we need it to go foreward with developing; it can make everything faster and reverzible; we can have then selected sets from it also like maximal minimal default uzer secified or optimized 4 speed space jobs taste anything; and it wont break to small unhandleable disconnected forgotten origined/purposed and even closed stuff as its organized like in apt github luarockz, but these are still not perfect because they alwayz (ok not alwayz...) cut themself off from the origins and start to b individual, but at the rootz wherez a lotsa zeroz and stuff we can compare everything easily cuz therez no too much different implementations for the stuff, like we kno a few methodz 4 the integral calculus and less for an addition - it wud b good to collect organize declare (4 ppl) optimize and make instant developeable compatible reversible and resolveable everything as we are abled to do it, we have everything already made just they are needed to b fully compatible, and the way is to automatically detect and handle diffs and dont cut the roots only put it away where its not needed and even dont try to compare stuff wid different pplz junk mixed wid the raw math, and anyway we have sourcecodes compilers JIT we are abled to do from these an implementation wich is runtime written for computerz strictly or fully surety 4 ppl or both parallel as the situation wishez it
 
- anyway infinite much programmerz uzin 0 wid workin rezoult and readability comes from the structures, info can come with error msg/code parallel with a 0, or can be read from the background or resolved from the state, if one task can make one failure we can handle it with a single 0 and if it can exist then we shud check it out, we can make check-handle circles and a 0 is enough for it, if we can have various errors in one step or we comin back from a farer journey or a closed system ('black box') and we shud bring a proper error description we need to check and mark it with a 0 or anything else but we shud do before trigger anything depending on our anything we got/xcepted

- its better to get an unambiguous 0 (4 sur im thinkin about nil null none and the stuff like, cuz if we need a number 0 wudnt b cool 4 us as the error/end hotline) than any other value wich can harm our code eazyer wid undetectable problems or give place for the uzr to do thingz like XSS, and if 0 can come we need a handler before we are moving or right after we moved at least a mark that its still not the expected stuff. and if u have an integer in a typed language like C u cant give it a 0 or a string or anything if u still dunno what gonna b there (anyway everything is solveable u can flag it when u start to use it and previously put a randint inside...)

- a few paces where i can see thoze evil zeroz behind the scenes are stuff etc it this that . ... ' ' (<--its a space) univerzal formz unfinnished formz deleted ignored stuff and the like or even behind a smile they are dead ends full stops and terminatin...

pm sry 4 meh gramma buddyz i luw it, fight 4 knowledge :) thx 4 watchin see u next week

2015-01-10 23:28 GMT+01:00 Javier Guerra Giraldez <[hidden email]>:
On Sat, Jan 10, 2015 at 3:36 PM, Dirk Laurie <[hidden email]> wrote:
> 2015-01-10 19:09 GMT+02:00 Enrique Arizón Benito
> <[hidden email]>:
>
>> Your example is really good to probe the "madness" of nil.
>
> Lua has lived with that madness for over 20 years.
> Though it be madness, yet there is method in it.


while i'm typicall a conservative in the common "change Lua" threads,
this one has a slightly different take, more like "imagine a language
with this uncommon trait... Lua seems a good platform to experiment".
In that light, the "we've always done things like this" argument isn't
so valid... maybe not even "i like it like it is".

unfortunately, the premise "imagine a nil-less Lua" is flawed on several points:

- the "NULL is a bug" rant is a very specific rant on a very specific
set of languages.  maybe not even full languages, more like the common
practices on those languages

- a big part of the "NULL problem" is that it's a value that can be
assigned to every pointer type, breaking type safety, or at least
making it harder to have strong types on static type systems.   but on
dynamic type systems, where the type is in the value and not in the
variable, there's no problem with nil (or None, or null), it's a
different type with a single value.  that's why some of the strongest
type systems are seen in dynamic type languages (or those with very
sophisticated type inference and automatic types).   in short: even if
NULL is a problem, it doesn't imply that nil is too.

- neither type statics nor type strength is a value on itself.

- the "removing nil would allow Lua to have static types!" argument
seems a non-sequitur, and a drawback if you happen to like dynamic
types.

- the original post ended in something like "i've done the easy part,
and i don't have time to do the rest", which is ok if somebody else
sees any value in the proposal... if not, then that should be the end
of it until the author finds time to either advance the code or to
draft a more consistent language design.


--
Javier


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Eduardo Ochs
Szbnwer, you're my hero!!!

This is the first post in this thread that I found myself not just
skimming through but reading and rereading it several times, finding
more layers of meaning in it every time!...

Thanks a lot =),
  Eduardo Ochs
  http://angg.twu.net/

On Sun, Jan 11, 2015 at 1:45 PM, [hidden email] <[hidden email]> wrote:

> hint 4 readin: imagination keep going foreward and dont skip stuff wich
> still izn undestood in the whole
>
> sorry 1st i didn read all the messages but my logic gave theze 4 this
> problem:
>
> - math containz 0 and it made the life better than previously it was, cause
> we can handle the empty and dead-end thingz not just the existent and
> continuous thingz, if u name sumtin uve grab it and later u can uze it, if
> we make a taboo from 0 its okhay 4 us humanz we will kno how to handle stuff
> without say any zero, but if u dont build it for a comp it wont kno, first u
> shud delete it from the life science from the end twice of a hundred and
> from a bit also
>
> - if you want to make a system more abstract u gonna go farer from the
> platform and go nearer to the ppl. for a programmer its okhay to kno how to
> handle a 0 and anyway we shud get something for it even if its not a 0 but
> its eyecandy, the computer gonna work with it in the background anyway and u
> can define it with any word but its 4 u, but for a computer any longer stuff
> for the shortest eaziest and most uzed stuff (all the endings, and it can be
> farer and more only but it will b there...) it wudnt b a good thing to
> implement it in a longer form. 4 the user give nice rounded colorful buttons
> and well declared informationz, when u cant go anywhere as far as the
> program has done its job
>
> - my main concept is if therez a default exit door from anywhere, then we
> wont stuck and we can terminate to the origin, like orderingz and the uzer,
> as i thinx its the main goal 4 programming to give the ppl what they wanted,
> or we still can say we kudnt got it sorry and not stay and wait for a
> miracle. the other end of the story is we didnt get the end of the road - we
> are building from the funds and from 0 to be sumthin and not organizing the
> whole which we can reach by default cuz we dont... <--herez a 0-end 4 u :D
>
> - this exit door is for terminate and give the stuff for the orderer, its
> the way to the 'outside the box' wich is the main goal for everything, the
> terminatin. as we dont like infinite cuz its a boring repetitive loop or an
> undone idle task or a random stuff wich is alwayz different but these
> endless stuffz makes ppl insane in long term and take their life, or they
> shud leave it behind without getting or knowing its end and mainly is not
> what they like. its only good for the reality wherez not needed the magical
> red button under our hand :) anyway life gonna push it a thouzend times
> hopefully to give place for our future and chill - slavery is flowering
> without exit inside any loop!
>
> - in programming every single endin of a tree graph (even if there are
> circles inside it - but their end can b a 1 for eg) are zeros as i mentioned
> earlier, wich is the point we shudn make more (longer) stuffz, why would we
> pollute the codes then with anything else? we also can go forward with a
> default if its needed to be handled automatized or stuff like, but why we
> shud build a construction for the ends if we have a default separated, wich
> gonna be called and wich we are more than abled to do in programming because
> therefore we have reusable parts namespaces functions circular and callable
> stuffz, and in Lua where we can make metatables and its so easy for us (poor
> other programmers ... sigh). thats why programming is for the machines to
> automatize raw math is for a piece of paper for make a single stuff and
> every leaf are for the tree for work together parallel - the reason for they
> are exists is the main angle
>
> - why wud i put anything there, where i dont kno what gonna b or where is
> actually/still nothing? if theres the possibility to continue a chain we
> have everything we may need and the comp has no junk. you can put the stuff
> behind a 0 to the uzerz screen, u can alias it for urself, and u can make ur
> stuff better if u compile ur stuff and the computer filter ur junk behind
> the procedures, but i think the perfect way would be if all of us make the
> valuable info 4 the human and the valuable procedures for the computers
> strictly separated and linked only (hint: linked root with the same tree and
> namespaces would b enough 4 make it) - the reazonz behind it are theze
> mainly: programs dont need our junk at execute, but we need it to go
> foreward with developing; it can make everything faster and reverzible; we
> can have then selected sets from it also like maximal minimal default uzer
> secified or optimized 4 speed space jobs taste anything; and it wont break
> to small unhandleable disconnected forgotten origined/purposed and even
> closed stuff as its organized like in apt github luarockz, but these are
> still not perfect because they alwayz (ok not alwayz...) cut themself off
> from the origins and start to b individual, but at the rootz wherez a lotsa
> zeroz and stuff we can compare everything easily cuz therez no too much
> different implementations for the stuff, like we kno a few methodz 4 the
> integral calculus and less for an addition - it wud b good to collect
> organize declare (4 ppl) optimize and make instant developeable compatible
> reversible and resolveable everything as we are abled to do it, we have
> everything already made just they are needed to b fully compatible, and the
> way is to automatically detect and handle diffs and dont cut the roots only
> put it away where its not needed and even dont try to compare stuff wid
> different pplz junk mixed wid the raw math, and anyway we have sourcecodes
> compilers JIT we are abled to do from these an implementation wich is
> runtime written for computerz strictly or fully surety 4 ppl or both
> parallel as the situation wishez it
>
> - anyway infinite much programmerz uzin 0 wid workin rezoult and readability
> comes from the structures, info can come with error msg/code parallel with a
> 0, or can be read from the background or resolved from the state, if one
> task can make one failure we can handle it with a single 0 and if it can
> exist then we shud check it out, we can make check-handle circles and a 0 is
> enough for it, if we can have various errors in one step or we comin back
> from a farer journey or a closed system ('black box') and we shud bring a
> proper error description we need to check and mark it with a 0 or anything
> else but we shud do before trigger anything depending on our anything we
> got/xcepted
>
> - its better to get an unambiguous 0 (4 sur im thinkin about nil null none
> and the stuff like, cuz if we need a number 0 wudnt b cool 4 us as the
> error/end hotline) than any other value wich can harm our code eazyer wid
> undetectable problems or give place for the uzr to do thingz like XSS, and
> if 0 can come we need a handler before we are moving or right after we moved
> at least a mark that its still not the expected stuff. and if u have an
> integer in a typed language like C u cant give it a 0 or a string or
> anything if u still dunno what gonna b there (anyway everything is solveable
> u can flag it when u start to use it and previously put a randint inside...)
>
> - a few paces where i can see thoze evil zeroz behind the scenes are stuff
> etc it this that . ... ' ' (<--its a space) univerzal formz unfinnished
> formz deleted ignored stuff and the like or even behind a smile they are
> dead ends full stops and terminatin...
>
> pm sry 4 meh gramma buddyz i luw it, fight 4 knowledge :) thx 4 watchin see
> u next week
>
> 2015-01-10 23:28 GMT+01:00 Javier Guerra Giraldez <[hidden email]>:
>>
>> On Sat, Jan 10, 2015 at 3:36 PM, Dirk Laurie <[hidden email]>
>> wrote:
>> > 2015-01-10 19:09 GMT+02:00 Enrique Arizón Benito
>> > <[hidden email]>:
>> >
>> >> Your example is really good to probe the "madness" of nil.
>> >
>> > Lua has lived with that madness for over 20 years.
>> > Though it be madness, yet there is method in it.
>>
>>
>> while i'm typicall a conservative in the common "change Lua" threads,
>> this one has a slightly different take, more like "imagine a language
>> with this uncommon trait... Lua seems a good platform to experiment".
>> In that light, the "we've always done things like this" argument isn't
>> so valid... maybe not even "i like it like it is".
>>
>> unfortunately, the premise "imagine a nil-less Lua" is flawed on several
>> points:
>>
>> - the "NULL is a bug" rant is a very specific rant on a very specific
>> set of languages.  maybe not even full languages, more like the common
>> practices on those languages
>>
>> - a big part of the "NULL problem" is that it's a value that can be
>> assigned to every pointer type, breaking type safety, or at least
>> making it harder to have strong types on static type systems.   but on
>> dynamic type systems, where the type is in the value and not in the
>> variable, there's no problem with nil (or None, or null), it's a
>> different type with a single value.  that's why some of the strongest
>> type systems are seen in dynamic type languages (or those with very
>> sophisticated type inference and automatic types).   in short: even if
>> NULL is a problem, it doesn't imply that nil is too.
>>
>> - neither type statics nor type strength is a value on itself.
>>
>> - the "removing nil would allow Lua to have static types!" argument
>> seems a non-sequitur, and a drawback if you happen to like dynamic
>> types.
>>
>> - the original post ended in something like "i've done the easy part,
>> and i don't have time to do the rest", which is ok if somebody else
>> sees any value in the proposal... if not, then that should be the end
>> of it until the author finds time to either advance the code or to
>> draft a more consistent language design.
>>
>>
>> --
>> Javier
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Robert Virding-2
In reply to this post by Rob Kendrick-2
Yes, it would be a terrible thing. Worst case it might actually force programmers to write correct code and code which can sensibly handle errors. I mean, where would it end?

Robert


On 10 January 2015 at 11:43, Rob Kendrick <[hidden email]> wrote:
On Fri, Jan 09, 2015 at 09:45:40PM +0100, Enrique Arizón Benito wrote:
> Hi,
>
> as Rob Kendrick indicated, replacing nil and raising an exception is the
> only possibility. (and it's a good thing to do, since this avoid the
> program to continue with an un-initialized variable).

But I actually indicated that it was a horrible thing to do :)

B.


Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Timothy Baldridge
Except it's not even about correct code. Depending on the implementation of a language its not unreasonable to attach methods to the nill type. This would make sense for something like string conversion:

nil.toString() == "nil"

Languages like Clojure also allow for this by simply extending most protocols to accept nils. So calling (count nil) returns 0. If you embrace nils, they stop becoming a hazard and start becoming just another value that has some methods and doesn't have others.

The whole deal about NULL being a "billion dollar mistake" is really completely bogus in a well designed dynamic language.

Timothy 

On Mon, Jan 12, 2015 at 2:10 PM, Robert Virding <[hidden email]> wrote:
Yes, it would be a terrible thing. Worst case it might actually force programmers to write correct code and code which can sensibly handle errors. I mean, where would it end?

Robert


On 10 January 2015 at 11:43, Rob Kendrick <[hidden email]> wrote:
On Fri, Jan 09, 2015 at 09:45:40PM +0100, Enrique Arizón Benito wrote:
> Hi,
>
> as Rob Kendrick indicated, replacing nil and raising an exception is the
> only possibility. (and it's a good thing to do, since this avoid the
> program to continue with an un-initialized variable).

But I actually indicated that it was a horrible thing to do :)

B.





--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)
Reply | Threaded
Open this post in threaded view
|

Re: Idea. Removing nils from the language.

Axel Kittenberger
Actually a few years back I suggested the same thing. 

http://lua.2524044.n2.nabble.com/Propsoal-a-lua-dialect-without-nil-td6026942.html

It is a fundamental change to a language that has lost its "storm and stress" phase. So if I can only see it happen as a derivative. If you want to do it, go for it and bring out "luap" or so. I'd sure give it a try when you finished.

I just don't have the focus to put a lot of effort into such by myself.

12