"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gossg8$2qj8$1@digitalmars.com...
> Michel Fortin wrote:
>> On 2009-03-06 14:35:59 -0500, Walter Bright <newshound1@digitalmars.com> said:
>>
>>> Andrei Alexandrescu wrote:
>>>> "Can't live without bitfields! Give me bitfields and I'll lift the Earth!"
>>>>
>>>> "Here they are, std.bitmanip. Well-defined and more portable and flexible than C's."
>>>>
>>>> "Meh, don't like the definition syntax."
>>>
>>> Classic.
>>
>> Well, he certainly has a point. Compare this:
>>
>>     mixin(bitfields!(
>>         uint, "x",    2,
>>         int,  "y",    3,
>>         uint, "z",    2,
>>         bool, "flag", 1));
>>
>> With this:
>>
>>     uint x : 2;
>>     int  y : 3;
>>     uint z : 2;
>>     bool flag : 1;
>>
>> The second is certainly prettier and more readable.
>
> (Just to clarify: to me the humor of the situation was that someone who considered bitfields an absolute prerequisite for language adoption subsequently found the syntax excuse to bail out. Essentially the hypothetical user was fabricating one pretext after another to rationalize their pre-made decision to not try D -- an absolute classic attitude when it comes about acquiring new programming languages.)
>

I have a different theory that's based on my own experience from other languages/software/products/brands/etc. that I've disliked in the past:

People come across a language (or anything else), see two or three things they really don't like, and think "Meh, not worth bothering to switch if I'd just be trading one set of complaints for another. I'll just stick with what I'm already using, but to be helpful, I'll point out the issues I have with it." If those issues were fixed at the time they said that, they probably would switch, but obviously it can't change instantaneously like that. So the things they disliked about it stick in their mind and leave them with a generally bad impression of the language (or product) for a few months or a couple years. Then, it finally gets fixed, but by that point they simply no longer care.

Basically, it's the old "first impression" thing with a few wrinkles.


> About the syntax itself - definitions are few and uses are many. In addition the D solution:
>
> (a) guarantees data layout;
>
> (b) offers symbolic limits, e.g. x_max and x_min are automatically added as enums;
>
> (c) checks for overflow, which is essential for small bitfields;
>
> (d) offers a way to manipulate the fields wholesale by using the concatenation of all their names, e.g. xyzflag;
>

These are all things that could be done with the old C-style syntax, provided it was built into the language. But of course, that strategy has it's own downsides, too.


> (e) suggests that there are other cool things that can be done within the language, not by adding features to it.
>
> Hopefully that makes up for the more loaded syntax.
>
>> Does it matter much? Not to me; I rarely use bit fields. If I were using them a lot, perhaps I'd be more concerned.
>
> I am using them here and there - even in Phobos - and they work very well.

Provided that they aren't as crappy as the ones in C, bitfields can be immensely useful for anything really low-level, like embedded systems, drivers, firmware, or packed data formats for network or file I/O (ie, "systems programming" stuff). Anything higher-level then that, though, and their usefulness certainly does seem to diminish.


>
>> While I don't care very much about bitfields, that "mixin(tmpl!(...))" syntax is awful. "mixin tmpl!(...)" is better, but has too many limitations, and it isn't always clear for the user which one should be used. Couldn't D2 get a better syntax for mixins?
>
> I agree it should.
>

That would certainly be very nice.

Nick Sabalausky wrote:
> Provided that they aren't as crappy as the ones in C, bitfields can be immensely useful for anything really low-level, like embedded systems, drivers, firmware, or packed data formats for network or file I/O (ie, "systems programming" stuff). Anything higher-level then that, though, and their usefulness certainly does seem to diminish.

I've written a lot of bit twiddling code. Bitfields are not immensely useful. They're at best a trivial convenience, and often result in poor code generation as compared with using bit masking operations.

Walter Bright wrote:
> 3. if Digital Mars vanishes in a puff of greasy black smoke, users depending on dmd are not left holding the bag
> 

Without redistribution rights, yes they are. All they can do is say "Anybody who was lucky enough to download DMD before Digital Mars exploded, you can apply these patches. Everybody else, too bad."

 - Gregor Richards

Nick Sabalausky wrote:
> "Jesse Phillips" <jessekphillips@gmail.com> wrote in message news:gosuaj$2qdu$1@digitalmars.com...
>> So it basically needs to be free in all senses of the word. I disagree
>> but many others seem to hold this view. I don't know why they don't just
>> call it "free software."
> 
> IIRC, Once upon a time, it was like that. "Open source" meant "source is available at no cost". "Free-as-in-freedom software" meant "A superset of 'open-source', plus other freedoms such as redistro." I think a lot of the people that got into the Linux/OSS/Slashdot/etc scenes in the last few years never actually learned the difference and thus go running around equating "open source" with GPL/zlib/BSD/etc.
> 
> 

Uhhhhh, no. The Open Source Definition, created by the Open Source Initiative which effectively created the term in 1998 (there was no real use of the term before then), requires redistribution, etc, and the term Open Source is trademarked. It's in violation of their trademark to use the term to describe anything that doesn't follow the definition, which is roughly equivalent to what FSF describes as Free Software (modulo a few quirks)

