Re: Re: c++ "with" keyword

Re: Re: c++ "with" keyword

[Norman Jonas]

I think you missed the point. The reason for the with keyword is not to use
a pointer but to leave
the long structs name which is not done by your example :

struct S
{
    char* name;
    char* street;
    char* city;
} verylongdescriptivename;

If you want to access several values of this struct you always have to type
in the whole name :

verylongdescriptivename.name = "hans";
verylongdescriptivename.street = "xxx 13";
verylongdescriptivename.city = "cologne";

using the "with" keyword this code becomes much smaller and cleaner :

with ( verylongdescriptivename )
{
    .name = "hans";
    .street = "xxx 13";
    .city = "cologne";
}

( It is possible to use a pointer with a very short, undescriptive name, but
that makes the
code unreadable and stupid ( variables should have explanative names, not a
confusing x* )

Norman

> erik wrote :
>
> The example
>
>  struct S
>  {
>      int x;
>      int y;
>  };
>
>  int main()
>  {
>      S s;
>      with (s)
>      {
>          .x = 1;
>          .y = 2;
>      }
>      return 0;
>  }
>
> can easily be rewritten by introducing temporary references, as in
>
>  int main()
>  {
>      S s;
>      {
>          S& t = s;
>          t.x = 1;
>          t.y = 2;
>      }
>      return 0;
>  }
>
> This requires only one additional variable reference each time the
> "with" object is used.  Additionally, it allows several "with" objects
> (with different names) at the same time.  In C, the same thing can be
> done by using pointers.
>
> -erik

Re: c++ "with" keyword

[Russ Allbery]

Norman Jonas <normanjonas@arcor.de> writes:

> using the "with" keyword this code becomes much smaller and cleaner :

> with ( verylongdescriptivename )
> {
>     .name = "hans";
>     .street = "xxx 13";
>     .city = "cologne";
> }

> ( It is possible to use a pointer with a very short, undescriptive name,
> but that makes the code unreadable and stupid ( variables should have
> explanative names, not a confusing x* )

I must admit that I don't see the effective difference between:

    with (verylongdescriptivename)
    {
        .name = "hans";
        .street = "xxx 13";
        .city = "cologne";
    }

and

    {
        struct S& s = verylongdescriptivename;
        s.name = "hans";
        s.street = "xxx 13";
        s.city = "cologne";
    }

You say that variables should have long, explanative names, but the
function of with is essentially to remove those names and rely on implicit
context.  That's exactly what using short variable names does.

with is one of those constructs that renders code extremely difficult to
understand if used for blocks of code longer than a few lines, because it
complicates the way symbol lookups are performed (something that's already
incredibly complex in C++).

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: c++ "with" keyword

[Robert Dewar]

> a.  Algol 68 was not implemented at the time it was specified

True also of COBOL-90, C++, Ada

But in any case why is this bad? It may simply mean that you have done a
good job of specification and have managed to do that earlier. There is no
inherent merit in delaying specification. Indeed in general in software,
the concept of specify before implementation is not usually considered
a bad thing :-)

> b.  Full Algol 68 was hard to implement given the resources available

Well yes, so what? That's not an argument for delaying its specification
until it was implemented.

> c.  The difficuly of implementing the full language hurt its sucess

But it would not have been implemented at all if it had not been specified
and published by WG2.1, so again this is not an argument for delaying
specification.

Part of the trouble with modern complex languages is that they are not
one-person-hobbyist-working-in-their-spare-time-to-make-prototype projects.
So in practice large teams are needed for implementation. That makes it
even more essential to have clear specifications.

Your argument that somehow Algol-68 (or any other language) is harmed
by accurate early specification in detail is definitely not convincing.

Re: c++ "with" keyword

[Robert Dewar]

> As does the source code to the Bourne shell (V7 Unix is now free software
> (BSD with advertising clause), freed by Caldera).
> 
> http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/
> 
> (especially mac.h for the macros converting this other language into C).


Gosh that's really naughty :-) [using the C macro feature to subvert the
syntax]. I wish I had known this when my students were writing bootstrapping
compilers, still I suppose it was a good excercise for them to create macro
sets of their own (about half bootstrapped using the A68 to C translator,
the other half by writing similar sets of C macros).

It's quite fun to look at that code, but it must drive some C programmers
nuts!

Re: c++ "with" keyword

[Robert Dewar]

> The Bottom Line: Extensions are like Sex; one mistake and you have to 
> support it a life time ...

Very nice, that's one to record for future use :-) 

Re: c++ "with" keyword

[Toon Moene]

Robert Dewar wrote:

>>The Bottom Line: Extensions are like Sex; one mistake and you have to 
>>support it a life time ...

> Very nice, that's one to record for future use :-) 

I have to confess that it's not completely original (but then, what is):

Type "programming is like sex" into Google and enjoy the 513,000 hits :-)

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: c++ "with" keyword

[Robert Dewar]

> Believe that if you wish.  I'm not a betting man.  The Algol 68
> language had no implementations when it was standardized -- AFAIK the
> first delivery was 1977!

That's serious misinformation. Algol-68R, which was widely used in universities
industry and defence applications first appeared in 1970 (I was at Leeds
in the summer of 1971 and used the compiler extensively at that time, it
was in excellent shape). Algol-68R was a very large subset, with only a few
restrictions (it was much closer to full Algol-68 than any "C++" compiler
was to the first C++ standard when it appeared). 

(Good thing you did not take on the bet, sounds like you have never programmed
in Algol-68 :-)

The first complete full language implementation for the CDC was delivered
in 1974 only a couple of years after the revised report.

