glossary for egcs - request for contributions

glossary for egcs - request for contributions

[Philipp Thomas]

[Gavin Romig-Koch <gavin@cygnus.com> suggested to post the request here, so
here it goes]

While doing the german translation of egcs messages I had problems
understanding the messages in the first place. 

So it occurred to me that there should be some kind of document helping the
'decoding' of egcs and the documentation. Gavin suggested that it would be
best to add a glossary to the egcs documentation. As this again is task where
I'm able to contribute, I've taken it up to start such a beast.

As I quite possibly will miss some terms as they're too familiar to me, I'd
like to ask that anybody who thinks he has (or had) problems with the terms
used in egcs (both messages and documentation) send me these terms for
inclusion.


Philipp Thomas

-- 
caffeine low .... brain halted

Re: glossary for egcs - request for contributions

[Jeffrey A Law]

  In message < 3735364e.75002974@mailer.gwdg.de >you write:
  > So it occurred to me that there should be some kind of document helping the
  > 'decoding' of egcs and the documentation. Gavin suggested that it would be
  > best to add a glossary to the egcs documentation. As this again is task where
  > I'm able to contribute, I've taken it up to start such a beast.
I thought someone had already started a glossary of terms or something like
that...   Though I got the impression it was mostly for terms we tend to use
on the list like LICM, PRE, LCM, CFG, etc etc.

I'm not sure what ever happened to that list, but having it online would be
a good idea :-)

jeff

Re: glossary for egcs - request for contributions

[Martin v. Loewis]

> As I quite possibly will miss some terms as they're too familiar to me, I'd
> like to ask that anybody who thinks he has (or had) problems with the terms
> used in egcs (both messages and documentation) send me these terms for
> inclusion.

For C++, 'covariant return types', and 'contravariance violation' are
probably most frequently confusing.

Regards,
Martin

Re: glossary for egcs - request for contributions

[Joe Buck]

> > As I quite possibly will miss some terms as they're too familiar to me, I'd
> > like to ask that anybody who thinks he has (or had) problems with the terms
> > used in egcs (both messages and documentation) send me these terms for
> > inclusion.
> 
> For C++, 'covariant return types', and 'contravariance violation' are
> probably most frequently confusing.

I can't think of any explanation for these errors that doesn't require at
least a paragraph.  Maybe we should add a URL or reference to a node in
gcc.info, or both, to the error message, since it seems that when people
encounter them they immediately post to gnu.g++.help or egcs.

Re: glossary for egcs - request for contributions

[Marc Espie]

In article < 199904280705.AAA04952@atrus.synopsys.com > you write:
>> > As I quite possibly will miss some terms as they're too familiar to me, I'd
>> > like to ask that anybody who thinks he has (or had) problems with the terms
>> > used in egcs (both messages and documentation) send me these terms for
>> > inclusion.
>> 
>> For C++, 'covariant return types', and 'contravariance violation' are
>> probably most frequently confusing.

>I can't think of any explanation for these errors that doesn't require at
>least a paragraph.  Maybe we should add a URL or reference to a node in
>gcc.info, or both, to the error message, since it seems that when people
>encounter them they immediately post to gnu.g++.help or egcs.

Is there any online paper that clearly explains, in understandable words,
what covariant/contravariant means in an object type theory ?

I have read several books on the subject, but I wouldn't recommend them to
someone who would just like to know what's going on.

On the other hand, I believe that, to understand what these error messages
means, one usually has to have at least an intuitive grasp of what these
concepts are... without a conceptual model, one is going to lose, sooner or
later.  Getting past the compiler,  but writing hierarchies in which lists of
triangles inherit from lists of shapes, or some other classical mistake.

What I mean is, if we want to put an explanation for that one in, it had
better cover the problem fairly, not give the casual reader a superficial
understanding of what's going on.

Re: glossary for egcs - request for contributions

[Theodore Papadopoulo]

>   In message < 3735364e.75002974@mailer.gwdg.de >you write:
>   > So it occurred to me that there should be some kind of document helping the
>   > 'decoding' of egcs and the documentation. Gavin suggested that it would be
>   > best to add a glossary to the egcs documentation. As this again is task where
>   > I'm able to contribute, I've taken it up to start such a beast.
> I thought someone had already started a glossary of terms or something like
> that...   Though I got the impression it was mostly for terms we tend to use
> on the list like LICM, PRE, LCM, CFG, etc etc.
> 
> I'm not sure what ever happened to that list, but having it online would be
> a good idea :-)

	I think I'm the responsible for suggesting that and promised 
