Advice about adding Option<T> in the Std?

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

Advice about adding Option<T> in the Std?

sledorze
Hi!
I see a lot of projects recreating their Own:

enum Option<T> {
  None;
  Some(v : T);
}

Can't we, at least, just introduce these 4 lines as part of the standard API?
..It would solve so much conflicts between APIs.

Stephane

P.S.:
I would love to see Stax (or something like it) taking much importance but I agree the amount of code it generates CAN be a show stopper, even if it can help saving much code if properly used afterwhile.
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

blackdog
On 11/09/2011 11:43 AM, sledorze wrote:

> Hi!
> I see a lot of projects recreating their Own:
>
> enum Option<T>  {
>    None;
>    Some(v : T);
> }
>
> Can't we, at least, just introduce these 4 lines as part of the standard
> API?
> ..It would solve so much conflicts between APIs.
>
> Stephane
>
> P.S.:
> I would love to see Stax (or something like it) taking much importance but I
> agree the amount of code it generates CAN be a show stopper, even if it can
> help saving much code if properly used afterwhile.
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6978190.html
> Sent from the Haxe mailing list archive at Nabble.com.
>
+1

--
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

Cauê W.
+1 and +1 for a minified stax version. What I do in my projects usually is to do

#if stax typedef Option<T> = haxe.Prelude.Option<T>
#else
enum Option<T>
{
...
}

#end

but stax must be defined manually since there is still no haxelib support for it yet :(

2011/11/9 blackdog <[hidden email]>
On 11/09/2011 11:43 AM, sledorze wrote:
Hi!
I see a lot of projects recreating their Own:

enum Option<T>  {
  None;
  Some(v : T);
}

Can't we, at least, just introduce these 4 lines as part of the standard
API?
..It would solve so much conflicts between APIs.

Stephane

P.S.:
I would love to see Stax (or something like it) taking much importance but I
agree the amount of code it generates CAN be a show stopper, even if it can
help saving much code if properly used afterwhile.


--
View this message in context: http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6978190.html
Sent from the Haxe mailing list archive at Nabble.com.

+1

--
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

Juraj Kirchheim
I think nullability should be revisited instead. Technically Null<T>
should do the same thing ... and happen to be faster at runtime.
Of course this matter is far more complicated, but OTOH it could
really solve a lot of problems.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

Cauê W.
yeah, I agree with you Juraj!
The problem would be mostly with backwards compatibility, as this would certainly break it. Maybe for haxe 3?

It would be so cool to have null-safety on haxe out of the box!

2011/11/9 Juraj Kirchheim <[hidden email]>
I think nullability should be revisited instead. Technically Null<T>
should do the same thing ... and happen to be faster at runtime.
Of course this matter is far more complicated, but OTOH it could
really solve a lot of problems.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

John A. De Goes
In reply to this post by Juraj Kirchheim

Null<T> is not the same at all. 

var street: Option<String> = person.flatMap(function(person) return person.address.flatMap(function(address) return address.street));

where Person is Option<Person>, and Person.address is Option<Address>.

Try doing that (or many other things) with Null<T>. Nulls don't compose at all.

Regards,

John A. De Goes
Twitter: @jdegoes 
LinkedIn: http://linkedin.com/in/jdegoes

On Nov 9, 2011, at 3:38 PM, Juraj Kirchheim wrote:

I think nullability should be revisited instead. Technically Null<T>
should do the same thing ... and happen to be faster at runtime.
Of course this matter is far more complicated, but OTOH it could
really solve a lot of problems.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

sledorze
In reply to this post by Juraj Kirchheim
I agree the Null<T> type behaving like an unboxed Option would be nice, especially when working against raw external stuctures without being able to change them, definitively.

If you use null, you do not destructure a value to access it.
To prevent illegal access then you need to protect it against access if it's not checked before.
So theorically, this requiers a sort of Type states / tagging and propagation (or something equivalent).

I don't think the compiler handle this currently as I've not seen such features.
However perhaps there's some short cuts on ifs or switch with the introduction of a fresh variable shadowing the Null<T> in the inner scope if the if/switch.

I the meanwhile, Option addition would a be nice addition - and ready in 5 mins.. :)

Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

