"Alf P. Steinbach" wrote:
> * SuperKoko:
> > "Alf P. Steinbach" wrote:
> >> Yep.  I think it's beyond hope to get a new, alternative typedef syntax
> >> in place.  In an ideal world, perhaps one could get a 'typename'
> >> construct added, used like (compare to real code in previous posting)
> >>
> >> <hypotheticalcode>
> >> #include <utility>                  // std::pair
> >> #include <boost/shared_ptr.hpp>     // boost::shared_ptr
> >> namespace stdx = boost;
> >>
> >> template< typename T >
> >> struct List
> >> {
> >>      typename Node;      // NEW LANGUAGE FEATURE, recursive defs.
> >>      typedef stdx::shared_ptr<Node>  Instance;
> >>      typedef std::pair<T, Instance>  Node;
> >>
> >>      static Instance null() { return Instance(); }
> >>      static Instance cons( T const& v, Instance list )
> >>      {
> >>          return Instance( new :Node( v, list ) );
> >>      }
> >> };
> >>
> >
> > Do you mean, something similar to (forward) declarations of structures.
>
> Yes.
>
>
> > In that case, it is not possible
>
> It is.
>
>
> >(or at least, not a good idea):
>
> I think it is.
>
>
> > It would require that all pointers have the same object representation.
>
> They already have, for pointers to class type objects. :-)
>
For class objects, but not for all objects!
Class objects can't have either performances or space efficiency of
scalar types on some platforms.

For example on a true 32 bits platform where individual bytes can't be
accessed, it might be good to have 8 bits bytes, in order to allow
space efficients algorithms working on char.

In that case it would be possible to write space-efficient algorithms
using char pointers.

But, on the same platform, it might be sensible, because class pointers
all have the same representation, to give 4-bytes alignment
requirements to all classes.

And:
struct X {
  public:
  char c;
};

Would not be such as sizeof(X)==4
When writing low-level things, space efficiency would be possible,
using raw char pointers instead of structures or classes.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

skaller wrote:
[...]
> I have a fairly long (unwritten) list of issues with C++,
> some of which can be corrected, some which are just my own
> incompetence, and some of which can be bypassed by using
> a code generator. I have spent something like 6 years
> more or less full time investigating this.
>
> In addition my perception is a lot of effort is being put
> into making C++ easier to use for human programmers,
> whereas I see a use for C++ in a different role,
> which doesn't seem to be taken as seriously.

>From what you write I get the impression that you expect ISO C++ to
provide a complete runtime support for languages like your own Felix.
Surely a special purpose library would also be needed? Or are the
difficulties you mention related to being unable to write such a
library efficiently?

> I personally believe the focus of the Standardisation
> committee needs to change, so that use of C++ as a target
> language is given more weight in deliberations.

I think this would be more plausible if you provided more concrete
examples of the kind of changes you have in mind.

[...]
> If there is any interest, I will try to post a list
> of issues. The difficulty is that whilst some are
> easy to describe, and some are easy to provide simple
> motivating examples for, others are much harder to
> present.

I'd be interested in reading them.

> A good way to reduce the difficulty of this
> presentation is to focus on *correctable* problems,
> which I think requires a considerable amount of
> expertise not just in C++, but in both the C++ Standard
> and the ISO standardisation process. If we could throw
> in a couple of library designers and compiler implementors
> that would help too :)

You could still try and convince the whole community by posting
descriptions of specific issues, either in this newsgroup or in
comp.lang.c++.moderated, if they're more related to the usage of the
language than to issues with the standard.

Cheers,
Nicola Musatti

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

skaller wrote:
[...]
> Whilst I have no objection to continued improvement of C++
> for human coders, my concerns have turned to different,
> though not unrelated usage: as compiler backend target language.
> In the long term I think this usage is more important!

In my opinion this depends on how you plan to do it. I think C++ would
be suitable to implement a set of primitives on which to implement
higher level languages and then write compilers and interpreters whose
generated code is expressed in terms of those primitives.

This would be analogous to how some compilers today generate assembly
code / machine language. As today we take for granted that machine
instructions are correctly implemented, the primitives I mentioned
above would have to be simple enough to be reliable, yet raise and
expand the kind of abstractions on which programming languages are
based.

However I'm not convinced that this is what you mean, so I'm not sure I
really see the advantages you envision over generating C.

[...]
> Furthermore, by targeting C++ there is the possibility
> of binding to existing C++ code, without the need
> for C level glue logic to wrap up C++ features used
> such as exceptions and constructors.

