Topic: proposal: using named parameters separators


Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Thu, 3 Jul 2003 00:41:12 +0000 (UTC)
Raw View
petebecker@acm.org (Pete Becker) wrote in message news:<3F021F5C.2555FA00@acm.org>...
> "danielgutson@hotmail.com" wrote:
> >
> > Consider the simple call (repeating my example) of string s substr:
> >    substr(1,2)
> > the first time you read it or an extremely fast review.
> > What would you (the unexperienced) think the second parameter means?
>
> The inexperienced programmer should look it up. I would. There should be
> no tolerance for programmers who guess at what code does when they don't
> know.
>

English is not my native language -as I said many times-.

The first English book (about literature) I read was William Gibson's
"All tomorrow's parties", my favorite alive writer.
I read the Spanish translation of all the previous books.
When I caught this one, and tried to read it, I had to stop almost
every 4 words for going to the dictionary. I had all the energy that
comes from the enthusiasm of being a fan of W.G.'s world. I lost it,
because I was loosing the sense, even with 2 or 3 re-reads.
I had to stop and buy a pen-scanner dictionary, then I could read it.
(and of course it fascinated me again).

I do believe that reading source code has a similar analogy, in fact,
we are talking about readability and understandability.
Of course I do agree with you about the lack of mercy needed with the
easy-reader. But I'm not proposing this for such kind of reader.
I'm proposing this for 2 reasons: for the high-level understandability
( a) first read, without loosing the meaning, b) for avoiding
misunderstandings while reading in a rush), and second, a minor but
consecuence, the ability of enhancing the overloading capability -not
only parameter types-.

Regards,
  Daniel.

ps: yes, I also look it up, in fact, I had to the first time I saw the
substr call :)

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





Author: pasa@lib.hu ("Balog Pal")
Date: Thu, 3 Jul 2003 23:49:21 +0000 (UTC)
Raw View
<danielgutson@hotmail.com> wrote in message
news:23478c42.0307020937.68d07109@posting.google.com...

> I had to stop and buy a pen-scanner dictionary, then I could read it.
> (and of course it fascinated me again).

Extremely good point. And really fits here.

As we have development environments for C++ that do exactly that. Even
really old ones did look up the help on right click or some-F1 press for
library functions, keywords, diagnostics.
More current ones show info in tooltips by simply movind the cursor on a
word, and when you type in a function, they can show the prototypes (with
the arguments and names). Not limited to factory-shipped stuff, but
including anything you have in your project.

That IMHO perfectly covers the substr case so much cited here without any
change to the language itself.

> I do believe that reading source code has a similar analogy, in fact,
> we are talking about readability and understandability.
> Of course I do agree with you about the lack of mercy needed with the
> easy-reader. But I'm not proposing this for such kind of reader.

I find it interesting that the 'literary code' guidelines still stick to the
TTY era. Like there were no development in the environment.  For example I
saw some other languages presenting the code in a tree view.   Where you
could open the deeper levels if wanted, fron class to function, in function
the nested if blocks, for loops, etc.

With C++ we unfortunately don;t have an easy way (if a way at all) to show a
general source like that. (preprocessor will definitely block the road).
But suppose it were possible -- the consequence would be gross.

Like the "keep your functions short" loses ground. We could finally get rid
of the sand-making effect I see nowadays, tons of meaningless one-call
functions, which could be perfectly kept inline.    But all that drifts
far...


Paul


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





Author: kanze@alex.gabi-soft.fr (James Kanze)
Date: Fri, 27 Jun 2003 17:38:50 +0000 (UTC)
Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) writes:


|>  > What about:

|>  >   void f(char const*); // (1)
|>  >   void f(char const* "AND" char const*);

|>  > and a call:
|>  >   f("1" "AND" "2");  // Which function is called?
|>  Well, actually, I'm proposing that function call doesn't use the
|>  double quotes, so it would become

|>     f("1" AND "2");
|>  However, everybody is terrified with the parsing issue. I agree, I
|>  admit it.

|>  But, The fact that current compilers -I think- don't use
|>  context-aided lexers, should not stop language evolving.

Current compilers DO use context-aided lexers.  And back-tracking.
And a lot of other exotic techniques.  You can't parse C++ without it.

The problem is that human beings don't use context-aided lexers.  They
already have a lot of problems with C++ syntax.  No point in making it
worse.

