Congratulations.

First, the site is well laid out and thoughtful.  Very nice.

Second, the language specs are terrific.  If emulation is the highest form of compliment, then I paid it to you yesterday.  I went to lunch with a friend of mine and we laid out our needs in a language, that turned out very similar to D in many ways.

I am not sure what words to use to search for the following topics.  If I am rehashing an old discusstion, please direct me to it, and accept my apologies for the noise.

Naming conventions: Do not allow "_" (single underscore) to begin any identifier.  Instead, require it ("_") to bein every keyword.  If a token begins with "_", it is either a keyword, or wrong.  This makes using powerful tools like "grep" much easier.  It  also tends to reduce newbie errors.  There will be a lot of them with a new language.

Changing control structures.  Use:
{ _if ( true ) a = b; } instead of   if ( true ) a = b; or if ( true ) { a = b ;
}
{ _else c = d; } instead of  else c = d; or else { c = d; }
{ _elseif ( true ) e = f; }
for  _else and _elseif blocks, each must immediately follow their contrasted _if
or _elseif block.
This syntax is unamgiguous to the developers who must read it.  Also, this is
simpler to parse.  These three keywords must be the first token in the block or
they are wrong.

{ _switch ( myInteger ) ... }       instead of     switch ( myinteger )  { ...
}
{ _case ( myCase ) ... }      instead of    case ( myCase) : {  ... }
{ _case ( myCase, myOtherCase, myLastCase ) ... }  instead of   case
(myCase):case(myOtherCase):case(myLastCase): { ... }
{ _default ... } instead of default: { ... }
{ _defaultcase ( my Case, myOtherCase ) ... }  instead of
case(myCase):case(myOtherCase):default: {... }
There is no case-to-case fallthrough here, not ever.  I find "case" fallthrough,
controlled with breaks to be wordy and dangerous. My admittedly anecdotal
experience is that almost all of the blocks of code that I see following case
statements are terminated with break statements.  Every time I have seen a
"fallthrough", ie without a break statement, it has been inadequately commented
or documented.  Again, keywords _switch,  _case, _default, and _defaultcase are
first token in the block, or they are wrong.

