Bruno Medeiros wrote:
> Andrei Alexandrescu wrote:
>> Because language design is putting many desiderata in agreement, not following one blindly.
>>
> 
> I don't get it. What other desiderata are in conflict? Those of other people, or other desiderata of your own? Because when you say "I'd like that too", I read that as meaning that, at least for your own, you would prefer if such change was implemented. (ie, weighting all your concerns, you still prefer the change)

It's really simple in fact. For example one desideratum is to not complicate the language unnecessarily. When I said I'd like that, I put aside the obvious cost of burdening the language. (Sorry for being unclear.)

>>>>> Requiring parentheses for some function calls, but not for others violates the principle of consistency.
>>>>
>>>> No. It violates economy of syntax. There are many syntaxes for the same
>>>> semantics. 
>>>
>>> It violates consistency, as defined above.
>>
>> No. You can't define a term to mean whatever you want. I mean you can, but then it's hard to communicate.
>>
> 
> By "some functions" I meant n-args functions, and by "others" I meant zero-args functions. That gives: "[Putting] parenthesis for n-args function calls, but not for zero-args function calls violates the principle of consistency."
> So we go back to the first point in this post.
> 
>>> It may violate economy of syntax as well (or it may be the same thing). Whatever. What I ask is, what would you suggest to fix it? Should all function calling not use parenthesis? And how would that syntax be?
>>
>> I'm happy with how things are now except for the assignment that is accepted all to often. I suggested a simple fix for that.
>>
>>
>> Andrei
> 
> I don't understand that. You stated "It violates economy of syntax.", so  it violates your Principle 1 of language design. So how can you be happy with that (apart from the assignment issue)? Does fixing this problem violate some other principle or concern of yours?

I think keeping the language simple is also a good goal.

Andrei

Bruno Medeiros wrote:
> Andrei Alexandrescu wrote:
>> Bruno Medeiros wrote:
>>> Sergey's argument (which is much more objective than subjective) is not strictly against omitting parenthesis, but rather against ambiguity (the dual possible ways to call zero-args functions), which as has been shown, creates various possibilities for bugs when you mix functions that return delegates. This ambiguity problem would also be resolved if omitting parenthesis would be *the only way* of calling functions with zero-args.
>>
>> Yah, he made great points. There are ambiguities. The counter-argument is that that would make the syntax of calling functions with no arguments inconsistent with the syntax of calling function with arguments. The "()" is a degenerate case of "(a, b, c)". So it's hard to keep everybody happy.
>>
> 
> Yes, if we solved the ambiguity problem that way, we would make a lot of people unhappy (myself included). But if we solved the problem the *other way* (forbidding omittable parenthesis for normal zero-args function), it would make, that I know of, only one person unhappy (you).

So there is a cabal. I knew it! :o)

I'm not that sure about "lot" and "one", and numbers-based arguments aren't that strong to begin with. Language design is complex and full of tradeoffs. In each decision there are consequences. If we require "()" then we must come with a separate thing for properties - an addition to the language. Then many people (maybe even including some the "lot" of people you mentioned) will cry foul: "where's my simple language?" etc. Maybe some people will say, hey, you were already there with the omittable "()" and the "=" thing, why didn't you just make the latter less trigger happy and we'd be home free?

One thing that often is a casualty of these discussion is keeping the eye on the big picture.

Andrei

I think someone should start a new thread on this? The argument is not relation to range design at all, and it's getting very difficult to watch this huge thread.

------

Andrei Alexandrescu wrote:
> I agree that 4 is a good principle. I'd even call it "consistency" -
> across languages that is. But let's not forget that C# defined an entire
> feature - properties - to fulfill what was perceived as a need.

And the "property" feature, unlike current D, do lift the ambiguity between procedures and properties that we (well, some of us) dislike.

I believe we all agree support for property in D is a good thing, but we just hate the current syntax (making f equivalent to f() regardless of what f is).

