technews@kangaroologic.com ("Jonathan Turkanis") writes:

> "David Abrahams" <dave@boost-consulting.com> wrote in message
> news:uoetia9v4.fsf@boost-consulting.com...
>> technews@kangaroologic.com (Jonathan Turkanis) writes:
>> <snip>
>> >
>> > I am wondering how much of the proposal is necessary to increase
>> > the expressive power of the language, and how much is offered as
>> > a notational convenience.
>>
>> What is the difference between notational convenience and expressive
>> power?
>>
>
> I guess you could say that since C can efficiently simulate a Turing
> Machine, all of C++ is a notational convenience. Is that what you mean?

Just about.  Else why not use machine code?

> What I meant was that a certain type of generic programming cannot
> currently be expressed fully in C++.

.. without introducing a library layer in which the programs were
written, OK ...

> If we were accept decltype but not the new function declarations,
> would the problems related to return-type deduction in Lambda, Bind,
> etc. be solved?

Only in part.  The result would be correct but not concise.

>> I used to think compilers should just "do the right thing" and
>> expose parameter names inside of any decltype that appears on the
>> left so we could just write
>>
>>   template <class T, class U>
>>   decltype(t + u) add(T t, U u);
>>
>> But I have come around to the extended function declaration syntax:
>> even if it's not idiomatic C++ today, it matches the natural syntax
>> for function declarations arrived at by Haskell, so maybe we should
>> just accept that it's better and get used to it.
>>
>
> Sure, I'll get used to it too -- probably in less than a week. But is it
> necessary?

It depends how uncomfortable some of C++'s syntax choices make you.

> I never want to have to use the '(*(T*)0)' hack; I was just
> suggesting an alternative.
>
> It occured to me that I sometimes use this hack in a different context:
> within 'sizeof(...)', e.g., when determining the results of overload
> resolution. 'instanceof' could be used there too:
>
>     template<typename T>
>     struct array_size {
>         enum { value = sizeof(T)/sizeof(instanceof(T)[0]) };
>     };

OK, my thing doesn't work there, but I don't like it.  Your instanceof
can only be used within sizeof or decltype.

How is that anything less than "mere notational convenience?"  Really,
that use of instanceof doesn't seem to have more expressive power
than:

     template<typename T>
     struct array_size {
         static T& a;
         enum { value = sizeof(T)/sizeof(a[0]) };
     };

> instead of
>
>     template<typename T>
>     struct array_size {
>         static T* t;
>         enum { value = sizeof(T)/sizeof(*t[0]) };
>     };
>
> or
>
>     template<typename T>
>     struct array_size2 {
>         enum { value = sizeof(T)/sizeof((*(T*)0)[0]) };
>     };
>
> (There might be problems with this formulation; it's just an illustration.)

There are.

> Of course it is hardly necesary for this purpose, but the example
> shows that the motivating hack for the new function declarations
> syntax occurs in other contexts already.

I'm not feeling motivated yet ;-)

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message:
> >> > I am wondering how much of the proposal is necessary to
increase
> >> > the expressive power of the language, and how much is offered
as
> >> > a notational convenience.
> >>
> >> What is the difference between notational convenience and
expressive
> >> power?
> >>
> >
> > I guess you could say that since C can efficiently simulate a
Turing
> > Machine, all of C++ is a notational convenience. Is that what you
mean?
>
> Just about.  Else why not use machine code?

 I can give a rough idea of the distinction I was trying to make as
follows: a language feature which substantially reduces the complexity
and/or amount of source code needed to achieve a certain functionality
could be said to increase expressive power; a language feature which
amounts to a superficial variation in sytax which some may find easier
to read could be called a notational convenience. I'm not arguing
against notational convenience -- I like convenience. :-)

I was wondering whether the extended function declaration syntax was
proposed as a notational convenience because I don't find it, well,
convenient. Of course I can get used to it if others find it
convenient or if it significantly reduces the amount and/or complexity
of code needed to implement widely used functionality.