The reason that people equate the term with those particular licenses is because those particular licenses are approved by the OSI, so you can't possibly run into any troubles using the term referring to them. But software for which the source is readable but not redistributable is NOT Open Source.

 - Gregor Richards

I sort of hate to throw myself into the fray, especially since my studies have kept me more-or-less detached from D entirely, but ...

I realize people are going to misuse the term Open Source. However, the term is NOT generic, and DOES have a specific meaning; it is in fact trademarked, and using it to describe software that does not fit the Open Source Definition is in violation of the trademark. But more importantly than that, it's confusing to the loads of people out here who use F/OSS and depend on the freedoms it provides. Without redistribution rights, F/OSS is substantially less valuable, as it doesn't provide any escape if the original creator loses interest, spontaneously combusts, decides he hates giving away his source and closes it again, etc, etc, etc.

I understand that the reason the redistribution license isn't fully Open Source is for quirkly legal reasons with Walter's license of it, and so it's not really anybody's fault. I'm not trying to put any blame anywhere for that part.

My only request is that people (or at least Walter) don't describe it using the term "Open Source". It's confusing, it's wrong, and it dilutes a perfectly meaningful term. Use "source available", "source included", "non-redistributable source provided", I don't care, just not the term with loaded additional meaning.

 - Gregor Richards

PS: Yes, I realize that there's nothing in the words "open" and "source" that suggest all the other stuff. Welcome to English.

Gregor Richards wrote:
> My only request is that people (or at least Walter) don't describe it using the term "Open Source". It's confusing, it's wrong, and it dilutes a perfectly meaningful term. Use "source available", "source included", "non-redistributable source provided", I don't care, just not the term with loaded additional meaning.

You're right. I didn't call it open source in the changelog for that reason, and the reason this thread is titled the way it is is because of the thread title on reddit. But I still shouldn't have titled this thread that way.