sledorze
In reply to this post by John A. De Goes
Hi John,

I think if we can do something like using 'using' on Null<..> and be able to build it recursively, ( Null<Null<..>> ) then it can compose.

Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

Tarwin Stroh-Spijer
Sorry for playing the fool again : where would you use this?


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Wed, Nov 9, 2011 at 3:41 PM, sledorze <[hidden email]> wrote:
Hi John,

I think if we can do something like using 'using' on Null<..> and be able to
build it recursively, ( Null<Null&lt;..>> ) then it can compose.



--
View this message in context: http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6980030.html
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

sledorze
This post was updated on .
I use that in all my programs over and over..
It's because I program in Functionnal style (FP), or hybrid, no more OOP tragedy.

in 2005, after 20 years of programming in OOP style, (11 years professionnally), I felt so sad programming, writing over and over the same boilerplate in C++ or the like.. (even with macros, boost, whatever) I felt the pain, wanted to change my job..

..then (and I will always rememeber this day), a friend of mine showed me two stuff:
ASIT:
http://www.start2think.com/?hop=pjarry
and then SICP videos:
http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/

(we won't talk about ASIT here.. really)
 
We've seen the first lecture of SICP.
then the second..
back home I watched the whole straight.

(I was half saved..)
then I decided I have to find where the current status of FP is and eventually had to decide between learning Ocaml or Haskell.
I choosed Haskell (was quite a brain twist to start with but very valuable).

Then I learned/toyed with Erlang, Nemerle, Clean, Omega, Idris, F#, etc..
(At this time I knew haXe and tried to push it inside the company I was working at).

In the next job I had as a Technical Director in 2008 I throw in Scala because I knew it would be the best candidate to become the next mainstream ground breaker in the next decade (I think I am right).

All these languages incorporate FP capabilities (like haxe does), so you can easily build upon them, they are very reliables, maintenables and  fast to program - because FP enable abstraction composition!

If you want to see the light, you got to look for it by yourself! It's a journey..
Here's the best paper ever to start with - don't resist, dive, feel the beauty, leverage the power .. :

http://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf

Enjoy!
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

blackdog

I'm  no where near to Stephane's or John's functional chops, but I spent
some time learning lisp (clojure), a couple of years ago, and it changed
the way i was thinking about programming too (having always been oop).
Particularly, reducing class var usage  to reduce state was one of my
main takeaways. So now, I try to write a lot of static functions and
keep class hierarchies as flat as possible. The "using" feature really
helps in this style too for a more succinct composition of static functions.

The main benefit is I find I can write code faster as I'm not trying to
plan for all possibilities at the start, as I think one tends to do with
oop. It's easier to refactor and recompose the smaller units too, you
don't get locked into a grand overarching design as much. In fact you
see this all through the haxe standard lib, Nicolas's code is very much
a flat style.

Anyway, I'm glad we have some functional gurus here, to learn from and
maybe help push functional features of haxe.

R


On 11/10/2011 05:10 AM, sledorze wrote:

> I use that in all my programs over and over..
> It's because I program in Functionnal style (FP), or hybrid, no more OOP
> tragedy.
>
> in 2005, after 20 years of programming in OOP style, (11 years
> professionnally), I felt so sad programming, writing over and over the same
> boilerplate in C++ or the like.. (even with macros, boost, whatever) I felt
> the pain, wanted to change my job..
>
> ..then (and I will always rememeber this day), a friend of mine showed me
> two stuff:
> ASIT:
> http://www.start2think.com/?hop=pjarry
> and then SICP videos:
> http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
>
> (we won't talk about ASIT here.. really)
>
> We've seen the first lecture of SICP.
> then the second..
> back one I watched the whole straight.
>
> (I was half saved..)
> then I decided I have to find where the current status of FP is and
> enventually had to decide between learning Ocaml or Haskell.
> I choose Haskell (was quite a brain twist to start with but very valuable).
>
> Then I learned/toyed with Erlang, Nemerle, Clean, Omega, Idris, F#, etc..
> (At this time I knew haXe and tried to push it inside the company I was
> working at).
>
> In the next job I had as a Technical Director in 2008 I throw in Scala
> because I knew it would be the best candaidate to become the next mainstream
> ground breaker in the next decade (I think I am right).
>
> All these languages incorporate FP capabilities (like haxe does), so you can
> easily build upon them, they are very reliables, maintenables and  fast to
> program - because FP enable abstraction composition!
>
> If you want to see the light, you got to look for it by yourself! It's a
> journey..
> Here's the best paper ever to start with - don't resist, dive, feel the
> beauty, leverage the power .. :
>
> http://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf
>
> Enjoy!
>
>
> --
> View this message in context: http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6980871.html
> Sent from the Haxe mailing list archive at Nabble.com.
>


--
Simplicity is the ultimate sophistication. ~ Leonardo da Vinci


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

Juraj Kirchheim
In reply to this post by John A. De Goes
On Thu, Nov 10, 2011 at 12:21 AM, John A. De Goes <[hidden email]> wrote:
>
> Null<T> is not the same at all.
>
> var street: Option<String> = person.flatMap(function(person) return
> person.address.flatMap(function(address) return address.street));
>
> where Person is Option<Person>, and Person.address is Option<Address>.
> Try doing that (or many other things) with Null<T>. Nulls don't compose at
> all.

Ok, I read this as person is Option<Person> and person.address is
Option<Address>. Whether Option is in the Std lib or not doesn't
change that that's wishful thinking. This would have to be introduced
at language level and there's no reason why you shouldn't be able to
do this with Null. In fact right now, I can easily write a macro where
person.get(address).get(street) will safely return me a Null<Street>,
or a Street if person and Person::address are both typed non-null.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

sledorze
Option is more than what John use case shows..
Please, let me introduce you Typeclassopedia:
little graph:
( Option is a MonadPlus )
and a summary:
The real pdf is worth knowing..

( For understanding where Option lies inside it, you have to know Option is called Maybe (Nothing | Just a) in the haskell world )

Every type class defined in it represents some concepts (concept being the name took by next C++ standard to introduce type classes) you can work with with appropriate combinators.

Sticking to the only samples we can throw via email will never give you the whole picture.
I takes time to understand FP concepts and their full utility.

But yes, like I said, I think we could see Null as an unbowed Option. At least as long as we do not rely on Dynamic as we would not differentiate Null<T> from Null<Null<T>> ..



On Thu, Nov 10, 2011 at 12:18 PM, Juraj Kirchheim [via Haxe] <[hidden email]> wrote:
On Thu, Nov 10, 2011 at 12:21 AM, John A. De Goes <[hidden email]> wrote:
>
> Null<T> is not the same at all.
>
> var street: Option<String> = person.flatMap(function(person) return
> person.address.flatMap(function(address) return address.street));
>
> where Person is Option<Person>, and Person.address is Option<Address>.
> Try doing that (or many other things) with Null<T>. Nulls don't compose at
> all.

Ok, I read this as person is Option<Person> and person.address is
Option<Address>. Whether Option is in the Std lib or not doesn't
change that that's wishful thinking. This would have to be introduced
at language level and there's no reason why you shouldn't be able to
do this with Null. In fact right now, I can easily write a macro where
person.get(address).get(street) will safely return me a Null<Street>,
or a Street if person and Person::address are both typed non-null.

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6981315.html
To unsubscribe from Advice about adding Option<T> in the Std?, click here.
See how NAML generates this email



--
Stéphane Le Dorze


Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

Juraj Kirchheim
I think Null<T> is exactly what you want. It is basically enum Null<T>
{ T; null; }

However the language should reduce Null<Null<X>> to Null<X> (which it
basically does already).
For options to be really usable, you'd want exactly the same thing,
but if you create them as standard enums, then you don't get this and
Option<Option<Option<X>>> is not compatible with Option<X>, while
Null<Null<X>> is compatible with Null<X> and X is compatible with
Null<X> as well.

This is completely something for haXe 3.0, because it's actually a
drastic change, that couldn't work without a big incision in the std
library:

        var h = new Hash<X>();
        ...
        h.get('foo');//this is Null<X> because the key couldn't be set
        if (h.exists('foo'))
                 h.get('foo');//this is still Null<X> although we just *know* it is X

And it would have to be modified like this (or maybe there's a better way yet):

        var h = new Hash<X>();
        ...
        h.tryGet('foo');//this is Null<X> because the key couldn't be set
        if (h.exists('foo'))
                 h.get('foo');//this is X
        h.get('bar');//this is X or it will throw an exception

It would also put up a lot of questions like how to ensure that
instance-fields are non-null etc.
I think nullability is an extremely delicate thing and since it is
part of haXe by design, it should be decently solved, rather than
working around it with yet another fancy trick, that comes with its
own set of quirks.

To my knowledge haXe would be the first non-academic language to
provide a clean solution to nullability and it would mean a lot more
safety without sacrificing speed. Just think of it: No null guard
clauses anywhere. Just declare the argument as non-null and the caller
will have to deal with it.

A solution to this problem would also be beneficiary to those, who
don't want to use haXe to do haskell programming (which I doubt to be
a good idea in the first place, but ok). After all, haXe is a
multi-paradigm language.

On Thu, Nov 10, 2011 at 1:33 PM, sledorze <[hidden email]> wrote:

> Option is more than what John use case shows..
> Please, let me introduce you Typeclassopedia:
> little graph:
> http://www.haskell.org/haskellwiki/Typeclassopedia
> ( Option is a MonadPlus )
> and a summary:
> http://typeclassopedia.citizen428.net/
> The real pdf is worth knowing..
> ( For understanding where Option lies inside it, you have to know Option is
> called Maybe (Nothing | Just a) in the haskell world )
> Every type class defined in it represents some concepts (concept being the
> name took by next C++ standard to introduce type classes) you can work with
> with appropriate combinators.
> Sticking to the only samples we can throw via email will never give you the
> whole picture.
> I takes time to understand FP concepts and their full utility.
> But yes, like I said, I think we could see Null as an unbowed Option. At
> least as long as we do not rely on Dynamic as we would not differentiate
> Null<T> from Null<Null<T>> ..
>
>
>
> On Thu, Nov 10, 2011 at 12:18 PM, Juraj Kirchheim [via Haxe] <[hidden
> email]> wrote:
>>
>> On Thu, Nov 10, 2011 at 12:21 AM, John A. De Goes <[hidden email]> wrote:
>> >
>> > Null<T> is not the same at all.
>> >
>> > var street: Option<String> = person.flatMap(function(person) return
>> > person.address.flatMap(function(address) return address.street));
>> >
>> > where Person is Option<Person>, and Person.address is Option<Address>.
>> > Try doing that (or many other things) with Null<T>. Nulls don't compose
>> > at
>> > all.
>>
>> Ok, I read this as person is Option<Person> and person.address is
>> Option<Address>. Whether Option is in the Std lib or not doesn't
>> change that that's wishful thinking. This would have to be introduced
>> at language level and there's no reason why you shouldn't be able to
>> do this with Null. In fact right now, I can easily write a macro where
>> person.get(address).get(street) will safely return me a Null<Street>,
>> or a Street if person and Person::address are both typed non-null.
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6981315.html
>> To unsubscribe from Advice about adding Option<T> in the Std?, click here.
>> See how NAML generates this email
>
>
> --
> Stéphane Le Dorze
> http://lambdabrella.blogspot.com/
> http://www.linkedin.com/in/stephaneledorze
> http://twitter.com/stephaneledorze
> Tel: +33 (0) 6 08  76 70 15
>
>
> ________________________________
> View this message in context: Re: Advice about adding Option<T> in the Std?
> Sent from the Haxe mailing list archive at Nabble.com.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

sledorze
Option<Option<T>> != Option<T> and this IS *VERY* nice for composition reasons !
and the language SHOULD NOT reduce Null<Null<T>> to Null<T> for Option like behavior.

Nice supports what you propose:

But Again (your vision of) Null and Option are not at all semantically the same concepts; this does not mean they cannot live together, however.

I don't think you'll like that.. :) :

Null the billion dollards mistake (from its author):
http://lambda-the-ultimate.org/node/3186

The best you can do to avoid a problem is to avoid its root causes; it's neat, problem solved, period.
So avoid it as much as possible; encapsulate it when possible / requiered; too much kittens has been killed so far..

Also, optimization (which null has to do with) is the wrong default; do it on purpose after the feature is done and only on relevant parts..

Hope it helps; it's the best I can say from my (derived)knowledge/experience in programming..


On Thu, Nov 10, 2011 at 2:15 PM, Juraj Kirchheim [via Haxe] <[hidden email]> wrote:
I think Null<T> is exactly what you want. It is basically enum Null<T>
{ T; null; }

However the language should reduce Null<Null<X>> to Null<X> (which it
basically does already).
For options to be really usable, you'd want exactly the same thing,
but if you create them as standard enums, then you don't get this and
Option<Option<Option<X>>> is not compatible with Option<X>, while
Null<Null<X>> is compatible with Null<X> and X is compatible with
Null<X> as well.

This is completely something for haXe 3.0, because it's actually a
drastic change, that couldn't work without a big incision in the std
library:

        var h = new Hash<X>();
        ...
        h.get('foo');//this is Null<X> because the key couldn't be set
        if (h.exists('foo'))
                 h.get('foo');//this is still Null<X> although we just *know* it is X

And it would have to be modified like this (or maybe there's a better way yet):

        var h = new Hash<X>();
        ...
        h.tryGet('foo');//this is Null<X> because the key couldn't be set
        if (h.exists('foo'))
                 h.get('foo');//this is X
        h.get('bar');//this is X or it will throw an exception

It would also put up a lot of questions like how to ensure that
instance-fields are non-null etc.
I think nullability is an extremely delicate thing and since it is
part of haXe by design, it should be decently solved, rather than
working around it with yet another fancy trick, that comes with its
own set of quirks.

To my knowledge haXe would be the first non-academic language to
provide a clean solution to nullability and it would mean a lot more
safety without sacrificing speed. Just think of it: No null guard
clauses anywhere. Just declare the argument as non-null and the caller
will have to deal with it.

A solution to this problem would also be beneficiary to those, who
don't want to use haXe to do haskell programming (which I doubt to be
a good idea in the first place, but ok). After all, haXe is a
multi-paradigm language.

On Thu, Nov 10, 2011 at 1:33 PM, sledorze <[hidden email]> wrote:

> Option is more than what John use case shows..
> Please, let me introduce you Typeclassopedia:
> little graph:
> http://www.haskell.org/haskellwiki/Typeclassopedia
> ( Option is a MonadPlus )
> and a summary:
> http://typeclassopedia.citizen428.net/
> The real pdf is worth knowing..
> ( For understanding where Option lies inside it, you have to know Option is
> called Maybe (Nothing | Just a) in the haskell world )
> Every type class defined in it represents some concepts (concept being the
> name took by next C++ standard to introduce type classes) you can work with
> with appropriate combinators.
> Sticking to the only samples we can throw via email will never give you the
> whole picture.
> I takes time to understand FP concepts and their full utility.
> But yes, like I said, I think we could see Null as an unbowed Option. At
> least as long as we do not rely on Dynamic as we would not differentiate
> Null<T> from Null<Null<T>> ..
>
>
>
> On Thu, Nov 10, 2011 at 12:18 PM, Juraj Kirchheim [via Haxe] <[hidden

> email]> wrote:
>>
>> On Thu, Nov 10, 2011 at 12:21 AM, John A. De Goes <[hidden email]> wrote:
>> >
>> > Null<T> is not the same at all.
>> >
>> > var street: Option<String> = person.flatMap(function(person) return
>> > person.address.flatMap(function(address) return address.street));
>> >
>> > where Person is Option<Person>, and Person.address is Option<Address>.
>> > Try doing that (or many other things) with Null<T>. Nulls don't compose
>> > at
>> > all.
>>
>> Ok, I read this as person is Option<Person> and person.address is
>> Option<Address>. Whether Option is in the Std lib or not doesn't
>> change that that's wishful thinking. This would have to be introduced
>> at language level and there's no reason why you shouldn't be able to
>> do this with Null. In fact right now, I can easily write a macro where
>> person.get(address).get(street) will safely return me a Null<Street>,
>> or a Street if person and Person::address are both typed non-null.
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6981315.html
>> To unsubscribe from Advice about adding Option<T> in the Std?, click here.
>> See how NAML generates this email
>
>
> --
> Stéphane Le Dorze
> http://lambdabrella.blogspot.com/
> http://www.linkedin.com/in/stephaneledorze
> http://twitter.com/stephaneledorze
> Tel: <a href="tel:%2B33%20%280%29%206%2008%20%C2%A076%2070%2015" value="+33608767015" target="_blank">+33 (0) 6 08  76 70 15
>
>
> ________________________________
> View this message in context: Re: Advice about adding Option<T> in the Std?
> Sent from the Haxe mailing list archive at Nabble.com.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6981549.html
To unsubscribe from Advice about adding Option<T> in the Std?, click here.
See how NAML generates this email



--
Stéphane Le Dorze


Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

sledorze
Don't take me wrong.. I would love to flatMap on raw externs null values.. ;)
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

Juraj Kirchheim
In reply to this post by sledorze
On Thu, Nov 10, 2011 at 2:34 PM, sledorze <[hidden email]> wrote:
> Option<Option<T>> != Option<T> and this IS *VERY* nice for composition
> reasons !

Possibly this is very nice for academic reasons, but I am eager to be
convinced otherwise. Care to explain this with a concrete and concise
code example?

> Nice supports what you propose:
> http://nice.sourceforge.net/

Well then that's Nice. But as a haXe developer, that's not of much use to me.

> But Again (your vision of) Null and Option are not at all semantically the
> same concepts; this does not mean they cannot live together, however.
> I don't think you'll like that.. :) :
> Null the billion dollards mistake (from its author):
> http://lambda-the-ultimate.org/node/3186

