March 24, 2010
On 03/24/2010 02:34 PM, Nick Sabalausky wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message
> news:hodla0$2sta$1@digitalmars.com...
>> On 03/24/2010 12:57 PM, Nick Sabalausky wrote:
>>> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>   wrote in message
>>> news:hod5o3$1nhg$1@digitalmars.com...
>>>>
>>>>
>>>> Who are "they"?
>>>>
>>> He was modifying the common expression "Those who don't learn from the
>>> past
>>> are doomed to repeat it."
>>
>> But paraphrasing ain't "as they say" because they don't say that. Besides,
>> I thought he's paraphrasing "Any sufficiently complicated C or Fortran
>> program contains a buggy implementation of Common Lisp." But I guess
>> that's just me being cranky - I'm sick.
>>
>
> Ok, I'm not going to get baited into picking apart minute details of
> someone's exact choice of wording.
>
>
>>>> Why does a mechanism that allows creating bitfields, custom enums,
>>>> flags,
>>>> custom-base literals, and more, feel hackish,
>>>
>>> Because it involves passing everything as parameters to a
>>> string-mixin-generating function/template. Powerful as such as thing is,
>>> and
>>> as much as I like having that ability available, it is a rather blunt
>>> instrument and does tend to feel very hackish.
>>
>> Feeling is subjective. To me it doesn't.
>>
>
> And so what, that proves it isn't hackish? Point is, there are people who do
> find it hackish, and saying "I don't" hardly addresses the issue.
>
>
>>> Also, looking at the docs for bitmanip, it looks like "bitfields" creates
>>> a
>>> "BitArray". But the interface for bitarray doesn't really seem to match
>>> the
>>> conceptual-level operations performed on bitfields any more than just
>>> using
>>> an ordinary uint would, and it doesn't seem to solve most of the problems
>>> with doing so, either.
>>
>> Nonsense. bitfields does not create a BitArray and does exactly what you'd
>> expect some bit fields to do. To saliently criticize an artifact, it does
>> help to understand it.
>>
>> First, custom bitfields are taken care of appropriately by bitfield. You
>> may want to try it before replying. Second, this thread is about enums
>> that are bitwise flags, so I take it you replied to disagree with every
>> paragraph I wrote.
>>
>
> "it does help to understand it"<- Which is why I went and double-checked
> the docs. The docs didn't say anything about what "bitfields" actually
> created, but it did have a big definition of the "BitArray" type right
> there, and no other types were mentioned besides FloatRep and DoubleRep
> (which were clearly mere uses of "bitfields"), so I assumed. Clearly I
> assumed wrong, big fucking deal. That's no reason to get all pissy about it.
>
>
>>>> while still failing to address major problems (concurrency,
>>>> immutability)
>>>> feels not?
>>>>
>>>
>>> I don't think anyone's suggesting that things like concurrency and
>>> immutability should fail to be addressed.
>>
>> Then stop extolling the virtues of an obscure feature.
>>
>
> Wow, cranky indeed.

Apology accepted :oD.

Andrei
March 24, 2010
On 25/03/10 07:22, Andrei Alexandrescu wrote:
> On 03/24/2010 12:57 PM, Nick Sabalausky wrote:
>> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org> wrote in message
>> news:hod5o3$1nhg$1@digitalmars.com...
>>> On 03/24/2010 08:28 AM, bearophile wrote:
>>>> As
>>>> they say: "Those who cannot learn from C# are doomed to re-invent it,
>>>> often badly."
>>>
>>> Who are "they"?
>>>
>>
>> He was modifying the common expression "Those who don't learn from the
>> past
>> are doomed to repeat it."
>
> But paraphrasing ain't "as they say" because they don't say that.
> Besides, I thought he's paraphrasing "Any sufficiently complicated C or
> Fortran program contains a buggy implementation of Common Lisp." But I
> guess that's just me being cranky - I'm sick.
>

"those who do not understand unix are doomed to reinvent it, poorly."

