Re: [OT] Some neat ideas from the Kotlin language

[crimaniak via Digitalmars-d]

On my experience programming using Optional's functional 
interfaces is more reliable then explicit logic, so in case when 
we have value semantic and Optional then Kotlin's approach is not 
very useful.
My old experiments about this (obviously java-inspired): 
optional.d


import std.typecons;
import std.stdio;

Nullable!T Optional(T)(){ return Nullable!T(); }
Nullable!T Optional(T)(T value){ return Nullable!T(value); }
Nullable!OUT map(IN, OUT)(Nullable!IN n, OUT delegate(IN) fn)
{
return n.isNull() ? Nullable!OUT() : 
Nullable!OUT(fn(n.get()));

}
T orElse(T)(Nullable!T n, T value){ return n.isNull() ? value : 
n.get(); }
void ifPresent(T)(Nullable!T n, void delegate(T) fn){ 
if(!n.isNull()) fn(n.get()); }
void ifPresent(T)(Nullable!T n, void function(T) fn){ 
if(!n.isNull()) fn(n.get()); }

bool isPresent(T)(Nullable!T n){ return !n.isNull(); }
Nullable!T coalesce(T)(Nullable!T n, Nullable!T other){ return 
n.isNull() ? other : n; }




unittest
{
 assert(Optional!string().isNull());
 assert(Optional!string("asd").isPresent());
 assert(Optional!string("asd").map((string v) => v~"$") == 
"asd$");

 assert(Optional!string().map((string v) => v~"$").isNull());
 assert(Optional!string("true").map((string v) => v=="1" || 
v=="true").orElse(false) == true);
 assert(Optional!string().coalesce(Optional!string("test")) == 
"test");
 
assert(Optional!string("test1").coalesce(Optional!string("test2")) == "test1");


 string a="-";
 Optional!string("A").ifPresent((string b){a=b;});
 Optional!string().ifPresent((string b){a=b;});
 assert(a == "A");

}

Re: [OT] Some neat ideas from the Kotlin language

[Kagamin via Digitalmars-d]

On Wednesday, 24 February 2016 at 14:50:37 UTC, Andrei 
Alexandrescu wrote:

There was a related PR in Phobos, wasn't there?


https://forum.dlang.org/post/n0j9nj$10e9$1...@digitalmars.com - 
probably this.

Re: [OT] Some neat ideas from the Kotlin language

[Kagamin via Digitalmars-d]

On Wednesday, 24 February 2016 at 14:50:37 UTC, Andrei 
Alexandrescu wrote:
Probably we can do the same in a library: never allow the value 
out of an Option, but provide a visitor with two aliases 
(ham/spam).


Rust provides value accessor for Option: 
https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.unwrap

Re: [OT] Some neat ideas from the Kotlin language

[Andrei Alexandrescu via Digitalmars-d]

On 02/23/2016 09:58 AM, Xinok wrote:


Option is an enum type in Rust (i.e. algebraic data type). The Rust
compiler forces you to check all possible cases so you can't use it
improperly. So you would have to use something like pattern matching or
"if let" to check the state.

https://doc.rust-lang.org/book/match.html#matching-on-enums


Probably we can do the same in a library: never allow the value out of 
an Option, but provide a visitor with two aliases (ham/spam). There was 
a related PR in Phobos, wasn't there? -- Andrei

Re: [OT] Some neat ideas from the Kotlin language

[Kagamin via Digitalmars-d]

On Tuesday, 23 February 2016 at 22:03:32 UTC, Xinok wrote:

On Tuesday, 23 February 2016 at 19:43:43 UTC, rsw0x wrote:

...
How does this differ from the example I gave where the branch 
is only taken if the pointer is non-null?


D doesn't prevent you from dereferencing a null pointer whereas 
these scenarios should be impossible in Kotlin as well as Rust. 
Case and point, this code compiles without issue but crashes at 
runtime:


int* foo()
{
return null;
}

void main()
{
if(int* ptr = new int)
{
ptr = foo();  // Whoops...
*ptr = 35;// Crash
}
}

In D, pointers and reference types can spontaneously become 
null under almost any context. That's the difference.


The idea is to match non-null pointers, this is how you do it:

int* foo()
{
return null;
}