Again, for me, if you can restrict obj.f to be a valid getter only to pure methods (that won't cause any side effect to content of "this") then I'm all set. But probably not the others who demand getters must be fast. :)

> Also the
> Cecil language goes as far as requiring accessors for any field (and

Who uses Cecil? Never heard of it.

> defining methods implicitly when missing). Eiffel also has properties
> that are obtained via syntactic conventions (getX and setX implement
> property x). 

But not making x === x() I afraid. I don't know Eiffel, though.

> People want to add properties to Java 7 (unfortunately the
> google search is clogged by a Java class called Properties so it needs
> some combing). 

There is an explicit "property" keyword in Java and more importantly, properties are accessed using the syntax obj->prop (ugly I know). The problem we concerned do not exist.

(Ref: http://www.javalobby.org/java/forums/t88090.html; The Google search keyword is "java-7 property")

> 
> I'm impressed a lot by the analogy with math because it is one extra argument in my favor. In math there's no function without arguments. At most people would say f(.) (with a central dot) when referring to what is akin to the address of the function.
> 
> 
> Andrei

Sorry, in math the normal way to represent a function is to just use the symbol, i.e. f, e.g. chain rule (f o g)' = g' * f' o g.

The central dot is used only when the "function" is not represented in the form f(a,b,c,...), e.g. the commutator [.,.] and the mean <.>. I have *never* seen anyone writes f(.).

But I don't think we should directly apply math language to a programming language.

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> Bruno Medeiros wrote:
> >
> > I don't understand that. You stated "It violates economy of syntax.", so
> >  it violates your Principle 1 of language design. So how can you be
> > happy with that (apart from the assignment issue)? Does fixing this
> > problem violate some other principle or concern of yours?
> I think keeping the language simple is also a good goal.

I apologize if this has been brought up before, but I'm not sure that simplicity is a good thing if it can result in unpredictable behavior.  For example:

    import std.stdio;

    class C
    {
        this( bool delegate() p )
        {
            version( a )
                cond = p;
            version( b )
                ptr = p;
        }
        version( a )
        {
            bool delegate() cond;
        }
        version( b )
        {
            bool delegate() ptr;
            bool delegate() cond() { return ptr; }
        }
    }

    void main()
    {
        bool test() { writefln( "hi" ); return false; }
        auto c = new C( &test );
        if( c.cond() )
            writefln( "true" );
    }

Running version=a prints "hi" while version=b prints "true."  If there were some way in the language to say "cond() is a property" then this issue would not be silently introduced when changing cond from a variable to a method.


Sean

Bruno Medeiros wrote:
>  And of that list, only VB 6, Pascal and Perl, have the possibility of omitting parenthesis. 

Correction, Ruby allows it as well. Hum.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Here comes another person that would be unhappy without omittable parenthesis.

Having properties is a very useful thing, one should be able to make a public field of a structure private and controlling access via methods with minimal or no changes to the external code.

This is a very nice feature to have.
D reaches this with a minimal change to the language:
optional parenthesis, and setter functions.

It might take a little to get used coming from other languages, but it works well.

It does have some limitation (no +=,-=,...) but is very compact, and simple to explain.

I like it very much.

Removing it would be very bad.
The other option is to replace it with a full fledged property mechanism.
This might overcome some of the limitations of the current approach, but would it be economical?
A language should not be perfect in all things, compactness is also an advantage.

Fawzi

On 2008-10-02 19:26:55 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>>> Bruno Medeiros wrote:
>>>> Sergey's argument (which is much more objective than subjective) is not strictly against omitting parenthesis, but rather against ambiguity (the dual possible ways to call zero-args functions), which as has been shown, creates various possibilities for bugs when you mix functions that return delegates. This ambiguity problem would also be resolved if omitting parenthesis would be *the only way* of calling functions with zero-args.
>>> 
>>> Yah, he made great points. There are ambiguities. The counter-argument is that that would make the syntax of calling functions with no arguments inconsistent with the syntax of calling function with arguments. The "()" is a degenerate case of "(a, b, c)". So it's hard to keep everybody happy.
>>> 
>> 
>> Yes, if we solved the ambiguity problem that way, we would make a lot of people unhappy (myself included). But if we solved the problem the *other way* (forbidding omittable parenthesis for normal zero-args function), it would make, that I know of, only one person unhappy (you).
> 
> So there is a cabal. I knew it! :o)
> 
> I'm not that sure about "lot" and "one", and numbers-based arguments aren't that strong to begin with. Language design is complex and full of tradeoffs. In each decision there are consequences. If we require "()" then we must come with a separate thing for properties - an addition to the language. Then many people (maybe even including some the "lot" of people you mentioned) will cry foul: "where's my simple language?" etc. Maybe some people will say, hey, you were already there with the omittable "()" and the "=" thing, why didn't you just make the latter less trigger happy and we'd be home free?
> 
> One thing that often is a casualty of these discussion is keeping the eye on the big picture.
> 
> Andrei