{ _do ( int i, i =1 ; i < imax ; i++ ;  a[i] < amax )  ... }  instead of   for (
.... ) , while (....), or do ... while(...);.
Note the additional post-body predicate test statement inside the parenthesis.
The following are all allowed ( with syntax exactly like C in the use of "," and
";":
{ _do (  )  ...  }, -- nothing between parenthesis.  This loop runs until it
executes a break.
{ _do ( int i, i = 0  ) ... }, -- initialize.  This loop runs a long time as
well.
{ _do ( int i, i = 0; i < imax ) ... }  -- initialize and test.  Still no
autoincrement.
{ _do ( int i, i = 0; i < imax ; i++) ... }  This should look familiar.
{ _do ( int i, i = 0;; i++; i < imax ) ... }  use a post-body predicate instead
of a pre-body predicate.  Didn't you ever want to use the construction:
for ( i = 0;;i++) { ... } while ( a[i] < amax ) ;
The above sytax has that meaning.
In other words, each of the statements inside the parenthesis are optional.  If
following parenthesis statements are not present, the statement terminator, ";",
may be left out as well.
Here is how to code a while( i < imax ){ ....} .
{ _do (; i< imax ) ... }
Here is how to code a do{ ...} while ( ... );
{ _do ( ;;; a[i] < amax ) ... }
I am not blind to the fact that the do ... while alternative superficially
violates the "no empty statements" rule.

Formatting: add a type's format specification to the general information about
the type.  For new types, use the base type as the default, but also allow it to
be specified.
e.g.  typedef string [ 20 ] knrtext ( %20.20lc );  (meaning: new type "name",
default formatting, use 20 char field, blank padded to 20 characters, left
justified.
Used like this:
knrtext  HeWo;
HeWo = "Hello World"
_printf( "\n >>>%D<<< \nThis is a sample of default formatting for D \n", HeWo
);
giving this result:
>>>Hello World         <<<
This is a sample of default formatting for D
Sorry.  I couldn't resist.  My apologies to Messrs. Kernigan and Ritchie, and C
programmers everywhere.

Add a default format for structures as well, so that the following does not produce parseable garbage, but a powerful and easily evaluated output: _debug _printf ( "\n %D\n", dataStruct );

Add format-time loop control, like so:
_printf ( "\n %(20 5.2d) ", a(i)(i = 0;i<20;i++;a(i) < amax )   );   /* prints a
row of twenty numbers */
This does not look right, somehow, although it gets the point across.

As usual for me, compliments, constructive criticisms, and nasty comments will all be warmly received.

Andy Walker
jawalker@stl.quik.com
copyright @ 2002 by J. Andrew Walker

I think?? the "_" (underscore) issue has been already discussed and discarded by Walter himself (using it for a slightly differn't topic). Apart from looking bad, the needless reduntancy and the extra two handed typing need for the "_", Walter wanted to make D easy to learn and convert from c and c++ and using "_" for every keyword works against this.   We don't put an underscore in front of every noun (although we capital some of them).

Infact, the "_" almost put me of reading all of your other comments but see below...

Sorry to be so tough but, many of the changes you suggest make are unnessary and make it harder for C/C++ programmers transition.


"Andy Walker" <Andy_member@pathlink.com> wrote in message news:acpm3g$2g2q$1@digitaldaemon.com...
> Congratulations.
>
> First, the site is well laid out and thoughtful.  Very nice.
>
> Second, the language specs are terrific.  If emulation is the highest form
of
> compliment, then I paid it to you yesterday.  I went to lunch with a
friend of
> mine and we laid out our needs in a language, that turned out very similar
to D
> in many ways.
>
> I am not sure what words to use to search for the following topics.  If I
am
> rehashing an old discusstion, please direct me to it, and accept my
apologies
> for the noise.
>
> Naming conventions: Do not allow "_" (single underscore) to begin any
> identifier.  Instead, require it ("_") to bein every keyword.  If a token
begins
> with "_", it is either a keyword, or wrong.  This makes using powerful
tools
> like "grep" much easier.  It  also tends to reduce newbie errors.  There
will be
> a lot of them with a new language.

I would like my  "if-else" commands in differen't colours from my "class" keyword in my IDE anyway.

> Changing control structures.  Use:
> { _if ( true ) a = b; } instead of   if ( true ) a = b; or if ( true ) { a
= b ;
> }
> { _else c = d; } instead of  else c = d; or else { c = d; }
> { _elseif ( true ) e = f; }
> for  _else and _elseif blocks, each must immediately follow their
contrasted _if
> or _elseif block.
> This syntax is unamgiguous to the developers who must read it.  Also, this
is
> simpler to parse.  These three keywords must be the first token in the
block or
> they are wrong.
> { _switch ( myInteger ) ... }       instead of     switch ( myinteger )
{ ...
> }
> { _case ( myCase ) ... }      instead of    case ( myCase) : {  ... }
> { _case ( myCase, myOtherCase, myLastCase ) ... }  instead of   case
> (myCase):case(myOtherCase):case(myLastCase): { ... }
> { _default ... } instead of default: { ... }
> { _defaultcase ( my Case, myOtherCase ) ... }  instead of
> case(myCase):case(myOtherCase):default: {... }
> There is no case-to-case fallthrough here, not ever.  I find "case"
fallthrough,
> controlled with breaks to be wordy and dangerous. My admittedly anecdotal experience is that almost all of the blocks of code that I see following
case
> statements are terminated with break statements.  Every time I have seen a "fallthrough", ie without a break statement, it has been inadequately
commented
> or documented.  Again, keywords _switch,  _case, _default, and
_defaultcase are
> first token in the block, or they are wrong.

That would require even more typing, I doubt the bracket supporters would go
for this one.
I would like a way to stop case fall though (ie using anothor name other
then switch - "switchbreak") , but this does not do it for me.

>
> { _do ( int i, i =1 ; i < imax ; i++ ;  a[i] < amax )  ... }  instead of
for (
> .... ) , while (....), or do ... while(...);.
> Note the additional post-body predicate test statement inside the
parenthesis.
> The following are all allowed ( with syntax exactly like C in the use of
"," and
> ";":
> { _do (  )  ...  }, -- nothing between parenthesis.  This loop runs until
it
> executes a break.
> { _do ( int i, i = 0  ) ... }, -- initialize.  This loop runs a long time
as
> well.
> { _do ( int i, i = 0; i < imax ) ... }  -- initialize and test.  Still no
> autoincrement.
> { _do ( int i, i = 0; i < imax ; i++) ... }  This should look familiar.
> { _do ( int i, i = 0;; i++; i < imax ) ... }  use a post-body predicate
instead
> of a pre-body predicate.  Didn't you ever want to use the construction:
> for ( i = 0;;i++) { ... } while ( a[i] < amax ) ;
> The above sytax has that meaning.
> In other words, each of the statements inside the parenthesis are
optional.  If
> following parenthesis statements are not present, the statement
terminator, ";",
> may be left out as well.
> Here is how to code a while( i < imax ){ ....} .
> { _do (; i< imax ) ... }
> Here is how to code a do{ ...} while ( ... );
> { _do ( ;;; a[i] < amax ) ... }
> I am not blind to the fact that the do ... while alternative superficially
> violates the "no empty statements" rule.

I would like the last ";" to be optional in "for" statements and the step incrementation to default to "++" off the variable declared in the first part of the for.

ie
for (int n; n<total)
instead of,
for (int n; n<total; n++)

I dissagree with the use of it in "do" statments, as you have presented.

> Formatting: add a type's format specification to the general information
about
> the type.  For new types, use the base type as the default, but also allow
it to
> be specified.
> e.g.  typedef string [ 20 ] knrtext ( %20.20lc );  (meaning: new type
"name",
> default formatting, use 20 char field, blank padded to 20 characters, left
> justified.
> Used like this:
> knrtext  HeWo;
> HeWo = "Hello World"
> _printf( "\n >>>%D<<< \nThis is a sample of default formatting for D \n",
HeWo
> );
> giving this result:
> >>>Hello World         <<<
> This is a sample of default formatting for D
> Sorry.  I couldn't resist.  My apologies to Messrs. Kernigan and Ritchie,
and C
> programmers everywhere.

It's an ok (I'd give a 1%) idea, but there are alternatives, and personally I don't like the look of it.  There otherways to do this type of formatting exist already. Why not have that format in the printf instead, infact It's already possible with printf. One advantage of the code above is resuse, but if your a smart C programmer, I'd make little dif to your D program.

> Add a default format for structures as well, so that the following does
not
> produce parseable garbage, but a powerful and easily evaluated output: _debug _printf ( "\n %D\n", dataStruct );
>
> Add format-time loop control, like so:
> _printf ( "\n %(20 5.2d) ", a(i)(i = 0;i<20;i++;a(i) < amax )   );   /*
prints a
> row of twenty numbers */
> This does not look right, somehow, although it gets the point across.
>

The idea is cool, but syntax is not.
More like
_printf ( "\n %(20 5.2d) ", for(i = 0;i<20;i++) return a(i) );


 I'd like to be able to write function on the fly like java allows. Of couse
this reduces code reusablily and I'd only want to uses it for small bits of
code.
printf ( "\n %d ",  int (a) {return for(i = 0;i<20;i++)a++}} ); //Note,
would have differn't output from the above code.

or

printf ( "\n %d ",  int get(a) {return for(i = 0;i<20;i++)a++}} );

> As usual for me, compliments, constructive criticisms, and nasty comments
will
> all be warmly received.

OK

> Andy Walker
> jawalker@stl.quik.com
> copyright @ 2002 by J. Andrew Walker

In article <acstdh$2jj3$1@digitaldaemon.com>, anderson says...
>
>I think?? the "_" (underscore) issue has been already discussed and
>discarded by Walter
<snip>

Ok.  Discussion over as far as I am concerned.

<snip>

>
>Sorry to be so tough but, many of the changes you suggest make are unnessary and make it harder for C/C++ programmers transition.
>

As you can tell from my previous posts, I have worked with a LOT of languages. These days, the most common background is C, not FORTRAN or BASIC.  A terrific idea from a compilation point of view is worthless if the vast majority of programmers will  not use the language because of it.

BTW, I do not consider your comments "tough" at all.  None of them insult my intelligence.  You just have a different point of view.  I am still, at heart, a FORTRAN programmer, and do not see with the eyes of a native "C" developer.  ( Every two months or so I code a for loop like so:  for ( i =0, i < 20, i++ ) ... Note the commas, not semicolons. :-P   )

<snip>
>
>I would like my  "if-else" commands in differen't colours from my "class" keyword in my IDE anyway.
>

I like multi color editors.  Very helpful.

<snip proposed MAJOR bracket syntax changes >

>
>That would require even more typing, I doubt the bracket supporters would go
>for this one.
>I would like a way to stop case fall though (ie using anothor name other
>then switch - "switchbreak") , but this does not do it for me.
>

I think I code "C" the way Pavel codes it, with lots of brackets:
if ( a == b)
{
c = f(z);
}
else
{
c = f(z+1);
}
I wholeheartedly agree, not pretty.  But at 2:30 AM, even when stupid for lack
of sleep, I can match brackets.  I also never worry about whether I need to add
brackets if I add a line.  I find I do not have time to worry about that.  Bugs
consume me.

This is what I get with my alternative:
{if ( a==b)
c = f(z);
}
{else
c = f(z+1);
}

Applied to a switch-case construction:
{switch ( tokenchar [0] )
{case ( '_' )
processKeyword ( tokenchar );
}
{case ( 'a',
'b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z')
processIdentifier (  tokenchar );
}
{default
throw invalidSyntaxFlag;
}
}
( I am not rehashing Keyword-leading underscores.  This was just the first
example I could find )

<snip proposed do-loop alternatives >
>
>I would like the last ";" to be optional in "for" statements and the step incrementation to default to "++" off the variable declared in the first part of the for.
>
>ie
>for (int n; n<total)
>instead of,
>for (int n; n<total; n++)
>
>I dissagree with the use of it in "do" statments, as you have presented.
>

Whether "do" or "for" makes no difference to me.  To me, the multiple loop types are redundant.  Having to find the post-condition "while" at the end of a block makes me lose my train of thought while trying to understand a block of code.  I have noticed that it distracts native "C" programmers as well.

I am not partial to the implied auto increment.  I have coded with the following style, and generally find it makes things very clear for other developers.

E.g. processing two arrays, whose indexes are not similar:

for (     i  = 0,         j = 37    ;
i < imax                  ;
i++,            j += 13  )
{
new_a[ i ] = structArray[ j ].old_a ;
}

>> Formatting: add a type's format specification to the general information
>about
>> the type.  For new types, use the base type as the default, but also allow
>it to
>> be specified.
>> e.g.  typedef string [ 20 ] knrtext ( %20.20lc );  (meaning: new type
>"name",
>> default formatting, use 20 char field, blank padded to 20 characters, left
>> justified.
>> Used like this:
>> knrtext  HeWo;
>> HeWo = "Hello World"
>> _printf( "\n >>>%D<<< \nThis is a sample of default formatting for D \n",
>HeWo
>> );
>> giving this result:
>> >>>Hello World         <<<
>> This is a sample of default formatting for D
>> Sorry.  I couldn't resist.  My apologies to Messrs. Kernighan and Ritchie,
>and C
>> programmers everywhere.
>
>It's an ok (I'd give a 1%) idea, but there are alternatives, and personally I don't like the look of it.  There otherways to do this type of formatting exist already. Why not have that format in the printf instead, infact It's already possible with printf. One advantage of the code above is resuse, but if your a smart C programmer, I'd make little dif to your D program.
>

I suppose what I really want is format type and data type syntax checking, with some declaration-time control.  In "C", if I change a data type from a two-byte short to a four-byte long, I must manually check every line of code for format changes, including every header.  I always miss one or two.  I never get a warning, and when I see unexpected output, I always assume I screwed up an algorithm, not the format.  I then waste a lot of time proving I did nothing wrong but the format.  It drives me to distraction.  I am to the point where I am ready to write a whole new language because this is something the computer should handle, not me.

Oh.  Wait.  That's why we are here.

I really like the individual cell formatting allowed by spreadsheets.  I can rapidly and correctly modify formats to get just the right "look".

( I find the "C++" stream formatting controls look like hieroglyphics.  I always have to stop and decode them.  Again, I also have watched native "C" developers do the same thing.  Every time I look at implementation details, stream formatting brings in a lot of extra executable code.  A lot of things about "C++" are major advances, but stream outputs are not one of them.  Flames may be directed to my email address, below. )

>> Add a default format for structures as well, so that the following does
>not
>> produce parseable garbage, but a powerful and easily evaluated output: _debug _printf ( "\n %D\n", dataStruct );
>>
>> Add format-time loop control, like so:
>> _printf ( "\n %(20 5.2d) ", a(i)(i = 0;i<20;i++;a(i) < amax )   );   /*
>prints a
>> row of twenty numbers */
>> This does not look right, somehow, although it gets the point across.
>>
>
>The idea is cool, but syntax is not.
>More like
>_printf ( "\n %(20 5.2d) ", for(i = 0;i<20;i++) return a(i) );
>

Now I see my problem from before.  More like

printf ( "\n %(20. %5.2d)", for(i=0;i<20;i++)return a(i)    );
/* this variation will require ")" in format strings to be escaped to be printed
*/

printf(  "\n %(20 %5.2d%)", for(i=0;i<20;i++)return a(i)    ); /* this variation does not, but it is really ugly   */

My first construction borrowed from PL/1.  Is this from Java?

>
> I'd like to be able to write function on the fly like java allows. Of couse
>this reduces code reusablily and I'd only want to uses it for small bits of
>code.
>printf ( "\n %d ",  int (a) {return for(i = 0;i<20;i++)a++}} ); //Note,
>would have differn't output from the above code.
>
>or
>
>printf ( "\n %d ",  int get(a) {return for(i = 0;i<20;i++)a++}} );