--=20
James Kanze                                  mailto:kanze@gabi-soft.fr
Conseils en informatique orient=E9e objet/
                      Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France  Tel. +33 1 41 89 80 93

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





Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Tue, 1 Jul 2003 23:45:15 +0000 (UTC)
Raw View
kanze@alex.gabi-soft.fr (James Kanze) wrote in message news:<868yru47rk.fsf@alex.gabi-soft.fr>...
> |>  But, The fact that current compilers -I think- don't use
> |>  context-aided lexers, should not stop language evolving.
>
> Current compilers DO use context-aided lexers.  And back-tracking.
> And a lot of other exotic techniques.  You can't parse C++ without it.

>
> The problem is that human beings don't use context-aided lexers.  They
> already have a lot of problems with C++ syntax.  No point in making it
> worse.
>

GOOD. We reached the point.

First, let   s agree that    worse    is your opinion.
And I say this because it is a good point: readability.
As we know, we need to use our brain-resources in the semantinc part
rather than the parsing part. (more resources for the understanding
process than the reading process). We all agree about that.

And I think we also agree that current C++ syntax allows to produce
code as unreadable as the programmers wants.
The difference is what tools it provides for the good programmer to
produce more readable code.

What I   m proposing here, is simple a tool, and of course it can be
used as a weapon -like a hammer-.

What I saw in the Oxford meeting was the trend to provide tools for
the advanced programming community: I want to repeat something I heard
from Francis Glassborow (it was something like this :) )
  before, the quote was    trust in the language   , and now, it became
   trust in the library writer   .

Merging that concept with yours, what I say is: if you -library
writer- are clean enough to write a code with good usage of -for
example- this feature, then the user will have a benefit.

Consider the simple call (repeating my example) of string   s substr:
   substr(1,2)
the first time you read it or an extremely fast review.
What would you (the unexperienced) think the second parameter means?
BUT, if you can see
   substr(1 TO 2)
or
   substr(2 COUNTING 3)

I think you won   t have any doubt about its meaning.

I do believe it can be misused, in the same sense I also think it can
really help readability with a good common sense.

It would be a matter of picking good (meaningful) string litterals
when used, and not messing them with other symbols same-named
somewhere.
In fact, overloading is expanded. Now overloaded is tight to parameter
types, even with same semantics (both substr methods do the same
thing: they extract a substring. How, in terms of their parameters,
**AND** their separator :) ).

 Daniel.

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





Author: petebecker@acm.org (Pete Becker)
Date: Wed, 2 Jul 2003 02:08:34 +0000 (UTC)
Raw View
"danielgutson@hotmail.com" wrote:
>=20
> Consider the simple call (repeating my example) of string=B4s substr:
>    substr(1,2)
> the first time you read it or an extremely fast review.
> What would you (the unexperienced) think the second parameter means?

The inexperienced programmer should look it up. I would. There should be
no tolerance for programmers who guess at what code does when they don't
know.

--=20

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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





Author: dave@boost-consulting.com (David Abrahams)
Date: Fri, 20 Jun 2003 19:35:17 +0000 (UTC)
Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) writes:

> BTW, I have to admit that the enum way didn=B4t come to my mind.
> In such case, an infamous macro solution could be done:
>
> enum to {To};
> enum downto {DownTo};
>
> #define TO ,To,
> #define DOWNTO ,DownTo,
>
> f(int start,to,int end);
> f(int end,downto,int start);
>
> But I=B4m sure you will agree with me how painfully awfull this is :)

Only in that the resulting usage is an abomination.  I think adding a
language feature to support it would be even more "awfull".

Sorry, just IMO.

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

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





Author: Michiel.Salters@cmg.nl (Michiel Salters)
Date: Wed, 11 Jun 2003 19:31:56 +0000 (UTC)
Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0306061427.6f249d8f@posting.google.com>...
> Hi there.
>
> INTRO.
>  Many was said about providing information or self documentation in
> function calls and/or function declarations, such as named parameters,
> etc.
>
> What I   m proposing is to provide the ability of using string literals
> as parameter separators, instead of the commas. [...]
> This would also permit overloading accepting the same types, but with
> different separators.
>
> For example:
>
> void f( int start "TO" int end );
> void f( int end "DOWNTO" int start);
>
> and, when calling:
>
> f(1 TO 10);      //first version invoked
> f(4 DOWNTO 1);   //second version invoked
> f(3,4) //error: not defined

I see nobody has mentioned the parser nightmares this will create.
Current C++ parsers are (rumored to be) worse enough for the current
language. This will make it unmanageable

In the current language, every token that isn't reserved for the
implementation names a type, variable, enumerator, template etc.
Such tokens are always introduced by a declaration. Except for
templates, they either are types, refer to types or have types.
A templates effectively is a group of types or a group of
functions; since functions have types too we can say that all
names fit in the type system.

With this proposed implementation, the declaration of f also
introduces a new token. In addition, this token is unlike any
other; it is totally unrelated to the type/object system.


