www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - remove keywords

reply mandel <oh no.es> writes:
A proposal in a nutshell:

- removal of the keywords "unittest, "version" and similar.

- replaced by global compile time variables.

- "dmd -<name>=<value>" to set them. Variables not found result in 
compiler warnings

- "dmd -list version*" or similar to list all global variable names with 
prefix "version"

-> less keywords, more powerfull control (use in boolean expressions), 
more native syntax, easier to understand

Ideas? Problems? Objections?

btw.:
bool enableXYZ;

if(enableXFZ) import foo.Bar;

..might be hairy to implement?
Dec 07 2007
next sibling parent reply Denton Cockburn <diboss hotmail.com> writes:
On Fri, 07 Dec 2007 08:55:45 +0000, mandel wrote:


 A proposal in a nutshell:
 
 - removal of the keywords "unittest, "version" and similar.
 
 - replaced by global compile time variables.
 
 - "dmd -<name>=<value>" to set them. Variables not found result in
 compiler warnings
 
 - "dmd -list version*" or similar to list all global variable names with
 prefix "version"
 
 -> less keywords, more powerfull control (use in boolean expressions),
 more native syntax, easier to understand
 
 Ideas? Problems? Objections?
 
 btw.:
 bool enableXYZ;
 
 if(enableXFZ) import foo.Bar;
 
 ..might be hairy to implement?


seems like a rather big change.
Do you really have a big problem with the current method? or you just 
think this is better?

I'd rather forgo a big change if the current method isn't painful (it's 
not).
Dec 07 2007
parent reply mandel <oh no.es> writes:
Yes, it would be a big change.
But the code changes would be trivial imho.

I just think it's better (consinstent) to do it this way for the 
mentioned reasons.
For example, one of the motivations was:

if(bar)
{
  version(Foo)
  {
     /**/
  }
}

I would rather like to write:

if(bar && Foo)
{
  /**/
}

There are workarounds, but none of them is as nice as the native/proposed 
solution above.

On Fri, 07 Dec 2007 09:16:02 +0000, Denton Cockburn wrote:


 On Fri, 07 Dec 2007 08:55:45 +0000, mandel wrote:


[..]


 seems like a rather big change.
 Do you really have a big problem with the current method? or you just
 think this is better?
 
 I'd rather forgo a big change if the current method isn't painful (it's
 not).
Dec 07 2007
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On Dec 7, 2007 9:45 AM, mandel <oh no.es> wrote:

 if(bar && Foo)


presumably you mean

    static if (bar && foo)
Dec 07 2007
parent mandel <oh no.es> writes:
On Fri, 07 Dec 2007 10:40:01 +0000, Janice Caron wrote:


 On Dec 7, 2007 9:45 AM, mandel <oh no.es> wrote:

 if(bar && Foo)


 
 presumably you mean
 
     static if (bar && foo)


right. :)
Dec 07 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
mandel wrote:

 For example, one of the motivations was:
 
 if(bar)
 {
   version(Foo)
   {
      /**/
   }
 }
 
 I would rather like to write:
 
 if(bar && Foo)
 {
   /**/
 }


The version statement is limited in that you cannot do !foo or 
foo&&bar||baz. Rather than a bug, that is deliberate. I've seen a lot of 
code that, over the years, accumulated detritus like:

     #if FOO || BAR>0x1234 && BAZ && !HACK

