With operator overloading fully implemented, is there anyway to overload
an -> operator for printf and <- operator for scanf to automatically resolve
conversion (format) specifies based on datatype?

For example:

char[] printSomething = "some arbitrary string";
int scanSomething;
printf("->", printSomething);
scanf("<-", &scanSomething);

This would automatically resolve -> to %.*s and <- to %d. Of course, one would still be able to explicitly specify conversion specifies when necessary.

Just a thought!
Andrew

In article <bc3eia$1mq8$1@digitaldaemon.com>, Andrew Edwards says...
>
>With operator overloading fully implemented, is there anyway to overload
>an -> operator for printf and <- operator for scanf to automatically resolve
>conversion (format) specifies based on datatype?
>
>For example:
>
>char[] printSomething = "some arbitrary string";
>int scanSomething;
>printf("->", printSomething);
>scanf("<-", &scanSomething);
>
>This would automatically resolve -> to %.*s and <- to %d. Of course, one would still be able to explicitly specify conversion specifies when necessary.
>
>Just a thought!
>Andrew


First, this isn't operator overloading, at least if used as in the above example. Second, I think this could be implemented in the library instead of being part of the language. (I think the intent here was to get something like C++ << and >>.)

Then the above could be written more conveniently as:

char[] printSomething = "some arbitrary string";
int scanSomething;

aprintf(printSomething);
ascanf(&scanSomething);

The new library functions aprintf and ascanf could then look at the given parameters and scan or print accordingly. Naturally, they'd throw the relevant exceptions. And both should take an arbitrary number of parameters.

I think your idea is really handy!

Georg Wrede wrote:
> First, this isn't operator overloading, at least if used as in the
> above example. Second, I think this could be implemented in the
> library instead of being part of the language. (I think the intent
> here was to get something like C++ << and >>.)

One thing comes to my mind: if stream libraries are implemented through operator overloading, concatenation operator should  be considered. I'm being led to this by Sather where you write:

#OUT + something_to_output;

This means "Create an object of type OUT and execute operator add on it with something_to_output". The result would also be OUT, so you can keep concatenating further. As you can see, this is one of the cases which can be improved by the separate concatenation operator. The input stream works the same way.

-i.

In article <bc5c29$cn4$1@digitaldaemon.com>, Ilya Minkov says...
>
>Georg Wrede wrote:
>> First, this isn't operator overloading, at least if used as in the above example. Second, I think this could be implemented in the library instead of being part of the language. (I think the intent here was to get something like C++ << and >>.)
>
>One thing comes to my mind: if stream libraries are implemented through operator overloading, concatenation operator should  be considered. I'm being led to this by Sather where you write:
>
>#OUT + something_to_output;
>
>This means "Create an object of type OUT and execute operator add on it with something_to_output". The result would also be OUT, so you can keep concatenating further. As you can see, this is one of the cases which can be improved by the separate concatenation operator. The input stream works the same way.

And with several items at a time would it be the following?

OutStream + TheString + BrownString + FoxString;

Similarly one could write

InStream + TheString + BrownString + FoxString;

This looks simple enough. But this relies on the programmer using descriptive names. Consider:

SerialPortStream + TheString + BrownString + FoxString;

Does this mean input or output? The computer knows, because this stream is opened as input or output, but how about the programmer?

Of course << and >> would be handy, people are either used to using them or at least have seen them already. But then maybe Walter has had a specific reason for not introducing them yet?

Also, with the input stream, I at least don't visualize reading as concatenating. Rather as splitting. So + would not be appropriate there.

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bc4goq$2k4i$1@digitaldaemon.com...

> First, this isn't operator overloading, at least if used as in the above example. Second, I think this could be implemented in the library instead of being part of the language. (I think the intent here was to get something like C++ << and >>.)

That is the general idea; however, I thought this could be accomplished by modifying or providing a modified version of the printf/scanf functions in the stream library. Forgive me if I use the incorrect terms for particular programming concepts. I would, however, appreciate a small explanation of exactly what this is called so that I can recognize what I'm looking at in the future.

> Then the above could be written more conveniently as:
>
> char[] printSomething = "some arbitrary string";
> int scanSomething;
>
> aprintf(printSomething);
> ascanf(&scanSomething);
>
> The new library functions aprintf and ascanf could then look at the given parameters and scan or print accordingly. Naturally, they'd throw the relevant exceptions. And both should take an arbitrary number of parameters.