I know that statement, yes. I am aware of the problems with null.
Therefore I think the problem should be addressed.

> The best you can do to avoid a problem is to avoid its root causes; it's
> neat, problem solved, period.

No. The best what you can do is solve the problem. Null is there, and
it must therefore be dealt with or possibly excluded from the language
as a matter of last resort.

What you propose is a work-around and one should strive to remove
deficiencies rather than to circumvent them. It introduces bloat,
where there could be simplicity. It is inherently slower. It doesn't
integrate well with the rest of the language (any time I want to
promote X to Option<X> I have to do this by hand, which is a dull
repetitive task and introduces noise). And most importantly: it
doesn't solve the problem at all. Every time you read an Option from
an Array, retrieve it as the head of a List or look it up in a Hash,
you're risking to step into the very same bear trap.
What you do is to pretend the problem isn't there, but it is. As of
now, null is a valid value for Option<T> and a switch on null where an
enum is expected causes a runtime error, because this isn't
semantically covered by the language. And you have nothing but good
faith to avoid this. Nothing but a contract between me and you will
make me consider null when passing Option.Some(myArray.pop()) to your
code and from my perspective it is not one bit more typesafe than if
you accepted a plain value instead.

I am confident, that Null being properly treated by the typesystem
would render Option obsolete, because the same problem would be better
solved in 3 way:
- entirely, because it would deal with all nullability problems
- transparently, because if I have an X at hand and want to pass it to
a function that accepts null as well, I don't care
- without performance cost, which means that one doesn't have to
choose between speed and safety - because this choice is all but
trivial when designing code for reuse

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