1976 saw the appearence of Algol-68S, the widely used subset on the PDP-11
(that's the subset I had my students write self-bootstrapping compilers
on Knuth's new MIX machine, we ended up with about 10 fully bootstrapped
compilers from a one semester course -- so it's not *that* hard to implement)

In fact, A68 is a much easier language to implement than C++ or Ada or F90
or Java I would say. Once again, the issue was general resources. We have
seen how difficult it has been to get g++ into reasonably complete shape,
and that's with far more investment of volunteer and paid effort than went
into any Algol-68 compiler. And the time scale for g++ was indeed far longer
than for the A68 compilers that did appear. It is indeed a pity that no
nice implementation appeared on the IBM mainframes.

In fact, to get back to something at least a big relevant to this mailing
list, this was a place where free software principles would have made all
the difference. 

There was in fact a VERY nice compiler for the IBM mainframes which appeared
in 1978. Remember this is a full featured language with strong abstraction
capabilities, full garbage collection, and built-in multi-threading
capabiltiies, appearing 25 years ago. But unfortunately the authors decided
to try to make money, and sold it for a very large amount of money (comparable
to what IBM charged for major compilers). I think they sold precisely three
copies to Canadian universities. I pleaded with them to make it more generally
available, but unsuccessfully. I think if we had todays free software and
open source environment, and that compiler had been distributed that way,
we might have seen a very different history for Algol-68.

Re: c++ "with" keyword

[Andrew Haley]

Robert Dewar writes:
 > > Believe that if you wish.  I'm not a betting man.  The Algol 68
 > > language had no implementations when it was standardized -- AFAIK the
 > > first delivery was 1977!
 > 
 > That's serious misinformation. Algol-68R, which was widely used in universities
 > industry and defence applications first appeared in 1970 (I was at Leeds
 > in the summer of 1971 and used the compiler extensively at that time, it
 > was in excellent shape). Algol-68R was a very large subset, with only a few
 > restrictions (it was much closer to full Algol-68 than any "C++" compiler
 > was to the first C++ standard when it appeared). 
 > (Good thing you did not take on the bet, sounds like you have never programmed
 > in Algol-68 :-)

 > The first complete full language implementation for the CDC was delivered
 > in 1974 only a couple of years after the revised report.

Well, for some unnacountable reason Lindsey doesn't say so.  He says
that the "CDC Netherlands" compiler, and I assume that's the one
you're talking about, was first delivered in 1977.  Of course, he may
be mistaken or he may have decided not to mention the 1974 deivery.

 > 1976 saw the appearence of Algol-68S, the widely used subset on the PDP-11
 > (that's the subset I had my students write self-bootstrapping compilers
 > on Knuth's new MIX machine, we ended up with about 10 fully bootstrapped
 > compilers from a one semester course -- so it's not *that* hard to implement)

Fair enough.  However

a.  Algol 68 was not implemented at the time it was specified
b.  Full Algol 68 was hard to implement given the resources available
c.  The difficuly of implementing the full language hurt its sucess

Andrew.

Re: c++ "with" keyword

[Robert Dewar]

By the way, to close the thread on Algol-68 as an example of something
or other, the URL http://user.it.uu.se/~richardc/txt/ALGOL68.txt has
a nice summary of sequence of events.

Little fact which I find some people don't know. The Bourne shell has a
syntax conciously modeled on Algol-68. That's because Steve was very much
involved in the A68 scene (he was the principle author of Algol-68C).

Re: c++ "with" keyword

[Joseph S. Myers]

On Sun, 5 Jan 2003, Robert Dewar wrote:

> Little fact which I find some people don't know. The Bourne shell has a
> syntax conciously modeled on Algol-68. That's because Steve was very much
> involved in the A68 scene (he was the principle author of Algol-68C).

As does the source code to the Bourne shell (V7 Unix is now free software
(BSD with advertising clause), freed by Caldera).

http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/

(especially mac.h for the macros converting this other language into C).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: c++ "with" keyword

[Robert Dewar]

> Believe that if you wish.  I'm not a betting man.  The Algol 68
> language had no implementations when it was standardized -- AFAIK the
> first delivery was 1977!

Right, but so what? Neither did Algol-60, and that was hugely successful.
The advantage of prototyping as you go along is to validate language
design features, as was done for example with Ada, but in practice the
design of Algol-68 went very smoothly (this standard appeared only 8
years after Algol-60, contrast the period of time between C and C++, or
for that matter between Ada-83 and Ada-95. 

There was in fact quite a lot of prototyping activity (AlgolW/X/Y). If you
look at C++ it is also the case that there was no implementation of C++
when it was standardized (I am not sure that there is a 100% conforming
implementation at the current time). Yes, there were prototypes of subsets,
but that was also true of Algol-68. 

> To quote Lindsey's official history: "...why it did not come into more
> widespread use, and the answer here is simple enough: because it was
> not implemented widely enough, or soon enough.  And the reason for
> that is that implementation was too hard..."  This would not have been
> the case if implementations had existed at the time of
> standardization.

The difficulty of implementing Algol-68 exists whether or not the standard
had waited to be issued till the first implementation. In fact the first
implementation appeared in the early 70's, more or less at the same time
as the revised report (really the revised report is Algol-68).

Of course if implementations had existed in 1968 that would have been nice,
but that's fantasy if you look at the history. Complex languages have always
taken a lot of time and effort to implement. 

Charles is quite right that it was not implemented widely enough or soon
enough, but that was a matter of market forces and resources (the one csae
in which a major manufacturer implemented Algol-68, which was CDC in response
to Dutch university tenders -- they invested about 100 person years of effort.
This compiler was widely used and very successful -- it was by the way the
first general purpose procedural language to have a full garbage collector).

There was certainly no phenomenon of people somehow delaying work on the
implementation of Algol-68 waiting for the standard. On the contrary, the
existence of an accurate standard early on was an enormous help in the
implementation effort (for example, our effort on the 1108 started in 1969
and would have been impossible without the standard).

The real reason for involving language design folks as early as possible is
to avoid half baked extensions that are not properly documented. I still have
not seen proper complete formal definitions of some of the GCC extensions
for example. 

What you need is language design people working hand in hand with implementors
to ensure that new features are properly designed and at the same time
implementable.

The first incarnation of a new language idea should be a fully developed
reasonably formal description of the idea, in the context of the existing
standard. This description should be developed with input from implementors
as to what is or is not implementable. Then trial implementations can be
carried out. It is also reasonable to do prototype implementations to verify
implentability as part of the initial development. This approach has been
followed very successfully in the Ada context for example.

So for me, if anyone is seriously interested in the WITH proposal (so far
I see only one advocate), the next step is to write a reasonably precise
description of what the feature is, including reasonably precise semantics
and syntax. Then that design needs to be evaulated by language design folks,
implementors and application developers to see if it makes sense. Only then
is an implementation reasonable. In the case of WITH, I think the idea is
so badly flawed that the proposal would fail at the first stage, avoiding
wasted implentation effort.

Re: c++ "with" keyword

[Robert Dewar]

> You talk about binary compatability.  I'm more concerned about source 
> compatability however there are issues with binary compatability as well 
> - in the case, use of enums or typedefs in a class may cause binary 
> issues.  Think a little harder, they are there.

No, I am talking *entirely* about source compatibility, obviously you can't
expect binaries to be compatible if you go changing the members in a struct
(think of space required for example).

You apparently have misread everything I said

> I've given examples.  They still stand.

No, you have not given any realistic example of the library situation which
worries you so much.

Re: c++ "with" keyword

[Robert Dewar]

> So, you are saying that nobody should be able to understand a hardcopy
> printout of code on it's own. They should be required to examine it
> inside of a GUI infested enviornment?

As an old paper reader myself, I will say that it is hard to go back to
paper once you are used to a competent browser.

> Also, the clickie thingie will only work if it can parse the code, but
> if I'm trying to get someone elses code to run on my *other-brand*
> machine, and I have syntax errors, the GUI tools will probably not
> be able to get their info until the syntax errors are gone, but I can't
> get rid of the syntax errors if I can't figure out what the code is
> supposed to do, which requires the tools, which ...

Well again, it depends on the tools. GPS can operate with partial semantic
information just fine. GNAT has an option to force generation of semantic
information to the extent possible even if there are errors, and it works
very nicely in practice in this situation.

But remember that you are talking about your *own* code here. If you are
using a library, and are deathly afraid of having to change your code for
new versions (perhaps because you only read stuff on paper, and indeed
you don't understand the code you are working with), then you may decide
to write in a style without WITH (or its equivalents), or to keep all
variable names very short. But if you are happy to use an environment in
which the very unlikely case of WITH causing trouble could be easily fixed,
then you may find that it is worth using to make your code more readable.

And again, to play broken record, this entire discussion is about an issue
that can perfectly well be left moot (= undecided, arguable), since the
powerful argument against WITH that it is expressively unnecessary since
there are better ways of doing the same thing already. 

The burden for a language change is always severe, you damage a language
by adding a new feature (by making it more complex) so you have to be
super sure that it is buying a gain that is *more* than this cost.

In this case we have a proposed feature WITH that provides minimal gains
at best and in addition has possible negatives. There is no way that the
burden of a new feature is met in this case.

Re: c++ "with" keyword

[Robert Dewar]

> And to search for references to a structure becomes much more
> complex.  Instead of looking for a '.x' or '->x', you must now search
> for 'x', and then look to see if the reference is within a 'using'
> clause.

You are imagining a very low level environment. In GNAT (using GPS) if you
click on an entity, you get immediately to its declaration, and of course
such a tool would disambiguate a reference immediately. You are also
talking about misuse of the feature if you are talking about hundreds of
lines of text.

> If long names are causing you typing problems, then DON'T CREATE LONG
> NAMES IN THE FIRST PLACE. The "standard" C and C++ libraries usually
> use fairly short names for everything. Most of the long names I've seen are
> those created specifically for the program in question.  If the long 
> names are
> a real problem for you, then why create them in the first place?

Well that's the strongest argument in *favor* of WITH so far :-)
Keeping names short because they are too painful to use is a significant
negative effect, since well chosen longish names can often make a big
difference to readability of code.

Now it is true that the C++ syntax style generally favors short names:

  *p++

is a much nicer notation than

  Julian_Date_At_Maturity++

so you could argue that a feature that made it more convenient to use long
names was inconsistent in style with C++ :-)

Re: c++ "with" keyword

[Kevin Handy]

Robert Dewar wrote:

>>And to search for references to a structure becomes much more
>>complex.  Instead of looking for a '.x' or '->x', you must now search
>>for 'x', and then look to see if the reference is within a 'using'
>>clause.
>>    
>>
>
>You are imagining a very low level environment. In GNAT (using GPS) if you
>click on an entity, you get immediately to its declaration, and of course
>such a tool would disambiguate a reference immediately. You are also
>talking about misuse of the feature if you are talking about hundreds of
>lines of text.
>  
>
So, you are saying that nobody should be able to understand a hardcopy
printout of code on it's own. They should be required to examine it
inside of a GUI infested enviornment?

Seems like it's just making it harder to work with the code, instead of
easier.

Also, the clickie thingie will only work if it can parse the code, but
if I'm trying to get someone elses code to run on my *other-brand*
machine, and I have syntax errors, the GUI tools will probably not
be able to get their info until the syntax errors are gone, but I can't
get rid of the syntax errors if I can't figure out what the code is
supposed to do, which requires the tools, which ...

I still think it would cause more maintainence problems than
any help it would be for someones tired fingers.

90% of the cost of a program is usually in it's maintenance.

>>If long names are causing you typing problems, then DON'T CREATE LONG
>>NAMES IN THE FIRST PLACE. The "standard" C and C++ libraries usually
>>use fairly short names for everything. Most of the long names I've seen are
>>those created specifically for the program in question.  If the long 
>>names are
>>a real problem for you, then why create them in the first place?
>>    
>>
>
>Well that's the strongest argument in *favor* of WITH so far :-)
>Keeping names short because they are too painful to use is a significant
>negative effect, since well chosen longish names can often make a big
>difference to readability of code.
>
>Now it is true that the C++ syntax style generally favors short names:
>
>  *p++
>
>is a much nicer notation than
>
>  Julian_Date_At_Maturity++
>
shouldnt that be ;-)

    with (*Julian_Date_At_Maturity)
    {
        ++;
    }

sorry, couldn't help myself.

>so you could argue that a feature that made it more convenient to use long
>names was inconsistent in style with C++ :-)
>  
>
So, you want to use long names, but you just don't want to use them?

There is a point at which a name becomes too long to be convienient,
and if it is too long to type when needed, then it is probably too long to
consistantly type correctly. At that point it's more of a burden then a
help.

I've also seen enough programs with long names containing misspelled
words in them. Knowingly typing the *wrong* name is a bit
disconcerting (and I'm a bad speller, so it needs to be really wrong
for me to notice)

Re: c++ "with" keyword

[Robert Dewar]

> Any language construct that fails in this regard (like with) is very bad 
> - period.

But look carefully at what you are saying. We are talking about a structure
or class whose members are visible to the client of the library. The change
we are talking about is adding a new member to the structure. You cannot
possibly think that such a change can be done in a guaranteed 100%
upwards compatible manner. That's absurd.

(for example, at the very least the size of an instance will change).

Furthermore, the situations under which adding this member will cause
specifically a difficulty with WITH are very marginal. It is indeed
far more likely that the addition of a member will cause other compatibility
differences.

If you disagree, give a specific realistic example of what you are talking
about. I certainly can't think of one!

> Again, our perspectives on what is important is different, as a library 
> maintainer, I see this as much more important an issue than you do.
> 
> 

Again, remember we are talking not about the writer of the library but the
user. Suppose the user obtains an offset of a member of the structure, and
you add a new member. Well then the offset changes, and that could cause
arbitrary chaos of a really difficult nature. Would you use this to argue
that it should be impossible to obtain the offset of a structure member.
Of course not. 

If a user uses WITH on one of your structs, then it is still extremely
unlikely that your change will cause trouble.

I really think that you need to give an example. Talking in generalities
is always misleading. If you think something is dangerous don't just go
around sounding red alert. Instead give a specific technical example :-)

