On 17/06/15 10:03, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com> wrote:

> Given the direction D2 has taken since D1, I'd say that I'm starting to
> agree with you that powerful symbolic programming would be the better
> deal overall.
>
> But it would take a major restructuring:
>
> 1. a simpler more orthogonal core language to cut down on the special
> casing when doing AST manipulations
>
> 2. a clean separation between library and application code (that way you
> can limit AST hacks to libraries tie library versions to language versions.
>
> So it won't happen… since you would then have essentially need a new
> language?

It will most likely not happen. Although, I guess you could just slap it on, but it would not be an ideal solution.

-- 
/Jacob Carlborg

On Thu, 18 Jun 2015 17:12:31 +0200, Timon Gehr wrote:

> On 06/18/2015 01:53 PM, ketmar wrote:
>> On Thu, 18 Jun 2015 01:44:08 +0000, Ola Fosheim Grøstad wrote:
>>
>>> On Wednesday, 17 June 2015 at 17:28:51 UTC, ketmar wrote:
>>>> and `version` isn't a constant. it's a version id. it even lives in it's own name space.
>>>
>>> For no gain whatsoever.
>>
>> and it can be removed for good if `static if` will be allowed at module level. one of Walter's nightmares, i suppose.
>>
>>
> static if is allowed at module level.

oops. i was so sure that i can't do that, so i don't even bother to check. my apologies.

"Walter Bright"  wrote in message news:mloslo$1o7v$1@digitalmars.com...

> I have yet to see a single case of "needing" boolean versions that could not be refactored into something much more readable and maintainable that did not use such.
>
> Over time, I've gotten rid of most of that stuff from the dmd source code, and the result has been quite pleasing.

Walter, how about a compromise?

If we allow setting versions to boolean expression then it becomes much easier to use it the way you suggest, while still requiring a (hopefully) sensible name and discouraging making a mess.

eg

version(A)
{
  version(B)
  {
  }
  else
  {
     version=NeedsSomeCode;
  }
}

becomes

version NeedsSomeCode = A && !B

An example from real code would be

version valistIsCharPointer = (Linux && LP32) || Windows;

This pattern does appear frequently in your compiler code, are you for or against seeing it in D? 

On Friday, 26 June 2015 at 06:06:09 UTC, Daniel Murphy wrote:
> Walter, how about a compromise?
>
> If we allow setting versions to boolean expression then it becomes much easier to use it the way you suggest, while still requiring a (hopefully) sensible name and discouraging making a mess.
>
> eg
>
> version(A)
> {
>   version(B)
>   {
>   }
>   else
>   {
>      version=NeedsSomeCode;
>   }
> }
>
> becomes
>
> version NeedsSomeCode = A && !B
>
> An example from real code would be
>
> version valistIsCharPointer = (Linux && LP32) || Windows;
>
> This pattern does appear frequently in your compiler code, are you for or against seeing it in D?

So you're trying to avoid writing this?

version(linux) version(D_LP32)
    version = valistIsCharPointer;
else version(Windows)
    version = valistIsCharPointer;

While your version is more concise, I actually think the current form is more clear.

On 6/25/2015 11:06 PM, Daniel Murphy wrote:
> This pattern does appear frequently in your compiler code, are you for or
> against seeing it in D?

Against. A lot of the compiler code is very, very old, and is not representative of modern thinking. I've also been pretty successful at removing that stuff from the front end, and as you know, have been working on the backend as well.

On 06/28/15 05:06, Joakim via Digitalmars-d wrote:
> On Friday, 26 June 2015 at 06:06:09 UTC, Daniel Murphy wrote:
>> Walter, how about a compromise?
>>
>> If we allow setting versions to boolean expression then it becomes much easier to use it the way you suggest, while still requiring a (hopefully) sensible name and discouraging making a mess.
>>
>> eg
>>
>> version(A)
>> {
>>   version(B)
>>   {
>>   }
>>   else
>>   {
>>      version=NeedsSomeCode;
>>   }
>> }
>>
>> becomes
>>
>> version NeedsSomeCode = A && !B
>>
>> An example from real code would be
>>
>> version valistIsCharPointer = (Linux && LP32) || Windows;
>>
>> This pattern does appear frequently in your compiler code, are you for or against seeing it in D?
> 
> So you're trying to avoid writing this?
> 
> version(linux) version(D_LP32)
>     version = valistIsCharPointer;
> else version(Windows)
>     version = valistIsCharPointer;
> 
> While your version is more concise, I actually think the current form is more clear.

And wrong. Spot the bug.

That's the real reason why 'version' needs to be banned from the codebase. You should *never* use D's 'version'.

artur

On Sunday, 28 June 2015 at 13:43:39 UTC, Artur Skawina wrote:
> On 06/28/15 05:06, Joakim via Digitalmars-d wrote:
>> So you're trying to avoid writing this?
>> 
>> version(linux) version(D_LP32)
>>     version = valistIsCharPointer;
>> else version(Windows)
>>     version = valistIsCharPointer;
>> 
>> While your version is more concise, I actually think the current form is more clear.
>
> And wrong. Spot the bug.

Eh, that idiom is not commonly used so I wasn't exactly clear on the syntax, but you're presumably referring to the need for braces?

version(linux)
{   version(D_LP32) version = valistIsCharPointer; }
else version(Windows)
    version = valistIsCharPointer;

I actually find this even more clear, the best of the bunch. :)

