I've looked at it and i find the italian keyboard very wierd. It is underpopulated in some spots and overpopulated in the others. Bad design. It also doesn't have a backquote, which is even present on hebrew, russian, and all other fancy keyboars i've ever seen - and which is requiered by some programming languages as well, most notably lisp. And UNIX simply doesn't work without ~.

You can use a keyboard layout editor. Under Windows i use KLM Medium:

http://www.klm.freeservers.com/

However, it costs more than a US keyboard.

Another sane solution would be a program which would be a resident and listen to a magic key combination, and then pastes the symbol into the program. Or even a widows shortcut with a hotkey to call a small program which would only paste a symbol into an active program...

-eye



Roberto Mariottini wrote:

> Italian keyboard.
> For sure every one of the 56 millions of italians has to use the Alt-126
> combination to enter a single ~.
> We also have no {}, but the undocumented AltGr-Shift-[ and AltGr-Shift-]
> cobinations fortunately work in any italian keyboard Windows driver, although I
> see many of my collegues using Alt-123 and Alt-125.
> 
> Old italian hackers use USA keyboards, but not all employers agree to buy one
> for every developer.
> 
> Ciao
> 
> 

What is so evil about it?

What is more evil:

Pascal:   WriteLn("foo", ' ', bar);
C:  printf("%s%c%i\n","foo",' ',bar);
C++:  cout << "foo" << ' ' << bar << endl;
BASIC:  print "foo", " ", %bar, chr(13)

D proposal #1:  stdout("foo")(' ')(bar)(endl);
D proposal #2:  stdout ~ "foo" ~ ' ' ~ bar ~ endl;

Why would you think commas are so much better than tildes or parens?

I can see tilde being confused with the array concatenation operator.

Parens are not confusing at all, once you get used to the chained call style.

Commas are confusing too because of the comma operator that C,C++, and D all share.

Sean

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bocr93$2am6$2@digitaldaemon.com...
> More operating overloading gunk. Hate it hate it hate it. Once again the evil zombie iostreams are sent to plague us, just wearing another head
>
> Gilbert Grump

Why not implement it like this?:

void print(... args)
{
    foreach(v in args)
        v.print(stdout);
}

Every type then would be required to provide a print function to a stream. There could be several such functions (auto-generated if not explicitly provided, of course) that read and write to/from text or binary streams. The auto-generated functions would perhaps just call the base class function then print the new members.

Sean

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bodopv$lfe$1@digitaldaemon.com...
> Andy Friesen wrote:
> > Maybe D just needs some (completely insane) way to overload the comma operator and translate what looks like a single varargs method call into a series of monadic calls.  Maybe not.
>
> Maybe D only needs a way to pass a variable number of arguments in a type-safe way. That would solve all problems of printf, since printf could always find out what was actually passed to it.
>
> Since D objects are always passed by reference only this problem is actually a little easier to solve than in C++.
>
> Howsabout the following:
>
> void print(char[] formatstring, vararglist args );
>
> vararglist would be a special internal type that the compiler recognizes. Instead of just pushing all arguments onto the stack the compiler internally creates an array of structs of the following form (the implementation should probably be hidden from the programmer):
>
> struct vararg
> {
> int type; //type-info pointer??
> TYPE arg;
> };
>
> type could be a special value indicating whether it is a simple type (int, double, etc.) or an object reference. The class of the object would not have to be included, since objects in D already have runtime type information.
>
> The only problem I see with this are structs and pointers to structs. Does the compiler automatically generate some kind of typeinfo structure for each struct? If it does then vararg could simply include a pointer to that typeinfo and the called function could find out what kind of struct was passed.
>
> Another alternative, of course, would be to not allow structs to be passed to such a function.
>
> Anyway, provided that the struct problem is solved somehow then on the called side everything could be typesafe. A vararglist object could behave like some kind of iterator or cursor:
>
> void print(char[] formatstring, vararglist args)
> {
> while(args.next())
> {
> if(args.isInt())
> {
> int val=args.getInt(); //throws exception if
>                                    //not an int or compatible type
> }
> else if(args.isObject())
> {
> Object obj=args.getObject(); //throws an
>                                   //exception if not an object
> }
> ...
> }
> }
>
>
> Hauke

