On Sun, 02 Aug 2009 20:53:35 -0400, Michel Fortin <michel.fortin@michelf.com> wrote:

> On 2009-08-02 20:18:51 -0400, "Robert Jacques" <sandford@jhu.edu> said:
>
>> I also like the idea of omitting parenthesis for functions with no  argument.
>
> I like it too. But the problem with the current approach D are:
>
> 1. A syntax that permits function to be called both without and with empty parenthesis creates ambiguities when it returns a callable type (a delegate or an object with an opCall member).
>
> 2. We want properties to be nouns, and actions to be verbs. In english a lot of words are both nouns and verbs, which makes it impractical to distinguish a property from a function by its name alone.
>
> Solving 1 involves having a way to say functions that can and must be called without parenthesis. Unless we want to force all functions with no parameter to be called without "()", we must have some kind of flag to tell us that a function expects or does not expect "()".
>
> Solving 2 involves making a difference in the call syntax between property and action functions. Since the idea behind a property is to mimic a field, it follows that the best differentiator for properties is the lack of parenthesis.
>
> I'd be glad too if we could continue to skip parenthesis for calls to functions with no arguments, but I think fixing the two problems above is more important.
>

I agree 1) is an issue, but I view it as a corner case. (I use zero/one arg functions all the time and make use of the 'property' syntax left right and center, but I've never run into the opCall problem) It would be nice if it were fixed, but we may be cutting off the nose to spite the face, as it were. (Or alternatively, taking the scientific instead of engineering approach)

Problem 2) I think is a major logical flaw: a property is a function. So I see no need to distinguish between the two. Properties, in fact, can be a very expensive functions that takes locks/do database lock-up/etc. So making syntax changes that make 'properties' look cheap and 'functions' look expensive is worse than what we have today. Today, at least, everyone knows that no parenthesis doesn't mean necessarily cheap O(1) operation.

Solution 1 is what I thought you were proposing. Again, I like it, though it does make zero-arg function pointers and delegates behave differently than other functions. And disallowing free_function = expression; would also address another concern many people have expressed. (Strangely enough, using the invalid code snippet: writeln = 5)

Frank Benoit wrote:
> KennyTM~ schrieb:
>> Frank Benoit wrote:
>>> Or how about making it a single method?
>>>
>>> bool empty=(bool* value){
>>>     if( value ) _empty = *value;
>>>     return _empty;
>>> }
>>>
>>> The compiler rewrites the calling code to either pass the address or
>>> null.
>> So properties can't be used in SafeD?
> 
> Hm, right pointers are not allowed there. So the "in" operator for AAs
> is also disallowed? That surprises me.

You could allow pointers in SafeD. You just can't allow pointer arithmetic, unless a pointer carries information on the upper and lower bounds of the memory block.

By the way, the -safe in dmd2 switch doesn't seem to do anything yet and allows unsafe pointer operations.

> I think this feels like a desperate grasping-at-straws attempt to not
> add a keyword (even though pure, nothrow, shared, __gshared, and
> immutable all seem to have made it in without any great fanfare).

Don't forget the introduction of ref and macro, which broke backwards compatibility in D1. macro is still unused in both D1 and D2. Comedy.

Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:h53g3i$elk$1@digitalmars.com...
>>   bool empty { ... }
>>   void empty=(bool b) { ... }
> 
> I think that if D starts to make a habit of aping the ugly C++ approach to adding new features (as this does), then we may as well just use C++.