March 25, 2010
"yigal chripun" <yigal100@gmail.com> wrote in message news:hodruh$aif$1@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> "yigal chripun" <yigal100@gmail.com> wrote in message news:hobg4b$12ej$1@digitalmars.com...
>> >
>> > This also interacts with the crude hack of "this enum is actually a
>> > constant".
>> > if you remove the implicit casts than how would you be able to do:
>> > void foo(int p);
>> > enum { bar = 4 }; // don't remember the exact syntax here
>> > foo(bar); // compile-error?!
>> >
>>
>> AIUI, That style enum is already considered different by the compiler
>> anyway. Specifically, it's doesn't create any new type, whereas the other
>> type of enum creates a new semi-weak type. I don't think it would be too
>> big
>> of a step to go one step further and change "this kind of enum creates a
>> new
>> semi-weak type" to "this kind of enum creates a new strong type". But
>> yea, I
>> absolutely agree that calling a manifest constant an "enum" is absurd. It
>> still bugs the hell out of me even today, but I've largely shut up about
>> it
>> since Walter hasn't wanted to change it even though he seems to be the
>> only
>> one who doesn't feel it's a bad idea (and it's not like it causes
>> practical
>> problems when actually using the language...although I'm sure it must be
>> a
>> big WTF for new and prospective D users).
>>
>>
>> > I feel that enum needs to be re-designed. I think that C style "enums
>> > are
>> > numbers" are *bad*, *wrong* designs that expose internal implementation
>> > and the only valid design is that of Java 5.
>> >
>> > e.g.
>> > enum Color {blue, green}
>> > Color c = Color.blue;
>> > c++; // WTF?  should NOT compile
>> >
>> > A C style enum with values assigned is *not* an enumeration but rather
>> > a
>> > set of meaningful integral values and should be represented as such.
>> >
>> > This was brought up many many times in the NG before and based on past occurences will most likely never change.
>>
>> I would hate to see enums lose the concept of *having* a base type and
>> base
>> values because I do find that to be extremely useful (Haxe's enums don't
>> have a base type and, from direct experience with them, I've found that
>> to
>> be a PITA too). But I feel very strongly that conversions both to and
>> from
>> the base type need to be explicit. In fact, that was one of the things
>> that
>> was bugging me about C/C++ even before I came across D. D improves the
>> situation of course, but it's still only half-way.
>>
>>
>>
>
> Regarding the base type notion, I re-phrased my inccurate saying above in
> a reply to my post. I don't agree that enums should have a base type,
> enums should be distinct storng types.
> The numeric value should be a *property* of an enum member and not define
> its identity.
> Which is how it works in Java 5 where each each member is a singelton
> class.
>
> you should never do:
> void foo(int);
> foo(MyEnum.Bar); // this is bad design
> instead do:
> foo(MyEnum.Bar.value); // value is a regular property.
>
> This is also more flexible, since you could do things like:
> // assume I defined a Color enum
> foo(Color.Red.ordinal);
> bar(Color.Red.rgb);
>
> where foo belongs to an API that defines a a list of colors (red is 5)and bar belongs to a different API that uses the rgb value (red is 0xff0000)
>
> how would you do that with a C style enum?
>

I see what you mean. Personally I don't care if it's handled as a property or as an underlying type that can only be obtained via an explicit cast, as long as you never get the "associated" value implicitly.



March 25, 2010
Nick Sabalausky wrote:
>> In D1, is there any reason I should be getting an error on this?:
>>
>> // module A:
>> enum FooA { fooA };
>> void bar(FooA x) {}
>>
>> // module B:
>> import A;
>> enum FooB { fooB };
>> void bar(FooB x) {}
>>
>> bar(FooB.fooB); // Error: A.bar conflicts with B.bar (WTF?)

------- a.d -------------------
enum FooA { fooA };
void bar(FooA x) {}
------- test.d ----------------
import a;
enum FooB { fooB };
void bar(FooB x) {}

void test()
{
    bar(FooB.fooB);
}
------------------------------

with:

   dmd test

I do not get an error with either D1 or D2. So, if you are getting an error, how is your code different?
March 25, 2010
Nick Sabalausky wrote:
> Custom bitfields are extremely useful for low-level code. Being a self-proclaimed "systems" language, there's no reason D should consider such a thing to be of "narrow-usefulness".

I've written a lot of low-level code, I even programmed Mattel Intellivision cartridges and one of those old 70's hand-held LED games (Mattel Soccer). I've done a lot of embedded 6800 microprocessor work, device drivers, graphics drivers, etc. I've done a lot of bit twiddling code.

But I find C bit fields to be generally worthless.

One reason is the standard requires them to be right justified after extraction. This kills performance. I muck with with them in-place using biased arithmetic.
March 25, 2010
Nick Sabalausky wrote:
> To put it simply, I agree with this even on mere principle. I'm convinced that the current D behavior is a blatant violation of strong-typing and smacks way too much of C's so-called "type system".

You're certainly not the first to feel this way about implicit conversions. Niklaus Wirth did the same, and designed Pascal with no implicit conversions. You had to do an explicit cast each time.