sledorze
You're right ;)

Sent from my iPhone

On 10 nov. 2011, at 15:50, "Juraj Kirchheim [via Haxe]" <[hidden email]> wrote:

On Thu, Nov 10, 2011 at 2:34 PM, sledorze <[hidden email]> wrote:
> Option<Option<T>> != Option<T> and this IS *VERY* nice for composition
> reasons !

Possibly this is very nice for academic reasons, but I am eager to be
convinced otherwise. Care to explain this with a concrete and concise
code example?

> Nice supports what you propose:
> http://nice.sourceforge.net/

Well then that's Nice. But as a haXe developer, that's not of much use to me.

> But Again (your vision of) Null and Option are not at all semantically the
> same concepts; this does not mean they cannot live together, however.
> I don't think you'll like that.. :) :
> Null the billion dollards mistake (from its author):
> http://lambda-the-ultimate.org/node/3186

I know that statement, yes. I am aware of the problems with null.
Therefore I think the problem should be addressed.

> The best you can do to avoid a problem is to avoid its root causes; it's
> neat, problem solved, period.

No. The best what you can do is solve the problem. Null is there, and
it must therefore be dealt with or possibly excluded from the language
as a matter of last resort.

What you propose is a work-around and one should strive to remove
deficiencies rather than to circumvent them. It introduces bloat,
where there could be simplicity. It is inherently slower. It doesn't
integrate well with the rest of the language (any time I want to
promote X to Option<X> I have to do this by hand, which is a dull
repetitive task and introduces noise). And most importantly: it
doesn't solve the problem at all. Every time you read an Option from
an Array, retrieve it as the head of a List or look it up in a Hash,
you're risking to step into the very same bear trap.
What you do is to pretend the problem isn't there, but it is. As of
now, null is a valid value for Option<T> and a switch on null where an
enum is expected causes a runtime error, because this isn't
semantically covered by the language. And you have nothing but good
faith to avoid this. Nothing but a contract between me and you will
make me consider null when passing Option.Some(myArray.pop()) to your
code and from my perspective it is not one bit more typesafe than if
you accepted a plain value instead.