This in itself would be a great bonus; I often wish scripting languages
like, say, Python were implemented in C++ rather than C.

[...]
> However, there are a number of problems which have varying
> impact on using C++ as a target language. For example
> the nice property of C unions that any data type can be
> used for a union variant component is lost in C++,
> with very serious consequences for a code generator:
> the workaround destroys many of the very advantages C++
> offers, and simultaneously makes the generated code
> entirely unreadable.

Could you provide a concrete example of why this is a problem?

>Another problem, the inability
> of templates to handle type recursion properly, virtually
> rules out any possibility of generating templated code.

Could you give an example of the kind of code that would take advantage
of this possibility?

Cheers,
Nicola Musatti

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Tue, 18 Jul 2006 21:52:31 +0000, Larry Evans wrote:

> On 07/18/2006 12:54 PM, skaller wrote:
> [snip]
>> impact on using C++ as a target language. For example
>> the nice property of C unions that any data type can be
>> used for a union variant component is lost in C++,
>> with very serious consequences for a code generator:
>> the workaround destroys many of the very advantages C++
>> offers, and simultaneously makes the generated code
>> entirely unreadable.
>
> Why wouldn't boost's variant or any solve these problems?

It might, but it isn't part of ISO C++, and in fact boost
variant isn't portable (it requires alignment information
that can only be calculated by a configuration script).

Of course the basic variant is useless because it doesn't
support recursion. By the time I looked at the recursive
version I gave up.

>> Another problem, the inability
>> of templates to handle type recursion properly, virtually
>> rules out any possibility of generating templated code.
>
> Could you define proper type recursion and show why c++'s
> method rules out generating templated code?

Sure: there is no way to do this in C++ at the moment:

 typedef list[T] = Empty | Cons of T * list[T];

This is Felix notation, similar to that used in ML languages.

In C you'd do this with some hackery like:

 struct list { T data; struct list *next; };

If you have a pair template, you want this in C++

 template<class T>
 typedef list<T> = pair<T, list<T>*>;

There is no way to do this in C++ at all. Since there are no
templated typedef we can try the usual class hack:

 template<class T> struct list {
  typedef pair<T, typename list<T>::type> type;
 };

but it doesn't work. You could try:

 template<class T> struct list {
  typedef pair<T, list<T> > type;
 };

This is compiles but it doesn't actually name the correct
type: neither 'list' nor 'list<T>::type' is actually a list.
In fact 'list' is just an empty struct, and list<int>::type
is just a pair consisting of an int and an empty struct .. :)

You can of course construct a list:

 template<class T>
 struct list { T data; list<T> *next; };

The problem is you had to write it out by hand,
you couldn't use the template combinator 'pair',
because type recursion doesn't work.

Sorry I haven't "defined" why type recursion doesn't
work, that's not the kind of question that can be answered.
Nor does giving an example 'prove' it.

In fact Gabriel des Rios <sp?> showed how it CAN be done,
in a general setting, using a technique known as open
recursion. With that technique you introduce a dummy
type argument for the fixpoint, and then you fix
it with a partial specialisation.

All in all, even if that works, it is just out
of the question for the average programmer, and it
is so hard to keep track of for a code generator ..
compared to simply implementing a working system of
first order polymorphism in the code generator
and ignoring templates altogether. It really is
easier to completely reinvent templates properly
than bother trying to make current ISO C++ ones work.

I think this can be fixed, although I'm not sure.
In fact Gaby proposed something like what I wrote above.

 template<class T>
 typedef list<T> = pair<T, list<T>*>;

Using the

 typedef x = y;

form, apart from being logical and readable compared to
the utterly stupid C typedef syntax, also introduces
the name being typedef'd into the scope of its own
definition, allowing type recursion. This cannot be
done with the existing typedef syntax because it
would break compatibility.

--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

* skaller:
> On Tue, 18 Jul 2006 21:52:31 +0000, Larry Evans wrote:
>> On 07/18/2006 12:54 PM, skaller wrote:
>>> Another problem, the inability
>>> of templates to handle type recursion properly, virtually
>>> rules out any possibility of generating templated code.
>> Could you define proper type recursion and show why c++'s
>> method rules out generating templated code?
>
> Sure: there is no way to do this in C++ at the moment:
>
>  typedef list[T] = Empty | Cons of T * list[T];
>
> This is Felix notation, similar to that used in ML languages.
>
> In C you'd do this with some hackery like:
>
>  struct list { T data; struct list *next; };
>
> If you have a pair template, you want this in C++
>
>  template<class T>
>  typedef list<T> = pair<T, list<T>*>;
>
> There is no way to do this in C++ at all.

