On 2015-10-11 11:45, Johannes Pfau wrote:

> We even have such a problem in object.d:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L1461
>
> I remember somebody asking in D.learn why his custom test runner did
> not work. Problem was related to wrong parenthesis: The user wrote
> mod.unitTest() instead of mod.unitTest()() IIRC. Unfortunately I can't
> find the exact link right now.

That would be me :) [1]. I think the biggest issue was that something that worked before stopped working, because a field was changed to a method and the method returned a function pointer.

[1] http://forum.dlang.org/thread/kaara7$dog$1@digitalmars.com#post-kaara7:24dog:241:40digitalmars.com

-- 
/Jacob Carlborg

On Sunday, 11 October 2015 at 01:52:12 UTC, deadalnix wrote:
> On Saturday, 10 October 2015 at 16:31:27 UTC, Ola Fosheim Grøstad wrote:
>> On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg wrote:
>>> In Ruby, no one will ever use empty parentheses for calling a method.
>>
>> That's actually the same as Simula. Functions/procedures with no parameters is called without parentheses.
>
> That's actually quite beautiful in its simplicity.

It is ok, but I find it more confusing than the C syntax when using a plain text editor. With distinguishing syntax colouring it might work out better, it is one of those cases where an IDE could make a difference.

Nygaard et al later improved on the uniformity of Simula in the language BETA by recognizing that a parameter list is the same as a tuple, with this syntax:

   input_tuple -> object_or_function -> output_tuple;
   (1,(2,3)) -> something1 -> something2 -> (a,b)
   (1,(2,3)) -> &run_concurrent_object

Without any input tuple, one can naturally omit the input arrow.

That also means that BETA does not distinguish between a function call and an assignment. An instanced object is just a function that persist state over calls, aka variable or a process/coroutine. A class type acts like a function when it called without being already instanced. So I think it provides better orthogonality than in C++/D where you can have both opCall and opAssign.

The downside by having the consise BETA syntax and OO semantics is that you need to change how you conceptualize OO modelling.

BETA has been generalized further in the academic language gbeta, which also have some dependent typing. Which is kind of interesting in relation to D, because it appears to be heavily built upon mixins:

http://www.daimi.au.dk/~eernst/gbeta/

On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim Grøstad wrote:
> That also means that BETA does not distinguish between a function call and an assignment.

Hey, neither does D!

writeln("Hello, World!");
writeln = "Hello, World!";

On Sunday, 11 October 2015 at 16:42:36 UTC, Meta wrote:
> On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim Grøstad wrote:
>> That also means that BETA does not distinguish between a function call and an assignment.
>
> Hey, neither does D!
>
> writeln("Hello, World!");
> writeln = "Hello, World!";

But BETA has a single syntax for it:

"Hello, World!" -> writeln;

On Sunday, 11 October 2015 at 17:27:39 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 11 October 2015 at 16:42:36 UTC, Meta wrote:
>> On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim Grøstad wrote:
>>> That also means that BETA does not distinguish between a function call and an assignment.
>>
>> Hey, neither does D!
>>
>> writeln("Hello, World!");
>> writeln = "Hello, World!";
>
> But BETA has a single syntax for it:
>
> "Hello, World!" -> writeln;
Just a joke; I consider this a terrible  aspect of D.

On Sunday, 11 October 2015 at 17:57:54 UTC, Meta wrote:
> Just a joke; I consider this a terrible  aspect of D.

:) I never know what is a joke or not in the forums these days.

Anyway, a key difference is that a key inspiration for both BETA and also the actor model is modelling physical (or imaginary) world processes . In that context it makes sense to think of a variable as a "process/object" that can store what you send to it just like a printer is an "process/object" asked to print what you send to it.

Most imperative languagedesign struggles with the stateful process vs pure math aspect of programming IMO.

On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
> First beta for the 2.069.0 release.
>
> http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html
>
> Please report any bugs at https://issues.dlang.org
>
> -Martin

brew reinstall dmd --devel

:) thanks for all the hard work

On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:
> I don't know how much metaprogramming-heavy generic code you've written, but I can say from first-hand experience that there is such a thing as Hell, and it is called Optional Parens.
>
> Jokes aside, I've finally fixed (read: worked around using awful hacks) a bug where the compiler was complaining about either "Type.memberFunction is not callable with arguments ()" or "Need 'this' for Type.memberFunction". I love optional parens in regular code, especially range-based code (doesn't everybody?), but I desperately want a way to ensure that the symbol that I'm trying to pass to a template function won't be interpreted as a function call instead.

Well, in order to pass the result of a function call to a template parameter means that the function must be evaluated at compile time, which is not always possible, so it probably doesn't make sense to call a function when passed as a template argument.

On Sunday, 11 October 2015 at 09:54:04 UTC, Jacob Carlborg wrote:
> That would be me :) [1]. I think the biggest issue was that something that worked before stopped working, because a field was changed to a method and the method returned a function pointer.
>
> [1] http://forum.dlang.org/thread/kaara7$dog$1@digitalmars.com#post-kaara7:24dog:241:40digitalmars.com

That refactoring is exactly the (only) use case for strict properties, they shouldn't be used in other cases.

On Tuesday, 13 October 2015 at 13:18:36 UTC, Kagamin wrote:
> Well, in order to pass the result of a function call to a template parameter means that the function must be evaluated at compile time, which is not always possible, so it probably doesn't make sense to call a function when passed as a template argument.

You'd be surprised what DMD thinks is a function call and what isn't.