I am confident, that Null being properly treated by the typesystem
would render Option obsolete, because the same problem would be better
solved in 3 way:
- entirely, because it would deal with all nullability problems
- transparently, because if I have an X at hand and want to pass it to
a function that accepts null as well, I don't care
- without performance cost, which means that one doesn't have to
choose between speed and safety - because this choice is all but
trivial when designing code for reuse

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6981815.html
To unsubscribe from Advice about adding Option<T> in the Std?, click here.
See how NAML generates this email
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

sledorze
In reply to this post by Juraj Kirchheim
I am on the move, so may answer later. But if you don't feel the need, no problem..
I can't sell fp is à best tool to do / use impérative stuff.
At this, oo is easier.

Sent from my iPhone

On 10 nov. 2011, at 15:50, "Juraj Kirchheim [via Haxe]" <[hidden email]> wrote:

On Thu, Nov 10, 2011 at 2:34 PM, sledorze <[hidden email]> wrote:
> Option<Option<T>> != Option<T> and this IS *VERY* nice for composition
> reasons !

Possibly this is very nice for academic reasons, but I am eager to be
convinced otherwise. Care to explain this with a concrete and concise
code example?

> Nice supports what you propose:
> http://nice.sourceforge.net/

Well then that's Nice. But as a haXe developer, that's not of much use to me.

