 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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?
Haskell's library support for mutable arrays is a mess. But we're still
talking about bad library design, not bad language design.
>> 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.
Sure. And my argument is that if a language is designed well, you can
use it to write powerful libraries which are simple and easy to use.
(And if a language is designed poorly, you often can't do that.) Hence
why good language design is so important.
>> 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?
Most of this stuff is due to social, organisational, economic and other
reasons, not language design.
Your core argument appears to be that a useful programming language
necessarily has to be badly designed. I reject that. The fact that all
of the widely used languages are badly designed doesn't mean that bad
design is a necessary attribute.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/14/2012 1:06, Invisible wrote:
> My point being that everybody acts like "oh, of /course/ you can't possibly
> do that", when in fact you can.
You can't possibly do it in a language where you are actually declaring your
types. You *can* return types that are private or anonymous. You just can't
declare a function that returns a private type.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/14/2012 3:17, clipka wrote:
> If you want to give such guarantees, you can't handle variables of types for
> which you have no declaration, because obviously you can't tell whether they
> can do A, B, C and D or not.
To be fair, I suspect Haskell just treats that declaration as if you're
returning Object in C#. In other words, haskell I suspect doesn't let you
return a value whose type you can't see, but instead of making that illegal,
it essentially inserts a cast for you to an opaque supertype. (So to speak,
of course, since Haskell isn't OO.)
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