Man, what a royal pain in the ass that makes coding in Pascal. Straightforward coding, like converting a string of digits to an integer, becomes a mess of casts. Even worse, casts are a blunt instrument that *destroys* type checking (that wasn't so much of a problem with Pascal with its stone age abstract types, but it would be killer for D).

Implicit integral conversions are not without problems, but when I found C I threw Pascal under the nearest bus and never wrote a line in it again. The taste was so bad, I refused to even look at Modula II and its failed successors.

D has 12 integral types. Disabling implicit integral conversions would make it unbearable to use.
March 25, 2010
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hoepts$2a98$1@digitalmars.com...
> Nick Sabalausky wrote:
>> Custom bitfields are extremely useful for low-level code. Being a self-proclaimed "systems" language, there's no reason D should consider such a thing to be of "narrow-usefulness".
>
> I've written a lot of low-level code, I even programmed Mattel Intellivision cartridges and one of those old 70's hand-held LED games (Mattel Soccer). I've done a lot of embedded 6800 microprocessor work, device drivers, graphics drivers, etc. I've done a lot of bit twiddling code.
>
> But I find C bit fields to be generally worthless.
>
> One reason is the standard requires them to be right justified after extraction. This kills performance. I muck with with them in-place using biased arithmetic.

Actually, with "bitfields", I've been mostly referring to pretty much just that: doing manual bit-twiddling, typically aided by manifest constants and/or enums, and taking the stance that doing that could use a better (ie, more abstracted and more type-safe) interface (while still keeping the same under-the-hood behavior).

Maybe it's all the low-level stuff I've done, but any time I come across the term "bitfield" I instinctively envision those abstract rows of labeled "bit" squares (or differently-sized rectangles) that you see in spec sheets for digital hardware (ie, the abstract concept of a small piece of memory having bit-aligned data), rather than specifically the structs-with-sub-byte-member-alignment that I keep forgetting C has. I can't really comment on that latter kind as I've never really used them (can't remember why not), although I can easily believe that they may be insufficient for the job. Maybe that difference is where the disagreement between me and Andrei arose.


March 25, 2010
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hoeukp$2kgv$1@digitalmars.com...
> Nick Sabalausky wrote:
>> To put it simply, I agree with this even on mere principle. I'm convinced that the current D behavior is a blatant violation of strong-typing and smacks way too much of C's so-called "type system".
>
> You're certainly not the first to feel this way about implicit conversions. Niklaus Wirth did the same, and designed Pascal with no implicit conversions. You had to do an explicit cast each time.
>
> Man, what a royal pain in the ass that makes coding in Pascal. Straightforward coding, like converting a string of digits to an integer, becomes a mess of casts. Even worse, casts are a blunt instrument that *destroys* type checking (that wasn't so much of a problem with Pascal with its stone age abstract types, but it would be killer for D).
>
> Implicit integral conversions are not without problems, but when I found C I threw Pascal under the nearest bus and never wrote a line in it again. The taste was so bad, I refused to even look at Modula II and its failed successors.
>
> D has 12 integral types. Disabling implicit integral conversions would make it unbearable to use.

Oh, I absolutely agree that implicit conversions are good in certain cases. I was only referring to implicit conversions between enums and the enum's base type (regardless of direction).


March 25, 2010
Walter Bright Wrote:

> Nick Sabalausky wrote:
> > To put it simply, I agree with this even on mere principle. I'm convinced that the current D behavior is a blatant violation of strong-typing and smacks way too much of C's so-called "type system".
> 
> You're certainly not the first to feel this way about implicit conversions. Niklaus Wirth did the same, and designed Pascal with no implicit conversions. You had to do an explicit cast each time.
> 
> Man, what a royal pain in the ass that makes coding in Pascal. Straightforward coding, like converting a string of digits to an integer, becomes a mess of casts. Even worse, casts are a blunt instrument that *destroys* type checking (that wasn't so much of a problem with Pascal with its stone age abstract types, but it would be killer for D).
> 
> Implicit integral conversions are not without problems, but when I found C I threw Pascal under the nearest bus and never wrote a line in it again. The taste was so bad, I refused to even look at Modula II and its failed successors.
> 
> D has 12 integral types. Disabling implicit integral conversions would make it unbearable to use.

here's a simple version without casts:
int toString(dchar[] arr) {
  int temp = 0;
  for (int i = 0; i < arr.length; i++) {
      int digit = arr[i].valueOf - 30; // *
      if (digit < 0 || digit > 9) break;
      temp += 10^^i * digit;
  }
  return temp;
}

[*] Assume that dchar has a valueOf property that returns the value.

where's that mess of casts you mention?
Pascal is hardly the only language without excplicit casts. ML is also properly strongly typed and is an awesome language to use.

The fact that D has 12 integral types is a bad design, why do we need so many built in types? to me this clearly shows a need to refactor this aspect of D.


March 25, 2010
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hoepeu$28po$1@digitalmars.com...
> Nick Sabalausky wrote:
>>> In D1, is there any reason I should be getting an error on this?:
>>>
>>> // module A:
>>> enum FooA { fooA };
>>> void bar(FooA x) {}
>>>
>>> // module B:
>>> import A;
>>> enum FooB { fooB };
>>> void bar(FooB x) {}
>>>
>>> bar(FooB.fooB); // Error: A.bar conflicts with B.bar (WTF?)
>
> ------- a.d -------------------
> enum FooA { fooA };
> void bar(FooA x) {}
> ------- test.d ----------------
> import a;
> enum FooB { fooB };
> void bar(FooB x) {}
>
> void test()
> {
>     bar(FooB.fooB);
> }
> ------------------------------
>
> with:
>
>    dmd test
>
> I do not get an error with either D1 or D2. So, if you are getting an error, how is your code different?

Hmm...That's odd...I guess I'll have to dig closer to see what's going on. The discussion on "D.learn" didn't seem to indicate that that above should work, so I hastily ruled out the possibility of something else going on in my code. It's too late for me to think stright ATM, so I'll have to check on that in the morning.