void main()
{
if(int* ptr = foo())
{
*ptr = 35;// no crash
}
}

Re: [OT] Some neat ideas from the Kotlin language

[Xinok via Digitalmars-d]

On Tuesday, 23 February 2016 at 19:43:43 UTC, rsw0x wrote:

...
How does this differ from the example I gave where the branch 
is only taken if the pointer is non-null?


D doesn't prevent you from dereferencing a null pointer whereas 
these scenarios should be impossible in Kotlin as well as Rust. 
Case and point, this code compiles without issue but crashes at 
runtime:


int* foo()
{
return null;
}

void main()
{
if(int* ptr = new int)
{
ptr = foo();  // Whoops...
*ptr = 35;// Crash
}
}

In D, pointers and reference types can spontaneously become null 
under almost any context. That's the difference.

Re: [OT] Some neat ideas from the Kotlin language

[rsw0x via Digitalmars-d]

On Tuesday, 23 February 2016 at 14:58:21 UTC, Xinok wrote:

On Tuesday, 23 February 2016 at 07:18:09 UTC, rsw0x wrote:
On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller 
wrote:
OTOH in the examples in Kotlin/Rust the variable 'var' 
changes its type

from 'int?' to plain 'int'.
In Kotlin this is done with static analysis, in Rust with 
rebinding of the

name.

Tobi


Rust's Option checks are not done at compile-time in most 
cases unless something changed drastically in the past ~18 
months.


Option is an enum type in Rust (i.e. algebraic data type). 
The Rust compiler forces you to check all possible cases so you 
can't use it improperly. So you would have to use something 
like pattern matching or "if let" to check the state.


https://doc.rust-lang.org/book/match.html#matching-on-enums


How does this differ from the example I gave where the branch is 
only taken if the pointer is non-null?

Re: [OT] Some neat ideas from the Kotlin language

[Xinok via Digitalmars-d]

On Tuesday, 23 February 2016 at 07:18:09 UTC, rsw0x wrote:
On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller 
wrote:
OTOH in the examples in Kotlin/Rust the variable 'var' changes 
its type

from 'int?' to plain 'int'.
In Kotlin this is done with static analysis, in Rust with 
rebinding of the

name.

Tobi


Rust's Option checks are not done at compile-time in most 
cases unless something changed drastically in the past ~18 
months.


Option is an enum type in Rust (i.e. algebraic data type). The 
Rust compiler forces you to check all possible cases so you can't 
use it improperly. So you would have to use something like 
pattern matching or "if let" to check the state.


https://doc.rust-lang.org/book/match.html#matching-on-enums

Re: [OT] Some neat ideas from the Kotlin language

[rsw0x via Digitalmars-d]

On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller wrote:

rsw0x  wrote:
On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller 
wrote:

[...]


D has this too, but only for nullable types afaik.

if(byte* ptr = someFunc()){
//...
}




That's not quite the same as there are no non-nullable pointers 
in D.
There's no guarantee from the type system that the byte* is not 
null and

there are no compiler checks involved.
It's a simple runtime check.

OTOH in the examples in Kotlin/Rust the variable 'var' changes 
its type

from 'int?' to plain 'int'.
In Kotlin this is done with static analysis, in Rust with 
rebinding of the

name.

Tobi


Rust's Option checks are not done at compile-time in most 
cases unless something changed drastically in the past ~18 months.

Re: [OT] Some neat ideas from the Kotlin language

[Tobias Müller via Digitalmars-d]

rsw0x  wrote:
> On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller 
> wrote:
>> Yuxuan Shui  wrote:
>>> [...]
>> 
>> In Rust that would be:
>> 
>> let var : Option = ...;
>> if let Some(var) = var {
>> // You can use var here
>> }
>> 
>> It works for every enum (= tagged union), not just Option
>> 
>> Swift also has "if let".
>> 
>> It's not much more verbose but more explicit.
>> Changing the type of a variable based on static analysis is 
>> just advanced
>> obfuscation. It hurts readability and the gain is questionable. 
>> At least it
>> only works for nullable types.
>> 
>> Tobi
> 
> D has this too, but only for nullable types afaik.
> 
> if(byte* ptr = someFunc()){
> //...
> }
> 
> 