> But Again (your vision of) Null and Option are not at all semantically the
> same concepts; this does not mean they cannot live together, however.
> I don't think you'll like that.. :) :
> Null the billion dollards mistake (from its author):
> http://lambda-the-ultimate.org/node/3186

I know that statement, yes. I am aware of the problems with null.
Therefore I think the problem should be addressed.

> The best you can do to avoid a problem is to avoid its root causes; it's
> neat, problem solved, period.

No. The best what you can do is solve the problem. Null is there, and
it must therefore be dealt with or possibly excluded from the language
as a matter of last resort.

What you propose is a work-around and one should strive to remove
deficiencies rather than to circumvent them. It introduces bloat,
where there could be simplicity. It is inherently slower. It doesn't
integrate well with the rest of the language (any time I want to
promote X to Option<X> I have to do this by hand, which is a dull
repetitive task and introduces noise). And most importantly: it
doesn't solve the problem at all. Every time you read an Option from
an Array, retrieve it as the head of a List or look it up in a Hash,
you're risking to step into the very same bear trap.
What you do is to pretend the problem isn't there, but it is. As of
now, null is a valid value for Option<T> and a switch on null where an
enum is expected causes a runtime error, because this isn't
semantically covered by the language. And you have nothing but good
faith to avoid this. Nothing but a contract between me and you will
make me consider null when passing Option.Some(myArray.pop()) to your
code and from my perspective it is not one bit more typesafe than if
you accepted a plain value instead.