Re: c++ "with" keyword

[Lynn Winebarger]

On Saturday 04 January 2003 17:35, Robert Dewar wrote:
> > Any language construct that fails in this regard (like with) is very bad 
> > - period.
> 
> But look carefully at what you are saying. We are talking about a structure
> or class whose members are visible to the client of the library. The change
> we are talking about is adding a new member to the structure. You cannot
> possibly think that such a change can be done in a guaranteed 100%
> upwards compatible manner. That's absurd.
> 
> (for example, at the very least the size of an instance will change).
> 
> Furthermore, the situations under which adding this member will cause
> specifically a difficulty with WITH are very marginal. It is indeed
> far more likely that the addition of a member will cause other compatibility
> differences.

    Why not just make it possible to specify exactly what identifiers you want to
import from the class of the variable (ala Perl's use mechanism)?

Lynn

Re: c++ "with" keyword

[Gianni Mariani]

Robert Dewar wrote:

>>Any language construct that fails in this regard (like with) is very bad 
>>- period.
>>    
>>
>
>But look carefully at what you are saying. We are talking about a structure
>or class whose members are visible to the client of the library. The change
>we are talking about is adding a new member to the structure. You cannot
>possibly think that such a change can be done in a guaranteed 100%
>upwards compatible manner. That's absurd.
>
>(for example, at the very least the size of an instance will change).
>
>Furthermore, the situations under which adding this member will cause
>specifically a difficulty with WITH are very marginal. It is indeed
>far more likely that the addition of a member will cause other compatibility
>differences.
>
>If you disagree, give a specific realistic example of what you are talking
>about. I certainly can't think of one!
>
You talk about binary compatability.  I'm more concerned about source 
compatability however there are issues with binary compatability as well 
- in the case, use of enums or typedefs in a class may cause binary 
issues.  Think a little harder, they are there.

>
>  
>
>>Again, our perspectives on what is important is different, as a library 
>>maintainer, I see this as much more important an issue than you do.
>>
>>
>>    
>>
>
>Again, remember we are talking not about the writer of the library but the
>user. 
>
Hey - I'm talking about both - in any case, almost moderately sized 
project will have libraries and in a software development house, you 
want source level compatability.  The distinction of library producer 
and consumer is mute.

>Suppose the user obtains an offset of a member of the structure, and
>you add a new member. Well then the offset changes, and that could cause
>arbitrary chaos of a really difficult nature. Would you use this to argue
>that it should be impossible to obtain the offset of a structure member.
>Of course not. 
>
>If a user uses WITH on one of your structs, then it is still extremely
>unlikely that your change will cause trouble.
>
>I really think that you need to give an example. Talking in generalities
>is always misleading. If you think something is dangerous don't just go
>around sounding red alert. Instead give a specific technical example :-)
>  
>
Robert, we have different perspectives on the same problem.  Obviously 
issues I see as critical, you see as mute.