to try to gather sthg... Unfortunately, I have not gone very far up 
to now (but I'm still willing to do sthg about it). I do not have 
much time currently but will definitely try to contribute one in a 
(close?) future. What would be the proper format however ? texi or 
html. Having it online would certainly be great... Having it in the 
manual would be great too... This applies as well to Philipp's 
proposal AFAICT.

However, I believe that what Philipp suggested however is a little 
different in that he is targetting more gcc's users than developper's
(well beginners in gcc development :-) ). Maybe two different sections
(web pages) ?

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: glossary for egcs - request for contributions

[Joe Buck]

> >> For C++, 'covariant return types', and 'contravariance violation' are
> >> probably most frequently confusing.
> 
> >I can't think of any explanation for these errors that doesn't require at
> >least a paragraph.  Maybe we should add a URL or reference to a node in
> >gcc.info, or both, to the error message, since it seems that when people
> >encounter them they immediately post to gnu.g++.help or egcs.
> 
> Is there any online paper that clearly explains, in understandable words,
> what covariant/contravariant means in an object type theory ?

No, we'd have to write a note.  Let me know if you think the following is
intuitive.  I'm just dashing it off so there may be syntax errors.  Note
that I'm using the C++ terms (base class, derived class) not the typical
terms from type theory (subclass/superclass).

covariant: varying in the same way as.  If a language feature is covariant
one may replace a class by a derived class.  e.g. I can overload a virtual
function 
	Base* Base::clone() const { return new Base(*this);}
with
	Derived* Derived::clone() const { return new Derived(*this);}

return types are covariant: when the class changes from Base to Derived,
the return type changes in the same way.

contravariant: varying in the opposite way as.  If a language feature is
contravariant, one may replace a class by a class that it is derived
from.

Function arguments, for pointers to functions, are contravariant.
If I have
	typedef int (*PFBase)(Base&);

naive users think that

	int dfunc(Derived&);
	PFBase p = &dfunc;

should be legal, since they are used to convariance.  But this is broken,
since if it were legal I could pass a Base object to dfunc.  Instead,
if I have

	typedef int (*PFDerived)(Derived&);
	int bfunc(Base&);
	PFDerived p = &bfunc;

this is legal: I replaced a more derived by a less derived class.

Re: glossary for egcs - request for contributions

[Alexandre Oliva]

On Apr 29, 1999, Joe Buck <jbuck@Synopsys.COM> wrote:

> one may replace a class by a derived class.  e.g. I can overload a virtual
                                                              ^^^^
make that override

> 	typedef int (*PFDerived)(Derived&);
> 	int bfunc(Base&);
> 	PFDerived p = &bfunc;

> this is legal

No way!  :-)

You can't touch types of arguments when casting function types.  This
mechanism only works for pointers-to-members:

struct Base { void foo(); };
struct Derived : Base {};
typedef void (Derived::*PFDerived)();
PFDerived pD = &Base::foo;

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: glossary for egcs - request for contributions

[Jason Merrill]

>>>>> Joe Buck <jbuck@Synopsys.COM> writes:

 > Function arguments, for pointers to functions, are contravariant.

Actually, function arguments are invariant as far as C++ is concerned;
there are no implicit conversions between function pointer types.  g++
used to treat them as contravariant, but I think I tore out that code a
while back.

Jason

Re: glossary for egcs - request for contributions

[Joe Buck]

> > one may replace a class by a derived class.  e.g. I can overload a virtual
>                                                               ^^^^
> make that override
> 
> > 	typedef int (*PFDerived)(Derived&);
> > 	int bfunc(Base&);
> > 	PFDerived p = &bfunc;
> 
> > this is legal
> 
> No way!  :-)

Alexandre is right, I was wrong, the C++ language is wrong.  (That is,
they should have permitted contravariance for regular function pointers,
not just member function pointers).

> You can't touch types of arguments when casting function types.  This
> mechanism only works for pointers-to-members:
> 
> struct Base { void foo(); };
> struct Derived : Base {};
> typedef void (Derived::*PFDerived)();
> PFDerived pD = &Base::foo;

Correct.  Let's pretend I wrote that. :-)

Re: glossary for egcs - request for contributions

[Alexandre Oliva]

On Apr 29, 1999, Joe Buck <jbuck@Synopsys.COM> wrote:

> Correct.  Let's pretend I wrote that. :-)

Sure!  It's copyleft :-)

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: glossary for egcs - request for contributions

[Jason Merrill]

>>>>> Joe Buck <jbuck@Synopsys.COM> writes:

 >> > 	typedef int (*PFDerived)(Derived&);
 >> > 	int bfunc(Base&);
 >> > 	PFDerived p = &bfunc;
 >> 
 >> > this is legal
 >> 
 >> No way!  :-)

 > Alexandre is right, I was wrong, the C++ language is wrong.  (That is,
 > they should have permitted contravariance for regular function pointers,
 > not just member function pointers).

But then how would you deal with MI?  It works for PMFs because they aren't
just pointers.