On 2008-10-02 20:06:32 +0200, Sean Kelly <sean@invisibleduck.org> said:

> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> Bruno Medeiros wrote:
>>> 
>>> I don't understand that. You stated "It violates economy of syntax.", so
>>> it violates your Principle 1 of language design. So how can you be
>>> happy with that (apart from the assignment issue)? Does fixing this
>>> problem violate some other principle or concern of yours?
>> I think keeping the language simple is also a good goal.
> 
> I apologize if this has been brought up before, but I'm not sure that simplicity
> is a good thing if it can result in unpredictable behavior.  For example:
> 
>     import std.stdio;
> 
>     class C
>     {
>         this( bool delegate() p )
>         {
>             version( a )
>                 cond = p;
>             version( b )
>                 ptr = p;
>         }
>         version( a )
>         {
>             bool delegate() cond;
>         }
>         version( b )
>         {
>             bool delegate() ptr;
>             bool delegate() cond() { return ptr; }
>         }
>     }
> 
>     void main()
>     {
>         bool test() { writefln( "hi" ); return false; }
>         auto c = new C( &test );
>         if( c.cond() )
>             writefln( "true" );
>     }
> 
> Running version=a prints "hi" while version=b prints "true."  If there were
> some way in the language to say "cond() is a property" then this issue would
> not be silently introduced when changing cond from a variable to a method.
> 
> 
> Sean

Ok this is a good reason to have real properties, a somewhat exotic example (with a delegate one can also wrap the delegate in the functions hew wants to call , and store the wrapped delegate instead of having a property access), but still a good reason.

Fawzi

Sean Kelly wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> Bruno Medeiros wrote:
>>> I don't understand that. You stated "It violates economy of syntax.", so
>>>  it violates your Principle 1 of language design. So how can you be
>>> happy with that (apart from the assignment issue)? Does fixing this
>>> problem violate some other principle or concern of yours?
>> I think keeping the language simple is also a good goal.
> 
> I apologize if this has been brought up before, but I'm not sure that simplicity
> is a good thing if it can result in unpredictable behavior.  For example:
> 
>     import std.stdio;
> 
>     class C
>     {
>         this( bool delegate() p )
>         {
>             version( a )
>                 cond = p;
>             version( b )
>                 ptr = p;
>         }
>         version( a )
>         {
>             bool delegate() cond;
>         }
>         version( b )
>         {
>             bool delegate() ptr;
>             bool delegate() cond() { return ptr; }
>         }
>     }
> 
>     void main()
>     {
>         bool test() { writefln( "hi" ); return false; }
>         auto c = new C( &test );
>         if( c.cond() )
>             writefln( "true" );
>     }
> 
> Running version=a prints "hi" while version=b prints "true."  If there were
> some way in the language to say "cond() is a property" then this issue would
> not be silently introduced when changing cond from a variable to a method.

