Re: Re: c++ "with" keyword

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: Re: c++ "with" keyword

[Fergus Henderson]

On 04-Jan-2003, Robert Dewar <dewar@gnat.com> wrote:
> > 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.

My viewpoint is slightly different: GCC *should* be used as an arena for
implementing random language extensions, but in general those extensions
should not be merged into the main CVS branch.  (They would only be merged
on the main branch if there is a *very* convincing case made for them.)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: Re: c++ "with" keyword

[Robert Dewar]

> My viewpoint is slightly different: GCC *should* be used as an arena for
> implementing random language extensions, but in general those extensions
> should not be merged into the main CVS branch.  (They would only be merged
> on the main branch if there is a *very* convincing case made for them.)

Yes, of course it is fine to use GCC as an arena for playing with language
extensions. I did not mean to imply otherwise. I was talking about the
official release.

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