Jason

Re: glossary for egcs - request for contributions

[Jeffrey A Law]

  In message < 3735364e.75002974@mailer.gwdg.de >you write:
  > So it occurred to me that there should be some kind of document helping the
  > 'decoding' of egcs and the documentation. Gavin suggested that it would be
  > best to add a glossary to the egcs documentation. As this again is task where
  > I'm able to contribute, I've taken it up to start such a beast.
I thought someone had already started a glossary of terms or something like
that...   Though I got the impression it was mostly for terms we tend to use
on the list like LICM, PRE, LCM, CFG, etc etc.

I'm not sure what ever happened to that list, but having it online would be
a good idea :-)

jeff

Re: glossary for egcs - request for contributions

[Theodore Papadopoulo]

>   In message < 3735364e.75002974@mailer.gwdg.de >you write:
>   > So it occurred to me that there should be some kind of document helping the
>   > 'decoding' of egcs and the documentation. Gavin suggested that it would be
>   > best to add a glossary to the egcs documentation. As this again is task where
>   > I'm able to contribute, I've taken it up to start such a beast.
> I thought someone had already started a glossary of terms or something like
> that...   Though I got the impression it was mostly for terms we tend to use
> on the list like LICM, PRE, LCM, CFG, etc etc.
> 
> I'm not sure what ever happened to that list, but having it online would be
> a good idea :-)

	I think I'm the responsible for suggesting that and promised 
to try to gather sthg... Unfortunately, I have not gone very far up 
to now (but I'm still willing to do sthg about it). I do not have 
much time currently but will definitely try to contribute one in a 
(close?) future. What would be the proper format however ? texi or 
html. Having it online would certainly be great... Having it in the 
manual would be great too... This applies as well to Philipp's 
proposal AFAICT.

However, I believe that what Philipp suggested however is a little 
different in that he is targetting more gcc's users than developper's
(well beginners in gcc development :-) ). Maybe two different sections
(web pages) ?

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: glossary for egcs - request for contributions

[Jason Merrill]

>>>>> Joe Buck <jbuck@Synopsys.COM> writes:

 > Function arguments, for pointers to functions, are contravariant.

Actually, function arguments are invariant as far as C++ is concerned;
there are no implicit conversions between function pointer types.  g++
used to treat them as contravariant, but I think I tore out that code a
while back.

Jason

Re: glossary for egcs - request for contributions

[Joe Buck]

> > As I quite possibly will miss some terms as they're too familiar to me, I'd
> > like to ask that anybody who thinks he has (or had) problems with the terms
> > used in egcs (both messages and documentation) send me these terms for
> > inclusion.
> 
> For C++, 'covariant return types', and 'contravariance violation' are
> probably most frequently confusing.

I can't think of any explanation for these errors that doesn't require at
least a paragraph.  Maybe we should add a URL or reference to a node in
gcc.info, or both, to the error message, since it seems that when people
encounter them they immediately post to gnu.g++.help or egcs.

Re: glossary for egcs - request for contributions

[Jason Merrill]

>>>>> Joe Buck <jbuck@Synopsys.COM> writes:

 >> > 	typedef int (*PFDerived)(Derived&);
 >> > 	int bfunc(Base&);
 >> > 	PFDerived p = &bfunc;
 >> 
 >> > this is legal
 >> 
 >> No way!  :-)

 > Alexandre is right, I was wrong, the C++ language is wrong.  (That is,
 > they should have permitted contravariance for regular function pointers,
 > not just member function pointers).

But then how would you deal with MI?  It works for PMFs because they aren't
just pointers.

Jason

Re: glossary for egcs - request for contributions

[Joe Buck]

> >> For C++, 'covariant return types', and 'contravariance violation' are
> >> probably most frequently confusing.
> 
> >I can't think of any explanation for these errors that doesn't require at
> >least a paragraph.  Maybe we should add a URL or reference to a node in
> >gcc.info, or both, to the error message, since it seems that when people
> >encounter them they immediately post to gnu.g++.help or egcs.
> 
> Is there any online paper that clearly explains, in understandable words,
> what covariant/contravariant means in an object type theory ?

No, we'd have to write a note.  Let me know if you think the following is
intuitive.  I'm just dashing it off so there may be syntax errors.  Note
that I'm using the C++ terms (base class, derived class) not the typical
terms from type theory (subclass/superclass).

covariant: varying in the same way as.  If a language feature is covariant
one may replace a class by a derived class.  e.g. I can overload a virtual
function 
	Base* Base::clone() const { return new Base(*this);}
with
	Derived* Derived::clone() const { return new Derived(*this);}

return types are covariant: when the class changes from Base to Derived,
the return type changes in the same way.

contravariant: varying in the opposite way as.  If a language feature is
contravariant, one may replace a class by a class that it is derived
from.