Sorry, but I do not see it.  How does this reduce reuse?  The format string, the data, and the control loop are all tightly interconnected from a logic point of view.  As far as I can tell, no matter how you code it, if any one of these things is changed, the whole process will have to be reviewed.

>
>> As usual for me, compliments, constructive criticisms, and nasty comments
>will
>> all be warmly received.
>
>OK
>


Andy Walker
jawalker@stl.quik.com

"Andy Walker" <Andy_member@pathlink.com> wrote in message news:actfkn$30t$1@digitaldaemon.com...

> I think I code "C" the way Pavel codes it, with lots of brackets:
> if ( a == b)
> {
> c = f(z);
> }
> else
> {
> c = f(z+1);
> }

Er... that's exactly the opposite to what I'd write:

    if (a == b)
        c = f(z);
    else
        c = f(z + 1);

No brackets! =)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:actg00$3eo$1@digitaldaemon.com...

>     if (a == b)
>         c = f(z);
>     else
>         c = f(z + 1);
>
> No brackets! =)

c = f(z+(a==b));

No if! :-)

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:acthvu$5b9$1@digitaldaemon.com...

> c = f(z+(a==b));
>
> No if! :-)

Hmm... never thought of it. But you are definitely right. I'll remember this, a great piece of code indeed. =)

