UFCS idea

Andrew Wiley wiley.andrew.j at gmail.com
Thu Jun 9 01:15:42 PDT 2011


On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:

> On 2011-06-09 00:20, Andrew Wiley wrote:
> > On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal <alex_dovhal at yahoo.com>
> wrote:
> > > There have been several topics discussing UFCS recently. So here is one
> > > more)
> > > One idea about UFCS - mark UFCS argument with @, @_, or _ symbol,
> > > e.g. you have some function:
> > > void func(Type1 p1, Type2 p2);
> > >
> > > and later call it:
> > > fucn(a, b);  //or
> > > a.func(@_, b);  //or
> > > b.func(a, @_);
> > >
> > > This way Timon Gehr's example:
> > >    take(10,stride(2,cycle([3,2,5,3])));
> > >    [3,2,5,3].cycle().stride(2).take(10);
> > >
> > > would be written as this:
> > >    [3,2,5,3].cycle(@_).stride(2, @_).take(10, @_);
> > >
> > > Which is a little longer. On the other side this way benefits from:
> > >  * UFCS is directly seen by both the programmer and compiler;
> > >  * UFCS doesn't mix with member call syntax;
> > >  * UFCS can be used for any type and for any argument, e.g.
> > >
> > >    a.func(@, b) or b.func(a, @);
> > >
> > >  * UFCS can be used for more than one argument: a.func(@_, @_~[1]);
> > >
> > > What do you think?
> >
> > I find it funny that @ was initially adopted for annotations, to be used
> > similar to Java and Scala. I come from that world, and one of the rules
> for
> > annotations is that they cannot directly alter the code the compiler
> > outputs. You can add plugins to the Java compiler that use annotations to
> > modify the AST before it's compiled, and you can use annotations for
> > runtime bytecode generation or interpret them using reflection, but if
> you
> > take unannotated code and annotated code and compile it (without altering
> > the compiler), the generated code will not change.
> > The idea was to make them a part of the language composed entirely of
> > metadata (some of which was enforced to be correct by the compiler) that
> > could be completely ignored if the programmer didn't want to use it.
> > Now that D has taken up this syntax, we've done almost the opposite. @ is
> > mostly used in situations where it changes the compiled code, changes the
> > existing language,  and is in no way optional. We don't really support
> user
> > defined metadata, and we can't use what annotations we have as metadata
> > because only the compiler can actually use it. Most of the uses I've seen
> > seem to be a way to cram more keywords into the language without adding
> > more keywords.
> > I've been holding in this sort of rant for a while, but in summary, my
> > response is that unless the desired use for @ was defined radically
> > differently by D when it was adopted (and, as far as I can tell, it
> > wasn't), seeing another abuse of it just makes me feel slightly sick
> > inside.
>
> As it is, user-defined attributes can be added later using the @ syntax.
> True,
> all of the current uses of @ are for where we decided to save a keyword,
> but
> that doesn't stop user-defined attributes from using the syntax later. It
> just
> means that those that are currently defined will always be special.
>

This is the difference in philosophy at the core of my general unhappiness.
When Java officially added annotations, they were designed and built to be
used for user-defined metadata. We added "Property" to the grammar,
celebrated that we had them too, then stopped. The result is that we're
throwing around @ as an excuse for language keywords and boasting about how
we have annotations when, by the definition of any other language, we simply
don't.
I guess the best answer from where I'm standing is to start throwing around
possible syntaxes for annotation declarations and references to them in
compile-time reflection. I just really hope this gets in to D2, so we aren't
permanently stuck with "fake annotations."


Regardless, I see little point in using it for UFCS. If we want to
> specifically mark parameters for it, I think that the suggestion of using
> "this" makes a lot more sense. You wouldn't even have to change the grammar
> (unlike if you used @). You'd just change the semantic phase to treat
> "this"
> specially as a function parameter and not freak out about it being a
> keyword.
> Using @ would be a much bigger language change and for no gain whatsoever
> as
> far as I can see.
>
>
I agree. The "this" syntax seems far more logical and straightforward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110609/b20ea36b/attachment-0001.html>


More information about the Digitalmars-d mailing list