Index » General » std.locale (page 8)

March 03, 2009
Andrei Alexandrescu wrote:
>> In another post you sounded as if there is a connection between this stuff and printing arrays. I'm not sure I see the connection.
> 
> Very simple. If we have a locale table, I am thinking of dedicating a branch "std" in it to stuff that's in std. For example, I can use currentLocale.get("std", "array-separator") or something.

Let's disconnect the two.

What if you were to document the data structure Algebraic, and mention that D itself uses an instance of it already to store array printing parameters.

You could also mention that an Algebraic would be a great place to store Unicode CLDR data, and other (Windows) registry type things.

And then, in the examples directory one could find a program that reads the CLDR xml (or of course a suitable snippet of it) and populates an instance of Algebraic. And then this example program would do something small but useful with the data.


March 03, 2009
Walter Bright wrote:
> Christopher Wright wrote:
>> Georg Wrede wrote:
>>> -- All very nice, but no cigar. That's about as smart as letting people define *unlimited* length variable names!)
>>
>> I recently dealt with a programming language that specified a limit of 63 characters for identifier names. This wouldn't have been a significant problem, except that I was generating code automatically, and some of my identifiers were over 90 characters. Identifier length limits are evil, unless they're ridiculously large (C#, I think, limits identifiers to 4096 characters).
> 
> As soon as you put in a limit on identifier name length, sooner or later you'll get a bug report on it.
> 
> For example, C++ can be compiled to C code. C++ templates encode their entire state into the template instance identifier, and these can easily reach 10,000 characters or more. So if your C compiler has a length limit on identifiers, then C++ templates become severely limited.
> 
> Another thing to consider is it's actually *more* work to put a limit on, where you have to document it, explain it, detect it, diagnose it, recover from it, than if you just make it unlimited.
> 
> There are really only 3 numbers in computer programming: 0, 1, and unlimited. I always chuckle when I see an ad for like, an editor, that says "up to 5 files open at once!".

I take it back.
March 03, 2009
On 2009-03-02 23:27:49 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Georg Wrede wrote:
> [snip]
> 
> Well I guess what I'll do is take the path of least resistance - nothing. Looks like locales are rather unpopular...

Sad.

Seriously, I think if D could have locales as a standard feature it'd be great. Supporting various locales is often a must when you deploy an application, and when libraries try to do it differently you find yourself in a mess.

One thing I dislike in your approach is that you're designing the underlying data storage system before considering the API we're going to use. What we need the most is a standard API for localizing the display and input of data, and I somewhat fail to see how storing all the localization parameters in an Algebraic solves this problem.

I mean, let's say you want to output a localized message, perhaps we could do this:

	writefln("Hello number %f", 123456.44);
	writefln(localize("Hello number %f"), 123456.44); // default locale

	Locale fr = locale("fr");
	writefln(localize("Hello number %f", fr), 123456.44);

and expect this output:

	Hello number 123456.44
	Hello number 123,456.44
	Bonjour numéro 123 456,44

?

That'd be an interesting feature. But as of yet I have no idea how we're supposed to use all that locale information you want to keep in your algebraic type; you haven't provided much examples like the one above where all you want is to format a string and a number. Perhaps it's clear in your head, but to me it's vague. Exposing all this locale data is useless if it isn't supported by the library's functions.

What I wrote above could work that way: localize(...) returns a FormattedString!(...) struct template containing a string and a templated function "format" for formatting its arguments. writefln being a templated function, it'll call toString on its first argument and check if it provide a "format" function, and if it does it passes all the other arguments through it before output.

The "localize" function could be overloaded to accept various types of locales. Including, but not limited to, your Algebraic locale data.

The downside of this approach is that it requires functions accepting a locale or a localized formatted string to be templates.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

March 03, 2009
On Mon, 02 Mar 2009 01:37:55 -0800, Walter Bright <newshound1@digitalmars.com> wrote:

>Georg Wrede wrote:
>> We've had Walter make nice features to D that were laborious to create, only to see nobody use them. It's happened, ask him.
>
>Sure. Often the only way to see if a feature is useful is to actually implement it and see what happens. Some features have succeeded and found uses far beyond my expectations (CTFE, string mixins) while others have pretty much languished (design by contract, complex numbers).

I think DbC would be widely used if it worked with inheritance and could possible be apply to interfaces. There is an entry in Bugzilla and has been voted sixth up to sixth place.

http://d.puremagic.com/issues/show_bug.cgi?id=302

Gide
March 03, 2009

Walter Bright wrote:
> Georg Wrede wrote:
>> We've had Walter make nice features to D that were laborious to create, only to see nobody use them. It's happened, ask him.
> 
> Sure. Often the only way to see if a feature is useful is to actually implement it and see what happens. Some features have succeeded and found uses far beyond my expectations (CTFE, string mixins) while others have pretty much languished (design by contract, complex numbers).

I've used complex numbers before, but only when rendering fractals. Sorry :P

As for design by contract, my problem has always been this:

Contracts let you ensure that your assumptions about program state are never violated.  That means checking pre- and post-conditions on functions, and invariants for classes.  Which is great.

So I put contracts on everything.  Fantastic.  I do a release compile, and all that safety disappears.  So only the debug build has contracts enabled.  But it's the release build, if it crashes, that I need help diagnosing.

There's also libraries.  If you put contracts on public APIs, then your library is only checking arguments in debug builds.  This makes release builds faster, but also less safe.  So do you only put contracts on internal APIs and do manual exception testing on public APIs?

I like DbC, I really do.  I just have trouble figuring out where and how to use it properly.

  -- Daniel
March 03, 2009
Daniel Keep:
> So I put contracts on everything.  Fantastic.  I do a release compile, and all that safety disappears.  So only the debug build has contracts enabled.  But it's the release build, if it crashes, that I need help diagnosing.

A simple solution is to not use -release for the final version of the code, but this keeps array bound controls too.
LDC may have already solved your problem, with extra compilation arguments that you can use to disable such controls independently from each other.
It's not a fault of design by contract, it's just that the D compiler switches are lumped together. It seems a simple to solve problem.

Bye,
bearophile
March 03, 2009
bearophile wrote:
> Daniel Keep:
>> So I put contracts on everything.  Fantastic.  I do a release compile,
>> and all that safety disappears.  So only the debug build has contracts
>> enabled.  But it's the release build, if it crashes, that I need help
>> diagnosing.
> 
> A simple solution is to not use -release for the final version of the code, but this keeps array bound controls too.
> LDC may have already solved your problem, with extra compilation arguments that you can use to disable such controls independently from each other.
> It's not a fault of design by contract, it's just that the D compiler switches are lumped together. It seems a simple to solve problem.
> 
> Bye,
> bearophile

I agree. I'm having the same problem: I put a contract in there, I know it's as good as assert. So I can't do e.g. input validation because in most functions input must always be validated. I also know that contracts are doing the wrong thing with inheritance and can't apply to interfaces, which is exactly the (only?) place they'd be interesting. So I send the contracts home and use assert, enforce, and unittest.

Andrei
March 03, 2009
Tue, 03 Mar 2009 07:05:51 -0800, Andrei Alexandrescu wrote:

> bearophile wrote:
>> Daniel Keep:
>>> So I put contracts on everything.  Fantastic.  I do a release compile, and all that safety disappears.  So only the debug build has contracts enabled.  But it's the release build, if it crashes, that I need help diagnosing.
>> 
>> A simple solution is to not use -release for the final version of the code, but this keeps array bound controls too.
>> LDC may have already solved your problem, with extra compilation arguments that you can use to disable such controls independently from each other.
>> It's not a fault of design by contract, it's just that the D compiler switches are lumped together. It seems a simple to solve problem.
>> 
>> Bye,
>> bearophile
> 
> I agree. I'm having the same problem: I put a contract in there, I know it's as good as assert. So I can't do e.g. input validation because in most functions input must always be validated. I also know that contracts are doing the wrong thing with inheritance and can't apply to interfaces, which is exactly the (only?) place they'd be interesting. So I send the contracts home and use assert, enforce, and unittest.

I'd really like to see enforce() as a built-in language feature.
assert() doesn't help in way too many situations.
March 03, 2009
Michel Fortin wrote:
> On 2009-03-02 14:58:26 -0500, Walter Bright <newshound1@digitalmars.com> said:
> 
>> It's a silly thing, but I love the little google widget you can add to a web page to automatically translate the pages. All the D site pages have it in the left column.
> 
> It's not a silly thing, it's hilarious. Look, Google has invented the D-French language:
> 
> -    import std.stdio;
> +    std.stdio importation;
> ----------
> -    delete cl;
> +    supprimer cl;
> ----------
> -    s.allocated += argv.length * typeof (argv[0]).sizeof;
> +    s.allocated + = * argv.length typeof (argv [0]). sizeof;

Wow, I didn't know the standard French form for formulas was prefix notation :-)


Sean
March 03, 2009

Sean Kelly wrote:
> Michel Fortin wrote:
>> On 2009-03-02 14:58:26 -0500, Walter Bright <newshound1@digitalmars.com> said:
>>
>>> It's a silly thing, but I love the little google widget you can add to a web page to automatically translate the pages. All the D site pages have it in the left column.
>>
>> It's not a silly thing, it's hilarious. Look, Google has invented the D-French language:
>>
>> -    import std.stdio;
>> +    std.stdio importation;
>> ----------
>> -    delete cl;
>> +    supprimer cl;
>> ----------
>> -    s.allocated += argv.length * typeof (argv[0]).sizeof;
>> +    s.allocated + = * argv.length typeof (argv [0]). sizeof;
> 
> Wow, I didn't know the standard French form for formulas was prefix notation :-)
> 
> 
> Sean

Wait, does this mean the French speak LISP?

No wonder I could never understand them! :O

  -- Daniel
1 2 3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home