...now if we could also get read of loops...

"Andy Walker" <Andy_member@pathlink.com> wrote in message news:actfkn$30t$1@digitaldaemon.com...
> In article <acstdh$2jj3$1@digitaldaemon.com>, anderson says...
> >
> >I think?? the "_" (underscore) issue has been already discussed and
> >discarded by Walter
> <snip>


>
> Whether "do" or "for" makes no difference to me.  To me, the multiple loop
types
> are redundant.  Having to find the post-condition "while" at the end of a
block
> makes me lose my train of thought while trying to understand a block of
code.  I
> have noticed that it distracts native "C" programmers as well.
>
> I am not partial to the implied auto increment.  I have coded with the
following
> style, and generally find it makes things very clear for other developers.
>
> E.g. processing two arrays, whose indexes are not similar:
>
> for (     i  = 0,         j = 37    ;
> i < imax                  ;
> i++,            j += 13  )
> {
> new_a[ i ] = structArray[ j ].old_a ;
> }
>

fair enough

>
> Now I see my problem from before.  More like
>
> printf ( "\n %(20. %5.2d)", for(i=0;i<20;i++)return a(i)    );
> /* this variation will require ")" in format strings to be escaped to be
printed
> */
>
> printf(  "\n %(20 %5.2d%)", for(i=0;i<20;i++)return a(i)    );
> /* this variation does not, but it is really ugly   */
>
> My first construction borrowed from PL/1.  Is this from Java?

