Am Fri, 25 Jan 2013 21:38:44 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 1/25/2013 2:14 PM, Jonathan M Davis wrote:
> > A property function is fundamentally different from a
> > normal function by its very nature, not just by its call syntax.
> 
> I would have agreed with you on that for years, simply taking its veracity as an axiom, but lately I am not convinced at all of that assertion. I suspect the differences between a property, field, and method are purely contrivance.
> 
> For example, even accessing a global variable isn't straightforward, if you look under the hood. If it's in a DLL or TLS, there may be a function call in there that is non-trivial.
> 

Although variable access might be implemented as a non-trivial function calls everyone tries to make these as fast as possible. Think of PLT/GOT or the TLS register on ARM processors.

And this is the difference between variable/property and function: Access to the former has to be 'fast'. There's no real definition of fast in this case, but I doubt an O(n^2) implementation of TLS or variable access in general would be acceptable to anyone.

On 24.1.2013 9:34, Walter Bright wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return
> value taking (), the () go on the return value.
>
> 2. the:
> f = g
> rewrite to:
> f(g)
> only happens if f is a function that only has overloads for () and (one
> argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.

Maybe one possible issue to note. I am sorry if someone already noted this but I didn't saw it so here it is.

In druntime's object_.d AssociativeArray has:
@property size_t length() { return _aaLen(p); }

By removing @property typeof([].length) is no longer uint or ulong. It would change into uint() or ulong(). And not just for length, but any other properties type's would change.

I think that this is one big possible code breaker for everyone that uses something similar to the following:

typeof([].length) l = [].length;

Maybe I am wrong but my personal opinion is that code like this should compile because semantically length is a property and the fact that it is a functions is just a implementation detail.

On 01/26/13 08:50, Philippe Sigaud wrote:
>>> please give us your own code and preferred solution
>>> to compile-time formatting string checking.
>> I am not interested in formatting at all. I wrote about the general problem to incorporate expectable many DSL's into one big source base, as D is intended to serve large scale coding.
> 
> And what's the solution, for you? Using strings as DSL is somewhat common in D.

I think his point was that inventing a custom dsl for everything does not scale. And he's of course right. Having one, or at most a few, common "std" dsls, plus ability do define custom ones is enough. But the "std" ones must be able to handle 95%+ of cases. So that everyone does not need to learn a set of custom per-site and/or per-project dsls.

BTW, the std compile-time string formatting "dsl" is not only checkable, but can relatively easily be parsed at CT; the compiler will then do the rest. So there's really no point in using such a CT checker - if the string can be checked then it can also be handled directly, skipping any runtime parsing overhead completely.

> As for DSL, well, I have a parser generator project here
> (https://github.com/PhilippeSigaud/Pegged), and I recently added the
> capacity to add new rules to a grammar at runtime and modify the
> resulting parse tree. I also used the existent, but unused macro
> keyword in D to get source code that can define its own subsequent
> grammar and parse tree transformations.
> Oh, and grammars can call one another, so adding a new sublanguage to
> a parent language is doable (I use this from time to time). I still
> have weeks fo work on this to have it reach the level I want, but I
> did not hit any wall up to now.
> So adding clean-looking DSL can be done in D, I think.

Yes, this is possible, and desirable, to avoid "polluting" the main language with certain "features". However it's likely not enough, as there are aspects of D which make pure macro/dsl solutions not as simple as they could be (consider static-foreach).

Your inline, parse-time, grammar extensions only work when the parser runs at CT, so the performance issues remain, right? Still, sounds interesting; and could be enough to explore the trickier cases and identify further problems. Must find time to play with it. Is that feature already in the repo?

artur

On 01/26/13 11:46, Artur Skawina wrote:
> identify further problems. Must find time to play with it. Is that feature already in the repo?

Found it. Unfortunately the old compiler here can't handle newer D features and I can't really upgrade right now, so playing with pegged will have to wait.

artur

On 2013-01-25 22:20, Andrei Alexandrescu wrote:

> That's right with the amendment that we're looking for a solution, not
> pushing one. Even the title of the thread is a question.
>
> Clearly properties are good to have. In an ideal world we wouldn't need
> a keyword for them and we'd have some simple rules for determining
> property status (especially when it comes to writes). If syntactic help
> is necessary, so be it. We want to make the language better, not worse.

It's always possible to avoid keywords in favor of syntax. Example:

Declaring a getter:

int foo {}

Just as a regular function declaration but without the parentheses.

Declaring a setter:

void foo= (int value) {}

Append an equal sign to the function name.

-- 
/Jacob Carlborg

On 2013-01-25 19:00, Rob T wrote:

> Why was a partial implementation of an experimental half-backed idea
> released into the wild?

It seems just to be how things are done in the D community. Another recent example of this is the UDA that popped up and got implemented from nowhere.

-- 
/Jacob Carlborg

On 1/26/13 2:50 AM, Philippe Sigaud wrote:
> As for DSL, well, I have a parser generator project here
> (https://github.com/PhilippeSigaud/Pegged), and I recently added the
> capacity to add new rules to a grammar at runtime and modify the
> resulting parse tree. I also used the existent, but unused macro
> keyword in D to get source code that can define its own subsequent
> grammar and parse tree transformations.
> Oh, and grammars can call one another, so adding a new sublanguage to
> a parent language is doable (I use this from time to time). I still
> have weeks fo work on this to have it reach the level I want, but I
> did not hit any wall up to now.
> So adding clean-looking DSL can be done in D, I think.
>
>> I am sure that your "stab at it" does not show any intent to
>> approach the general problem.
>
> No, indeed :) Since it's a recurring question here, I just showed it
> could be done. It's also a simple example of what can be done with D
> meta-programming capacities.

Looking forward to your talk? :o)

Andrei

On 2013-01-26 02:48, Jonathan M Davis wrote:

> : works works with any function attribute, as does {}.

And even for user defined attributes :)

-- 
/Jacob Carlborg

On 2013-01-26 08:52, Mehrdad wrote:

> Again, I didn't say they're "necessarily" true either, hence why I
> mentioned Linux and Windows specifically.
> OS X is really the odd one out here, not Windows or Linux.

They can be implemented as a function call on (at least) Linux as well. It's depends on which model is used. Which model is used then depends on various things like who the compiler is able to optimize and dynamic libraries are involved or not.

Mac OS X chose the easiest way out and implemented only one mode. A model that works in all cases, and that is a function call.

-- 
/Jacob Carlborg

On 2013-01-25 17:37, eles wrote:

> One more thing (see also this:
> http://www.25hoursaday.com/CsharpVsJava.html#properties)
>
> In order to avoid properties throwing exceptions, maybe is wise
> to impose getters and setters to be nothrow.
>
> Why? Because code like this (C#) seems a bit unnatural:
>
> try{
>
> myClock.Hours   = 28;  /* setter throws exception because 28 is
> an invalid hour value */
> myClock.Minutes = 15;
> myClock.Seconds = 39;
>
> }catch(InvalidTimeValueException itve){
>
> /* figure out which field was invalid and report error */
>
> }

One of the points of properties is to have a field with validation. To indicate the validation failed you would throw an exception. Therefore properties need to be able to throw exceptions.

-- 
/Jacob Carlborg