"Kazuhiro Inaba" <Kazuhiro_member@pathlink.com> wrote in message news:bodpsg$n5e$1@digitaldaemon.com...
> >Andy Friesen also had very close to this idea earlier. -Walter
> >
> >http://www.digitalmars.com/drn-bin/wwwnews?D/17402
>
> Or, C++ has type-safe 'format' library
> http://boost.org/libs/format/doc/format.html
> which
> cout << format("%|04| *%|=7|*\n") % 100 % "foo";
> prints "0100 *  foo  *" and linefeed.
> operator % is used here. (maybe % of "%d" or "%s"... is the origin)
>
> But i prefer Andy's operator~ approach.
> Since ~ already has the meaning "concatination", i think it's quite
natural.


Thanks for the boost link. The ~ certainly does look better. One of my problems with the format() function, though, is it creates and returns a string, which then gets output. This results in double-buffering, something I want to avoid (for efficiency reasons).

Why not make IO a more formal operation.

Introduce a new keyword "write"

Syntax: write object, param [,param]*;

Example:

float a = 12.4;
write stdOut,"Hello ",12,.format(4,2,a)," amount";

Any "." preceeded name is considers a function of
the object.

The object has opWrite functions.

class StdOut
{
opWrite(char[]) { }
opWrite(int) { }
opWrite(float) { }

format(int digits,int postDigits, float value);
}

Read is handled in a similar way.

Example:

read stdIn, a, b, c;

class StdIn
{
opRead(out char[]) { }
opRead(out int) {}
//etc...
}

Any function that returns itself should work like that, but how the heck would you specify the signature of a function that returns itself?!?

(int,int)(*)(int,int)(*)(int,int)(*)(int,int)(*)(int,int)(*)(int,int)
DrawTo(int x,int y) { Line(opx,opy,x,y); opx = x; opy = y; return DrawTo; }

It doesn't even seem that typedef will help here.

Sean

"Helmut Leitner" <helmut.leitner@wikiservice.at> wrote in message news:3FA9F16C.9DF16013@wikiservice.at...
>
>
> Walter wrote:
> > I can make all that work, so the question is do people like the ()() approach, or does it just stink? Andy suggests using ~ instead, that certainly has an appeal, but I'm a bit concerned though about sinking
into
> > the C++ << quagmire <G>.
>
> I dislike both, especially the ~.
>
> If you use the ()() syntax, then it must be a general language feature,
> that can be used for any function, e. g.
>
>    MoveTo(x1,y1);
>    DrawTo(x2,y1)(x2,y2)(x1,y2)(x1,y1);
>
> If it is that way, it may be ok. It won't hurt, if it isn't used with io
in the end.
> If it is only usable with opCall, then it is an ugly hack.
>
> On the other hand it doesn't solve the inefficiency problem of "C++ <<",
> effecitivly producing a flood of
>    func(this,fmt[,type])
> calls.
>
> And it is not searchable.
>
> And what is the advantage over:
>    stream.print(...)(...)(...);
> ?
>
> Even if you do this, these are still open problems
>   - to pass a variable number of arguments safely
>   - to get a generic interface to pass
>        - any arry                                             =>
ArrayInfoStruct
>        - any primitive (now "Type", should be "Prim[itive]")  =>
PrimInfoStruct
>        - any object, array or primitive                       =>
TypeInfoStruct
>
> It would be no good to fix the io problem without taking these into account.
>
> -- 
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

"Walter" <walter@digitalmars.com> wrote in message
news:boc9me$1g2b$1@digitaldaemon.com...
| ...
|     stdout("hello")(" world")(47).nl()("bar")("%06i\n", 62);
| ...