Oh how I am with you on this. I've always thought mentioning a delegate name should NOT EVER evaluate the delegate. Walter definitely took the wrong turn down that alley there. And guess what. He got ambushed by the "lazy" keyword right there. I told Walter to not do that "lazy" keyword, he disregarded, but the time will come when that stone will be turned.


Andrei

Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> On Thu, Oct 2, 2008 at 8:26 PM, Michel Fortin <michel.fortin@michelf.com> wrote:
>>> Compare this with properties which have exactly the same performance,
>>> memory, and flexibility implications as regular functions. The only
>>> difference between a property and a function is the meaning the author give
>>> to it, and that meaning vary between authors and contexts. Which means that
>>> from the API user point of view, something being a property or a function
>>> doesn't mean much... except of course that the user has to remember if
>>> Singleton.Instance is a property or a function before using it, or else
>>> suffer some useless compiler errors.
>>
>> Good points.
>>
>> I think this discussion is diverging a little far from the real raison
>> d'etre for property syntax, though.  They are there in the first place
>> not to save the typing of a few () here and there, but to allow a
>> library designer to start with a plain field when that suffices and
>> transition to a function later if that becomes necessary, without
>> breaking client code.  And there's where we can invoke a grand
>> principle of software design as Andrei would have us do:
>>
>> * Changing implementation details should not affect client code.
>>
>> Ok I guess that's a software design principle, not language design but
>> I guess I can say the underlying language principle is that the a good
>> language should facilitate good software design.
>>
>> This one has to trump principles about economy of syntax and such,
>> because the point of having a language in the first place is to make
>> writing software easier/better/faster.
>>
>> More specifically this is a case of where we want syntax to facilitate
>> making the transition from a simple field to something with some logic
>> too.  So what can we hope to get from the language to support this in
>> the best way possible.   These two conclusions seem pretty obvious to
>> me:
>>
>> 1) The "fake" field's behavior should be indistinguishable from real
>> field behavior in as many circumstances as possible.  This prevents
>> client code from  having to change.  This is why things like += on a
>> property should be transformed by the compiler.
>> 2) In situations where behavior does differ from that of a real field,
>> a compiler error should occur at the point of usage.  This prevents
>> nasty surprises where code silently starts behaving incorrectly.  This
>> suggests that something like attempting to take the address of the
>> field should be a syntax error if the field is turned into a property
>> function.   (This probably already happens in most cases since a
>> function pointer won't usually be interchangeable with an int pointer
>> or whatever it was before)
>>
>> Anyway, the point I want to make is that while it's neat that you can
>> save typing a few parentheses, there are more important things, like
>> being able to refactor code locally and knowing with reasonable
>> certainty that all client code will either still work correctly or
>> fail to compile.
>>
>> Going by these principles could lead to some interesting conclusions
>> like for instance an argument that you shouldn't be able to take the
>> address of a property function, or do anything else to it that exposes
>> the fact that it is not, in fact, a field.
> 
> Yes, I entirely agree. I mentioned this a couple of times, but never explained it so well and thoroughly.
> 
> Andrei

Me too.

My previous use of the word "consistency" was perhaps a little sloppy, but I think Bill explains my thoughts to a tee.

I'd be happiest if we could strengthen the semantics of properties, to make them indistinguishable from fields (from the class consumer's perspective). If we can't accomplish that, I'd rather do without the optional-parentheses and "x.prop = 3" tricks, using functions instead of properties.

--benji

On Fri, Oct 3, 2008 at 3:16 AM, Fawzi Mohamed <fmohamed@mac.com> wrote:

> This is a very nice feature to have.
> D reaches this with a minimal change to the language:
> optional parenthesis, and setter functions.
>
> ...
> It does have some limitation (no +=,-=,...) but is very compact, and simple
> to explain.

Fortunately this is an orthogonal issue.  This could (and should IMO) be fixed independent of the current discussion.

--bb