I'm not sure what you mean, but sitting down at the keyboard and
implementing a little "functional-language-like" list (instead of just
using std::list ;-) ) based on std::pair, I found the following language
limitations:

   * no template typedef (is coming in C++0x, AFAIK)
   * verbiage (as I understand it, is also addressed)

More?

<code>
#include <utility>                  // std::pair
#include <boost/shared_ptr.hpp>     // boost::shared_ptr
namespace stdx = boost;

template< typename T >
struct List
{
     struct Node;
     typedef stdx::shared_ptr<Node>  Instance;
     struct Node: std::pair< T, Instance >
     {
         typedef std::pair< T, Instance > Base;
         Node() {}
         Node( T v, Instance list ): Base( v, list ) {}
     };

     static Instance null()
     {
         static Instance theNull;
         return theNull;
     }
};

template< typename T >
typename List<T>::Instance cons( T const& v, typename List<T>::Instance
list )
{
     return List<T>::Instance( new typename List<T>::Node( v, list ) );
}

#include    <iostream>
#include    <ostream>

int main()
{
     typedef List<int>   IntList;

     for(    IntList::Instance list  =
                 cons( 1, cons( 2, cons( 3, IntList::null() ) ) );
             list;
             list = list->second )
     {
         std::cout << list->first << std::endl;
     }
}
</code>


[snip]
> You can of course construct a list:
>
>  template<class T>
>  struct list { T data; list<T> *next; };
>
> The problem is you had to write it out by hand,
> you couldn't use the template combinator 'pair',
> because type recursion doesn't work.

See above.

But I wonder whether that will be possible with the proposed template
typedef for C++0x?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Fri, 21 Jul 2006 01:59:45 -0600, Alf P. Steinbach wrote:


>> If you have a pair template, you want this in C++
>>
>>  template<class T>
>>  typedef list<T> = pair<T, list<T>*>;
>>
>> There is no way to do this in C++ at all.
>
> I'm not sure what you mean,

'no way to do it' isn't clear? :)

>but sitting down at the keyboard and
> implementing a little "functional-language-like" list (instead of just
> using std::list ;-) ) based on std::pair, I found the following language
> limitations:
>
>    * no template typedef (is coming in C++0x, AFAIK)

Be nice to have confirmation of that.
Has it passed WG21 yet?

>    * verbiage (as I understand it, is also addressed)

Verbiage will never be fully addressed for C++.
Improvements will be nice though. The 'auto' deduction
will be very cool.

> More?
>
> <code>
> #include <utility>                  // std::pair
> #include <boost/shared_ptr.hpp>     // boost::shared_ptr
> namespace stdx = boost;
>
> template< typename T >
> struct List
> {
>      struct Node;
>      typedef stdx::shared_ptr<Node>  Instance;
>      struct Node: std::pair< T, Instance >
>      {
>          typedef std::pair< T, Instance > Base;
>          Node() {}
>          Node( T v, Instance list ): Base( v, list ) {}
>      };
>
>      static Instance null()
>      {
>          static Instance theNull;
>          return theNull;
>      }
> };