That's not quite the same as there are no non-nullable pointers in D.
There's no guarantee from the type system that the byte* is not null and
there are no compiler checks involved.
It's a simple runtime check.

OTOH in the examples in Kotlin/Rust the variable 'var' changes its type
from 'int?' to plain 'int'.
In Kotlin this is done with static analysis, in Rust with rebinding of the
name.

Tobi

Re: [OT] Some neat ideas from the Kotlin language

[Russel Winder via Digitalmars-d]

On Mon, 2016-02-22 at 19:33 +, Ice Create Man via Digitalmars-d
wrote:
> On Thursday, 18 February 2016 at 23:33:45 UTC, Yuxuan Shui wrote:
> > Just come across Kotlin today, and found some interesting ideas 
> > skimming through its tutorial:
> > 
> > [...]
> 
> Both those issues predate both Kotlin and Swift. C# has had both 
> of them for as long as I've been coding in the language. Nothing 
> new here.

But lots of what Kotlin, and Ceylon, are doing are new… on the JVM. I
like new, I like progress and evolution. Just because an idea is not
objectively new, doesn't mean it isn't new and useful. Context and
application can be as refreshing as having a brand new idea. Just think
in programming languages today actors, dataflow, CSP are new, despite
being 50-ish, and 40-ish years old.
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: [OT] Some neat ideas from the Kotlin language

[Yuxuan Shui via Digitalmars-d]

On Monday, 22 February 2016 at 19:33:12 UTC, Ice Create Man wrote:
On Thursday, 18 February 2016 at 23:33:45 UTC, Yuxuan Shui 
wrote:
Just come across Kotlin today, and found some interesting 
ideas skimming through its tutorial:


[...]


Both those issues predate both Kotlin and Swift. C# has had 
both of them for as long as I've been coding in the language. 
Nothing new here.


Sure that Optional types and dynamic casts have been there for 
ages. But this is the first time I see a compiler does the 
unwrapping & casting for you based on static analyses.


And Xinok pointed out we have been using the same technique for 
detecting uninitialized variables, so what Kotlin does can be 
seen as a small, but clever, extension of this.

Re: [OT] Some neat ideas from the Kotlin language

[Ice Create Man via Digitalmars-d]

On Thursday, 18 February 2016 at 23:33:45 UTC, Yuxuan Shui wrote:
Just come across Kotlin today, and found some interesting ideas 
skimming through its tutorial:


[...]


Both those issues predate both Kotlin and Swift. C# has had both 
of them for as long as I've been coding in the language. Nothing 
new here.

Re: [OT] Some neat ideas from the Kotlin language

[Jacob Carlborg via Digitalmars-d]

On 2016-02-19 13:28, Nemanja Boric wrote:


IMHO, without language support looks really bad - `map` really sticks
out here.

What Rust is doing:

```
let foo: Option = bar();

let new_stuff = match foo {
Some(x) => x,
None => 0
}
```


You can do the same in Scala, it has built-in pattern matching. Although 
I think the map approach is preferred, but I'm not a Scala expert.


--
/Jacob Carlborg

Re: [OT] Some neat ideas from the Kotlin language

[Xinok via Digitalmars-d]

On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller 
wrote:

...
It's not much more verbose but more explicit.
Changing the type of a variable based on static analysis is 
just advanced
obfuscation. It hurts readability and the gain is questionable. 
At least it

only works for nullable types.


I consider this feature similar to requiring all control paths to 
initialize a variable or return a value. Imagine requiring some 
explicit or verbose syntax to enforce this behavior. I don't see 
this being an issue as long as the behavior is consistent between 
compilers (if code works in one compiler, it works in all 
compilers).

Re: [OT] Some neat ideas from the Kotlin language

[Steven Schveighoffer via Digitalmars-d]

On 2/20/16 5:04 AM, Daniel N wrote:

On Friday, 19 February 2016 at 21:30:37 UTC, Yuxuan Shui wrote:

I think the same applies to Swift. But I think you're supposed to use
it like this:

if let a = var {
  // a is no unwrapped
}


But you would need to give the unwrapped value a new name.



Swift also has guard, which solves this issue.

func ex(a: Int?) {
 // unwrap (possible to add additional check if desired)
 guard let a = a where a > 0 else {
 return // fail
 }

 a.ok // a is now a plain validated Int
}