I've given examples.  They still stand.

G

Re: c++ "with" keyword

[Robert Dewar]

By the way, I continue to think that language discussions on new features
are dubious on this list, and if that is a more general consensus I would
be very happy to see the whole discussion disappear).

Re: c++ "with" keyword

[Robert Dewar]

> I argue that it is not trivially fixable.  In the case of a third party 
> library, it is virtually impossible to guarentee that introducing a new 
> member will not break any clients of the library.

It may certainly break any clients who use the WITH feature, but that is
their choice. Anyone who uses WITH on a 3rd party library is accepting
that updates to the library that add names may possibly cause some
illegalities, just as someone using USE in Ada takes this "risk".
But the user of the library knows immediately that the problem has
arisen and can fix it trivially. 

> This is why I like "orthogonality" of code - the act of making a change 
> in one facet does not introduce changes in another.  The "with" concept 
> breaks orthogonality in arbitrary ways.

Well I dislike the word orthogonal being used in this sloppy sense, but I
know what you mean. This is only an informal concept. Any change to a library
may require changes in client code (e.g. perhaps the library gets 10 words
bigger in an embedded environment with only 9 words free). The issue is 
whether WITH adds substantially to this problem. I don't think this is
the case.

Again, I think you are arguing the weak point of the case against WITH. The
strong argument is that the renaming is good enough.

Re: c++ "with" keyword

[Gianni Mariani]

Robert Dewar wrote:

>>I argue that it is not trivially fixable.  In the case of a third party 
>>library, it is virtually impossible to guarentee that introducing a new 
>>member will not break any clients of the library.
>>    
>>
>
>It may certainly break any clients who use the WITH feature, but that is
>their choice. Anyone who uses WITH on a 3rd party library is accepting
>that updates to the library that add names may possibly cause some
>illegalities, just as someone using USE in Ada takes this "risk".
>But the user of the library knows immediately that the problem has
>arisen and can fix it trivially. 
>  
>
I beg to differ.

Maintaing source compatability where possible with new library versions 
(without having to mess with clients) is an important aspect of interfaces.

Any language construct that fails in this regard (like with) is very bad 
- period.

Again, our perspectives on what is important is different, as a library 
maintainer, I see this as much more important an issue than you do.

Re: c++ "with" keyword

[Robert Dewar]

> using the method you proposed will possibly degrade the code, wheras using 
> macros (and "with" should be implemented into the cpp) has never any runtime 
> penalties.


Either may degrade the code, you have no idea. Neither should have any
significant penalty.

No, WITH absolutely can not be done using CPP, this is a horrible suggestion,
since fairly subtle visibility analysis is required, particularly with
respect to detecting and rejecting ambiguous references. So the processing
of WITH would be part of the static semantic processing.

Re: c++ "with" keyword

[Robert Dewar]

> ... and potentially two new variables in your code and binary.
> what i wanted to have:
> 
>  
>              {
>                #define y long_descriptive_expression_I_dont_like_repeating;
>                #define z long_descriptive_expression_I_dont_like_repeating;
>  
>                  z.memberA = z.memberB;
>                  z.memberB = y.memberA;
>                #undef z
>                #undef y
>              }
>  
> but this is just ugly. 

Saying something is ugly is not an argument. It is the absence of a useful
argument. What are you suggesting we do, take a vote to find out which
form more people find ugly?

(hint: you will probably lose, most C++ programmers will be quite familiar
with the construct above, but will find the proposed WITH unfamiliar and
thus ugly).

As for two new variables. One would hope not, a stupid compiler might do
that, but then a stupid compiler might generate junk copies to implement
WITH. You really can't base arguments on fantasies about what stupid
compilers might or might not do.

In short, you have given no technical arguments to prefer your new form
over the familiar existing technique.

Re: c++ "with" keyword

[Tolga Dalman]

On Sat,  4 Jan 2003 14:13:16 -0500 (EST) dewar@gnat.com (Robert Dewar) wrote:

> > ... and potentially two new variables in your code and binary.
> > what i wanted to have:
> > 
> >  
> >              {
> >                #define y long_descriptive_expression_I_dont_like_repeating;
> >                #define z long_descriptive_expression_I_dont_like_repeating;
> >  
> >                  z.memberA = z.memberB;
> >                  z.memberB = y.memberA;
> >                #undef z
> >                #undef y
> >              }
> >  
> > but this is just ugly. 
> 
> Saying something is ugly is not an argument. It is the absence of a useful
> argument. What are you suggesting we do, take a vote to find out which
> form more people find ugly?
> 
> (hint: you will probably lose, most C++ programmers will be quite familiar
> with the construct above, but will find the proposed WITH unfamiliar and
> thus ugly).
> 
> As for two new variables. One would hope not, a stupid compiler might do
> that, but then a stupid compiler might generate junk copies to implement
> WITH. You really can't base arguments on fantasies about what stupid
> compilers might or might not do.
> 
> In short, you have given no technical arguments to prefer your new form
> over the familiar existing technique.

using the method you proposed will possibly degrade the code, wheras using 
macros (and "with" should be implemented into the cpp) has never any runtime 
penalties.

btw, being ugly or not is not the question here (as you said, we could
argue about), but rather having a clean programming style with an appropriate 
language. i do regard using macro definitions within "normal" code 
as blasphemical as using "goto" now and then...

Tolga Dalman.

Re: c++ "with" keyword

[Robert Dewar]

> I favour code maintenance.  I don't like fixing bugs only to introduce a 
> whole bunch of new ones that are hard to find.  This is probably my 
> largest concern when it comes to writing code.


But once again, if you fix a bug by introducing a new name, then you never
introduce a new "bug", simply instances of illegalities that are trivially
fixable (you can even write a trivial tool to fix them if you really find
it that hard). So they are not "hard to find", since they generate clear
diagnostics, and they are not "hard to fix".

Re: c++ "with" keyword

[Gianni Mariani]

Robert Dewar wrote:

>>I favour code maintenance.  I don't like fixing bugs only to introduce a 
>>whole bunch of new ones that are hard to find.  This is probably my 
>>largest concern when it comes to writing code.
>>    
>>
>
>
>But once again, if you fix a bug by introducing a new name, then you never
>introduce a new "bug", simply instances of illegalities that are trivially
>fixable (you can even write a trivial tool to fix them if you really find
>it that hard). So they are not "hard to find", since they generate clear
>diagnostics, and they are not "hard to fix".
>  
>
I argue that it is not trivially fixable.  In the case of a third party 
library, it is virtually impossible to guarentee that introducing a new 
member will not break any clients of the library.

