View mode: basic / threaded / horizontal-split · Log in · Help
March 03, 2009
Re: std.locale
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
Re: std.locale
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
Re: std.locale
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
Re: std.locale
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
Re: std.locale
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
Re: std.locale
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
Re: std.locale
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
Re: std.locale
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
Re: std.locale
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
Re: std.locale
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
4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home