I'm glad you pointed this out, I did not know this. Having to rename 
variables all the time is quite annoying.


-Steve

Re: [OT] Some neat ideas from the Kotlin language

[Daniel N via Digitalmars-d]

On Friday, 19 February 2016 at 21:30:37 UTC, Yuxuan Shui wrote:
I think the same applies to Swift. But I think you're supposed 
to use it like this:


if let a = var {
  // a is no unwrapped
}


But you would need to give the unwrapped value a new name.



Swift also has guard, which solves this issue.

func ex(a: Int?) {
// unwrap (possible to add additional check if desired)
guard let a = a where a > 0 else {
return // fail
}

a.ok // a is now a plain validated Int
}

Re: [OT] Some neat ideas from the Kotlin language

[rsw0x via Digitalmars-d]

On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller 
wrote:

Yuxuan Shui  wrote:

[...]


In Rust that would be:

let var : Option = ...;
if let Some(var) = var {
// You can use var here
}

It works for every enum (= tagged union), not just Option

Swift also has "if let".

It's not much more verbose but more explicit.
Changing the type of a variable based on static analysis is 
just advanced
obfuscation. It hurts readability and the gain is questionable. 
At least it

only works for nullable types.

Tobi


D has this too, but only for nullable types afaik.

if(byte* ptr = someFunc()){
//...
}

Re: [OT] Some neat ideas from the Kotlin language

[Tobias Müller via Digitalmars-d]

Yuxuan Shui  wrote:
> Just come across Kotlin today, and found some interesting ideas 
> skimming through its tutorial:
> 
> 1) Null check
> 
> Kotlin has Optional types, suffixed with a '?'. Like 'Int?', same 
> as in Swift. But instead of explicitly unwrapping them (e.g. var! 
> in Swift, or var.unwrap() in Rust), Kotlin let you do this:
> 
> 
> var: Int?
> if (var != null)
> //You can use var here

In Rust that would be:

let var : Option = ...;
if let Some(var) = var {
// You can use var here
}

It works for every enum (= tagged union), not just Option

Swift also has "if let".

It's not much more verbose but more explicit.
Changing the type of a variable based on static analysis is just advanced
obfuscation. It hurts readability and the gain is questionable. At least it
only works for nullable types.

Tobi

Re: [OT] Some neat ideas from the Kotlin language

[Yuxuan Shui via Digitalmars-d]

On Friday, 19 February 2016 at 12:16:49 UTC, Jacob Carlborg wrote:

On 2016-02-19 00:33, Yuxuan Shui wrote:
Just come across Kotlin today, and found some interesting 
ideas skimming

through its tutorial:

1) Null check
[snip]

You can even do this:

 if (var == null) return;
 //You can use var from now on


I think the same applies to Swift. But I think you're supposed 
to use it like this:


if let a = var {
  // a is no unwrapped
}


But you would need to give the unwrapped value a new name.



I like the way it's used in Scala:

val a = Option(value)
val b = a.map(e => e /* do something with the unrapped 
e).getOrElse(/* use a default value here */)


The Option type in Scala acts like a zero or one element 
collection. The Scala way can be implemented in D as well 
without any language support.



2) Smart cast
[snip]


It's similar how it works in D, for Objects:

class Foo {}
Object foo = new Foo;

if (auto o = cast(Foo) foo)
// use o as Foo here

When casting to a subclass it will return null reference if the 
cast fails.


The point is, in other languages you would have to explicitly do 
an operation to the wrapped value, but in Kotlin the compiler is 
able to automatically unwrap it for you when it knows doing so is 
legal, based on static analysis results.

Re: [OT] Some neat ideas from the Kotlin language

[Nick Sabalausky via Digitalmars-d]

On 02/19/2016 07:16 AM, Jacob Carlborg wrote:

On 2016-02-19 00:33, Yuxuan Shui wrote:

Just come across Kotlin today, and found some interesting ideas skimming
through its tutorial:

1) Null check

Kotlin has Optional types, suffixed with a '?'. Like 'Int?', same as in
Swift. But instead of explicitly unwrapping them (e.g. var! in Swift, or
var.unwrap() in Rust), Kotlin let you do this:


 var: Int?
 if (var != null)
 //You can use var here