This is why I like "orthogonality" of code - the act of making a change 
in one facet does not introduce changes in another.  The "with" concept 
breaks orthogonality in arbitrary ways.

Forthwith remove with prejudice. (sorry)

G

Re: c++ "with" keyword

[Robert Dewar]

> I think you missed the point.
> 
> The fact that this can happen - even if you make it illegal, means more 
> maintenance.  Using it from libraries also means that simply adding a 
> member to a library could cause untold number of users to that library 
> have compilation errors.
> 
> Besides, this was a "real" problem with a Pascal program I wrote many 20 
> years ago and why I never used the 'with' keyword since.

I did not miss any point. You said "change the meaning of a program", and
of course ANY change changes the meaning of a program in the literal sense,
so I took it to be the (legitimate) worry that a chnage could cause a silent
change in meaning.

Obviously if you have implicit naming, then introducing new names may
cause existing programs to become illegal. 

A lot depends on whether you want to favor the reader or writer. Your
complaint about having to fix existing programs when a change is made
is about favoring the writer, but the concern about encouraging long
name usage is about favoring the reader.

Note that this is an old discussion in the Ada world. Ada allows the USE
clause to open up visibility, but at the expense of possible illegalities
when new names are used. Some Ada users eschew USE completely, but others
find USE an important capability for improving readability of code.

So I find this general argument against WITH dubious. For sure it is not
a consensus viewpoint, since in practice the world divides between those
who dislike all implicit naming and those who find it valuable. Note that
if such a feature is used, you presumably would prefer not to use it, but
I don't regard that as a good argument for imposing your viewpoint.

The stronger argument against adding WITH in C++ seems to be that there
is already an adequate mechanism for providing short nicknames locally
for long names, and WITH does not provide sufficient extra functionality
to be worth the effort (note that compiler writers will worry that taking
the address of something may degrade the code, so the example with the
reference is an interesting one for the optimization crowd :-)

Re: c++ "with" keyword

[Gianni Mariani]

Robert Dewar wrote:

>>I think you missed the point.
>>
>>The fact that this can happen - even if you make it illegal, means more 
>>maintenance.  Using it from libraries also means that simply adding a 
>>member to a library could cause untold number of users to that library 
>>have compilation errors.
>>
>>Besides, this was a "real" problem with a Pascal program I wrote many 20 
>>years ago and why I never used the 'with' keyword since.
>>    
>>
>
>A lot depends on whether you want to favor the reader or writer. Your
>complaint about having to fix existing programs when a change is made
>is about favoring the writer, but the concern about encouraging long
>name usage is about favoring the reader.
>
I favour code maintenance.  I don't like fixing bugs only to introduce a 
whole bunch of new ones that are hard to find.  This is probably my 
largest concern when it comes to writing code.

Perhaps this is why we have a large difference of opinion of what is 
more important.

>Note that this is an old discussion in the Ada world. Ada allows the USE
>clause to open up visibility, but at the expense of possible illegalities
>when new names are used. Some Ada users eschew USE completely, but others
>find USE an important capability for improving readability of code.
>
>So I find this general argument against WITH dubious. For sure it is not
>a consensus viewpoint, since in practice the world divides between those
>who dislike all implicit naming and those who find it valuable. Note that
>if such a feature is used, you presumably would prefer not to use it, but
>I don't regard that as a good argument for imposing your viewpoint.
>
>The stronger argument against adding WITH in C++ seems to be that there
>is already an adequate mechanism for providing short nicknames locally
>for long names, and WITH does not provide sufficient extra functionality
>to be worth the effort (note that compiler writers will worry that taking
>the address of something may degrade the code, so the example with the
>reference is an interesting one for the optimization crowd :-)
>  
>
Agreed.

Re: c++ "with" keyword

[Robert Dewar]

> Someone innocently added a new member and completly changed the 
> behaviour of the code.  For code maintainability, I'd suggest that this 
> would cause more difficult to discover problems than would be merited.

