Michel Fortin escribió:
> 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.
> 
> 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.
> 
> 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?

Well, now the \ is character if free:

\bitfields(
  unit, "x", 2,
  int, "y", 3,
  uint, "z", 2,
  bool, "flag", 1,
);

But I think it looks ugly: the \ is "lambda" in some languages and this also reminds me of LaTeX... :-P

Ary Borenszweig wrote:
> Michel Fortin escribió:
>> 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.
>>
>> 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.
>>
>> 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?
> 
> Well, now the \ is character if free:
> 
> \bitfields(
>   unit, "x", 2,
>   int, "y", 3,
>   uint, "z", 2,
>   bool, "flag", 1,
> );
> 
> But I think it looks ugly: the \ is "lambda" in some languages and this also reminds me of LaTeX... :-P

String mixins are awful in the first place. The only thing that could save this kind of thing are AST macros.

Georg Wrede wrote:
> 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."
> 
> 
> Now, now. There. Don't cry.  ;-)
> 
> They might be an unglamorous part of D, and seldom used, but for the guy who ends up needing bitfields, they're a godsend!
> 
> Like a can opener. You can live weeks without needing one, but when you've got a can, it's not nice to open it with the kitchen knife.

Creating a can opener on your own is not as trivial as re-implementing bitfields.

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

grauzone wrote:
> Georg Wrede wrote:
>> Like a can opener. You can live weeks without needing one, but when you've got a can, it's not nice to open it with the kitchen knife.
> 
> Creating a can opener on your own is not as trivial as re-implementing bitfields.


Using a table knife as a chisel should do the job. A kitchen knife is probably too thin and brittle.

On Thu, 05 Mar 2009 23:25:04 +0100, grauzone wrote:

> hasen wrote:
>> Walter Bright wrote:
>>> http://www.reddit.com/r/programming/comments/82ck4/
digitalmars_d_now_open_source/
>>>
>>>
>>> http://www.reddit.com/r/programming/comments/82cgp/
new_release_of_the_d_programming_language_now/
>>>
>>>
>> Wow there's a big fuss over there about it not being /really/ open source,
> 
> To us, this doesn't really matter. The important thing is that we can build the compiler itself, and can debug it if it craps up (which happens often, sorry Walter). For example, now we might be able to find out on which piece of code exactly it segfaults when compiling. Oh, and remember the libc issues. Now users affected by this problem can compile their own binary.
> 
> When we want a completely free compiler for ideological reasons or for unrestricted redistribution, there's still LDC. LDC connects the free (GPL'ed) frontend with the free LLVM backend.
> 
> Also, I thought open source != free software.
> 
>> Can you explain (to the ignorant likes of me) what is constraining you
>> from changing the license?

Open Source = Free really has to do with how you define open source. And the definition that most OSS advocates use can be found on wikipedia

http://en.wikipedia.org/wiki/Open_Source_Definition

"1. Free Redistribution

    The license shall not restrict any party from selling or giving away
the software as a component of an aggregate software distribution
containing programs from several different sources. The license shall not
require a royalty or other fee for such sale.

2. Source Code

    The program must include source code, and must allow distribution in
source code as well as compiled form. Where some form of a product is not
distributed with source code, there must be a well-publicized means of
obtaining the source code for no more than a reasonable reproduction cost
preferably, downloading via the Internet without charge. The source code
must be the preferred form in which a programmer would modify the
program. Deliberately obfuscated source code is not allowed. Intermediate
forms such as the output of a preprocessor or translator are not allowed.
"

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."

== Quote from grauzone (none@example.net)'s article
> Ary Borenszweig wrote:
> > Michel Fortin escribió:
> >> 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.
> >>
> >> 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.
> >>
> >> 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?
> >
> > Well, now the \ is character if free:
> >
> > \bitfields(
> >   unit, "x", 2,
> >   int, "y", 3,
> >   uint, "z", 2,
> >   bool, "flag", 1,
> > );
> >
> > But I think it looks ugly: the \ is "lambda" in some languages and this also reminds me of LaTeX... :-P
> String mixins are awful in the first place. The only thing that could save this kind of thing are AST macros.

????????????? String mixins are an absolute godsend.  I mean really, how much more general a metaprogramming facility could you possibly ask for than the ability to generate arbitrary D code at compile time?  Of course they can get ugly, so there should be better ways to do things that are done frequently (regular templates accomplish this), but last I checked, bit fields are not an everyday run-of-the-mill programming type of feature.

As a more general comment, of course syntax and readability count for frequently used features, but there's only so much pretty syntax available, and simplicity of the core language is a virtue.  If certain things in D are going to have ugly syntax, they may as well be niche features like bit fields.

"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.

Georg Wrede wrote:
> Denis Koroskin wrote:
>> On Fri, 06 Mar 2009 08:51:57 +0300, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>> [snip]
>>> The ones I listen to are the ones who *are* using D and have some sweat equity in it.
>>
>> http://www.micropoll.com/akira/mpresult/539369-138652
> 
> Bipolar folks the Americans. All of the states are either 100% for or against...

Don't forget arrogant. They don't care what the rest of the world thinks, which is why the map only shows the US ;).
(My vote isn't on there...)

"dsimcha" <dsimcha@yahoo.com> wrote in message news:got0ff$28r4$1@digitalmars.com...
> == Quote from grauzone (none@example.net)'s article
>>
>> String mixins are awful in the first place. The only thing that could save this kind of thing are AST macros.

Both Murphey's law and the law of D bitfields dictate that we're all going to end up hating AST macros when they finally show up ;)

>
> ????????????? String mixins are an absolute godsend.  I mean really, how
> much more
> general a metaprogramming facility could you possibly ask for than the
> ability to
> generate arbitrary D code at compile time?  Of course they can get ugly,
> so there
> should be better ways to do things that are done frequently (regular
> templates
> accomplish this), but last I checked, bit fields are not an everyday
> run-of-the-mill programming type of feature.
>
> As a more general comment, of course syntax and readability count for
> frequently
> used features, but there's only so much pretty syntax available, and
> simplicity of
> the core language is a virtue.  If certain things in D are going to have
> ugly
> syntax, they may as well be niche features like bit fields.

My thought is that it's absolutely great to have string mixins, but they should never be thought of as anything more than a clumbsy substitute (athough notably less clumbsy than a preprocessor macro) for a real language feature to accomplish the same task (or possibly an AST macro).