I think this relies on a trick that only works in
special cases (though I'm not 100% sure).

Instead of writing

 typedef list<T> = pair<T, list<T>* >;

you write:

 Node : pair <T, Node* >

where : means 'inheritance'. At this point, Node is
incomplete. This is 'open recursion'. You then
close the recursion by completing the type.

Rather unfortunate you have to define a class to
do that, and can't freely write type expressions.

You can do this:

 pair< T, pair< U, ptr<V> > >

for any pre-existing types T, U, V, but have to go through
hoops when recursion is required.

In some sense you bypassed the real requirement: to be
able to specify types in combinator form. In particular
the above construction forces you to lift the type definition
out of local code into the global scope (since local classes
don't have extern linkage and so can't be used in templates).

There is also another defect: list is a variant,
but you have cheated and used a special case which is
already a variant, namely the moral equivalent of:

 ptr<T> = NULL | Ptr_to_real_object T

but again .. this is probably a variant issue not
a recursion one. Nice job actually!


--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

* skaller:
>
> Instead of writing
>
>  typedef list<T> = pair<T, list<T>* >;
>
> you write:
>
>  Node : pair <T, Node* >
>
> where : means 'inheritance'. At this point, Node is
> incomplete. This is 'open recursion'. You then
> close the recursion by completing the type.
>
> Rather unfortunate you have to define a class to
> do that, and can't freely write type expressions.

Yep.  I think it's beyond hope to get a new, alternative typedef syntax
in place.  In an ideal world, perhaps one could get a 'typename'
construct added, used like (compare to real code in previous posting)

<hypotheticalcode>
#include <utility>                  // std::pair
#include <boost/shared_ptr.hpp>     // boost::shared_ptr
namespace stdx = boost;

template< typename T >
struct List
{
     typename Node;      // NEW LANGUAGE FEATURE, recursive defs.
     typedef stdx::shared_ptr<Node>  Instance;
     typedef std::pair<T, Instance>  Node;

     static Instance null() { return Instance(); }
     static Instance cons( T const& v, Instance list )
     {
         return Instance( new :Node( v, list ) );
     }
};

#include    <iostream>
#include    <ostream>

int main()
{
     typedef List<int>   IntList;
     using class IntList;    // NEW LANGUAGE FEATURE, less verbiage.

     for(    Instance list  =
                 cons( 1, cons( 2, cons( 3, null() ) ) );
             list;
             list = list->second )
     {
         std::cout << list->first << std::endl;
     }
}
</hypotheticalcode>

Or, if we get templated namespaces, then less need for 'using class'.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

"Alf P. Steinbach" wrote:
> Yep.  I think it's beyond hope to get a new, alternative typedef syntax
> in place.  In an ideal world, perhaps one could get a 'typename'
> construct added, used like (compare to real code in previous posting)
>
> <hypotheticalcode>
> #include <utility>                  // std::pair
> #include <boost/shared_ptr.hpp>     // boost::shared_ptr
> namespace stdx = boost;
>
> template< typename T >
> struct List
> {
>      typename Node;      // NEW LANGUAGE FEATURE, recursive defs.
>      typedef stdx::shared_ptr<Node>  Instance;
>      typedef std::pair<T, Instance>  Node;
>
>      static Instance null() { return Instance(); }
>      static Instance cons( T const& v, Instance list )
>      {
>          return Instance( new :Node( v, list ) );
>      }
> };
>

Do you mean, something similar to (forward) declarations of structures.

In that case, it is not possible (or at least, not a good idea):
It would require that all pointers have the same object representation.

//Translation unit 1:

typename AnUnknownType; // assume that it creates an incomplete type

int main() {
  AnUnknownType* p=0; /* which size? which null-pointer representation?
*/
}

//Translation unit 2:

typedef int AnUnknownType;


In particular, on true 32 bits machine which can't address natively
individual octets, a possible implementation may have 8-bits bytes and
32 bits (4-bytes aligned) int pointers, but 64 bits pointers to
character types and void pointers.

The performance loss of using the same representation for all pointers
would be really big.

The only acceptable solution I see, is to distinguish between pointers
having a declaration preceding a definition.
That is:

typename Type;
typedef int Type; // Type would not be equivalent to int, but would
behave such as Type* has a generic representation (e.g. the same
representation as void*).

In that case, the sample of code I gave, with two translation units
would be rewritten:

//Translation unit 1:

typename AnUnknownType; // assume that it creates an incomplete type

int main() {
  AnUnknownType* p=0; /* which size? which null-pointer representation?
*/
}

//Translation unit 2:
typename AnUnknownType;
typedef int AnUnknownType;


Mhhh... That is not a pretty solution.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

* SuperKoko:
> "Alf P. Steinbach" wrote:
>> Yep.  I think it's beyond hope to get a new, alternative typedef syntax
>> in place.  In an ideal world, perhaps one could get a 'typename'
>> construct added, used like (compare to real code in previous posting)
>>
>> <hypotheticalcode>
>> #include <utility>                  // std::pair
>> #include <boost/shared_ptr.hpp>     // boost::shared_ptr
>> namespace stdx = boost;
>>
>> template< typename T >
>> struct List
>> {
>>      typename Node;      // NEW LANGUAGE FEATURE, recursive defs.
>>      typedef stdx::shared_ptr<Node>  Instance;
>>      typedef std::pair<T, Instance>  Node;
>>
>>      static Instance null() { return Instance(); }
>>      static Instance cons( T const& v, Instance list )
>>      {
>>          return Instance( new :Node( v, list ) );
>>      }
>> };
>>
>
> Do you mean, something similar to (forward) declarations of structures.

Yes.


> In that case, it is not possible

It is.


>(or at least, not a good idea):

I think it is.


> It would require that all pointers have the same object representation.

They already have, for pointers to class type objects. :-)