This is a red herring. Any reasonable definition of the with feature would
make it impossible for the addition of a member name to change the meaning
of existing code (yes, it might make it illegal, but that's reaosnable).

Re: c++ "with" keyword

[Gianni Mariani]

Robert Dewar wrote:

>>Someone innocently added a new member and completly changed the 
>>behaviour of the code.  For code maintainability, I'd suggest that this 
>>would cause more difficult to discover problems than would be merited.
>>    
>>
>
>This is a red herring. Any reasonable definition of the with feature would
>make it impossible for the addition of a member name to change the meaning
>of existing code (yes, it might make it illegal, but that's reaosnable).
>  
>
I think you missed the point.

The fact that this can happen - even if you make it illegal, means more 
maintenance.  Using it from libraries also means that simply adding a 
member to a library could cause untold number of users to that library 
have compilation errors.

Besides, this was a "real" problem with a Pascal program I wrote many 20 
years ago and why I never used the 'with' keyword since.

Re: c++ "with" keyword

[Robert Dewar]

> See Algol 68 for what happens if you do it the other way...

I am willing to bet that this comment is made with *ZERO* knowledge
about Algol-68. In fact the Algol-68 standard was remarkably complete
and successful, and in environments where full Algol-69 compilers
became available (notably on the ICL-9000 and CDC-6000 series machines
it was widely used). The issue of why it was not more successful is
a commercial/marketing one, which had very little if anything to do
with the way the standard was produced.

I am certainly not opposed to experimentation with new features
using existing compilers (GNAT has been used this way in the Adaq
community, for example we implemented "with type" pretty early on
and partly as a result of this experience, we have learned that it
was not the best approach). But discussion and suggestions of new
features are best carried out in forums primarily populated by
users and language designers, rather than compiler implementors.

Another danger of course is that if a half baked feature is
implemented, then it gets stuck and never removed (we will in
fact remove the "WITH TYPE" feature in GNAT when a better
substitute comes along, even though it will discombobulate
people). It is too easy to argue for keeping junk stuff around
for compatibility reasons (witness recent thread here in which
some argued that junk illegal semicolons should be accepted in
C++ due to the existence of incorrect code :-)

Re: c++ "with" keyword

[Daniel Berlin]

>
> Another danger of course is that if a half baked feature is
> implemented, then it gets stuck and never removed (we will in
> fact remove the "WITH TYPE" feature in GNAT when a better
> substitute comes along, even though it will discombobulate
> people).

people?
That sounds bad.
Maybe you should not remove it, sticking instead to removing things 
that only affect code.
Otherwise, you might have some mightily po'ed discombobulated people on 
your hands.

Re: c++ "with" keyword

[Andrew Haley]

Robert Dewar writes:
 > > See Algol 68 for what happens if you do it the other way...
 > 
 > I am willing to bet that this comment is made with *ZERO* knowledge
 > about Algol-68.

Believe that if you wish.  I'm not a betting man.  The Algol 68
language had no implementations when it was standardized -- AFAIK the
first delivery was 1977!

 > In fact the Algol-68 standard was remarkably complete and
 > successful, and in environments where full Algol-69 compilers
 > became available (notably on the ICL-9000 and CDC-6000 series
 > machines it was widely used). The issue of why it was not more
 > successful is a commercial/marketing one, which had very little if
 > anything to do with the way the standard was produced.

To quote Lindsey's official history: "...why it did not come into more
widespread use, and the answer here is simple enough: because it was
not implemented widely enough, or soon enough.  And the reason for
that is that implementation was too hard..."  This would not have been
the case if implementations had existed at the time of
standardization.

 > Another danger of course is that if a half baked feature is
 > implemented, then it gets stuck and never removed (we will in
 > fact remove the "WITH TYPE" feature in GNAT when a better
 > substitute comes along, even though it will discombobulate
 > people). It is too easy to argue for keeping junk stuff around
 > for compatibility reasons (witness recent thread here in which
 > some argued that junk illegal semicolons should be accepted in
 > C++ due to the existence of incorrect code :-)

Yes, but it's a lot easier to remove a feature from a compiler than
from a standard.

Andrew.

Re: c++ "with" keyword

[Toon Moene]

Andrew Haley wrote:

> Yes, but it's a lot easier to remove a feature from a compiler than
> from a standard.

Hmmm, the Fortran community has the opposite experience: Several Fortran 
77 constructs were "obsoleted" in Fortran 95, but every time they get 
mentioned in committee meetings, the vendor members of the committee 
exclaim in unisono: "But our compiler will always support <this construct>".

The Bottom Line: Extensions are like Sex; one mistake and you have to 
support it a life time ...

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Re: c++ "with" keyword

[Robert Dewar]

> I think you missed the point. The reason for the with keyword is not to use
> a pointer but to leave
> the long structs name which is not done by your example :

My viewpoint here is that gcc should not be used as an arena for
implementing random language extensions, no matter how meritorious
they be. Yes, we have some useful extensions in C that should
certainly be maintained at this stage (e.g. nested procedures),
but it is a mistake to go implementing new ones unless there is
some very convincing argument, and a simple "gosh, this woul dbe
convenient to have" is never convincing enough in this context.

If you think "with" is valuable, then the task is to convince the
guardians of the C++ standard of this. If you can't convince the
C++ community to add the feature, then I think it is a mistake
for gcc to second guess.

Re: c++ "with" keyword

[Momchil Velikov]

>>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:

    Robert> If you think "with" is valuable, then the task is to convince the
    Robert> guardians of the C++ standard of this. If you can't convince the

Not related to this particular "with" discussion, but I couldn't
disagree more.  A standards body should not invent language
"features", but rather codify existing (proven) extensions.

    Robert> C++ community to add the feature, then I think it is a mistake
    Robert> for gcc to second guess.

What community ? Compiler developers add features.  

~velco

Re: c++ "with" keyword

[Andrew Haley]

Momchil Velikov writes:
 > >>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:
 > 
 >     Robert> If you think "with" is valuable, then the task is to
 >     Robert> convince the guardians of the C++ standard of this. If
 >     Robert> you can't convince the
 > 
 > Not related to this particular "with" discussion, but I couldn't
 > disagree more.  A standards body should not invent language
 > "features", but rather codify existing (proven) extensions.

I totally agree.  A standards should not invent language features, or
-- heaven forbid -- programming languages.  The reason for this is
pretty obvious, in that once a feature is standardized it's too late
to remove it if it has some fatal flaw.

See Algol 68 for what happens if you do it the other way...

Andrew.

Re: c++ "with" keyword

[Neil Booth]

Andrew Haley wrote:-

> Momchil Velikov writes:
>  > >>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:
>  > 
>  >     Robert> If you think "with" is valuable, then the task is to
>  >     Robert> convince the guardians of the C++ standard of this. If
>  >     Robert> you can't convince the
>  > 
>  > Not related to this particular "with" discussion, but I couldn't
>  > disagree more.  A standards body should not invent language
>  > "features", but rather codify existing (proven) extensions.
> 
> I totally agree.  A standards should not invent language features, or
> -- heaven forbid -- programming languages.  The reason for this is
> pretty obvious, in that once a feature is standardized it's too late
> to remove it if it has some fatal flaw.
> 
> See Algol 68 for what happens if you do it the other way...

Or C++ 8-)

Neil.

Re: c++ "with" keyword

[Gianni Mariani]

Andrew Haley wrote:

>Momchil Velikov writes:
> > >>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:
> > 
> >     Robert> If you think "with" is valuable, then the task is to
> >     Robert> convince the guardians of the C++ standard of this. If
> >     Robert> you can't convince the
> > 
> > Not related to this particular "with" discussion, but I couldn't
> > disagree more.  A standards body should not invent language
> > "features", but rather codify existing (proven) extensions.
>
>I totally agree.  A standards should not invent language features, or
>-- heaven forbid -- programming languages.  The reason for this is
>pretty obvious, in that once a feature is standardized it's too late
>to remove it if it has some fatal flaw.
>  
>
I agree as well.

Proposals of language extensions should come from anyone :)  The metrits 
discussed in community and accepted as a standard once it is generally 
accepted.

So, I'd like to steer the discussion back to the merits of "with".

The "with" syntax was a pain in the rear in Pascal and I never want to 
see it again - this is why:

Take 2 structures, A and B which are both used in a "with" statement.