I rather like the printf/scanf way for doing I/O processing, which calls for a string with optional embedded conversion specifiers and associated variables as its parameters. I do however believe I/O can be handled differently. My idea is to have four distinct functions: scan, print, open, and close. Both scan and print would be bounded to the keyboard and monitor respectively.  Additionally, two auxiliary functions (read, write) would be defined and activated based on the current state of open( ).  The @ would resolve to the appropriate conversion specifier both print( ) and write ( ). I do agree with your thoughts on the scan function, but do not believe it necessary to explicitly specify the &. Afterall, everytime I've ever used the scanf( ) function, I've intended for the scanned value(s) to be stored in the identified variable(s). Exception handling, and parameters implemented as you've described above.

For example:

// standard input/output
print("What is your name? ");
scan(name); // scan( ) determines desired input based on parameter type.
print("How the hell are you @? Welcome to D programming.\n", name);

// file input/output
open( infile; outfile );
    read(name); // OK. read( ) determines desired input based on parameter
type.
    write("How the hell are ya @?", name); // OK
open( infile; );
    write("How the hell are ya @?", name); // illegal operation, outfile not
defined.
open( ; outfile );
    read(name); // illegal operation, infile not defined.
close( infile; );
    read(name); // illegal operation, infile not defined.
    write("Something to write"); // OK
close( ; outfile );
    read(name); // OK
    write("Something to write"); // illegal operation, outfile not defined.
close( );
    read(name); // illegal operation, infile not defined.
    write("Something to write"); // illegal operation, outfile not defined.


>
> I think your idea is really handy!
>
>

> "Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bc4goq$2k4i$1@digitaldaemon.com...
> 
> > First, this isn't operator overloading, at least if used as in the above example. Second, I think this could be implemented in the library instead of being part of the language. (I think the intent here was to get something like C++ << and >>.)
> 
> 
> That is the general idea; however, I thought this could be accomplished by modifying or providing a modified version of the printf/scanf functions in the stream library. Forgive me if I use the incorrect terms for particular programming concepts. I would, however, appreciate a small explanation of exactly what this is called so that I can recognize what I'm looking at in the future.

Operator overloading means you can define an operator (+,= and others
are operators) to have meaning in new contexts. If a,b and c are
integers then everybody knows what "c=a+b" means. If they are strings
then most of us assume "c=a+b" could mean concatenation. For example
c="Mary"+"Belle" gives "MaryBelle" in c. But what if you have a type
called RomanString? Would + mean concatenation or something else?
If you write "c=a+b" when a is "vi" and b is "mix", should c become
"vimix"? No, it should become "mxv". Likewise "vii"+"xv" should
become "xxii", as the Romans think.  The act of defining + to
work like this is called Operator Overloading.

> differently. My idea is to have four distinct functions: scan, print, open,
> and close. Both scan and print would be bounded to the keyboard and monitor
> respectively.  Additionally, two auxiliary functions (read, write) would be
> defined and activated based on the current state of open( ).  The @ would
> resolve to the appropriate conversion specifier both print( ) and write ( ).
> I do agree with your thoughts on the scan function, but do not believe it
> necessary to explicitly specify the &. Afterall, everytime I've ever used
> the scanf( ) function, I've intended for the scanned value(s) to be stored
> in the identified variable(s). Exception handling, and parameters
> implemented as you've described above.
> 
> For example:

So essentially you want what Pascal has?

writeln('Hello, ',name);
write('Give your age: ');
readln(age);
writeln('Age of ',name, ' is ', age);

Where the defaults for read and write are stdin and stdout (the keyboard and the screen, respectively) until altered with

AssignFile(Input, sourceName);
Reset(Input);
AssignFile(Output, destName);
Rewrite(Output);

But this has a problem because there are many number formats. And you might want to read text fields of certain lengths. Then just using scanf would be easier. BTW, scanf does read from stdin (the keyboard), while fscanf reads from a specified input stream (which can be a file), and sscanf reads from a string in memory. The same with printf, fprintf and sprintf.

Georg Wrede wrote:
> Operator overloading means you can define an operator (+,= and others
> are operators) to have meaning in new contexts. If a,b and c are integers then everybody knows what "c=a+b" means. If they are strings
> then most of us assume "c=a+b" could mean concatenation. 

That's why we have conceatenation operator: "a ~ b" means concatenattion only. This is especially important with arrays and other extensible agregates, since "a + b" would rather mean a memberwise addition.

-i.

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:bc7109$1s64$1@digitaldaemon.com...

> Operator overloading means <snip>

Much appreciated.


> So essentially you want what Pascal has?

I have no idea what Pascal have, however, if they do have what I've explained earlier, then my answer is yes!