Personally, I don't like so many (). ~ feels a bit better. However, I agree that true typesafe varargs would be the ideal solution for this.

————————————————————————— Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.536 / Virus Database: 331 - Release Date: 2003-11-03

He he. That's as much counter-semantic operator overloading as I like to see.

Bravo!


"Dario" <Dario_member@pathlink.com> wrote in message news:bodm0g$he4$1@digitaldaemon.com...
> Something like this will work:

You lose atomicity of write.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:boe43g$16ri$1@digitaldaemon.com...
> Why not implement it like this?:
>
> void print(... args)
> {
>     foreach(v in args)
>         v.print(stdout);
> }
>
> Every type then would be required to provide a print function to a stream. There could be several such functions (auto-generated if not explicitly provided, of course) that read and write to/from text or binary streams. The auto-generated functions would perhaps just call the base class
function
> then print the new members.
>
> Sean
>
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bodopv$lfe$1@digitaldaemon.com...
> > Andy Friesen wrote:
> > > Maybe D just needs some (completely insane) way to overload the comma operator and translate what looks like a single varargs method call
into
> > > a series of monadic calls.  Maybe not.
> >
> > Maybe D only needs a way to pass a variable number of arguments in a type-safe way. That would solve all problems of printf, since printf could always find out what was actually passed to it.
> >
> > Since D objects are always passed by reference only this problem is actually a little easier to solve than in C++.
> >
> > Howsabout the following:
> >
> > void print(char[] formatstring, vararglist args );
> >
> > vararglist would be a special internal type that the compiler recognizes. Instead of just pushing all arguments onto the stack the compiler internally creates an array of structs of the following form (the implementation should probably be hidden from the programmer):
> >
> > struct vararg
> > {
> > int type; //type-info pointer??
> > TYPE arg;
> > };
> >
> > type could be a special value indicating whether it is a simple type (int, double, etc.) or an object reference. The class of the object would not have to be included, since objects in D already have runtime type information.
> >
> > The only problem I see with this are structs and pointers to structs. Does the compiler automatically generate some kind of typeinfo structure for each struct? If it does then vararg could simply include a pointer to that typeinfo and the called function could find out what kind of struct was passed.
> >
> > Another alternative, of course, would be to not allow structs to be passed to such a function.
> >
> > Anyway, provided that the struct problem is solved somehow then on the called side everything could be typesafe. A vararglist object could behave like some kind of iterator or cursor:
> >
> > void print(char[] formatstring, vararglist args)
> > {
> > while(args.next())
> > {
> > if(args.isInt())
> > {
> > int val=args.getInt(); //throws exception if
> >                                    //not an int or compatible type
> > }
> > else if(args.isObject())
> > {
> > Object obj=args.getObject(); //throws an
> >                                   //exception if not an object
> > }
> > ...
> > }
> > }
> >
> >
> > Hauke
>
>

> This got me thinking about message chaining in Object C and SmallTalk (or
> message cascading...)
> Maybe a whole new syntax could help and possibly replace printf and ~.
> Something like
>
>   stdout.printf["hello", " world", 47, "\nbar", ("%06i\n", 62)];
>   string.cat["a", "bc", 47, "def"];
>
> would turn into
>
>   stdout.printf("hello").printf("
> world").printf(47).printf("\nbar").printf("%06i\n", 62);
>   string.cat("a").cat("bc").cat(47).cat("def");
>
> I haven't thought about if this syntax conflicts with anything else or is
> implementable ;-)
> -Ben

I think the point of the concatenated (not concatenating, mind you) syntax
is that the write operation would be atomic, which would certainly need to
be the case to system streams such as the log stream, and to process-wide
streams in
a multi-threaded process.

If your example translates to a function that does that, by concatenating all input in a buffer, and then sending that to the requisite output stream in a single operation, then I would think it worth pursuing.