The problem isn't about following haskell precisely or not (I
think we shouldn't). The problem is wanting to have everything,
and resulting in getting nothing.
Let's take haskell as example. Function are all pure. So it
doesn't matter when a function get executed or not, and, as a
result,
On Tuesday, 7 August 2012 at 18:36:28 UTC, deadalnix wrote:
The problem isn't about following haskell precisely or not (I
think
we shouldn't). The problem is wanting to have everything, and
resulting in getting nothing.
Let's take haskell as example. Function are all pure. So it
doesn't
Timon Gehr , dans le message (digitalmars.D:174361), a écrit :
On 08/06/2012 09:42 PM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to
Le 07/08/2012 07:45, David Piepgrass a écrit :
class A { void B() {} }
auto a = new A().B();
// ^ semicolon expected following auto declaration, not '.'
Obviously. No clue what this snippet is trying to do.
Well I meant int B() { return 0; } of course. I think you deliberately
miss the
On Monday, 6 August 2012 at 19:45:17 UTC, deadalnix wrote:
Le 06/08/2012 21:07, Mafi a écrit :
No dereferencing is done in the compiled code anyway. BTW, an
«
address of » operation is done on the type mentioned above.
I don't get what you are saying here. For me there's an
inherent
Le 07/08/2012 14:15, Mafi a écrit :
On Monday, 6 August 2012 at 19:45:17 UTC, deadalnix wrote:
Le 06/08/2012 21:07, Mafi a écrit :
No dereferencing is done in the compiled code anyway. BTW, an «
address of » operation is done on the type mentioned above.
I don't get what you are saying
Le 06/08/2012 20:05, David Piepgrass a écrit :
I'm not sure if I understand your point perfectly, but I definitely feel
that the way D handles optional parens is awful.
That is the point.
More specifically, the fact that D picks functionality from different
paradigm here that totally don't
You do not seriously expect D to copy exactly how Haskel (or any
other similar declarative langauge) treat functions? Does it
really have to be an exact copy? I am not trying to defend D
language designer(s) here, just trying to say that D should have
own style, if there is sense behind it, it
Le 07/08/2012 17:14, Dejan Lekic a écrit :
You do not seriously expect D to copy exactly how Haskel (or any other
similar declarative langauge) treat functions? Does it really have to be
an exact copy? I am not trying to defend D language designer(s) here,
just trying to say that D should have
On Tuesday, 7 August 2012 at 15:14:09 UTC, Dejan Lekic wrote:
You do not seriously expect D to copy exactly how Haskel (or
any other similar declarative langauge) treat functions? Does
it really have to be an exact copy? I am not trying to defend D
language designer(s) here, just trying to say
It is known that some part of D are very dmd's implementation defined.
One of the part is manipulation function as first class objects and
implicitly calling them.
Some digressions about functional programing first.
Functional programming emphasis function purity, function as first class
deadalnix:
The same way, the difference between a delegate and an expression don't
exist anymore.
int fun();
int fun(int t);
One solution would be to find a way that would enable fun to be both a
function and its return type, and that would enable 1.fun to be both
delegate and its return
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the language.
Le 06/08/2012 19:25, Timon Gehr a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the language.
We already have bizantine language rule here.
Le 06/08/2012 19:20, Christophe Travert a écrit :
What do you think?
The implicit cast is likely to create madness, especially for template
instantiation.
On Monday, 6 August 2012 at 16:40:02 UTC, deadalnix wrote:
It is known that some part of D are very dmd's implementation
defined. One of the part is manipulation function as first
class objects and implicitly calling them.
...
To me, the first big failure of D to implement functional style
To me, the first big failure of D to implement functional style
is to not have first class functions. You get a function using
operator. But does it really make sense ? See code below :
void foo(){}
void bar(void function() buzz) {}
void main() { bar(foo); } // This will execute foo, and so
On 08/06/2012 07:54 PM, deadalnix wrote:
Le 06/08/2012 19:25, Timon Gehr a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the language.
We already have
On 08/06/2012 06:40 PM, deadalnix wrote:
It is known that some part of D are very dmd's implementation defined.
One of the part is manipulation function as first class objects and
implicitly calling them.
Some digressions about functional programing first.
Functional programming emphasis
On 08/06/2012 08:05 PM, David Piepgrass wrote:
...
I'm not sure if I understand your point perfectly, but I definitely feel
that the way D handles optional parens is awful. The other day I noticed
that the following is a syntax error (DMD 2.059):
class A { void B() {} }
auto a = new A().B();
Le 06/08/2012 20:01, Mafi a écrit :
This comes from the 'real' function type is 'void f()' whose usage is
deprecated in D except for any function-/method-declaration:
Imagine a C-style declaration of the fuction type and you'll come to the
conclusion it's the way one defines functions in
On Monday, 6 August 2012 at 18:29:38 UTC, deadalnix wrote:
Le 06/08/2012 20:01, Mafi a écrit :
This comes from the 'real' function type is 'void f()' whose
usage is
deprecated in D except for any function-/method-declaration:
Imagine a C-style declaration of the fuction type and you'll
come
Le 06/08/2012 20:15, Timon Gehr a écrit :
To me, the first big failure of D to implement functional style is to
not have first class functions.
Last time I checked, D still had closures. The 'first big failure of D
to implement functional style' is the lack of most of the other
features
Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the language.
What exactly do you consider byzantine here,
Le 06/08/2012 21:07, Mafi a écrit :
No dereferencing is done in the compiled code anyway. BTW, an «
address of » operation is done on the type mentioned above.
I don't get what you are saying here. For me there's an inherent
difference between a fuction and a function pointer. You shouldn't
Le 06/08/2012 21:42, Christophe Travert a écrit :
Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the
On 08/06/2012 09:42 PM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the
Le 06/08/2012 22:45, Timon Gehr a écrit :
It isn't. My point is that there actually is no issue that would
require some complex solution.
Actually, we have a very complex solution with no issue. That is in
itself, an issue, especially when that very complex solution isn't
defined properly
On 08/06/2012 09:33 PM, deadalnix wrote:
Le 06/08/2012 20:15, Timon Gehr a écrit :
To me, the first big failure of D to implement functional style is to
not have first class functions.
Last time I checked, D still had closures. The 'first big failure of D
to implement functional style' is the
class A { void B() {} }
auto a = new A().B();
// ^ semicolon expected following auto declaration, not '.'
Obviously. No clue what this snippet is trying to do.
Well I meant int B() { return 0; } of course. I think you
deliberately miss the point.
30 matches
Mail list logo
