Re: Just a bit of silliness

"Bartc" <bartc@xxxxxxxxxx> writes:
[...]
There seems to be a preoccuption with the concept of format strings,
probably because they seem a prerequisite for printing numeric values in C.

Larry Gates' original comment was to do with simply printing a list of
values. The %? idea was a way of achieving this within the framework of
the -printf() functions. But format strings could be eliminated completely:

print(x,i,c);

So that the problem of compiletime/runtime strings doesn't come into it.

(One problem with print() would be controlling the separaters between
values, but this is straightforward:

print(x," ",i," ",c); And in complex cases, or for specific width control,
printf() can always be used.)

After all, there is puts(s) which is a neat way of writing printf("%s\n",s);

And a println() version would also eliminate writing all those fiddly \n's
at the end of format strings:

println (a,b); equivalent to: print (a,b,"\n");

(Implementing a function such as print() I think would require compiler
support to turn it into an equivalent printf call. I'm not sure it's
achievable with macros + "%?" support)

This would require a great deal of compiler support, and as you say it
wouldn't handle anything other than the default format for each type.
Currently C has two kinds of functions: ordinary functions whose
parameter lists are declared explicitly, and variadic functions where
some of the parameters are unspecified but must be determined at run
time through other information passed to the function. These print
and println functions would be a third kind of function, where the
number and types of the arguments can be different for each call, but
the function is able to determine this without any extra information
begin explicitly passed in.

One way to implement this might be by having the compiler (which knows
the actual argument types) generate and pass an implicit extra
parameter, which the implementation of print() could then access.
This might be done with a set of functions/macros in a new header,
something similar to <stdarg.h> but depending on this extra implicit
parameter rather than on the parameter(s) preceding the ", ...". This
would have the advantage that user code could use the same mechanism.
Since C doesn't have runtime type information, you'd probably have to
limit the arguments to a small finite set of types; it's difficult to
see how you could pass a "struct foo" to a function that isn't already
expecting one.

Other languages have taken various other approaches to this. Pascal
(at least the dialects I've used) lets you do something like
writeln('x = ', x);
but writeln isn't an ordinary function, and user code can't use the
same mechanism. The compiler would break this call down into three
calls to three different functions.

Ada doesn't bundle arguments together into a single call; instead, it
has a variety of "Put" functions:
Put("x = "); Put(x); New_Line;
This depends on function overloading. The name "Put" was chosen for
its brevity.

C++ does something similer, but using an overloaded "<<" operator:
cout << "x = " << x << '\n';

Perl has a "print" statement that can take multiple arguments of
various types, but even for ordinary functions, arguments are passed
as a list of arbitrary elements; the machinery needed to handle
something like
print("x = ", $x, "\n");
is already in the language. BTW, this would probably be written as:
print "x = $x\n";

Most of these approaches would be impractical or impossible in C,
unless you're willing to add features that many would consider to be
far too un-C-like. (Perl's variable interpolation in string literals,
optional parentheses, and combining of integers, floating-point
values, strings, and references into "scalars" are *very* un-C-like.)

Another possibility is that code could be generated that makes the
actual type information visible to printf at execution time; then "%?"
would work with format strings that aren't known at compile time.

That is a good idea too, but requiring a lot of extra cooperation from
the -printf functions.

For the record, it wasn't actually intended to be a good idea (i.e.,
I'm not advocating this).

--
Keith Thompson (The_Other_Keith) kst@xxxxxxx <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: Sacla loop: a new loop implementation
    ... the compiler is able to deduce enough about the type of thing ... That requires only that type information is *sometimes* ... > necessary information for the macro to expand. ... "statically typed language". ...
    (comp.lang.lisp)
  • Re: More static type fun.
    ... > perception of how common runtime type errors are. ... to invest in unit tests to catch bugs and gotchas in my program would ... and about placating the compiler. ... > to explicitly tell the compiler that you want to use lists with more ...
    (comp.lang.lisp)
  • Aurora Beta 1
    ... The Aurora compiler has just been updated to Beta 1. ... non-indexed triangle lists. ... The ClassView pane in the IDE now does something. ...
    (comp.lang.misc)
  • Re: Symbols, metacircular evaluation, external representation.
    ... You could only use strings, and you would have to use parsers all the time. ... same kind of symbolic expressions, it's very easy to write functions ... writting a metacircular interpreter (or a lisp compiler), ... lists. ...
    (comp.lang.scheme)
  • Re: foreach enhancement
    ... > strong typing is not an option, and that optimization will not be able to ... > concerned with optimization of for loops and typing - since lists will be ... *very* different and the compiler itself will certainly be able to know the ...
    (microsoft.public.dotnet.languages.csharp)