'prop=' for property setters is used by Io, not C++.  D already much closer to C++ than Io.  (BTW, Io doesn't have operators in the same sense that C++ and D do.  '+' and 'prop=' are just identifiers in Io.)


-- 
Rainer Deyke - rainerd@eldwood.com

Robert Jacques wrote:
> On Sun, 02 Aug 2009 12:02:22 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Jarrett Billingsley wrote:
>>> I think it's funny that for a week, Andrei has been arguing against
>>> throwing around new syntax to solve this problem, and that's exactly
>>> what you guys have come up with.  Really, how much more complicated
>>> would this make the parser, compared to adding a new attribute?
>>
>> We couldn't find a good solution without adding new syntax, so this is now on the table. Adding syntax or keywords is the next thing to look at. I'd still be unsatisfied if:
>>
>> (a) there would be significant syntactic noise to defining a read-only property
>>
>> (b) we had to add a keyword
>>
>>
>> Andrei
> 
> I'd also still like to be able to do stuff like this:
> 
> auto data = std.file.readText(filename).chomp.split;

I love that too. Unfortunately, the way the water is moving, it looks like we'll lose some or all of that.

Andrei

Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:h53g3i$elk$1@digitalmars.com...
>>   bool empty { ... }
>>   void empty=(bool b) { ... }
>>
>> What do you think?
> 
> I think that if D starts to make a habit of aping the ugly C++ approach to adding new features (as this does), then we may as well just use C++. 

Let's not forget that C++ got very conservative about adding keywords after a keyword spree (class that is essentially same as struct, namespace, xyz_cast, oh yes typename, and, or, not plus other useful names that I probably forgot). We don't want to get there.


Andrei

Andrei Alexandrescu wrote:

>> auto data = std.file.readText(filename).chomp.split;
> 
> I love that too. Unfortunately, the way the water is moving, it looks like we'll lose some or all of that.

That's not really true. Some of those no-parameter functions are just meant to be read-only properties instead of functions.

auto data = std.file.textFrom(filename).chomped.split;

-- 
Michiel Helvensteijn

Michiel Helvensteijn wrote:
> Andrei Alexandrescu wrote:
> 
>>> auto data = std.file.readText(filename).chomp.split;
>> I love that too. Unfortunately, the way the water is moving, it looks
>> like we'll lose some or all of that.
> 
> That's not really true. Some of those no-parameter functions are just meant
> to be read-only properties instead of functions.
> 
> auto data = std.file.textFrom(filename).chomped.split;
> 

So to allow omission of the parenthesis of these "read-only properties" we do

@property string chomped (string x) { ... }

? I don't think Walter's syntax is capable of introducing "properties" to these free methods, but the property attribute can. (However,
this may make

chomped = "abcd"

valid, which is not what we want.)

KennyTM~ wrote:

>>>> auto data = std.file.readText(filename).chomp.split;
>>>
>>> I love that too. Unfortunately, the way the water is moving, it looks like we'll lose some or all of that.
>> 
>> That's not really true. Some of those no-parameter functions are just meant to be read-only properties instead of functions.
>> 
>> auto data = std.file.textFrom(filename).chomped.split;
> 
> So to allow omission of the parenthesis of these "read-only properties" we do

No, it's not "allowing omission", it's "forcing omission". That's what properties are.

> @property string chomped (string x) { ... }
> 
> ? I don't think Walter's syntax is capable of introducing "properties" to these free methods, but the property attribute can.

I still think an identifier is either property or function, but not both.

And judging by the way the wind is blowing, attributes/annotations will not be used for properties.

> (However, this may make
> 
> chomped = "abcd"
> 
> valid, which is not what we want.)

No, it wouldn't, since it'd be a read-only property. That means you can only read, not write.

-- 
Michiel Helvensteijn

grauzone wrote:
> Frank Benoit wrote:
>> KennyTM~ schrieb:
>>> Frank Benoit wrote:
>>>> Or how about making it a single method?
>>>>
>>>> bool empty=(bool* value){
>>>>     if( value ) _empty = *value;
>>>>     return _empty;
>>>> }
>>>>
>>>> The compiler rewrites the calling code to either pass the address or
>>>> null.
>>> So properties can't be used in SafeD?
>>
>> Hm, right pointers are not allowed there. So the "in" operator for AAs
>> is also disallowed? That surprises me.
> 
> You could allow pointers in SafeD. You just can't allow pointer arithmetic, unless a pointer carries information on the upper and lower bounds of the memory block.
> 
> By the way, the -safe in dmd2 switch doesn't seem to do anything yet 

Almost nothing. It disallows inline asm.

and
> allows unsafe pointer operations.