No it was an idea,  probably got for formating wrong, and the code above is not quite right (it needs work). Also isn't d used for integers. The formating

> >
> > I'd like to be able to write function on the fly like java allows. Of
couse
> >this reduces code reusablily and I'd only want to uses it for small bits
of
> >code.
> >printf ( "\n %d ",  int (a) {return for(i = 0;i<20;i++)a++}} ); //Note,
> >would have differn't output from the above code.
> >
> >or
> >
> >printf ( "\n %d ",  int get(a) {return for(i = 0;i<20;i++)a++}} );
>
> Sorry, but I do not see it.  How does this reduce reuse?  The format
string, the
> data, and the control loop are all tightly interconnected from a logic
point of
> view.  As far as I can tell, no matter how you code it, if any one of
these
> things is changed, the whole process will have to be reviewed.

Sorry I mean't, reduce reuse as a bad think (I don't think I'm termming it properly).  In otherwords, it doesn't premote resuable functions. If you have a function created inside another function, you can't use it outside the function, so it's probably no a good Idea.  I found it most useful for event driven programming.


>
> Andy Walker
> jawalker@stl.quik.com

On Mon, 27 May 2002 17:11:37 +0100, "Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote:
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:actg00$3eo$1@digitaldaemon.com...
> 
> >     if (a == b)
> >         c = f(z);
> >     else
> >         c = f(z + 1);
> >
> > No brackets! =)
> 
> c = f(z+(a==b));
> 
> No if! :-)
> 
It's called obfuscation. I suppose when a change requred 'z+OFFSET+2' in the else clause you could write

    c = f(z+(a==b)*2 + (a==b)*OFFSET);

