www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: UFCS idea

reply bearophile <bearophileHUGS lycos.com> writes:
Alex_Dovhal:


 One idea about UFCS - mark UFCS argument with  ,  _, or _ symbol,
 e.g. you have some function:



Maybe it's better to save the   prefix for a more important purpose: to tag
reference/pointer types that can't be null.



     [3,2,5,3].cycle().stride(2).take(10);
 would be written as this:
     [3,2,5,3].cycle( _).stride(2,  _).take(10,  _);



To solve such problems Haskell uses the $ operator (and the "." operator). What
about adding the same *binary* operator to D?

Bye,
bearophile
Jun 08 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Keep the language simple, why the verbosity with special symbols?
Leave that to Perl 7 fans.
Jun 08 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 Keep the language simple, why the verbosity with special symbols?
 Leave that to Perl 7 fans.



My post was referring about two or three symbols. Regarding two of them, the $
and . operators used in Haskell, they may look a bit weird for the first hour
your use Haskell, but after that you learn to appreciate them, and use them all
the time, because they allow you to write very clean code. Haskell code is not
easy to write for newbies, but it's easy enough to read. "Advanced" Haskell
code uses several funny operators (like &&&, etc), but the basic ones like ++
and $ have a very simple semantics and you use them very often. So while
Haskell is not an "easy" language, its code is more readable and quite more
clean than Perl code. In Perl you use all kind of side effects, invisible
variables, global variables, this doesn't happen in Haskell. So you can't
compare the two languages.

In the end an operator like $ is just syntax sugar, so it's not so important.

The third symbol I was talking about was the   used to denote reference/pointer
types that can't be null (and ? used for the normal nullable ones). This is not
just syntax sugar, this needs a change to the type system too. And I think it's
a change important enough to deserve a special symbol in the language. Recently
Andrei has said something is moving about this whole topic, so we'll see.

So I agree it's generally better to avoid special symbols, but there are
situations where they are acceptable, if their semantics is "natural" (like
coming from mathematics), or if their usage is very common (like the $ . ++ in
Haskell), or if they are important enough (like a symbol used to denote
nullable/nonnullable reference type).

Bye,
bearophile
Jun 08 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
bearophile wrote:

 Andrej Mitrovic:


 Keep the language simple, why the verbosity with special symbols?
 Leave that to Perl 7 fans.



 My post was referring about two or three symbols. Regarding two of them, the $



use Haskell, > but after that you learn to appreciate them, and use them all the
time, because they allow you to write very clean code. Haskell code is not easy
to
write for newbies, but

 it's easy enough to read. "Advanced" Haskell code uses several funny operators



you use them

 very often. So while Haskell is not an "easy" language, its code is more



effects, invisible

 variables, global variables, this doesn't happen in Haskell. So you can't




 In the end an operator like $ is just syntax sugar, so it's not so important.

 The third symbol I was talking about was the   used to denote reference/pointer



just syntax

 sugar, this needs a change to the type system too. And I think it's a change



said something

 is moving about this whole topic, so we'll see.

 So I agree it's generally better to avoid special symbols, but there are



from mathematics), > or if their usage is very common (like the $ . ++ in
Haskell), or if they are important enough (like a symbol used to denote
nullable/nonnullable reference type).

 Bye,
 bearophile



I'm very curious how you wold fit the $ operator into D. Afaik $ in haskell is
just an infix operator for (partial) function application at a lower
precedence? D
does not have built in partial function application since all arguments are
always
passed in tuples so you'd have a hard time to make

take 10 $ stride 2 $ cycle [1,2,3];

work in D.


Also, don't we have non-nullable references in the language already?:

int foo(ref int x){ // non nullable int reference!


Timon
Jun 08 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 6/9/11 2:10 AM, Timon Gehr wrote:

 Also, don't we have non-nullable references in the language already?:

 int foo(ref int x){ // non nullable int reference!



Nope, what's commonly meant by »non-nullable references« is, having some 
reference type, the ability to declare some variable of that type that 
can never be null, i.e.:

---
class Foo {}

void main() {
   Foo  foo; // An error, because foo would be null.
}
---

David
Jun 08 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
   Foo  foo; // An error, because foo would be null.



I believe we're getting this in the library soon. I saw disabling
the default constructor on a todo list not long ago.

By disabling the default constructor, a library construct will be
able to reliably detect null at construction time:

struct NotNull(T) {
    disable this() {}
   this(T t) { assert(t !is null); payload = t; }
   T payload;
   alias payload this;
}

NotNull!(int*) a; // error - default constructor is disabled

int* aPtr = null;
auto a = NotNull(aPtr); // assert triggers at runtime - a is never null



The type system may or may not catch nulls - depends on the specific
implementation of the struct - but worst case, it will be noticed
immediately at runtime when you try to store it.
Jun 08 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
David Nadlinger wrote:

 On 6/9/11 2:10 AM, Timon Gehr wrote:

 Also, don't we have non-nullable references in the language already?:

 int foo(ref int x){ // non nullable int reference!



 Nope, what's commonly meant by »non-nullable references« is, having some
 reference type, the ability to declare some variable of that type that
 can never be null, i.e.:

 ---
 class Foo {}

 void main() {
    Foo  foo; // An error, because foo would be null.
 }
 ---

 David



I understand that. I just think it would be a bit messy to have both  
references
and ref for call by reference.


Timon
Jun 08 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 09.06.2011 02:32, schrieb Timon Gehr:

 David Nadlinger wrote:

 On 6/9/11 2:10 AM, Timon Gehr wrote:

 Also, don't we have non-nullable references in the language already?:

 int foo(ref int x){ // non nullable int reference!



 Nope, what's commonly meant by »non-nullable references« is, having some
 reference type, the ability to declare some variable of that type that
 can never be null, i.e.:

 ---
 class Foo {}

 void main() {
    Foo  foo; // An error, because foo would be null.
 }
 ---

 David



 I understand that. I just think it would be a bit messy to have both  
references
 and ref for call by reference.
 
 
 Timon



I don't think it's for call by reference, it's to enforce that something
that already is a reference type (Objects, pointers) are not null.

Cheers,
- Daniel
Jun 08 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I doubt a non-null reference is going to get its own symbol. It's
probably going to get a new keyword. But that's just a hunch of mine.
Jun 08 2011