These tend to snarl themselves into such a rat's nest of conditionals 
the only way to figure out which lines actually got compiled was to 
examine the preprocessor output. (Another consequence of these is that, 
inevitably, the various conditionals were WRONG as they were layered on 
by people who didn't really understand the code.)

So, by limiting the version statement, the idea is to encourage the 
programmer to think in terms of distinct versions being generated, and 
then code in terms of those distinct versions - each of those versions 
having a name.
Dec 07 2007
next sibling parent mandel <oh no.es> writes:
On Fri, 07 Dec 2007 02:47:36 -0800, Walter Bright wrote:

 The version statement is limited in that you cannot do !foo or
 foo&&bar||baz. Rather than a bug, that is deliberate. I've seen a lot of
 code that, over the years, accumulated detritus like:
 
      #if FOO || BAR>0x1234 && BAZ && !HACK
 
 These tend to snarl themselves into such a rat's nest of conditionals
 the only way to figure out which lines actually got compiled was to
 examine the preprocessor output. (Another consequence of these is that,
 inevitably, the various conditionals were WRONG as they were layered on
 by people who didn't really understand the code.)
 
 So, by limiting the version statement, the idea is to encourage the
 programmer to think in terms of distinct versions being generated, and
 then code in terms of those distinct versions - each of those versions
 having a name.


I'am aware of that problem and understand the design decision.
Still, I can't get rid of the desire to give more power to the programmer
by simplifying stuff. :>
But I can code with the way it is.
Dec 07 2007
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fjb8c6$2nqs$1 digitalmars.com...

 The version statement is limited in that you cannot do !foo or 
 foo&&bar||baz. Rather than a bug, that is deliberate. I've seen a lot of 
 code that, over the years, accumulated detritus like:

     #if FOO || BAR>0x1234 && BAZ && !HACK

 These tend to snarl themselves into such a rat's nest of conditionals the 
 only way to figure out which lines actually got compiled was to examine 
 the preprocessor output. (Another consequence of these is that, 
 inevitably, the various conditionals were WRONG as they were layered on by 
 people who didn't really understand the code.)

 So, by limiting the version statement, the idea is to encourage the 
 programmer to think in terms of distinct versions being generated, and 
 then code in terms of those distinct versions - each of those versions 
 having a name.


You tell me which is more readable:

version(linux || darwin || bsd)
    version = UseDlfcn;
else
    version = UseDLLs;

vs.

version(linux)
    version = UseDlfcn;
else version(darwin)
    version = UseDlfcn;
else version(bsd)
    version = UseDlfcn;
else
    version = UseDLLs;

It only gets worse when you actually *need* complex versioning, and when the 
contents of those version blocks become more than trivial.  Yes, you can 
define intermediate versions like I've done here, but even that becomes 
tedious and hard to read.
Dec 07 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Jarrett Billingsley wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fjb8c6$2nqs$1 digitalmars.com...

 The version statement is limited in that you cannot do !foo or 
 foo&&bar||baz. Rather than a bug, that is deliberate. I've seen a lot of 
 code that, over the years, accumulated detritus like:

     #if FOO || BAR>0x1234 && BAZ && !HACK

 These tend to snarl themselves into such a rat's nest of conditionals the 
 only way to figure out which lines actually got compiled was to examine 
 the preprocessor output. (Another consequence of these is that, 
 inevitably, the various conditionals were WRONG as they were layered on by 
 people who didn't really understand the code.)

 So, by limiting the version statement, the idea is to encourage the 
 programmer to think in terms of distinct versions being generated, and 
 then code in terms of those distinct versions - each of those versions 
 having a name.


 
 You tell me which is more readable:
 
 version(linux || darwin || bsd)
     version = UseDlfcn;
 else
     version = UseDLLs;
 
 vs.
 
 version(linux)
     version = UseDlfcn;
 else version(darwin)
     version = UseDlfcn;
 else version(bsd)
     version = UseDlfcn;
 else
     version = UseDLLs;
 
 It only gets worse when you actually *need* complex versioning, and when the 
 contents of those version blocks become more than trivial.  Yes, you can 
 define intermediate versions like I've done here, but even that becomes 
 tedious and hard to read. 


There's always static if.


Sean
Dec 07 2007
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Jarrett Billingsley" wrote

 You tell me which is more readable:

 version(linux || darwin || bsd)
    version = UseDlfcn;
 else
    version = UseDLLs;

 vs.

 version(linux)
    version = UseDlfcn;
 else version(darwin)
    version = UseDlfcn;
 else version(bsd)
    version = UseDlfcn;
 else
    version = UseDLLs;


First one is more readable.

I think maybe the version syntax could be expanded to mean 'or' with commas.
i.e.

version(linux, darwin, bsd)

And forget any other logic syntax (ands, less than, etc).  I believe the 
current method does a good job of preventing convoluted version statements, 
but I think the 'or' is a very common requirement, and does not detract from 
the readability.

-Steve
Dec 07 2007
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 You tell me which is more readable:
 
 version(linux || darwin || bsd)
     version = UseDlfcn;
 else
     version = UseDLLs;
 
 vs.
 
 version(linux)
     version = UseDlfcn;
 else version(darwin)
     version = UseDlfcn;
 else version(bsd)
     version = UseDlfcn;
 else
     version = UseDLLs;


I'm going to say the latter is more readable, especially when under each 
os there are a series of version declarations. The former approach is 
used by, for example, the Hans Boehm garbage collector, and I have found 
it very difficult to follow.



 It only gets worse when you actually *need* complex versioning, and when the 
 contents of those version blocks become more than trivial.  Yes, you can 
 define intermediate versions like I've done here, but even that becomes 
 tedious and hard to read. 


When the versioning becomes complex, there are alternative ways of 
managing it. One way that works well is to factor out version 
differences into version specific modules, with a general purpose api to 
those modules. Yes, this is more work, but when I've done it the results 
have been well worthwhile.
Dec 07 2007
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Jarrett Billingsley wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:fjb8c6$2nqs$1 digitalmars.com...

 The version statement is limited in that you cannot do !foo or 
 foo&&bar||baz. Rather than a bug, that is deliberate. I've seen a lot of 
 code that, over the years, accumulated detritus like:

     #if FOO || BAR>0x1234 && BAZ && !HACK

 These tend to snarl themselves into such a rat's nest of conditionals the 
 only way to figure out which lines actually got compiled was to examine 
 the preprocessor output. (Another consequence of these is that, 
 inevitably, the various conditionals were WRONG as they were layered on by 
 people who didn't really understand the code.)

 So, by limiting the version statement, the idea is to encourage the 
 programmer to think in terms of distinct versions being generated, and 
 then code in terms of those distinct versions - each of those versions 
 having a name.


 
 You tell me which is more readable:
 
 version(linux || darwin || bsd)
     version = UseDlfcn;
 else
     version = UseDLLs;
 
 vs.
 
 version(linux)
     version = UseDlfcn;
 else version(darwin)
     version = UseDlfcn;
 else version(bsd)
     version = UseDlfcn;
 else
     version = UseDLLs;
 
 It only gets worse when you actually *need* complex versioning, and when the 
 contents of those version blocks become more than trivial.  Yes, you can 
 define intermediate versions like I've done here, but even that becomes 
 tedious and hard to read. 


I've dealt with production code -- a mere 5k line project -- that was 
ported manually to four operating systems (Linux, HPUX, Darwin, and I 
think FreeBSD). My task was to convert it to use autotools.

Ugly. Horrible. Terrible. I wanted to find the coders and shoot them.

You're recommending an autoconf-like system, basically. Which I commend. 
But then you just code for version(has_feature). And your config file 
might be relatively large, with several entries for each OS. So you'd have:

// dll stuff
version(linux || darwin || bsd)
    version = UseDlfcn;
else
    version = UseDll;

// socket stuff
...

I would prefer:
version(linux)
    version = UseDlfcn;
    // ...
version(darwin)...

It works with the current syntax, and it is equally organized. It's 
easier to see, given a platform, what versions you have defined. On the 
other hand, it's a bit harder to see whether a particular version is 
defined.
Dec 07 2007
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2007-12-07 05:47:36 -0500, Walter Bright <newshound1 digitalmars.com> said:


 So, by limiting the version statement, the idea is to encourage the 
 programmer to think in terms of distinct versions being generated, and 
 then code in terms of those distinct versions - each of those versions 
 having a name.


I've come into a situation where I'll probably have to take the bloat 
from the code and transfer it to the build process because of this 
limitation. Apple's C/C++/Obj-C headers all use the following idiom to 
create single header files adapted to the target version of Mac OS X 
you wish to use:

	#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_3
	// Mac OS X 10.3 specific functions prototypes
	#endif
	#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4
	// Mac OS X 10.4 specific functions prototypes
	#endif
	#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5
	// Mac OS X 10.5 specific functions prototypes
	#endif

Then you only need to set MAC_OS_X_VERSION_MAX_ALLOWED to the actual 
version number and you instantly have headers limited to the version 
your application is targeting. (Or if you don't you get headers for the 
latest version.)

The only way I see to replicate that in D when converting Apple headers 
is to use:

	version (MAC_OS_X_VERSION_10_3) {
		// Mac OS X 10.3 specific functions prototypes.
	}
	version (MAC_OS_X_VERSION_10_4) {
		// Mac OS X 10.4 specific functions prototypes.
	}
	version (MAC_OS_X_VERSION_10_5) {
		// Mac OS X 10.5 specific functions prototypes.
	}

This is inconvenient (and error prone) because if you're going to 
import a module with these version flags in your program, you then need 
to define when version flags for each previous version of the OS; and 
the number of symbols to define will always go in increasing. If you 
could just write:

	version (MAC_OS_X_VERSION >= 10.3)

it'd make things much easier. Even better would be:

	version (MAC_OS_X_VERSION <= 10.1 && MAC_OS_X_VERSION > 10.4)

to indicate a function added at version 10.1 and removed in 10.4. To do 
that with my current system, it'd read:

	version (MAC_OS_X_VERSION_10_3) { }
	else version (MAC_OS_X_VERSION_10_1) {
		// some functions added in Mac OS X 10.1 but removed in 10.4.
	}

which isn't that clear either.

By the way, I know I could use simply a version number flag and write:

	version (1) { }
	version (2) { }
	version (3) { }

But then it'll prevent anyone from using version numbers for their own 
application when using ported headers.

Now that I'm thinking about it, the simplest solution probably lies in 
using version to declare some constants in a module mimicking 
AvailabilityMacros.h, then using those constants with static ifs.=.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Dec 07 2007
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
mandel wrote:

 A proposal in a nutshell:
 
 - removal of the keywords "unittest, "version" and similar.
 
 - replaced by global compile time variables.
 
 - "dmd -<name>=<value>" to set them. Variables not found result in 
 compiler warnings
 
 - "dmd -list version*" or similar to list all global variable names with 
 prefix "version"
 
 -> less keywords, more powerfull control (use in boolean expressions), 
 more native syntax, easier to understand
 
 Ideas? Problems? Objections?


There are two things I like in the current system that will be lost with 
this proposal:
1. Distinction between conditional compilation as in different versions 
of the software and use of static if for meta- and generic programming

2. A standardized naming scheme. For example, there's nothing magical 
about the debug keyword as far as I know, it could just be replaced with 
version(Debug). But it's nice that everybody uses the same thing for the 
same purpose.
Dec 07 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Lutger wrote:

 For example, there's nothing magical 
 about the debug keyword as far as I know, it could just be replaced with 
 version(Debug). But it's nice that everybody uses the same thing for the 
 same purpose.


You're quite right in your assessment of the debug conditional. It stems 
from my experience (and that of some managers who begged me for this) 
that every C/C++ project has their own, unique, way of building for 
debug. It's not that any of them are wrong, it's just that they're all 
different. No standardized convention has ever emerged, yet all these 
debug schemes essentially do the same thing.

Providing a standard means of debug compilation means:

1) Projects developed by different groups will naturally gravitate 
towards using it, rather than invent their own, aiding source code 
portability.

2) Programmers can move from project to project with one less coding 
convention they must relearn.

3) Standardized tools can be developed to manipulate the debug compilations.

4) A standardized scheme is something that can be enforced by larger 
organizations.
Dec 07 2007
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
mandel:

 Still, I can't get rid of the desire to give more power to the programmer
 by simplifying stuff. :>


Some built-in restraints can be *really* useful to avoid bugs.

Bye,
bearophile
Dec 07 2007
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
mandel wrote:

 Ideas? Problems? Objections?
 
 ...might be hairy to implement?


Maybe. And it would be EXTREMELY hairy to read.

...what would happen if you compiled with '-if=false' ?
Dec 07 2007
prev sibling parent reply Robby <robby.lansaw gmail.com> writes:
mandel wrote:

 A proposal in a nutshell:
 
 - removal of the keywords "unittest, "version" and similar.
 
 - replaced by global compile time variables.
 
 - "dmd -<name>=<value>" to set them. Variables not found result in 
 compiler warnings
 
 - "dmd -list version*" or similar to list all global variable names with 
 prefix "version"
 
 -> less keywords, more powerfull control (use in boolean expressions), 
 more native syntax, easier to understand
 
 Ideas? Problems? Objections?
 
 btw.:
 bool enableXYZ;
 
 if(enableXFZ) import foo.Bar;
 
 ...might be hairy to implement?


Please please don't. From my standpoint, and converting over 70k lines 
of code over to D I can attest how easy the simplistic way of how D 
handles versions is so nice in the long run. I do like the idea of 
version (a,b,c) though, oddly enough.

Now if I could get a way to enforce a type can't be null by the language 
itself, it would save a lot of if(whatever == null) cruft I have lined 
throughout from the *other* language port we're doing:(.

yanno, something that says I expect class Whatever, I want class 
Whatever and don't you damn well give me null.

I have noticed a push for changing adding complication for unittest as 
well, but I hope it stays quite similar, though I really would like a 
lil more fine tuning of how it's ran.
Dec 07 2007
parent Robby <robby.lansaw gmail.com> writes:
Robby wrote:

 mandel wrote:

 A proposal in a nutshell:

 - removal of the keywords "unittest, "version" and similar.

 - replaced by global compile time variables.

 - "dmd -<name>=<value>" to set them. Variables not found result in 
 compiler warnings

 - "dmd -list version*" or similar to list all global variable names 
 with prefix "version"

 -> less keywords, more powerfull control (use in boolean expressions), 
 more native syntax, easier to understand

 Ideas? Problems? Objections?

 btw.:
 bool enableXYZ;

 if(enableXFZ) import foo.Bar;

 ...might be hairy to implement?


 
 Please please don't. From my standpoint, and converting over 70k lines 
 of code over to D I can attest how easy the simplistic way of how D 
 handles versions is so nice in the long run. I do like the idea of 
 version (a,b,c) though, oddly enough.
 
 Now if I could get a way to enforce a type can't be null by the language 
 itself, it would save a lot of if(whatever == null) cruft I have lined 
 throughout from the *other* language port we're doing:(.
 
 yanno, something that says I expect class Whatever, I want class 
 Whatever and don't you damn well give me null.
 
 I have noticed a push for changing adding complication for unittest as 
 well, but I hope it stays quite similar, though I really would like a 
 lil more fine tuning of how it's ran.
 


is null*, thinking one thing, writing another. sigh
Dec 07 2007