There are also issued related to parsing strings. Currently, text
between "" relates to the runtime character set, while variable
names are in the compiler's character set. These domains are
really unrelated in C++, witness the "string form of enumerator"
discussions which regularly pop up. We'd need new rules for what
can appear between quotes.

Producing clear error messages has become even harder, as that
requires all kind of hooks in the parser to "guess" what was meant.
With this extension, there are a lot of new borderline cases where
the parser just can't guess:

void foo( int, float, int );
void foo( int "TO" int );
float TO = 17;
foo( 5, TO 7 ); //Challenge: produce a decent error message.

In short, a high price, little benefit (see Dave's post why the
relative benefit is even smaller) and no concrete proposal where
and how the standard should be changed. I'll vote against it.

Regards,
--
Michiel Salters

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





Author: heliosc@mindspring.com (Rayiner Hashem)
Date: Thu, 12 Jun 2003 04:07:16 +0000 (UTC)
Raw View
This whole thing seems remeniscent of the "#define == is" thing you
sometimes see. The language isn't supposed to work like that, so
please don't try to shoe-horn it. It just throws people for a loop
when they see stuff like that. What would be far more interesting to
me would be standardizing on something like JavaDoc (maybe the Doxygen
method) so our intelligent editors (you *do* use one of those, don't
you?) could do a better job of popping up some documentation when you
try to use a function.

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





Author: kanze@gabi-soft.fr
Date: Thu, 12 Jun 2003 17:42:21 +0000 (UTC)
Raw View
Michiel.Salters@cmg.nl (Michiel Salters) wrote in message
news:<cefd6cde.0306110747.1141d81a@posting.google.com>...
> danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message
> news:<23478c42.0306061427.6f249d8f@posting.google.com>...

> > INTRO.
> >  Many was said about providing information or self documentation in
> > function calls and/or function declarations, such as named parameters,
> > etc.

> > What I   m proposing is to provide the ability of using string literals
> > as parameter separators, instead of the commas. [...]
> > This would also permit overloading accepting the same types, but with
> > different separators.

> > For example:

> > void f( int start "TO" int end );
> > void f( int end "DOWNTO" int start);

> > and, when calling:

> > f(1 TO 10);      //first version invoked
> > f(4 DOWNTO 1);   //second version invoked
> > f(3,4) //error: not defined

> I see nobody has mentioned the parser nightmares this will create.
> Current C++ parsers are (rumored to be) worse enough for the current
> language. This will make it unmanageable

> In the current language, every token that isn't reserved for the
> implementation names a type, variable, enumerator, template etc.  Such
> tokens are always introduced by a declaration. Except for templates,
> they either are types, refer to types or have types.  A templates
> effectively is a group of types or a group of functions; since
> functions have types too we can say that all names fit in the type
> system.

> With this proposed implementation, the declaration of f also
> introduces a new token. In addition, this token is unlike any other;
> it is totally unrelated to the type/object system.

This is the real problem.  To begin with, every user defined symbol has
scope.  His proposal introduces symbols that act like keywords or
operators.  Do they have scope, or not?  If they don't have scope, what
happens if I try to define a variable called DOWNTO.  If they do, it
would be a real challange to write a parser, since the grammar of the
language would depend on what is in scope at the moment -- if the above
declaration is in an outer scope, in:
    f ( 4 DOWNTO 1 ) ;
DOWNTO is a pseudo-keyword, and operator, but in
    int DOWNTO ;
it is a user variable.

It's the sort of ambiguity that all modern languages try to avoid.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T   l. : +33 (0)1 30 23 45 16

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





Author: jhyslop@ieee.org (Jim Hyslop)
Date: Sun, 15 Jun 2003 05:27:10 +0000 (UTC)
Raw View
danielgutson@hotmail.com wrote:
> Hi there.
>=20
> INTRO.
>  Many was said about providing information or self documentation in
> function calls and/or function declarations, such as named parameters,
> etc.
>=20
> What I=B4m proposing is to provide the ability of using string literals
> as parameter separators, instead of the commas. (I=B4M NOT TALKING ABOU=
T
> REMOVING COMMAS FROM THE LANGUAGE).
> This would also permit overloading accepting the same types, but with
> different separators.
>=20
> For example:
>=20
> void f( int start "TO" int end );
> void f( int end "DOWNTO" int start);
>=20

I think this is a violation of the principle of least surprise. When one=20
sees an overloaded function, one would expect that the two functions do=20
the same thing (that is, perform conceptually the same actions). In this=20
case, the two functions appear to do two different things - one counts=20
up, the other counts down. They should _not_ have the same name.

Two solutions to this particular example would be:

a)
void CountUp(int start, int end);
void CountDown(int end, int start);

b)
enum Direction { UP, DOWN };
void Count( int start, int end, Direction );

Can you provide an example where you think you want overloading, that=20
would not be satisfactorily resolved by either of the two ideas above?

--=20
Jim

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





Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Sun, 15 Jun 2003 06:02:20 +0000 (UTC)
Raw View
> > With this proposed implementation, the declaration of f also
> > introduces a new token. In addition, this token is unlike any other;
> > it is totally unrelated to the type/object system.
>
> This is the real problem.  To begin with, every user defined symbol has
> scope.  His proposal introduces symbols that act like keywords or
> operators.  Do they have scope, or not?  If they don't have scope, what
> happens if I try to define a variable called DOWNTO.  If they do, it

YES, they do. That's why I'm saying that this could be seen as
"signature scope". But I don't like that.

As far as the language complexity evolves, and -additionaly- parsing
technologies also evolves, why not starting to consider context-aided
lexing?
Or those parser-aided lexers, or in general [upper_level]-aided
[level]?

YEs, of course I know compilers are already written, nobody (nobody?
Not exactly :) ) writes compilers from scratch, and they are the flesh
of the language.

But...

> would be a real challange to write a parser, since the grammar of the
> language would depend on what is in scope at the moment -- if the above
> declaration is in an outer scope, in:
>     f ( 4 DOWNTO 1 ) ;
> DOWNTO is a pseudo-keyword, and operator, but in

I don't understand why is a pseudo-keyword.
I don't propose to change NOTHING about the tokenizing process.
It **should** be just another identifier. Parser level.

For the declaration, the string is read as a string-literal token.
Symbol table.
Invocation: expression expression(i.e. DOWNTO) expression ...

I think this could be solved during the AST traversing...at least the
compiler I saw could be solved in that way.


>     int DOWNTO ;
> it is a user variable.
>
> It's the sort of ambiguity that all modern languages try to avoid.

We already can repeated identifiers in different contexts, name
hidings, disambiguation rules, ...

Suppose:

char* substr(const char* str, size_t start "TO" size_t end);
char* substr(const char* str, size_t start "COUNTING" size_t count);

void usage
{
  int TO(1);

  char* sub = substr("HELLO WORLD", 1 TO 5);
}

I have 2 comments about this code:

1) I DO AGREE that same function name (function overloading) is
justified as far as they DO THE SAME: they return a substring. We
already use overloading for grouping functionality differentiated from
the parameters types. Same parameters type? I'm sorry, name it
different (start with those names like "find_last_of" or
"find_not_last_of" for every flavor...
I don't like it, and this would solve it unless we have a 'strong
typedef' and again defining one type for each function flavor (ok, you
can define units)...

2) I don't see ambiguity, as far as signature's "TO" produces a name
hiding of the "int TO".


Unfortunatelly, I have nothing else to say, because your arguments are
very strong in terms of [un]feasibility.
I consider usability, I'm a compiler customer :)
IMHO, fast to write (rapid dev.), easy to read (from the programmers
point of view), and improves overloading usage by avoiding
almost-sentences in function names.

Thank you,

  Daniel.

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





Author: kanze@alex.gabi-soft.fr (James Kanze)
Date: Sun, 15 Jun 2003 22:13:55 +0000 (UTC)
Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) writes:

|>  > > With this proposed implementation, the declaration of f also
|>  > > introduces a new token. In addition, this token is unlike any
|>  > > other; it is totally unrelated to the type/object system.

|>  > This is the real problem.  To begin with, every user defined
|>  > symbol has scope.  His proposal introduces symbols that act like
|>  > keywords or operators.  Do they have scope, or not?  If they
|>  > don't have scope, what happens if I try to define a variable
|>  > called DOWNTO.  If they do, it

|>  YES, they do. That's why I'm saying that this could be seen as
|>  "signature scope". But I don't like that.

|>  As far as the language complexity evolves, and -additionaly-
|>  parsing technologies also evolves, why not starting to consider
|>  context-aided lexing?  Or those parser-aided lexers, or in general
|>  [upper_level]-aided [level]?

|>  YEs, of course I know compilers are already written, nobody
|>  (nobody?  Not exactly :) ) writes compilers from scratch, and they
|>  are the flesh of the language.

|>  But...
|>  > would be a real challange to write a parser, since the grammar
|>  > of the language would depend on what is in scope at the moment
|>  > -- if the above declaration is in an outer scope, in:
|>  >     f ( 4 DOWNTO 1 ) ;
|>  > DOWNTO is a pseudo-keyword, and operator, but in

|>  I don't understand why is a pseudo-keyword.