[lengthy irrelevant argument, snipped]

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Tue, 18 Jul 2006 17:54:48 +0000, skaller wrote:

>
> ===================================== MODERATOR'S COMMENT:
>
> This article is marginally on-topic, but seems interesting and does relate to
> (for example) the stability of the C++ standard. If the poster doesn't care to
> read replies in the newsgroup, I guess that's his problem, not the problem of
> people who want to respond in the newsgroup.

Sorry I was not quite as clear as I should have been!'

I will of course respond to posts on this topic here
on the newsgroup, however the article is basically a request
for people interested in doing some work investigating issues
and presenting them to the C++ committee in the form of a
paper to contact me. Surely that is on-topic for comp.std.c++?

Most of the prior article is intended to provide motivation and
some background to explain why I am interested.

I have a fairly long (unwritten) list of issues with C++,
some of which can be corrected, some which are just my own
incompetence, and some of which can be bypassed by using
a code generator. I have spent something like 6 years
more or less full time investigating this.

In addition my perception is a lot of effort is being put
into making C++ easier to use for human programmers,
whereas I see a use for C++ in a different role,
which doesn't seem to be taken as seriously.

I personally believe the focus of the Standardisation
committee needs to change, so that use of C++ as a target
language is given more weight in deliberations. This is
basically because I think it has gone as far as it can
go in terms of offering high level facilities, and whilst
it will remain a strong mainstream language for some time
to come, there are many new languages available today
for application programming: Java, C#, Ocaml, Python ..

Focusing on minor improvements in usability by hand coders
will not rescue it from the natural move to other
systems, and major changes are ruled out both by the
Standardisation process itself, and the limitations
of the basic design.

You can write good code in C++ but in large scale
projects a huge amount of manual housekeeping is needed,
and verification that protocols have been properly followed
is exceedingly difficult. (Just look at containers conforming
to the Standard Library requirements for a simple example).

To me the *logical* way forward is to stop writing
as much raw C++ by hand, and instead generate some of it
with tools that guarantee various protocols are followed, and
which do all the housekeeping automatically.

In particular this allows retaining compatibility with
much existing C++ code, continues to allow high performance
binaries to be generated, and greatly simplifies the task
of building software projects.

To put this a different way: C++ is past its prime,
its heyday is gone. However it has very many good features,
and in my opinion many of the places programmers are going
are considerably worse options! I'm interested in
static typing, polymorphism, generation of high performance
machine binaries, and portability of source codes by means
of open standards.

It seems to me we have this situation:

 C --> C++ --> F --> ML --> Haskell

C is too low level for modern applications,
and this is now true of C++. ML languages are
the natural future in the transition to advanced
systems like Haskell. Haskell isn't ready yet,
and whilst ML family languages are gaining strength,
they fail to offer compatibility required by industry,
in the same way C++ offered C compatibility.

We need a language 'F' which is a bridge from C++ to
ML family languages, which provides much of the functionality
such as garbage collection, pattern matching, algebraic types,
polymorphism, and first class functions, but which also retains
enough compatibility with C++ to allow it to be adopted in much
the same way as C++ allowed C programmers to move upwards.

If anything, it is the importance of this migration path,
and how it impacts both language design and political
processes, which most impressed me in my time on the
C++ committee.

Well of course that 'F' is chosen to hint that the Felix
project is an attempt to fill in the slot above ..
but this particular thread is not about F, but about
what we need to do with C++ to make the implementation
of F possible. As with CFront the necessary first step
is a compiler that generates C++.

Of course there may be other programming languages
which could profitably target C++. In fact, I believe
C++ could -- and should -- become the preferred compiler
backend target language.

The way forward is to build meta-languages on top
of C++ .. not discard it for Java!

If there is any interest, I will try to post a list
of issues. The difficulty is that whilst some are
easy to describe, and some are easy to provide simple
motivating examples for, others are much harder to
present.

A good way to reduce the difficulty of this
presentation is to focus on *correctable* problems,
which I think requires a considerable amount of
expertise not just in C++, but in both the C++ Standard
and the ISO standardisation process. If we could throw
in a couple of library designers and compiler implementors
that would help too :)

--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

