Andrei Alexandrescu wrote:
> Nick Sabalausky wrote:
>> "BCS" <ao@pathlink.com> wrote
>>> Reply to Nick,
>>>
>>>> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message
>>>> news:gsiqdr$1csj$2@digitalmars.com...
>>>>
>>>>> BCS wrote:
>>>>>> One option would be to not throw an error if the format string uses
>>>>>> indexing formats (e.i. out of order formatting)
>>>>>>
>>>>> Yah, that's an option I considered. Maybe it's the best way to go.
>>>>>
>>>> That would be far too clumbsy, unless you made it into two separate
>>>> functions.
>>>>
>>>> For instance (psuedocode):
>>>> auto userInput = getUserInput()
>>>> // userInput now contains "{Name} at {Address}", zip deliberately
>>>> ignored
>>>> writefln(userInput, name, address, zip); // They're used in-order, but
>>>> there
>>>> shouldn't be an error
>>> They are in order but are listed by name so the error doesn't throw. The case where the error would be thrown is where the only format strings used are the "get the next arg" kind.
>>>
>> I was just using names for illustrative purposes. Also, I was under the impression that printf-style "get the next arg" formatting codes were the only ones writef supported. Is this not so?
>>
> Since a few versions ago writef supports positional arguments with Posix syntax.
> 
> Andrei

Positional format specifications really make a huge difference, especially where one needs to have the user interface in several languages. Thanks for them!!

Now, for the case without positional format specifications, we could (and I guess, should) have a solution to "the wrong number of arguments" problem. If we have:

 - a non-printing format spec
 - a munch-the-remaining-ones format spec
 - an ignore-too-few-arguments format spec

we could cover all the needed cases.

The first one lets you use one parameter without printing it. (Maybe you don't want to print the middle part of somebody's name.) The second is used when you don't want to print possibly many remaining arguments, say the address of someone, or the country.

The last one, is for the case where you use a single format string in several contexts, some of which you suspect may not contain enough information to be formally correct, but where you are satisfied to print an empty string '' (that is, not print anything) for them.

This situation might arise when the format string originates from outside the program.

** When none of the latter two are used, and there is the wrong number of arguments, I think a runtime exception should be thrown.

The only time where I think a compile time error is warranted, is when the format string is a string literal, with the wrong number of arguments.


The programmer may put the ignore-too-few-arguments format spec anywhere in the format string. Its effect starts from that point on.

Andrei Alexandrescu wrote:
> Craig Black wrote:
>> I like very much the direction D2 is going now.  Language refactoring and enhancements driven by the goal of more elegant implementation of standard libraries.  This approach seems very practical and promising.  Thank you very much and keep it up!
>>
>> -Craig
> 
> Thanks. Walter pointed out to me something interesting - STL is non-intuitive. That doesn't make it any less true (as a pursuit of the most generic incarnation of fundamental structs and algos). It's non-intuitive the same way complex numbers and relativity theory are non-intuitive.
> 
> No language has ever managed to comprehend STL by sheer chance. (This in spite of e.g. C# adding a boatload of new features with each release.) There are two that can express it at all: C++ and D. Both C++ and D had to be changed to allow STL to exist, and became better languages as a result. The range shtick and D's support for lambdas is taking STL support to a whole new level.
> 
> The downside is, it's rather difficult to explain the STL to anyone using other languages and wanting to just figure what the STL buzz is all about.

I wrote my MSc thesis about the STL. I think the conceptual idea was clean and clear, and at the time it was reasonably easy to explain it to even the professors. ;-)

Today, however, and especially with the advanced implementation we have here in D, if someone has no prior knowledge of the STL way of thinking, it may be really hard to get them to 'get it'. There are too many trees up front to grasp the forest.

What's sad, http://en.wikipedia.org/wiki/Standard_Template_Library
really sucks at introducing the STL on a conceptual level. Even worse, that is actually the only thing it *should* do. Everyting else is optional.

On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright <newshound1@digitalmars.com> wrote:

>
>This is a major revision to Phobos, including Andrei's revolutionary new range support.
>
>http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip

Wicked awesome!

file:///C:/dmd/html/d/phobos/std_range.html#cons
Looks like bug 2676 was fixed in 2.027

On Mon, 20 Apr 2009 09:57:55 +0200, Max Samukha <samukha@voliacable.com.removethis> wrote:

>On Mon, 20 Apr 2009 00:09:09 -0700, Walter Bright <newshound1@digitalmars.com> wrote:
>
>>
>>This is a major revision to Phobos, including Andrei's revolutionary new range support.
>>
>>http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip
>
>Wicked awesome!
>
>file:///C:/dmd/html/d/phobos/std_range.html#cons
http://www.digitalmars.com/d/2.0/phobos/std_range.html#cons