Because the grammar doesn't have any production for int-literal symbol
int-literal.

|>  I don't propose to change NOTHING about the tokenizing process.
|>  It **should** be just another identifier. Parser level.

Parser level, its not possible.  Scanner level, perhaps.

It's probably doable.  I've written scanners which were aware of the
parser state, and would scan according to a list of legal tokens in
that context.

|>  For the declaration, the string is read as a string-literal token.
|>  Symbol table.
|>  Invocation: expression expression(i.e. DOWNTO) expression ...

|>  I think this could be solved during the AST traversing...at least
|>  the compiler I saw could be solved in that way.

|>  >     int DOWNTO ;
|>  > it is a user variable.

|>  > It's the sort of ambiguity that all modern languages try to avoid.

|>  We already can repeated identifiers in different contexts, name
|>  hidings, disambiguation rules, ...

But they always remain symbols.  It is already a major problem in C
and C++ that you must know whether a symbol is a typename or not in
order to parse.  It makes things difficult for the compiler, and even
more difficult for the reader.  What you are suggesting adds to that
difficultly.

|>  Suppose:

|>  char* substr(const char* str, size_t start "TO" size_t end);
|>  char* substr(const char* str, size_t start "COUNTING" size_t count);

|>  void usage
|>  {
|>    int TO(1);

|>    char* sub =3D substr("HELLO WORLD", 1 TO 5);
|>  }

|>  I have 2 comments about this code:

|>  1) I DO AGREE that same function name (function overloading) is
|>  justified as far as they DO THE SAME: they return a substring. We
|>  already use overloading for grouping functionality differentiated fro=
m
|>  the parameters types. Same parameters type? I'm sorry, name it
|>  different (start with those names like "find_last_of" or
|>  "find_not_last_of" for every flavor...
|>  I don't like it, and this would solve it unless we have a 'strong
|>  typedef' and again defining one type for each function flavor (ok, yo=
u
|>  can define units)...

|>  2) I don't see ambiguity, as far as signature's "TO" produces a name
|>  hiding of the "int TO".

|>  Unfortunatelly, I have nothing else to say, because your arguments
|>  are very strong in terms of [un]feasibility.

OK.  We understand each other, at least.

|>  I consider usability, I'm a compiler customer :) IMHO, fast to
|>  write (rapid dev.), easy to read (from the programmers point of
|>  view), and improves overloading usage by avoiding almost-sentences
|>  in function names.

I understand the point.  However, from the point of usability, we need
something that is absolutely clear.  C++ has enough ambiguities as it
is, without adding any.

--=20
James Kanze                                  mailto:kanze@gabi-soft.fr
Conseils en informatique orient=E9e objet/
                      Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France  Tel. +33 1 41 89 80 93

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





Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Mon, 16 Jun 2003 19:37:05 +0000 (UTC)
Raw View
Hi Daveed:
>
> What about:
>
>   void f(char const*); // (1)
>   void f(char const* "AND" char const*);
>
> and a call:
>   f("1" "AND" "2");  // Which function is called?

Well, actually, I'm proposing that function call doesn't use the
double quotes, so it would become
   f("1" AND "2");

However, everybody is terrified with the parsing issue.
I agree, I admit it.

But, The fact that current compilers -I think- don't use context-aided
lexers, should not stop language evolving.
I know, if current compilers don't implement it, it would arrive to a
discussion similar to the export templates...and it's not my
intention.

I'll continue answering about the scope in the next message, when the
poster mentions it.

Thanks,
  Daniel.

>
> Note that with current C++, (1) is a perfectly viable
> candidate.  To keep compatibility, you'll need an ugly
> kink in your feature.  To avoid that kink, you break
> compatibility for something that does not seem all that
> compelling to me.

Well, according to the comment above, and the original post, it does
not break existing code as far as I see.

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





Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Mon, 16 Jun 2003 19:37:33 +0000 (UTC)
Raw View
> >     void f(int start "TO" int end);
> >     void f(int end "DOWNTO" int start);
> > [usage]
> >     f(1 TO 10);
> >     f(10 DOWNTO 1);
> > [end]
>
> Oh, wait, now you want to be able to invoke it without the quotes in
> the separator?

YES :) I DO (I did want from the beginning, see the    open issues    in
the original message)

> >What characters do you plan to allow in these
> strings?

"string literal expr."  (nothing starting with a number, but numbers
allowed in the middle, and of course no whitespace in the middle (the
you   d have two words)you know:

  (a)+ (d)* (a)+

  a :- [   A   ..   Z] | [   a   ..   z   ] |    _

in an ANTLR-like syntax (where ()+ denotes one or more, ()* denotes
zero or more, and [...] is a range, etc)
(I   m not sure whether this is 100% ANTLR or a mix with ebnf,
fortunately it was long ago I had to deal with a parser generator :) )