> Where the defaults for read and write are stdin and stdout (the keyboard and the screen, respectively) until altered with

Please note that I'm not trying to manipulate I/O by redirecting where
scan( ) gathers its information from or print( ) outputs its information to.
IMO read and write( ) will always point to a file or stream which is
determined by the current state some object open.

> But this has a problem because there are many number formats.

Why? There are already conversion specifiers defined to handle those numbers. All you would need to do is define @ to decern which to use based on the parameters provided.

> And you might want to read text fields of certain lengths.

char[10] letters;
int number;
char[] word;

// implicit
for ( int i = 0; i < 10; i++ )
{
    scan(letters[i] );  //  @ == %c
    print("Letter scanned: @\n", letters[i] ); // @ == %c
}

scan(number); // @ == %d
print("Number scanned: @", number); // @ == %d

scan(word); //  @ == %.*s
print("Word scanned: @", word); // @ == %.*s

// explicit
scan("%.*s,%d,%c", word, number, letters[5]); // works just as well...

I do not know if this is possible, however, assuming that it is, I do not see where the problem lies.

Andrew

Andrew Edwards wrote:
> "Georg Wrede" <Georg_member@pathlink.com> wrote in message
> news:bc7109$1s64$1@digitaldaemon.com...
> 
> 
>>Operator overloading means <snip>
> 
> 
> Much appreciated.
> 
> 
> 
>>So essentially you want what Pascal has?
> 
> 
> I have no idea what Pascal have, however, if they do have what I've
> explained earlier, then my answer is yes!
> 
> 
>>Where the defaults for read and write are stdin and stdout (the
>>keyboard and the screen, respectively) until altered with
> 
> 
> Please note that I'm not trying to manipulate I/O by redirecting where
> scan( ) gathers its information from or print( ) outputs its information to.
> IMO read and write( ) will always point to a file or stream which is
> determined by the current state some object open.
> 
> 
>>But this has a problem because there are many number formats.
> 
> 
> Why? There are already conversion specifiers defined to handle those
> numbers. All you would need to do is define @ to decern which to use based
> on the parameters provided.
> 
> 
>>And you might want to read text fields of certain lengths.
> 
> 
> char[10] letters;
> int number;
> char[] word;
> 
> // implicit
> for ( int i = 0; i < 10; i++ )
> {
>     scan(letters[i] );  //  @ == %c
>     print("Letter scanned: @\n", letters[i] ); // @ == %c
> }
> 
> scan(number); // @ == %d
> print("Number scanned: @", number); // @ == %d
> 
> scan(word); //  @ == %.*s
> print("Word scanned: @", word); // @ == %.*s
> 
> // explicit
> scan("%.*s,%d,%c", word, number, letters[5]); // works just as well...
> 
> I do not know if this is possible, however, assuming that it is, I do not
> see where the problem lies.

With the way varargs work right now, it's not.  No type information is kept at all, in fact, which is why printf has all those wacky symbols; there's no other way to guess the type.

Awhile ago, I took a cue from boost::format, and wrote a Formatter class in D.  It has its issues too, but it almost does what you want:

print(new Formatter("Word scanned: {0}") % word % Formatter.end);

(the Formatter.end bit is just a hack to convert the Formatter object to a string, since D doesn't provide any way to perform an implicit conversion)

Doing this sort of thing with operator overloading is the only way I can see to get the desired effect, though it suffers the problem of assigning an arbitrary meaning to the % operator. (I guess it depends on whether or not you like using >> and << for C++ streams)

> With the way varargs work right now, it's not.  No type information is kept at all, in fact, which is why printf has all those wacky symbols; there's no other way to guess the type.

My question to this is: If there's no way determine the type of a particular variable, how does the compiler know when you incorrectly assign a int to a bit or how to silently promote an int to a double? It would seem to me the only way to determine this is to know exactly what an int, bit, double, or any particular data type look like.

> Doing this sort of thing with operator overloading is the only way I can see to get the desired effect, though it suffers the problem of assigning an arbitrary meaning to the % operator. (I guess it depends on whether or not you like using >> and << for C++ streams)

I don't too much care for C++.  I'm learning it right know simply because there are no books or tutorials available for D.  I attempted to start one, but I'm not knowledgeable enough in the programming department to accomplish this on my own.  Additionally, there are not allot of people here with the time to dedicate to such a trivial project in such an early stage of D's development.  I even thought of plagiarizing the cpptutorial at cplusplus.com but I'm not interested in being sued by anyone so I stopped. I'm now learning C++ so that I can have a foundation on which to build a solid understanding of programming in D.