> That's the real reason why 'version' needs to be banned from the codebase. You should *never* use D's 'version'.

If you think it needs to be banned because of some non-obvious bracing syntax, you don't have much to stand on.

On Sun, 28 Jun 2015 00:10:28 -0400, Walter Bright
<newshound2@digitalmars.com> wrote:

> On 6/25/2015 11:06 PM, Daniel Murphy wrote:
>> This pattern does appear frequently in your compiler code, are you for or
>> against seeing it in D?
>
> Against. A lot of the compiler code is very, very old, and is not representative of modern thinking. I've also been pretty successful at removing that stuff from the front end, and as you know, have been working on the backend as well.

FWIW, I've thought through most of my use cases, and it seems I can do without this feature(both mine and Daniels suggestions). This is mainly because I've decided to write anything close to the system in C++. If/When the day comes that system APIs are written in D, this may change, but I don't see this happening in the foreseeable future. IMO, the D community's time would be better spent improving D/C++ interop than trying to make D a systems language. At a glance, I don't see a binding for OpenCV or FBX SDK, and although there are many bindings for OpenGL and such, I wouldn't feel safe relying on them to be up to date or complete. The lesser evil clearly seems to be writing some C++.

    Bit

On 6/29/2015 8:30 AM, bitwise wrote:
> FWIW, I've thought through most of my use cases, and it seems I can do without
> this feature(both mine and Daniels suggestions). This is mainly because I've
> decided to write anything close to the system in C++. If/When the day comes that
> system APIs are written in D, this may change, but I don't see this happening in
> the foreseeable future. IMO, the D community's time would be better spent
> improving D/C++ interop than trying to make D a systems language. At a glance, I
> don't see a binding for OpenCV or FBX SDK, and although there are many bindings
> for OpenGL and such, I wouldn't feel safe relying on them to be up to date or
> complete. The lesser evil clearly seems to be writing some C++.


I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either.

On Mon, 29 Jun 2015 22:30:50 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/29/2015 8:30 AM, bitwise wrote:
>> FWIW, I've thought through most of my use cases, and it seems I can do without
>> this feature(both mine and Daniels suggestions). This is mainly because I've
>> decided to write anything close to the system in C++. If/When the day comes that
>> system APIs are written in D, this may change, but I don't see this happening in
>> the foreseeable future. IMO, the D community's time would be better spent
>> improving D/C++ interop than trying to make D a systems language. At a glance, I
>> don't see a binding for OpenCV or FBX SDK, and although there are many bindings
>> for OpenGL and such, I wouldn't feel safe relying on them to be up to date or
>> complete. The lesser evil clearly seems to be writing some C++.
>
>
> I don't believe a macro processor is necessary to write systems code, nor do I believe version expressions are, either.

Was pretty sure I worded that wrong.

I'm willing to concede at this point that if I was writing some fresh new systems code, I could deal with the limitations of 'version', and that it does seem like good practice not to spam preprocessors/version everywhere, but for me, a big selling point of D is _not_ having to re-write/refactor/re-think my code.

From the point I picked up D, and having a strong background in C++, it just felt natural, and I was able to start programming with it immediately. I've been able to transfer over a lot of design-patterns/code with little to no effort.

Still though, I think that with the dominance of C++ for system APIs, it makes more sense right now to keep the interop layer as narrow as possible, and just access the system from C++. I can then create a small group of interfaces for accessing graphics/audio/etc..

So I guess this nullifies my original grievance. Sorry for nagging :)

  Bit