skaller wrote:
.
> I am seeking expressions of interest in investigating the use of
> C++ as a compiler backend target language, with a view to coauthoring
> a paper
>
> * outlining the advantages of using C++ as a compiler backend
> * listing some difficulties using C++ as a compiler backend
> * some proposals for changes to C++ which may make it
>   more suitable as a compiler backend
.

To support exceptions, these could be added:

- The ability to take the address of a label.
- New standard library function(s) to iterate over
return addresses in the stack, up to some
call to setjmp().

These could be added to both C and C++
(thus supporting the use of C as a
backend for a C++ compiler).

Except perhaps for garbage collection,
I can't think of any other language
feature that wouldn't be feasable using
either C or C++ as backend.

It doesn't seem to make sense to change
the C++ Standard just to make it
easier to implement some other language
X.  If X were popular enough so that it would
be worth changing the C++ Standard
to support it, there would be plenty of
volunteers to help with the extra work
of writing an X tranlator that only used
the existing features of C or C++.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:

This article is marginally on-topic, but seems interesting and does relate to
(for example) the stability of the C++ standard. If the poster doesn't care to
read replies in the newsgroup, I guess that's his problem, not the problem of
people who want to respond in the newsgroup.


===================================== END OF MODERATOR'S COMMENT
I am seeking expressions of interest in investigating the use of
C++ as a compiler backend target language, with a view to coauthoring
a paper

* outlining the advantages of using C++ as a compiler backend
* listing some difficulties using C++ as a compiler backend
* some proposals for changes to C++ which may make it
  more suitable as a compiler backend

At least one  member of ISO/IEC SC22/WG21 or one member of
one of the national body delegations who regularly attend
meetings would be needed to champion the paper.

By way of background: I was a member of the committee myself for
around a decade, having the privilege to represent Australia at
a number of meetings, and generally annoy many people on the
committee reflector for most of that period.

More recently I have chosen to further the ability of programmers
to write quality code by designing my own programming language,
since I see the central core of C++ as fairly stable, and unlikely
to ever be extended sufficiently to become a truly advanced
programming language.

Whilst I have no objection to continued improvement of C++
for human coders, my concerns have turned to different,
though not unrelated usage: as compiler backend target language.
In the long term I think this usage is more important!

As you know, most compilers for advanced languages generate
one of three kinds of output:

(a) bytecode
(b) C
(c) native code

For a variety of reasons, C++ is rarely chosen as a backend
target language, yet it offers quite a lot of advantages
in that role! For example, it offers

* extra safety from type checking
* classes with dynamic dispatch
* exception handling
* constructors and destructors

all of which can greatly simplify the task of code generation,
by providing much higher level constructions than any of
the other alternatives. Much work can be delegated to C++
itself and to C++ libraries.

Furthermore, by targeting C++ there is the possibility
of binding to existing C++ code, without the need
for C level glue logic to wrap up C++ features used
such as exceptions and constructors.

The ISO C++ Standard is now well established, and many
compilers implement almost all of it properly, the excuse
that C is more portable is no longer very reasonable:
GNU g++ in particular is widely available and works
reasonably well.

My system, Felix, gains considerable profit from using
C++ as a backend.

However, there are a number of problems which have varying
impact on using C++ as a target language. For example
the nice property of C unions that any data type can be
used for a union variant component is lost in C++,
with very serious consequences for a code generator:
the workaround destroys many of the very advantages C++
offers, and simultaneously makes the generated code
entirely unreadable. Another problem, the inability
of templates to handle type recursion properly, virtually
rules out any possibility of generating templated code.

In general, the failure of C++ to maintain important
invariants, particularly in the type system, is responsible
for most of its weaknesses as a target language.
What I might call 'orthogonality' is essential for
systematic code generation: any caveats and special
cases probably need to be reflected in the code
generator.

If anyone is interested in this topic, please
email me at the address found in my sig below.
[I don't normally read this group]

--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On 07/18/2006 12:54 PM, skaller wrote:
[snip]
> impact on using C++ as a target language. For example
> the nice property of C unions that any data type can be
> used for a union variant component is lost in C++,
> with very serious consequences for a code generator:
> the workaround destroys many of the very advantages C++
> offers, and simultaneously makes the generated code
> entirely unreadable.

Why wouldn't boost's variant or any solve these problems?

> Another problem, the inability
> of templates to handle type recursion properly, virtually
> rules out any possibility of generating templated code.

Could you define proper type recursion and show why c++'s
method rules out generating templated code?

---
[ 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.comeaucomputing.com/csc/faq.html                      ]