 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Hint: There's more to Unicode than just ~1 million code points with
>>> glyphs mapped to some of them.
>>
>> Sure. But if you can't even /write down/ those code-points, that's kinda
>> limiting.
>>
>> (It also strikes me that if the String type /can/ hold them all and Char
>> /can't/, that has interesting implications for trying to iterate over a
>> String one Char at a time...)
>
> As soon as you think of combining diacritics, you'll see that this type
> of limitation is actually inevitable
I guess combining characters are The Real WTF...
(No, wait - that's the BOM.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.08.2012 12:36, schrieb Invisible:
>>> I was referring only to the design of the language itself, not the
>>> libraries that go with it, nor any of the various other tools required
>>> to make a language generally useful. It's no secret that Haskell fails
>>> spectacularly on that count.
>>
>> I'm reiterating: I don't doubt that the Haskell /core language/ is
>> simple and elegant. I doubt that it "solves everything".
>
> It solves every problem of core application logic. It doesn't solve the
> problem of talking to the outside world. (That's the job of the
> libraries, and once they currently don't do so well.)
Neither does it solve every problem of core application logic in a
/practical/ manner. At least that's the impression I get from your
occasional rants. So for those things you'll need libraries, too.
>> As soon as you've dealt with the "solves everything" part, we'll talk
>> again, and see if the "simple and elegant" also applies to that one. My
>> claim is that the combo isn't possible.
>>
>> THAT is the point I'm trying to get through to you.
>
> You somehow believe that writing a bunch of libraries would make the
> language no longer elegant?
I believe that writing a sufficient bunch of libraries to care for all
needs would make the /combo/ non-elegant in various places.
That said, if the core language was /that/ simple, elegant and
cover-all, how come nobody has managed to put an easy-to-use cover-all
library for X yet? (X := any feature already implemented in multiple
libraries but with different severe limitations to each of them. Dunno
which example it was you did your rant over - mutable lists or some such?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> - The "char" type works with Unicode. Well done. Oh, but wait... It only
>>> stores 16 bits, and yet Unicode actually requires 24 bits to represent a
>>> single code-point. So this "Unicode character" only actually covers the
>>> Basic Multilingual Plane. FAIL!
>>
>> Oh great. Apparently "char" doesn't store a code-point at all, it stores
>> a code-unit.
>>
>> For anything in the BMP, these are effectively the same thing. For
>> anything outside that range, *you* must manually write the code to
>> decode UTF-16 into actual code-points (which then do not fit into a
>> "char").
>
> Uh... why does this come as a surprise to you?
I guess I'm used to using a programming language where a Char is...
well... any valid Unicode code-point, and once you set the encoding of a
file handle, the library does all necessary encoding and decoding,
whether it's UTF-8, UTF-16, Latin-1 or whatever.
Still, I suppose it's better than char = unsigned byte. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I'm reiterating: I don't doubt that the Haskell /core language/ is
>>> simple and elegant. I doubt that it "solves everything".
>>
>> It solves every problem of core application logic. It doesn't solve the
>> problem of talking to the outside world. (That's the job of the
>> libraries, and once they currently don't do so well.)
>
> Neither does it solve every problem of core application logic in a
> /practical/ manner. At least that's the impression I get from your
> occasional rants. So for those things you'll need libraries, too.
So what application logic problems aren't solved by Haskell then?
>> You somehow believe that writing a bunch of libraries would make the
>> language no longer elegant?
>
> I believe that writing a sufficient bunch of libraries to care for all
> needs would make the /combo/ non-elegant in various places.
And I believe you're wrong.
The purpose of a library is to make stuff easy, after all...
> That said, if the core language was /that/ simple, elegant and
> cover-all, how come nobody has managed to put an easy-to-use cover-all
> library for X yet? (X := any feature already implemented in multiple
> libraries but with different severe limitations to each of them. Dunno
> which example it was you did your rant over - mutable lists or some such?)
If C is so great for writing operating systems, where are there so many
different, incompatible operating systems? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.08.2012 12:48, schrieb Invisible:
> On 14/08/2012 03:42 PM, Invisible wrote:
>> As with any language, my WTF list:
>
> Enums. Urgh. An enumeration is supposed to be a type that can only take
> on the specified set of values. Except that in C#, an enumeration can
> take on /any/ integer value. It's just that some of these values also
> have friendly names. *sigh*
Erm... did you actually /try/ this??
Trying to assing an int to an enum variable, I get a "Cannot implicitly
convert [...]" error for any integer value other than 0. (Don't ask me
why they did allow it for 0 though.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Enums. Urgh. An enumeration is supposed to be a type that can only take
>> on the specified set of values. Except that in C#, an enumeration can
>> take on /any/ integer value. It's just that some of these values also
>> have friendly names. *sigh*
>
> Erm... did you actually /try/ this??
Quoting Microsoft's C# language specification:
"Each enum type has a corresponding integral type called the
underlying type of the enum type. [...] The set of values that an enum
type can take on is not limited by its enum members. In particular, any
value of the underlying type of an enum can be cast to the enum type and
is a distinct valid value of that enum type."
> Trying to assing an int to an enum variable, I get a "Cannot implicitly
> convert [...]" error for any integer value other than 0. (Don't ask me
> why they did allow it for 0 though.)
Perhaps you can't /implicitly/ convert, but try writing an /explicit/
cast. According to the spec, that's supposed to work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.08.2012 13:06, schrieb Invisible:
>>>> Hint: There's more to Unicode than just ~1 million code points with
>>>> glyphs mapped to some of them.
>>>
>>> Sure. But if you can't even /write down/ those code-points, that's kinda
>>> limiting.
>>>
>>> (It also strikes me that if the String type /can/ hold them all and Char
>>> /can't/, that has interesting implications for trying to iterate over a
>>> String one Char at a time...)
>>
>> As soon as you think of combining diacritics, you'll see that this type
>> of limitation is actually inevitable
>
> I guess combining characters are The Real WTF...
Nope. You just can't do without them for plenty of purposes, because
coding each conceivable combo as a single character would have the
Unicode code space explode (and make comprehensive Unicode fonts even
more scarce). You'd be surprised how many diacritics some languages
stack even on one single character, or how many different diacritics
there are for the IPA phonetic notation.
> (No, wait - that's the BOM.)
Nope, the BOM is quite sane.
First, it is a legal Unicode codepoint, indicating a zero-width
non-breaking space. While this may sound weird to have, it does allow
you to suppress kerning, as well as lots of other stuff that might
happen to pairs of characters (just think of properly implemented arabic
script, where a character's glyph depends not only on the character
itself, but also on its neighbors).
Second, it is suggested to prepend this Unicode character (which by
definition doesn't do any harm) to any text stream that leaves a
program's boundaries.
Why not mandate a canonical byte ordering? Simple: As long as the next
program to pick up the data runs on the same machine (and hence uses the
same byte ordering), re-ordering would just add unnecessary overhead.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.08.2012 13:37, schrieb Invisible:
>>> Enums. Urgh. An enumeration is supposed to be a type that can only take
>>> on the specified set of values. Except that in C#, an enumeration can
>>> take on /any/ integer value. It's just that some of these values also
>>> have friendly names. *sigh*
>>
>> Erm... did you actually /try/ this??
>
> Quoting Microsoft's C# language specification:
>
> "Each enum type has a corresponding integral type called the
> underlying type of the enum type. [...] The set of values that an enum
> type can take on is not limited by its enum members. In particular, any
> value of the underlying type of an enum can be cast to the enum type and
> is a distinct valid value of that enum type."
>
>> Trying to assing an int to an enum variable, I get a "Cannot implicitly
>> convert [...]" error for any integer value other than 0. (Don't ask me
>> why they did allow it for 0 though.)
>
> Perhaps you can't /implicitly/ convert, but try writing an /explicit/
> cast. According to the spec, that's supposed to work.
You're right there. I guess it's to provide support for bitfield-style
use of enums.
Note that one of the design goals of C#, AFAIK, was to provide a
comparatively easy migration path from C/C++.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.08.2012 13:10, schrieb Invisible:
>>>> I'm reiterating: I don't doubt that the Haskell /core language/ is
>>>> simple and elegant. I doubt that it "solves everything".
>>>
>>> It solves every problem of core application logic. It doesn't solve the
>>> problem of talking to the outside world. (That's the job of the
>>> libraries, and once they currently don't do so well.)
>>
>> Neither does it solve every problem of core application logic in a
>> /practical/ manner. At least that's the impression I get from your
>> occasional rants. So for those things you'll need libraries, too.
>
> So what application logic problems aren't solved by Haskell then?
Operating on mutable lists (or whatever it was you tried back then, and
ran into a set of libraries that all did it in a different way
unsuitable for your needs so you resorted to a rant), for instance?
>>> You somehow believe that writing a bunch of libraries would make the
>>> language no longer elegant?
>>
>> I believe that writing a sufficient bunch of libraries to care for all
>> needs would make the /combo/ non-elegant in various places.
>
> And I believe you're wrong.
>
> The purpose of a library is to make stuff easy, after all...
Still, not every library succeeds in that job to a degree that it can be
called "simple and elegant". And sometimes that's not due to design
flaws in the library, but due to the underlying language standing in the
way.
>> That said, if the core language was /that/ simple, elegant and
>> cover-all, how come nobody has managed to put an easy-to-use cover-all
>> library for X yet? (X := any feature already implemented in multiple
>> libraries but with different severe limitations to each of them. Dunno
>> which example it was you did your rant over - mutable lists or some
>> such?)
>
> If C is so great for writing operating systems, where are there so many
> different, incompatible operating systems? :-P
Because there's no such thing as a simple, elegant cover-it-all, maybe?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Trying to assing an int to an enum variable, I get a "Cannot implicitly
> convert [...]" error for any integer value other than 0. (Don't ask me
> why they did allow it for 0 though.)
If it works like C++ enums, then enumerated constants will implicitly cast
to integrals, though (and integrals can be cast explicitly to enums).
While this is useful oftentimes (there are many, many situations where
an enumerated list of names is much handier than writing integral constants),
there are othertimes where strongly-typed enums would be more desirable.
C++11 added strongly-typed enums to the language (in addition to the existing
weakly-typed ones). If an enumerated type is not intended to be used as
an integral, then you can now say so. (You can also specify its underlying
type if you want.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