and when the 'z' in the if clause (also) became 'z-1'

    c = f (z + (a==b)*2 + (a==b)*OFFSET - (a<=b));

What fun!
Karl Bochert

"Andy Walker" <Andy_member@pathlink.com> wrote in message news:actfkn$30t$1@digitaldaemon.com...
>  I am still, at heart, a
> FORTRAN programmer, and do not see with the eyes of a native "C"
developer.  (
> Every two months or so I code a for loop like so:  for ( i =0, i < 20,
i++ ) ...
> Note the commas, not semicolons. :-P   )

I come from a FORTRAN background myself. I've been doing C for so long now, though, I doubt I could ever write a working FORTRAN program again. A couple months ago I tried to help some people port some FORTRAN code I wrote 25 years ago, but it just escapes me. But I still use i,j,k,l,m as integer variables <g>.

"Andy Walker" <Andy_member@pathlink.com> wrote in message news:actfkn$30t$1@digitaldaemon.com...
> Whether "do" or "for" makes no difference to me.  To me, the multiple loop
types
> are redundant.  Having to find the post-condition "while" at the end of a
block
> makes me lose my train of thought while trying to understand a block of
code.  I
> have noticed that it distracts native "C" programmers as well.

I wouldn't mind integrating the various loop structures together somehow... a loop is a loop is a loop.  Oftentimes I find myself wanting a for loop that does the test at the end of the block.  In fact oftentimes I find myself coding

if (a)
do
{
  a  = input();
} while (a);

just to make it explicitly clear to the compiler what kind of code I want it
to generate.  (the above is a while loop)  It'd be nice if the compiler
always translated while(a) { foo(); } to:

goto test;
loopbody:
  foo();
test:
  if (a) goto loopbody;

In fact my usual loop construct is a count-down for loop like so:

for (int i = container.size(); --i>=0; )
  f(container[i]);

Notice that container.size() only gets executed once, even if the compiler is stupid or you're in a debug build.

Sean