e.g. (I'll use the proposed new "with" syntax in c++ below)

Let's start with some valid working code ...

struct A {
    int    X;
    int    Y;
    int    hUgH;
};

struct B {
    int    Z;
};

int func()
{
        ....
        A & a;
        B & b;
        ....

        with ( a )
        witb ( b )
        {

            Y = Z;
            hUgH = X; //  woz this then eh ? <-- point of confusion
        }
        ...
}

And a little later someone comes and fixes a bug and adds

struct B {
    int    Z;
    int    X;    // need an X to fix The Bug (tm)
};

Oops - which X is now instantiated at "point of confusion" ?

Someone innocently added a new member and completly changed the 
behaviour of the code.  For code maintainability, I'd suggest that this 
would cause more difficult to discover problems than would be merited.

This is also one of the reasons I don't like namespaces much either - 
hence I allways prefix identifiers that are not within a class's scope.

If you were to implement (heaven forbid) the "with" mechanism, I'd 
suggest you use the "using" keyword instead.

G

Re: c++ "with" keyword

[Tolga Dalman]

On Sat, 04 Jan 2003 09:31:50 -0800 Gianni Mariani <gmariani@chaincast.com> wrote:

> Andrew Haley wrote:
> 
> >Momchil Velikov writes:
> > > >>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:
> > > 
> > >     Robert> If you think "with" is valuable, then the task is to
> > >     Robert> convince the guardians of the C++ standard of this. If
> > >     Robert> you can't convince the
> > > 
> > > Not related to this particular "with" discussion, but I couldn't
> > > disagree more.  A standards body should not invent language
> > > "features", but rather codify existing (proven) extensions.
> >
> >I totally agree.  A standards should not invent language features, or
> >-- heaven forbid -- programming languages.  The reason for this is
> >pretty obvious, in that once a feature is standardized it's too late
> >to remove it if it has some fatal flaw.
> >  
> >
> I agree as well.
> 
> Proposals of language extensions should come from anyone :)  The metrits 
> discussed in community and accepted as a standard once it is generally 
> accepted.
> 
> So, I'd like to steer the discussion back to the merits of "with".
> 
> The "with" syntax was a pain in the rear in Pascal and I never want to 
> see it again - this is why:
> 
> Take 2 structures, A and B which are both used in a "with" statement.
> 
> e.g. (I'll use the proposed new "with" syntax in c++ below)
> 
> Let's start with some valid working code ...
> 
> struct A {
>     int    X;
>     int    Y;
>     int    hUgH;
> };
> 
> struct B {
>     int    Z;
> };
> 
> int func()
> {
>         ....
>         A & a;
>         B & b;
>         ....
> 
>         with ( a )
>         witb ( b )
>         {
> 
>             Y = Z;
>             hUgH = X; //  woz this then eh ? <-- point of confusion
>         }
>         ...
> }
> 
> And a little later someone comes and fixes a bug and adds
> 
> struct B {
>     int    Z;
>     int    X;    // need an X to fix The Bug (tm)
> };
> 
> Oops - which X is now instantiated at "point of confusion" ?
> 
> Someone innocently added a new member and completly changed the 
> behaviour of the code.  For code maintainability, I'd suggest that this 
> would cause more difficult to discover problems than would be merited.
> 

it should be possible to disallow a "with" keyword within another "with" block.

> This is also one of the reasons I don't like namespaces much either - 
> hence I allways prefix identifiers that are not within a class's scope.
> 

hm, i know a lot of people who don't like namespaces aswell, but the point is: 
it'd be great to have a compiler-feature to make code more readable. 
i think, long struct-names are very annoying and a common  solution 
(either standard or compiler-addon) for this problem would be very good.
just my opinion. 

> If you were to implement (heaven forbid) the "with" mechanism, I'd 
> suggest you use the "using" keyword instead.
>

the actual name doesn't matter i think, but "with" is already used in other programming languages. so, why to use "using"?
 

brg, 
Tolga Dalman.

Re: c++ "with" keyword

[Gianni Mariani]

Tolga Dalman wrote:

>On Sat, 04 Jan 2003 09:31:50 -0800 Gianni Mariani <gmariani@chaincast.com> wrote
>  
>
>>
>>So, I'd like to steer the discussion back to the merits of "with".
>>
>>The "with" syntax was a pain in the rear in Pascal and I never want to 
>>see it again - this is why:
>>
>>Take 2 structures, A and B which are both used in a "with" statement.
>>
>>e.g. (I'll use the proposed new "with" syntax in c++ below)
>>
>>Let's start with some valid working code ...
>>
>>struct A {
>>    int    X;
>>    int    Y;
>>    int    hUgH;
>>};
>>
>>struct B {
>>    int    Z;
>>};
>>
>>int func()
>>{
>>        ....
>>        A & a;
>>        B & b;
>>        ....
>>
>>        with ( a )
>>        witb ( b )
>>        {
>>
>>            Y = Z;
>>            hUgH = X; //  woz this then eh ? <-- point of confusion
>>        }
>>        ...
>>}
>>
>>And a little later someone comes and fixes a bug and adds
>>
>>struct B {
>>    int    Z;
>>    int    X;    // need an X to fix The Bug (tm)
>>};
>>
>>Oops - which X is now instantiated at "point of confusion" ?
>>
>>Someone innocently added a new member and completly changed the 
>>behaviour of the code.  For code maintainability, I'd suggest that this 
>>would cause more difficult to discover problems than would be merited.
>>
>>    
>>
>
>it should be possible to disallow a "with" keyword within another "with" block.
>  
>
It becomes MUCH less useful if you do this and hence I'll argue that it 
makes little sense to have a "with" at all.
In almost every case where I used the "with" keyword in my distant past, 
I remember that I was dealing with at least 2 structures and messing 
with them together.

>>This is also one of the reasons I don't like namespaces much either - 
>>hence I allways prefix identifiers that are not within a class's scope.
>>
>>    
>>
>
>hm, i know a lot of people who don't like namespaces aswell, but the point is: 
>it'd be great to have a compiler-feature to make code more readable. 
>i think, long struct-names are very annoying and a common  solution 
>(either standard or compiler-addon) for this problem would be very good.
>just my opinion. 
>  
>

But there is, as has been explained :)

            {
                A & y = long_descriptive_expression_I_dont_like_repeating;
                B & z = long_descriptive_expression_I_dont_like_repeating;

                z.memberA = z.memberB;
                z.memberB = y.memberA;
            }

... Totally unambiguous, very readable, no new syntax - QED.

>  
>
>>If you were to implement (heaven forbid) the "with" mechanism, I'd 
>>suggest you use the "using" keyword instead.
>>
>>    
>>
>
>the actual name doesn't matter i think, but "with" is already used in other programming languages. so, why to use "using"?
>
sematically similar meaning of the keyword - it's just a suggestion.

Re: c++ "with" keyword

[Tolga Dalman]

On Sat, 04 Jan 2003 10:12:11 -0800 Gianni Mariani <gmariani@chaincast.com> wrote:

> Tolga Dalman wrote:
> 
> >On Sat, 04 Jan 2003 09:31:50 -0800 Gianni Mariani <gmariani@chaincast.com> wrote
> >  
> >
> >>
> >>So, I'd like to steer the discussion back to the merits of "with".
> >>
> >>The "with" syntax was a pain in the rear in Pascal and I never want to 
> >>see it again - this is why:
> >>
> >>Take 2 structures, A and B which are both used in a "with" statement.
> >>
> >>e.g. (I'll use the proposed new "with" syntax in c++ below)
> >>
> >>Let's start with some valid working code ...
> >>
> >>struct A {
> >>    int    X;
> >>    int    Y;
> >>    int    hUgH;
> >>};
> >>
> >>struct B {
> >>    int    Z;
> >>};
> >>
> >>int func()
> >>{
> >>        ....
> >>        A & a;
> >>        B & b;
> >>        ....
> >>
> >>        with ( a )
> >>        witb ( b )
> >>        {
> >>
> >>            Y = Z;
> >>            hUgH = X; //  woz this then eh ? <-- point of confusion
> >>        }
> >>        ...
> >>}
> >>
> >>And a little later someone comes and fixes a bug and adds
> >>
> >>struct B {
> >>    int    Z;
> >>    int    X;    // need an X to fix The Bug (tm)
> >>};
> >>
> >>Oops - which X is now instantiated at "point of confusion" ?
> >>
> >>Someone innocently added a new member and completly changed the 
> >>behaviour of the code.  For code maintainability, I'd suggest that this 
> >>would cause more difficult to discover problems than would be merited.
> >>
> >>    
> >>
> >
> >it should be possible to disallow a "with" keyword within another "with" block.
> >  
> >
> It becomes MUCH less useful if you do this and hence I'll argue that it 
> makes little sense to have a "with" at all.
> In almost every case where I used the "with" keyword in my distant past, 
> I remember that I was dealing with at least 2 structures and messing 
> with them together.

i understand. "with" is comparable to the switch-case construct. there, you aren't allowed to uses cascaded switch'es. i'm happy to have it anyways, 
and i believe a with would be aswell useful. 

additionally, i don't think there's a (efficient, at least) way to solve the 
ambiguity problem for multiple withs. 

> 
> >>This is also one of the reasons I don't like namespaces much either - 
> >>hence I allways prefix identifiers that are not within a class's scope.
> >>
> >>    
> >>
> >
> >hm, i know a lot of people who don't like namespaces aswell, but the point is: 
> >it'd be great to have a compiler-feature to make code more readable. 
> >i think, long struct-names are very annoying and a common  solution 
> >(either standard or compiler-addon) for this problem would be very good.
> >just my opinion. 
> >  
> >
> 
> But there is, as has been explained :)
> 
>             {
>                 A & y = long_descriptive_expression_I_dont_like_repeating;
>                 B & z = long_descriptive_expression_I_dont_like_repeating;
> 
>                 z.memberA = z.memberB;
>                 z.memberB = y.memberA;
>             }
> 
> ... Totally unambiguous, very readable, no new syntax - QED.
> 

... and potentially two new variables in your code and binary.
what i wanted to have:

 
             {
               #define y long_descriptive_expression_I_dont_like_repeating;
               #define z long_descriptive_expression_I_dont_like_repeating;
 
                 z.memberA = z.memberB;
                 z.memberB = y.memberA;
               #undef z
               #undef y
             }
 
but this is just ugly. 
no offense, but you state you wouldn't like namespaces, on the other hand 
you propagate using new variables within a new block to be less confusing?


> >  
> >
> >>If you were to implement (heaven forbid) the "with" mechanism, I'd 
> >>suggest you use the "using" keyword instead.
> >>
> >>    
> >>
> >
> >the actual name doesn't matter i think, but "with" is already used in other programming languages. so, why to use "using"?
> >
> sematically similar meaning of the keyword - it's just a suggestion.
> 

one reason against the with keyword would be that there's one more word in our
C vocabulary. a (programming-)language with too many words is rather unattractive, i'd say.

Tolga Dalman.

Re: c++ "with" keyword

[Kevin Handy]

Tolga Dalman wrote:

>On Sat, 04 Jan 2003 09:31:50 -0800 Gianni Mariani <gmariani@chaincast.com> wrote:
>
>  
>
>>Andrew Haley wrote:
>>
>>    
>>
>>>Momchil Velikov writes:
>>>      
>>>
>>>>>>>>>"Robert" == Robert Dewar <dewar@gnat.com> writes:
>>>>>>>>>                  
>>>>>>>>>
>>>>    Robert> If you think "with" is valuable, then the task is to
>>>>    Robert> convince the guardians of the C++ standard of this. If
>>>>    Robert> you can't convince the
>>>>
>>>>Not related to this particular "with" discussion, but I couldn't
>>>>disagree more.  A standards body should not invent language
>>>>"features", but rather codify existing (proven) extensions.
>>>>        
>>>>
>>>I totally agree.  A standards should not invent language features, or
>>>-- heaven forbid -- programming languages.  The reason for this is
>>>pretty obvious, in that once a feature is standardized it's too late
>>>to remove it if it has some fatal flaw.
>>> 
>>>
>>>      
>>>
>>I agree as well.
>>
>>Proposals of language extensions should come from anyone :)  The metrits 
>>discussed in community and accepted as a standard once it is generally 
>>accepted.
>>
>>So, I'd like to steer the discussion back to the merits of "with".
>>
>>The "with" syntax was a pain in the rear in Pascal and I never want to 
>>see it again - this is why:
>>
>>Take 2 structures, A and B which are both used in a "with" statement.
>>
>>e.g. (I'll use the proposed new "with" syntax in c++ below)
>>
>>Let's start with some valid working code ...
>>
>>struct A {
>>    int    X;
>>    int    Y;
>>    int    hUgH;
>>};
>>
>>struct B {
>>    int    Z;
>>};
>>
>>int func()
>>{
>>        ....
>>        A & a;
>>        B & b;
>>        ....
>>
>>        with ( a )
>>        witb ( b )
>>        {
>>
>>            Y = Z;
>>            hUgH = X; //  woz this then eh ? <-- point of confusion
>>        }
>>        ...
>>}
>>
>>And a little later someone comes and fixes a bug and adds
>>
>>struct B {
>>    int    Z;
>>    int    X;    // need an X to fix The Bug (tm)
>>};
>>
>>Oops - which X is now instantiated at "point of confusion" ?
>>
>>Someone innocently added a new member and completly changed the 
>>behaviour of the code.  For code maintainability, I'd suggest that this 
>>would cause more difficult to discover problems than would be merited.
>>
>>    
>>
>
>it should be possible to disallow a "with" keyword within another "with" block.
>  
>
Rendering it even more useless.


I dislike "with" in any language because it adds much more burden to
maintainers of the code. In the middle of a hundred line section of code
using with

    with (some_very_long_name) with(another_very_long_name)
    {
        ... Many lines of code
        x = y;    // suspect line
        ...Many more lines of code
    }

You see a simple line of code. Now, where does 'x' come from? How
about 'y'? Is it refering to something in the structire or a global
variable? If there is both a simple variable 'x' in scope, as well as
a structure memebr 'x', which one gets used? What if 'x' exists in
both structures?

It requires the maintainer, who may not have been the original
author, to deal with much more context than if it were simply
written

    x = some_very_long_name.y;

When classes are thrown into the mix, you also have the fun of
needing to trace through all the inherited classes where it may
possibly be a member. Not my idea of fun.

And to search for references to a structure becomes much more
complex.  Instead of looking for a '.x' or '->x', you must now search
for 'x', and then look to see if the reference is within a 'using'
clause.

Sorry, I don't see how 'using' would improve the language in
more ways than it would harm it. Never liked it in Pascal, and
wouldn't like it in C++ either.

>  
>
>>This is also one of the reasons I don't like namespaces much either - 
>>hence I allways prefix identifiers that are not within a class's scope.
>>
>>    
>>
>
>hm, i know a lot of people who don't like namespaces aswell, but the point is: 
>it'd be great to have a compiler-feature to make code more readable. 
>i think, long struct-names are very annoying and a common  solution 
>
If long names are causing you typing problems, then DON'T CREATE LONG
NAMES IN THE FIRST PLACE. The "standard" C and C++ libraries usually
use fairly short names for everything. Most of the long names I've seen are
those created specifically for the program in question.  If the long 
names are
a real problem for you, then why create them in the first place?

>(either standard or compiler-addon) for this problem would be very good.
>just my opinion. 
>
>  
>
>>If you were to implement (heaven forbid) the "with" mechanism, I'd 
>>suggest you use the "using" keyword instead.
>>
>>    
>>
>
>the actual name doesn't matter i think, but "with" is already used in other programming languages. so, why to use "using"?
> 
>
>  
>

Re: c++ "with" keyword

[Erik Schnetter]

The example

	struct S
	{
	    int x;
	    int y;
	};
	
	int main()
	{
	    S s;
	    with (s)
	    {
	        .x = 1;
	        .y = 2;
	    }
	    return 0;
	}

can easily be rewritten by introducing temporary references, as in

	int main()
	{
	    S s;
	    {
	        S& t = s;
	        t.x = 1;
	        t.y = 2;
	    }
	    return 0;
	}

This requires only one additional variable reference each time the 
"with" object is used.  Additionally, it allows several "with" objects 
(with different names) at the same time.  In C, the same thing can be 
done by using pointers.

-erik

-- 
Erik Schnetter <schnetter@uni-tuebingen.de>
Web: http://www.tat.physik.uni-tuebingen.de/~schnette/

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.