Function arguments, for pointers to functions, are contravariant.
If I have
	typedef int (*PFBase)(Base&);

naive users think that

	int dfunc(Derived&);
	PFBase p = &dfunc;

should be legal, since they are used to convariance.  But this is broken,
since if it were legal I could pass a Base object to dfunc.  Instead,
if I have

	typedef int (*PFDerived)(Derived&);
	int bfunc(Base&);
	PFDerived p = &bfunc;

this is legal: I replaced a more derived by a less derived class.

Re: glossary for egcs - request for contributions

[Marc Espie]

In article < 199904280705.AAA04952@atrus.synopsys.com > you write:
>> > As I quite possibly will miss some terms as they're too familiar to me, I'd
>> > like to ask that anybody who thinks he has (or had) problems with the terms
>> > used in egcs (both messages and documentation) send me these terms for
>> > inclusion.
>> 
>> For C++, 'covariant return types', and 'contravariance violation' are
>> probably most frequently confusing.

>I can't think of any explanation for these errors that doesn't require at
>least a paragraph.  Maybe we should add a URL or reference to a node in
>gcc.info, or both, to the error message, since it seems that when people
>encounter them they immediately post to gnu.g++.help or egcs.

Is there any online paper that clearly explains, in understandable words,
what covariant/contravariant means in an object type theory ?

I have read several books on the subject, but I wouldn't recommend them to
someone who would just like to know what's going on.

On the other hand, I believe that, to understand what these error messages
means, one usually has to have at least an intuitive grasp of what these
concepts are... without a conceptual model, one is going to lose, sooner or
later.  Getting past the compiler,  but writing hierarchies in which lists of
triangles inherit from lists of shapes, or some other classical mistake.

What I mean is, if we want to put an explanation for that one in, it had
better cover the problem fairly, not give the casual reader a superficial
understanding of what's going on.

glossary for egcs - request for contributions

[Philipp Thomas]

[Gavin Romig-Koch <gavin@cygnus.com> suggested to post the request here, so
here it goes]

While doing the german translation of egcs messages I had problems
understanding the messages in the first place. 

So it occurred to me that there should be some kind of document helping the
'decoding' of egcs and the documentation. Gavin suggested that it would be
best to add a glossary to the egcs documentation. As this again is task where
I'm able to contribute, I've taken it up to start such a beast.

As I quite possibly will miss some terms as they're too familiar to me, I'd
like to ask that anybody who thinks he has (or had) problems with the terms
used in egcs (both messages and documentation) send me these terms for
inclusion.


Philipp Thomas

-- 
caffeine low .... brain halted

Re: glossary for egcs - request for contributions

[Alexandre Oliva]

On Apr 29, 1999, Joe Buck <jbuck@Synopsys.COM> wrote:

> Correct.  Let's pretend I wrote that. :-)

Sure!  It's copyleft :-)

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: glossary for egcs - request for contributions

[Alexandre Oliva]

On Apr 29, 1999, Joe Buck <jbuck@Synopsys.COM> wrote:

> one may replace a class by a derived class.  e.g. I can overload a virtual
                                                              ^^^^
make that override

> 	typedef int (*PFDerived)(Derived&);
> 	int bfunc(Base&);
> 	PFDerived p = &bfunc;

> this is legal

No way!  :-)

You can't touch types of arguments when casting function types.  This
mechanism only works for pointers-to-members:

struct Base { void foo(); };
struct Derived : Base {};
typedef void (Derived::*PFDerived)();
PFDerived pD = &Base::foo;

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: glossary for egcs - request for contributions

[Martin v. Loewis]

> As I quite possibly will miss some terms as they're too familiar to me, I'd
> like to ask that anybody who thinks he has (or had) problems with the terms
> used in egcs (both messages and documentation) send me these terms for
> inclusion.

For C++, 'covariant return types', and 'contravariance violation' are
probably most frequently confusing.

Regards,
Martin

Re: glossary for egcs - request for contributions

[Joe Buck]

> > one may replace a class by a derived class.  e.g. I can overload a virtual
>                                                               ^^^^
> make that override
> 
> > 	typedef int (*PFDerived)(Derived&);
> > 	int bfunc(Base&);
> > 	PFDerived p = &bfunc;
> 
> > this is legal
> 
> No way!  :-)

Alexandre is right, I was wrong, the C++ language is wrong.  (That is,
they should have permitted contravariance for regular function pointers,
not just member function pointers).

> You can't touch types of arguments when casting function types.  This
> mechanism only works for pointers-to-members:
> 
> struct Base { void foo(); };
> struct Derived : Base {};
> typedef void (Derived::*PFDerived)();
> PFDerived pD = &Base::foo;

Correct.  Let's pretend I wrote that. :-)