I am confident, that Null being properly treated by the typesystem
would render Option obsolete, because the same problem would be better
solved in 3 way:
- entirely, because it would deal with all nullability problems
- transparently, because if I have an X at hand and want to pass it to
a function that accepts null as well, I don't care
- without performance cost, which means that one doesn't have to
choose between speed and safety - because this choice is all but
trivial when designing code for reuse

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6981815.html
To unsubscribe from Advice about adding Option<T> in the Std?, click here.
See how NAML generates this email
Reply | Threaded
Open this post in threaded view
|

Re: Advice about adding Option<T> in the Std?

Cauê W.
one option would be to add a way to strictly parse Null<> variables, so you can e.g. make your library or entire code "entirely null-safe", but still compile without the strict directive. Maybe this strict directive could be also set on a per-file basis

2011/11/10 sledorze <[hidden email]>
I am on the move, so may answer later. But if you don't feel the need, no problem..
I can't sell fp is à best tool to do / use impérative stuff.
At this, oo is easier.

Sent from my iPhone

On 10 nov. 2011, at 15:50, "Juraj Kirchheim [via Haxe]" <[hidden email]> wrote:

On Thu, Nov 10, 2011 at 2:34 PM, sledorze <[hidden email]> wrote:
> Option<Option<T>> != Option<T> and this IS *VERY* nice for composition
> reasons !