Andrei Alexandrescu wrote:
> Michel Fortin wrote:
>> On 2009-03-06 14:35:59 -0500, Walter Bright <newshound1@digitalmars.com> said:
>>
>>> Andrei Alexandrescu wrote:
>>>> "Can't live without bitfields! Give me bitfields and I'll lift the Earth!"
>>>>
>>>> "Here they are, std.bitmanip. Well-defined and more portable and flexible than C's."
>>>>
>>>> "Meh, don't like the definition syntax."
>>>
>>> Classic.
>>
>> Well, he certainly has a point. Compare this:
>>
>>     mixin(bitfields!(
>>         uint, "x",    2,
>>         int,  "y",    3,
>>         uint, "z",    2,
>>         bool, "flag", 1));
>>
>> With this:
>>
>>     uint x : 2;
>>     int  y : 3;
>>     uint z : 2;
>>     bool flag : 1;
>>
>> The second is certainly prettier and more readable.
> 
> (Just to clarify: to me the humor of the situation was that someone who considered bitfields an absolute prerequisite for language adoption subsequently found the syntax excuse to bail out. Essentially the hypothetical user was fabricating one pretext after another to rationalize their pre-made decision to not try D -- an absolute classic attitude when it comes about acquiring new programming languages.)
> 
> About the syntax itself - definitions are few and uses are many. In addition the D solution:
> 
> (a) guarantees data layout;
> 
> (b) offers symbolic limits, e.g. x_max and x_min are automatically added as enums;
> 
> (c) checks for overflow, which is essential for small bitfields;
> 
> (d) offers a way to manipulate the fields wholesale by using the concatenation of all their names, e.g. xyzflag;
> 
> (e) suggests that there are other cool things that can be done within the language, not by adding features to it.
> 
> Hopefully that makes up for the more loaded syntax.
> 
>> Does it matter much? Not to me; I rarely use bit fields. If I were using them a lot, perhaps I'd be more concerned.
> 
> I am using them here and there - even in Phobos - and they work very well.
> 
>> While I don't care very much about bitfields, that "mixin(tmpl!(...))" syntax is awful. "mixin tmpl!(...)" is better, but has too many limitations, and it isn't always clear for the user which one should be used. Couldn't D2 get a better syntax for mixins?
> 
> I agree it should.
> 
> 
> Andrei
I'm glad that they're there.  And I'm glad that they work.  But I really hate the syntax, and am glad I've never needed to use them.  MUCH better would have been:
mixin(bitfields!("
     uint, x,    2,
     int,  y,    3,
     uint, z,    2,
     bool, flag, 1
     ")

even better would have been:
mixin(bitfields!("
     uint x :  2,
     int  y :  3,
     uint z :  2,
     bool flag : 1
     ")

The bitfield battle isn't one I'm involved with, and I rarely comment on syntax...but this is, to my mind, a much nicer syntax.  Moving the quote marks to a pre-existing boundary location and removing them internally is a large gain.  There is a small further gain in specifying the bit-field as a type-name : length string.  The colon is a slightly better delimiter to use here than the comma, as the comma is being used as the separator between individual bit field specifications.  A further gain is that it's more similar to a form already known by many people.

I'm not a compiler writer, so I don't know if this would have been difficult.  I just know that looking at it *I* find it much more readable.  Another step might have been to allow the entire string to end with a comma, thus:
mixin(bitfields!("
     uint x :  2,
     int  y :  3,
     uint z :  2,
     bool flag : 1,
     ")
so that it would be easier to shuffle the fields during development. This has it's pluses and minuses, but by and large I think it's optional presence would be a benefit.

Walter Bright wrote:
> Nick Sabalausky wrote:
>> Provided that they aren't as crappy as the ones in C, bitfields can be immensely useful for anything really low-level, like embedded systems, drivers, firmware, or packed data formats for network or file I/O (ie, "systems programming" stuff). Anything higher-level then that, though, and their usefulness certainly does seem to diminish.
> 
> I've written a lot of bit twiddling code. Bitfields are not immensely useful. They're at best a trivial convenience, and often result in poor code generation as compared with using bit masking operations.

Bit fields are much less useful than they once were...because there's less need to pack storage tightly.  The times I've really wanted to use named bit fields was when I was packing numbers into a word for export (usually to disk), or reading conversely.  They were, indeed, only a convenience...but they were a significant convenience.  I suppose that such occasions still arise when one is interacting with foreign code.

But I don't like the syntax that D choose for this feature.  (See my suggestions earlier in this thread as to what I would consider an improvement.)

I'm much more interested in the general comments about what constitutes good syntax than in the specific commentary around bitfields.

Perhaps there just *ISN'T* a good way to do templates & mixins.  The syntaxes that I have encountered previously, including D's, have caused me to avoid all but the simplest cases of using them.  I admit that they appear quite powerful (not really using them I can't say more than that), but they're UGLY.  Well, habituation can change ones aesthetic sense, so that's not really objective.  They look ugly to me at the present time, as they have for the past year.

An additional problem is that generics are crippled when one of the basic types is desired as a parameter.  Say you want a tree with keys sorted by uint.  It should be possible to just write a generic sorted tree and specify the key.  But Objects and ints have incompatible comparison mechanisms.  The obvious fix to this would be to have the basic types all respond to, e.g., opCmp.  Apparently, however, this would have significant costs.  But the lack of this kind of mechanism renders templates significantly less useful to me than they would otherwise be.

As always, these are relatively trivial problems.  The major problem is the lack of libraries, and there doesn't seem to be any way around that except time.  But the division between tango and phobos isn't making solving that any easier.  (I'm afraid that I can't bring myself to trust tangobos.  It always seems to be mentioned with a "you can use this until you really convert to tango" kind of comment.)

Charles Hixson wrote:
> mixin(bitfields!("
>      uint x :  2,
>      int  y :  3,
>      uint z :  2,
>      bool flag : 1,
>      ")
> so that it would be easier to shuffle the fields during development. This has it's pluses and minuses, but by and large I think it's optional presence would be a benefit.

That's a pretty neat idea. It's not difficult to implement, and it could possibly placate a few naysayers. And it's not ambiguous with the existing syntax either, so at least for a while both might be supported.

One improvement from the language could come from dropping the parens requirement for mixin, in which case:

 mixin bitfields!"
      uint x :  2,
      int  y :  3,
      uint z :  2,
      bool flag : 1,
      ";


Andrei

Charles Hixson wrote:
> Walter Bright wrote:
>> I've written a lot of bit twiddling code. Bitfields are not immensely useful. They're at best a trivial convenience, and often result in poor code generation as compared with using bit masking operations.
> 
> Bit fields are much less useful than they once were...because there's less need to pack storage tightly.  The times I've really wanted to use named bit fields was when I was packing numbers into a word for export (usually to disk), or reading conversely.  They were, indeed, only a convenience...but they were a significant convenience.  I suppose that such occasions still arise when one is interacting with foreign code.

I think bitfields are very useful on today's architectures, where memory bandwidth is scarce and processor ops (masking etc.) are virtually free. Whenever I have a struct that I pass around by value in speed-sensitive code, I use bitfields if applicable.

> But I don't like the syntax that D choose for this feature.  (See my suggestions earlier in this thread as to what I would consider an improvement.)
> 
> I'm much more interested in the general comments about what constitutes good syntax than in the specific commentary around bitfields.
> 
> Perhaps there just *ISN'T* a good way to do templates & mixins.  The syntaxes that I have encountered previously, including D's, have caused me to avoid all but the simplest cases of using them.  I admit that they appear quite powerful (not really using them I can't say more than that), but they're UGLY.  Well, habituation can change ones aesthetic sense, so that's not really objective.  They look ugly to me at the present time, as they have for the past year.
> 
> An additional problem is that generics are crippled when one of the basic types is desired as a parameter.  Say you want a tree with keys sorted by uint.  It should be possible to just write a generic sorted tree and specify the key.  But Objects and ints have incompatible comparison mechanisms.  The obvious fix to this would be to have the basic types all respond to, e.g., opCmp.  Apparently, however, this would have significant costs.  But the lack of this kind of mechanism renders templates significantly less useful to me than they would otherwise be.

What happened to a < b? I don't quite get it.

Andrei