> >
> > It occured to me that I sometimes use this hack in a different
context:
> > within 'sizeof(...)', e.g., when determining the results of
overload
> > resolution. 'instanceof' could be used there too:
> >
> >     template<typename T>
> >     struct array_size {
> >         enum { value = sizeof(T)/sizeof(instanceof(T)[0]) };
> >     };
>
> OK, my thing doesn't work there, but I don't like it.  Your
instanceof
> can only be used within sizeof or decltype.
>
> How is that anything less than "mere notational convenience?"
<snip>

100% notational convenience; 0% increase in expressive power.

I'm not really arguing for the introduction of an 'instanceof'
operator -- it's probably not useful enough. (Besides, in simple
cases, users who want the operator could define it as a macro.) It's
more of a challenge: it seems to eliminate the need for the type of
hack used as a motivation for the extended declaration syntax, but
without any radical change in syntax. So why not adopt the less
radical proposal?

Perhaps what I need are some more motivating examples for the new
syntax. My gut feeling is that allowing implicit return types and
allowing variables to be decalred with 'auto' will be much more useful
than allowing the return type of a function to appear last.

>
> > Of course it is hardly necesary for this purpose, but the example
> > shows that the motivating hack for the new function declarations
> > syntax occurs in other contexts already.
>
> I'm not feeling motivated yet ;-)
>

Neither am I :-)

Jonathan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

technews@kangaroologic.com ("Jonathan Turkanis") writes:

| "David Abrahams" <dave@boost-consulting.com> wrote in message
| news:uoetia9v4.fsf@boost-consulting.com...
| > technews@kangaroologic.com (Jonathan Turkanis) writes:
| > <snip>
| > >
| > > I am wondering how much of the proposal is necessary to increase the
| > > expressive power of the language, and how much is offered as a
| notational
| > > convenience.
| >
| > What is the difference between notational convenience and expressive
| > power?
| >
|
| I guess you could say that since C can efficiently simulate a Turing
| Machine, all of C++ is a notational convenience. Is that what you mean?

It is all about syntax. <g>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I notice that I got the declaration of 'add' using 'auto' wrong. Under the
previous proposal it would have been

    template <class T, class U> fun add(T t, U u) -> decltype(t + u);

According to the Sept 2003 proposal it could be something like this:

    auto add(auto t, auto u) -> decltype(t + u).

Presumably this would also be okay:

    template <class T, class U> auto add(T t, U u) -> decltype(t + u);

I hope I have it right now.

Jonathan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I've been studying the proposal by Jarvi, Stroustrup et al. to add
'decltype' and 'auto' to the language. (See
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1527.pdf.) I find the
current lack of expressive power a serious problem, and am eager to see a
facility such as this approved.

I am wondering how much of the proposal is necessary to increase the
expressive power of the language, and how much is offered as a notational
convenience. I say this because I find some of the proposed constructs a bit
hard to read, particularly the extended function declaration syntax and the
wide-ranging use of 'auto'.

For example, the syntax

     auto add(T t, U u) -> decltype(u + t);

is proposed as a replacement for the 'hack'

     template<class T,class U> decltype((*(T*)0)+(*(U*)0)) add(Tt, Uu);

Suppose we could to accustom ourselves to this hack; would there still be a
deficit in expressive power?

Has any consideration been given to introducing an official replacement for
the '(*(T*)0' hack? For instance, one could introduce an 'instanceof'
operator which takes a type and returns an expression which can be used as
an instance of that type within decltype(...):

    template<class T, class U>
    decltype(instanceof(T) + instanceof(U)) add(T, U);

Despite the verbosity I find this version easier to understand than the
formulation using ->. There is also a nice symmetry: one can see the
'instanceof' operator as a sort of inverse to the 'decltype' operator. (Some
might prefer another name, since 'instanceof' is sometimes a binary
operator, as in Java.)

Any thoughts?

Best regards,
Jonathan





---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message:

It's unfortunate that my rather cryptic correction to my original post
appeared  before the original post (my fault). My question about
typeof/decltype/auto appears in the message dated 1/4/2004.

Jonathan






---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

technews@kangaroologic.com (Jonathan Turkanis) writes:

> I've been studying the proposal by Jarvi, Stroustrup et al. to add
> 'decltype' and 'auto' to the language. (See
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1527.pdf.) I find the
> current lack of expressive power a serious problem, and am eager to see a
> facility such as this approved.
>
> I am wondering how much of the proposal is necessary to increase the
> expressive power of the language, and how much is offered as a notational
> convenience.

What is the difference between notational convenience and expressive
power?

> I say this because I find some of the proposed constructs a bit
> hard to read, particularly the extended function declaration syntax and the
> wide-ranging use of 'auto'.
>
> For example, the syntax
>
>      auto add(T t, U u) -> decltype(u + t);
>
> is proposed as a replacement for the 'hack'
>
>      template<class T,class U> decltype((*(T*)0)+(*(U*)0)) add(Tt, Uu);
>
> Suppose we could to accustom ourselves to this hack; would there still be a
> deficit in expressive power?
>
> Has any consideration been given to introducing an official replacement for
> the '(*(T*)0' hack? For instance, one could introduce an 'instanceof'
> operator which takes a type and returns an expression which can be used as
> an instance of that type within decltype(...):
>
>     template<class T, class U>
>     decltype(instanceof(T) + instanceof(U)) add(T, U);

     template <class T>
     T& instanceof();

     template<class T, class U>
     decltype(instanceof<T>() + instanceof<U>()) add(T, U);


> Despite the verbosity I find this version easier to understand than the
> formulation using ->. There is also a nice symmetry: one can see the
> 'instanceof' operator as a sort of inverse to the 'decltype' operator. (Some
> might prefer another name, since 'instanceof' is sometimes a binary
> operator, as in Java.)

I used to think compilers should just "do the right thing" and expose
parameter names inside of any decltype that appears on the left so we
could just write

  template <class T, class U>
  decltype(t + u) add(T t, U u);

But I have come around to the extended function declaration syntax:
even if it's not idiomatic C++ today, it matches the natural syntax
for function declarations arrived at by Haskell, so maybe we should
just accept that it's better and get used to it.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:uoetia9v4.fsf@boost-consulting.com...
> technews@kangaroologic.com (Jonathan Turkanis) writes:
> <snip>
> >
> > I am wondering how much of the proposal is necessary to increase the
> > expressive power of the language, and how much is offered as a
notational
> > convenience.
>
> What is the difference between notational convenience and expressive
> power?
>

I guess you could say that since C can efficiently simulate a Turing
Machine, all of C++ is a notational convenience. Is that what you mean?

What I meant was that a certain type of generic programming cannot currently
be expressed fully in C++. If we were accept decltype but not the new
function declarations, would the problems related to return-type deduction
in Lambda, Bind, etc. be solved?

>
> I used to think compilers should just "do the right thing" and expose
> parameter names inside of any decltype that appears on the left so we
> could just write
>
>   template <class T, class U>
>   decltype(t + u) add(T t, U u);
>
> But I have come around to the extended function declaration syntax:
> even if it's not idiomatic C++ today, it matches the natural syntax
> for function declarations arrived at by Haskell, so maybe we should
> just accept that it's better and get used to it.
>

Sure, I'll get used to it too -- probably in less than a week. But is it
necessary? I never want to have to use the '(*(T*)0)' hack; I was just
suggesting an alternative.

It occured to me that I sometimes use this hack in a different context:
within 'sizeof(...)', e.g., when determining the results of overload
resolution. 'instanceof' could be used there too:

    template<typename T>
    struct array_size {
        enum { value = sizeof(T)/sizeof(instanceof(T)[0]) };
    };

instead of

    template<typename T>
    struct array_size {
        static T* t;
        enum { value = sizeof(T)/sizeof(*t[0]) };
    };

or

    template<typename T>
    struct array_size2 {
        enum { value = sizeof(T)/sizeof((*(T*)0)[0]) };
    };

(There might be problems with this formulation; it's just an illustration.)

Of course it is hardly necesary for this purpose, but the example shows that
the motivating hack for the new function declarations syntax occurs in other
contexts already.

Jonathan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]