>Looks like bug 2676 was fixed in 2.027

Walter Bright wrote:
> 
> This is a major revision to Phobos, including Andrei's revolutionary new range support.
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.029.zip

This is looking very nice! I want to switch from D1 to D2, but...

I don't want to sound greedy or anything, and I know others have asked for this before, but is making a 64-bit Linux version of DMD a lot of work?

I admit I don't know much about these things, and what I'm going to say next may not make sense at all, but here goes:

x86-64 is just a superset of x86, right? Wouldn't it be possible, as a first step in the direction of a full-fledged x86-64 compiler, to simply make one that uses the same instruction set as the current DMD, but, I dunno, marks the executable as 64-bit (or something like that)? Specialisation and optimisation for the 64-bit architecture could then come at a later point in time.

I know it is possible to run the 32-bit compiler (and the executables it produces) on a 64-bit operating system, but it isn't possible to link against 64-bit libraries. This means that one has to install and maintain 32-bit versions of all the libraries one wants to use, and those are, in general, not available through the repositories of most 64-bit distros.

-Lars

Lars T. Kyllingstad wrote:
> Walter Bright wrote:
>>
>> This is a major revision to Phobos, including Andrei's revolutionary new range support.
>>
>> http://www.digitalmars.com/d/2.0/changelog.html
>> http://ftp.digitalmars.com/dmd.2.029.zip
> 
> This is looking very nice! I want to switch from D1 to D2, but...
> 
> I don't want to sound greedy or anything, and I know others have asked for this before, but is making a 64-bit Linux version of DMD a lot of work?
> 
> I admit I don't know much about these things, and what I'm going to say next may not make sense at all, but here goes:
> 
> x86-64 is just a superset of x86, right? Wouldn't it be possible, as a first step in the direction of a full-fledged x86-64 compiler, to simply make one that uses the same instruction set as the current DMD, but, I dunno, marks the executable as 64-bit (or something like that)? Specialisation and optimisation for the 64-bit architecture could then come at a later point in time.

It's not quite that simple. It's not a full superset; some x86 instructions are not valid x86-64 instructions.
For example, I think 'inc' was removed to make place for prefixes that set some flags for the next instruction and allow it to use the extra registers r8-r15.

Lars T. Kyllingstad wrote:
> Walter Bright wrote:
>>
>> This is a major revision to Phobos, including Andrei's revolutionary new range support.
>>
>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip
> 
> This is looking very nice! I want to switch from D1 to D2, but...
> 
> I don't want to sound greedy or anything, and I know others have asked
> for this before, but is making a 64-bit Linux version of DMD a lot of work?
> 
> I admit I don't know much about these things, and what I'm going to say next may not make sense at all, but here goes:
> 
> x86-64 is just a superset of x86, right? Wouldn't it be possible, as a first step in the direction of a full-fledged x86-64 compiler, to simply make one that uses the same instruction set as the current DMD, but, I dunno, marks the executable as 64-bit (or something like that)? Specialisation and optimisation for the 64-bit architecture could then come at a later point in time.

I'm pretty sure that 64-bit code is binary incompatible with 32-bit code.  For example:

struct Foo { void* ptr; }

Is a different size for 32-bit and 64-bit code.

> I know it is possible to run the 32-bit compiler (and the executables it produces) on a 64-bit operating system, but it isn't possible to link against 64-bit libraries. This means that one has to install and maintain 32-bit versions of all the libraries one wants to use, and those are, in general, not available through the repositories of most 64-bit distros.

This is because the OS puts the CPU into a 32-bit compatible mode, but it can't magic away the differences between 32-bit and 64-bit code.

> -Lars

The best bet for 64-bit D executables at this point is probably LDC; dunno what the current state is, though.

  -- Daniel

Daniel Keep wrote:
> 
> Lars T. Kyllingstad wrote:
>> Walter Bright wrote:
>>> This is a major revision to Phobos, including Andrei's revolutionary
>>> new range support.
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.029.zip
>> This is looking very nice! I want to switch from D1 to D2, but...
>>
[snip]
> 
> The best bet for 64-bit D executables at this point is probably LDC;
> dunno what the current state is, though.

The state for D2 is currently "very broken", AFAIK.

Daniel Keep wrote:

...
>> -Lars
> 
> The best bet for 64-bit D executables at this point is probably LDC; dunno what the current state is, though.
> 
>   -- Daniel

if you grep the dmd backend sources for x86_64, you'll get some results. Don't know what that means though, the source looks like magic to me!

Walter Bright wrote:

> 
> This is a major revision to Phobos, including Andrei's revolutionary new range support.
> 
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip

Thanks so much, looking good!

The lambda template parameters: very cool.