> > Can you write a parser for it?

Sure! :) And if I can, I   m even more sure that compilers    writers will
:)

> > Will anyone understand the code you write?

Yes, I   m sure they will, in the same way you did.

> > I,IMHO, don't like the argument that because you can already do
> > something in current language state, then is useless.
>
> I never made that argument.  What I said was that you can do it
> *better* with the current language state.  I still believe that.

Warning: I   m not saying you did, it was a general complain, I know you
did not.

BTW, I have to admit that the enum way didn   t come to my mind.
In such case, an infamous macro solution could be done:

enum to {To};
enum downto {DownTo};

#define TO ,To,
#define DOWNTO ,DownTo,

f(int start,to,int end);
f(int end,downto,int start);

But I   m sure you will agree with me how painfully awfull this is :)

  Daniel.

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





Author: tslettebo@chello.no.nospam (=?iso-8859-1?Q?Terje_Sletteb=F8?=)
Date: Tue, 17 Jun 2003 01:38:40 +0000 (UTC)
Raw View
<danielgutson@hotmail.com> wrote in message
news:23478c42.0306141855.14c51d1d@posting.google.com...
> >
> > What about:
> >
> >   void f(char const*); // (1)
> >   void f(char const* "AND" char const*);
> >
> > and a call:
> >   f("1" "AND" "2");  // Which function is called?
>
> Well, actually, I'm proposing that function call doesn't use the
> double quotes, so it would become
>    f("1" AND "2");

What would be the type of this function? Do you perhaps propose that the
compiler does an implementation-defined concatenation of the function
name and any "named parameter separators", e.g. like this
(decorated/mangled name):

f_AND(const char *, const char *)

If so, does it mean it has the same type as e.g.:

f("1" OR "2")


Regards,

Terje

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





Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Fri, 6 Jun 2003 23:10:29 +0000 (UTC)
Raw View
Hi there.

INTRO.
 Many was said about providing information or self documentation in
function calls and/or function declarations, such as named parameters,
etc.

What I   m proposing is to provide the ability of using string literals
as parameter separators, instead of the commas. (I   M NOT TALKING ABOUT
REMOVING COMMAS FROM THE LANGUAGE).
This would also permit overloading accepting the same types, but with
different separators.

For example:

void f( int start "TO" int end );
void f( int end "DOWNTO" int start);

and, when calling:

f(1 TO 10);      //first version invoked
f(4 DOWNTO 1);   //second version invoked
f(3,4) //error: not defined

Of course defining f with the comma would be allowed as the third
overloading.

COMPATIBILITY: 100%, breaks nothing existent.

What we get:
 - more readability
 - overloading with same    signature    (in terms of the parameter types)

Open issues:
 - I suggest no spaces allowed inside separators ("DOWN TO" not
allowed)
 - can a    pre    [optional?] separator be allowed? (for example,
prefixing a "FROM":
     void f("FROM" int start "TO" int end);

  - I also suggest that double quotes have to be used in the
prototype, but not in the function call


Comments submission open!  :)


   Daniel.

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





Author: dave@boost-consulting.com (David Abrahams)
Date: Sun, 8 Jun 2003 18:05:27 +0000 (UTC)
Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) writes:

> For example:
>
> void f( int start "TO" int end );
> void f( int end "DOWNTO" int start);
>
> and, when calling:
>
> f(1 TO 10);      //first version invoked
> f(4 DOWNTO 1);   //second version invoked
> f(3,4) //error: not defined
>
> Of course defining f with the comma would be allowed as the third
> overloading.
>
> COMPATIBILITY: 100%, breaks nothing existent.
>
> What we get:
>  - more readability
>  - overloading with same =B4signature=B4 (in terms of the parameter typ=
es)
>
> Open issues:
>  - I suggest no spaces allowed inside separators ("DOWN TO" not
> allowed)
>  - can a =B4pre=B4 [optional?] separator be allowed? (for example,
> prefixing a "FROM":
>      void f("FROM" int start "TO" int end);
>
>   - I also suggest that double quotes have to be used in the
> prototype, but not in the function call
>
>
> Comments submission open!  :)

Existing language features make a much cleaner implementation
possible:

    struct to {}
    struct downto {}

    void f (int start, to, int end);
    void f (int start, downto, int end);