Me want.




2) Smart cast

This is a similar to previous one, instead of:

 var1: Object;
 var2 = cast(String)var1;

You do this:

 if (var1 is String)
 //You can use var1 as a String here


It's similar how it works in D, for Objects:

class Foo {}
Object foo = new Foo;

if (auto o = cast(Foo) foo)
 // use o as Foo here

When casting to a subclass it will return null reference if the cast fails.



It'd be nice if it didn't require a new variable name though. When I do 
that, I usually find I wind up needing to resort to some 
hungarian-notation-inspired "start including the type in the variable's 
name" verbosity. It's a fantastic feature of D, but that Kotlin version 
seems much nicer.

Re: [OT] Some neat ideas from the Kotlin language

[Thiez via Digitalmars-d]

On Friday, 19 February 2016 at 12:28:14 UTC, Nemanja Boric wrote:

What Rust is doing:

```
let foo: Option = bar();

let new_stuff = match foo {
   Some(x) => x,
   None => 0
}
```

(or similar, I don't have compiler handy).


I think most would write that as:

let new_stuf = bar().unwrap_or(0);

When you use the methods on `Option` you rarely need to match.

Re: [OT] Some neat ideas from the Kotlin language

[Nemanja Boric via Digitalmars-d]

On Friday, 19 February 2016 at 12:16:49 UTC, Jacob Carlborg wrote:

I like the way it's used in Scala:

val a = Option(value)
val b = a.map(e => e /* do something with the unrapped 
e).getOrElse(/* use a default value here */)


The Option type in Scala acts like a zero or one element 
collection. The Scala way can be implemented in D as well 
without any language support.




IMHO, without language support looks really bad - `map` really 
sticks out here.


What Rust is doing:

```
let foo: Option = bar();

let new_stuff = match foo {
   Some(x) => x,
   None => 0
}
```

(or similar, I don't have compiler handy).

Re: [OT] Some neat ideas from the Kotlin language

[Jacob Carlborg via Digitalmars-d]

On 2016-02-19 00:33, Yuxuan Shui wrote:

Just come across Kotlin today, and found some interesting ideas skimming
through its tutorial:

1) Null check

Kotlin has Optional types, suffixed with a '?'. Like 'Int?', same as in
Swift. But instead of explicitly unwrapping them (e.g. var! in Swift, or
var.unwrap() in Rust), Kotlin let you do this:


 var: Int?
 if (var != null)
 //You can use var here


Skipping the null check will get you compile time error.

You can even do this:

 if (var == null) return;
 //You can use var from now on


I think the same applies to Swift. But I think you're supposed to use it 
like this:


if let a = var {
  // a is no unwrapped
}

I like the way it's used in Scala:

val a = Option(value)
val b = a.map(e => e /* do something with the unrapped e).getOrElse(/* 
use a default value here */)


The Option type in Scala acts like a zero or one element collection. The 
Scala way can be implemented in D as well without any language support.



2) Smart cast

This is a similar to previous one, instead of:

 var1: Object;
 var2 = cast(String)var1;

You do this:

 if (var1 is String)
 //You can use var1 as a String here


It's similar how it works in D, for Objects:

class Foo {}
Object foo = new Foo;

if (auto o = cast(Foo) foo)
// use o as Foo here

When casting to a subclass it will return null reference if the cast fails.

--
/Jacob Carlborg

[OT] Some neat ideas from the Kotlin language

[Yuxuan Shui via Digitalmars-d]

Just come across Kotlin today, and found some interesting ideas 
skimming through its tutorial:


1) Null check

Kotlin has Optional types, suffixed with a '?'. Like 'Int?', same 
as in Swift. But instead of explicitly unwrapping them (e.g. var! 
in Swift, or var.unwrap() in Rust), Kotlin let you do this:



var: Int?
if (var != null)
//You can use var here


Skipping the null check will get you compile time error.

You can even do this:

if (var == null) return;
//You can use var from now on

2) Smart cast

This is a similar to previous one, instead of:

var1: Object;
var2 = cast(String)var1;

You do this:

if (var1 is String)
//You can use var1 as a String here


I think this two ideas are pretty neat, for more information, see:

http://kotlinlang.org/docs/reference/typecasts.html