> I am not partial to the implied auto increment.  I have coded with the
following
> style, and generally find it makes things very clear for other developers.
>
> E.g. processing two arrays, whose indexes are not similar:
>
> for (     i  = 0,         j = 37    ;
> i < imax                  ;
> i++,            j += 13  )
> {
> new_a[ i ] = structArray[ j ].old_a ;
> }
>
> >> Formatting: add a type's format specification to the general
information
> >about
> >> the type.  For new types, use the base type as the default, but also
allow
> >it to
> >> be specified.
> >> e.g.  typedef string [ 20 ] knrtext ( %20.20lc );  (meaning: new type
> >"name",
> >> default formatting, use 20 char field, blank padded to 20 characters,
left
> >> justified.
> >> Used like this:
> >> knrtext  HeWo;
> >> HeWo = "Hello World"
> >> _printf( "\n >>>%D<<< \nThis is a sample of default formatting for D
\n",
> >HeWo
> >> );
> >> giving this result:
> >> >>>Hello World         <<<
> >> This is a sample of default formatting for D
> >> Sorry.  I couldn't resist.  My apologies to Messrs. Kernighan and
Ritchie,
> >and C
> >> programmers everywhere.
> >
> >It's an ok (I'd give a 1%) idea, but there are alternatives, and
personally
> >I don't like the look of it.  There otherways to do this type of
formatting
> >exist already. Why not have that format in the printf instead, infact
It's
> >already possible with printf. One advantage of the code above is resuse,
but
> >if your a smart C programmer, I'd make little dif to your D program.
> >
>
> I suppose what I really want is format type and data type syntax checking,
with
> some declaration-time control.  In "C", if I change a data type from a
two-byte
> short to a four-byte long, I must manually check every line of code for
format
> changes, including every header.  I always miss one or two.  I never get a warning, and when I see unexpected output, I always assume I screwed up an algorithm, not the format.  I then waste a lot of time proving I did
nothing
> wrong but the format.  It drives me to distraction.  I am to the point
where I
> am ready to write a whole new language because this is something the
computer
> should handle, not me.
>
> Oh.  Wait.  That's why we are here.
>
> I really like the individual cell formatting allowed by spreadsheets.  I
can
> rapidly and correctly modify formats to get just the right "look".
>
> ( I find the "C++" stream formatting controls look like hieroglyphics.  I
always
> have to stop and decode them.  Again, I also have watched native "C"
developers
> do the same thing.  Every time I look at implementation details, stream formatting brings in a lot of extra executable code.  A lot of things
about
> "C++" are major advances, but stream outputs are not one of them.  Flames
may be
> directed to my email address, below. )
>
> >> Add a default format for structures as well, so that the following does
> >not
> >> produce parseable garbage, but a powerful and easily evaluated output: _debug _printf ( "\n %D\n", dataStruct );
> >>
> >> Add format-time loop control, like so:
> >> _printf ( "\n %(20 5.2d) ", a(i)(i = 0;i<20;i++;a(i) < amax )   );   /*
> >prints a
> >> row of twenty numbers */
> >> This does not look right, somehow, although it gets the point across.
> >>
> >
> >The idea is cool, but syntax is not.
> >More like
> >_printf ( "\n %(20 5.2d) ", for(i = 0;i<20;i++) return a(i) );
> >
>
> Now I see my problem from before.  More like
>
> printf ( "\n %(20. %5.2d)", for(i=0;i<20;i++)return a(i)    );
> /* this variation will require ")" in format strings to be escaped to be
printed
> */
>
> printf(  "\n %(20 %5.2d%)", for(i=0;i<20;i++)return a(i)    );
> /* this variation does not, but it is really ugly   */
>
> My first construction borrowed from PL/1.  Is this from Java?
>
> >
> > I'd like to be able to write function on the fly like java allows. Of
couse
> >this reduces code reusablily and I'd only want to uses it for small bits
of
> >code.
> >printf ( "\n %d ",  int (a) {return for(i = 0;i<20;i++)a++}} ); //Note,
> >would have differn't output from the above code.
> >
> >or
> >
> >printf ( "\n %d ",  int get(a) {return for(i = 0;i<20;i++)a++}} );
>
> Sorry, but I do not see it.  How does this reduce reuse?  The format
string, the
> data, and the control loop are all tightly interconnected from a logic
point of
> view.  As far as I can tell, no matter how you code it, if any one of
these
> things is changed, the whole process will have to be reviewed.
>
> >
> >> As usual for me, compliments, constructive criticisms, and nasty
comments
> >will
> >> all be warmly received.
> >
> >OK
> >
>
>
> Andy Walker
> jawalker@stl.quik.com