I don't see any advantage to replacing those commas with double quote
characters in invocations.

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

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





Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Mon, 9 Jun 2003 02:04:35 +0000 (UTC)
Raw View
dave@boost-consulting.com (David Abrahams) wrote in message news:<uisrgtxoc.fsf@boost-consulting.com>...
> danielgutson@hotmail.com (danielgutson@hotmail.com) writes:
>
> > For example:
> >
> > void f( int start "TO" int end );
> > void f( int end "DOWNTO" int start);

> Existing language features make a much cleaner implementation
> possible:
>
>     struct to {}
>     struct downto {}
>
>     void f (int start, to, int end);
>     void f (int start, downto, int end);

Well, with some corrections (such as the () after each class, and we
are still using commas).
Another way people is doing this is:

struct TO
{
   explicit TO(int i) : value(i){}
   operator int() const { return value; }

   int value;
};

and so on.

But allways using additional classes/structures.

The thing is, Dave, that again we are focusing in the parameters.

The Pros and cons of using structures:
- additional code required
- namespace messing (there's no 'signature scope' boundary)
- additional characters (such as commas, parenthesis) are still
required, messing readability.

Simply, I think this can't compete with just adding the string literal
and just using it, without any additional code or per-function
structure creation basis.
Imagine a *medium/large* api (let's say, don't know, 40 apis), each
one requiring its own 'separators', how many additional structures
should we create and complicate the reader with a huge header file?

I think that

[decl]
     struct to {}
     struct downto {}

     void f (int start, to t, int end);
     void f (int start, downto d, int end);
[usage]
     f(1,to(),10);
     f(10,downto(),1);
[end]

is not as simply,readable and intuitive as

[decl]
    void f(int start "TO" int end);
    void f(int end "DOWNTO" int start);
[usage]
    f(1 TO 10);
    f(10 DOWNTO 1);
[end]

Another reason is that allowing the string literal in the signature
gives an idea of 'parsing' information to the reader.

And, finishing my comments, I hate messing the header files with
'helper' or additional no-central code because of lacking of language
support.
Yes, of course this can be done with actual C++, but also with
assembler! :)
I,IMHO, don't like the argument that because you can already do
something in current language state, then is useless. Templates would
be, for example! :)
Even C++ can be translated to C, so why create c++? (okokokok....I
went too far, don't want a useless discussion, sorry about that).

I donnow...I should study marketing :)

  Thanks anyway Dave!

Daniel.

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





Author: danielgutson@hotmail.com (danielgutson@hotmail.com)
Date: Mon, 9 Jun 2003 02:04:56 +0000 (UTC)
Raw View
A comment from the weekend...

  You don't know HOW I WOULD like to have two substr method of
std::string

    substr( size_type begin "TO" size_type end)

and

    substr( size_type begin "COUNTING" size_type count)


    :)

(they call it "follow-up", I call 'correct what a poor programmer did
by misunderstanding', then I would be able to enjoy my weekend :(   )


ps: don't remember the type name, size_type or whatever :)

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





Author: dave@boost-consulting.com (David Abrahams)
Date: Mon, 9 Jun 2003 13:10:45 +0000 (UTC)
Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) writes:

> dave@boost-consulting.com (David Abrahams) wrote in message news:<uisrgtxoc.fsf@boost-consulting.com>...
>> danielgutson@hotmail.com (danielgutson@hotmail.com) writes:
>>
>> > For example:
>> >
>> > void f( int start "TO" int end );
>> > void f( int end "DOWNTO" int start);
>
>> Existing language features make a much cleaner implementation
>> possible:
>>
>>     struct to {}
>>     struct downto {}
>>
>>     void f (int start, to, int end);
>>     void f (int start, downto, int end);
>
> Well, with some corrections (such as the () after each class, and we
> are still using commas).

OK, so use enums.

> Another way people is doing this is:
>
> struct TO
> {
>    explicit TO(int i) : value(i){}
>    operator int() const { return value; }
>
>    int value;
> };
>
> and so on.
>
> But allways using additional classes/structures.

enums are cheap.

> The thing is, Dave, that again we are focusing in the parameters.
>
> The Pros and cons of using structures:
> - additional code required

Not much.