Possibly this is very nice for academic reasons, but I am eager to be
convinced otherwise. Care to explain this with a concrete and concise
code example?

> Nice supports what you propose:
> http://nice.sourceforge.net/

Well then that's Nice. But as a haXe developer, that's not of much use to me.

> But Again (your vision of) Null and Option are not at all semantically the
> same concepts; this does not mean they cannot live together, however.
> I don't think you'll like that.. :) :
> Null the billion dollards mistake (from its author):
> http://lambda-the-ultimate.org/node/3186

I know that statement, yes. I am aware of the problems with null.
Therefore I think the problem should be addressed.

> The best you can do to avoid a problem is to avoid its root causes; it's
> neat, problem solved, period.

No. The best what you can do is solve the problem. Null is there, and
it must therefore be dealt with or possibly excluded from the language
as a matter of last resort.

What you propose is a work-around and one should strive to remove
deficiencies rather than to circumvent them. It introduces bloat,
where there could be simplicity. It is inherently slower. It doesn't
integrate well with the rest of the language (any time I want to
promote X to Option<X> I have to do this by hand, which is a dull
repetitive task and introduces noise). And most importantly: it
doesn't solve the problem at all. Every time you read an Option from
an Array, retrieve it as the head of a List or look it up in a Hash,
you're risking to step into the very same bear trap.
What you do is to pretend the problem isn't there, but it is. As of
now, null is a valid value for Option<T> and a switch on null where an
enum is expected causes a runtime error, because this isn't
semantically covered by the language. And you have nothing but good
faith to avoid this. Nothing but a contract between me and you will
make me consider null when passing Option.Some(myArray.pop()) to your
code and from my perspective it is not one bit more typesafe than if
you accepted a plain value instead.

I am confident, that Null being properly treated by the typesystem
would render Option obsolete, because the same problem would be better
solved in 3 way:
- entirely, because it would deal with all nullability problems
- transparently, because if I have an X at hand and want to pass it to
a function that accepts null as well, I don't care
- without performance cost, which means that one doesn't have to
choose between speed and safety - because this choice is all but
trivial when designing code for reuse

--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/Advice-about-adding-Option-T-in-the-Std-tp6978190p6981815.html
To unsubscribe from Advice about adding Option<T> in the Std?, click here.
See how NAML generates this email


View this message in context: Re: Advice about adding Option<T> in the Std?
Sent from the Haxe mailing list archive at Nabble.com.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
12