> - namespace messing (there's no 'signature scope' boundary)

You say that like it's a good thing.

> - additional characters (such as commas, parenthesis) are still
> required, messing readability.

  , foo,

is no worse than

  "foo"

as far as I can see, and probably more expressive since the 2nd one
says "string", which it is not (semantically).

> Simply, I think this can't compete with just adding the string literal
> and just using it, without any additional code or per-function
> structure creation basis.
> Imagine a *medium/large* api (let's say, don't know, 40 apis), each
> one requiring its own 'separators', how many additional structures
> should we create and complicate the reader with a huge header file?

Well, I think any separators idea is aesthetically horrible, so I have
little sympathy for that scenario, but anyway...

> I think that
>
> [decl]
>      struct to {}
>      struct downto {}
>
>      void f (int start, to t, int end);
>      void f (int start, downto d, int end);
> [usage]
>      f(1,to(),10);
>      f(10,downto(),1);
> [end]
>
> is not as simply,readable and intuitive

Fine,

       enum to {TO};
       enum downto {DOWNTO};
  [decl]
       void f(int start, to, int end);
       void f(int start, downto, int end);
  [usage]
       f(1, TO, 10)
       f(1, DOWNTO, 10)

> as
>
> [decl]
>     void f(int start "TO" int end);
>     void f(int end "DOWNTO" int start);
> [usage]
>     f(1 TO 10);
>     f(10 DOWNTO 1);
> [end]

Oh, wait, now you want to be able to invoke it without the quotes in
the separator?  What characters do you plan to allow in these
strings?  Can you write a parser for it?  Will anyone understand the
code you write?

> Another reason is that allowing the string literal in the signature
> gives an idea of 'parsing' information to the reader.
>
> And, finishing my comments, I hate messing the header files with
> 'helper' or additional no-central code because of lacking of language
> support.
> Yes, of course this can be done with actual C++, but also with
> assembler! :)
> I,IMHO, don't like the argument that because you can already do
> something in current language state, then is useless.

I never made that argument.  What I said was that you can do it
*better* with the current language state.  I still believe that.

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

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





Author: pasa@lib.hu ("Balog Pal")
Date: Wed, 11 Jun 2003 18:04:15 +0000 (UTC)
Raw View
<danielgutson@hotmail.com> wrote in message
news:23478c42.0306081337.3e59b3e0@posting.google.com...

>   You don't know HOW I WOULD like to have two substr method of
> std::string
>
>     substr( size_type begin "TO" size_type end)
>
> and
>
>     substr( size_type begin "COUNTING" size_type count)
>
>     :)

And where is the benefit to have them az overload?  Why not use distinct
function names?

subrange( size_type begin, size_type end); // [) range
subrange_inclusive( size_type begin, size_type end); // [] range

chunk_at( size_type pos, size_type length);

[just a naive try, I guess people here could think up much better names. ;]

Paul


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





Author: google@vandevoorde.com (Daveed Vandevoorde)
Date: Wed, 11 Jun 2003 19:18:22 +0000 (UTC)
Raw View
danielgutson@hotmail.com (danielgutson@hotmail.com) wrote:
> Hi there.
>
> INTRO.
>  Many was said about providing information or self documentation in
> function calls and/or function declarations, such as named parameters,
> etc.
>
> What I   m proposing is to provide the ability of using string literals
> as parameter separators, instead of the commas. (I   M NOT TALKING ABOUT
> REMOVING COMMAS FROM THE LANGUAGE).
> This would also permit overloading accepting the same types, but with
> different separators.
>
> For example:
>
> void f( int start "TO" int end );
> void f( int end "DOWNTO" int start);
>
> and, when calling:
>
> f(1 TO 10);      //first version invoked
> f(4 DOWNTO 1);   //second version invoked
> f(3,4) //error: not defined
>
> Of course defining f with the comma would be allowed as the third
> overloading.
>
> COMPATIBILITY: 100%, breaks nothing existent.

What about:

  void f(char const*); // (1)
  void f(char const* "AND" char const*);

and a call:
  f("1" "AND" "2");  // Which function is called?

Note that with current C++, (1) is a perfectly viable
candidate.  To keep compatibility, you'll need an ugly
kink in your feature.  To avoid that kink, you break
compatibility for something that does not seem all that
compelling to me.

        Daveed

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





Author: philippe_mori@hotmail.com ("Philippe Mori")
Date: Wed, 11 Jun 2003 19:19:27 +0000 (UTC)
Raw View
>
> enums are cheap.
>
>
> Fine,
>
>        enum to {TO};
>        enum downto {DOWNTO};
>   [decl]
>        void f(int start, to, int end);
>        void f(int start, downto, int end);
>   [usage]
>        f(1, TO, 10)
>        f(1, DOWNTO, 10)
>

Nice solution.... Typically, in my case, I sometime do something like that:

enum dir { TO, DOWNTO };

void f(int start, int end, dir direction = TO) { ... }

and do explicit test in f(). In fact, in that case we won't even need
explicit test.
Just give the value of 1 to TO and -1 to DOWNTO and you can do something
like:

for (int cur = start; cur != end; cur += dir) { ... }

Also if you don't like the comma at call site, you can always do something
like:

enum to { TO_VALUE };
#define TO , TO_VALUE ,

and it will works as you want except for the declaration that you need to
write
only once per function anyway

Philippe

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