www.digitalmars.com         C & C++   DMDScript  

D - D compiler customisability

reply "Matthew Wilson" <matthew thedjournal.com> writes:
Guys

We've had a few exchanges on the level of strictness or pedanticism in the
compiler, with some arguing for customisability in the form of command-line
params, others in environment variables, still others arguing for maximum
pedanticism built-in (and quite right too, in my autocratic opinion) and
others wanting a laisse faire approach.

I've had an idea that may be helpful, as well as exciting all the inveterate
tinkerers amongst us (I imagine that describes everyone on this newsgroup).
Why don't we have the compiler provide a plug-in (D plug-ins, of course!)
architecture, such that the compiler would emit absolutely every last
error/warning/criticism/whinge to this component, which would filter out the
ones (obviously not errors) that the particular plug-in developer/user did
not want to see, enabling every last personal preference to be accomodated.
By default, there would be a default filter that filters whatever Walter
deems appropriate?

This relies on a D dynamic-loading facility - which I've not heard anyone
mention - but other than that I cannot imagine why it cannot be implemented.

The specification of the filter could be a simple config file, or its
presence in the dmd\bin directory, or registry, or whatever is the most
appropriate.

Thoughts?

Matthew
Jun 13 2002
next sibling parent reply Karl Bochert <kbochert ix.netcom.com> writes:
On Fri, 14 Jun 2002 09:53:17 +1000, "Matthew Wilson" <matthew thedjournal.com>
wrote:

 
 The specification of the filter could be a simple config file, or its
 presence in the dmd\bin directory, or registry, or whatever is the most
 appropriate.
 
 Thoughts?


'Lint' as a plugin ? Probably easier than as a standalone program.
Jun 13 2002
parent reply "Matthew Wilson" <matthew thedjournal.com> writes:
I'm not so much hung up at this stage on the issue of how the compiler knows
that there is a plug-in to use, as on the idea itself. Does anyone think
it's worth exploring? It seems like a way in which we can all get what we
want out of the compiler (at least in terms of its strictness or lackof)

"Karl Bochert" <kbochert ix.netcom.com> wrote in message
news:1103_1024028838 bose...

 On Fri, 14 Jun 2002 09:53:17 +1000, "Matthew Wilson"


<matthew thedjournal.com> wrote:

 The specification of the filter could be a simple config file, or its
 presence in the dmd\bin directory, or registry, or whatever is the most
 appropriate.

 Thoughts?


 'Lint' as a plugin ? Probably easier than as a standalone program.
Jun 13 2002
parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I think it is a good idea.  D standard says there are these warnings
(actually only errors);  Those can be disabled selectively or some choice
"suggested" warnings and errors can be "enabled" if you so desire.  Ones
that are contributed by concerned compiler users or ones that people tend to
find occasionally useful from other languages.

Entirely a vendor-specific issue though.

Sean

"Matthew Wilson" <matthew thedjournal.com> wrote in message
news:aebsht$1u4t$1 digitaldaemon.com...

 I'm not so much hung up at this stage on the issue of how the compiler


knows

 that there is a plug-in to use, as on the idea itself. Does anyone think
 it's worth exploring? It seems like a way in which we can all get what we
 want out of the compiler (at least in terms of its strictness or lackof)

 "Karl Bochert" <kbochert ix.netcom.com> wrote in message
 news:1103_1024028838 bose...

 On Fri, 14 Jun 2002 09:53:17 +1000, "Matthew Wilson"


 <matthew thedjournal.com> wrote:

 The specification of the filter could be a simple config file, or its
 presence in the dmd\bin directory, or registry, or whatever is the






most

 appropriate.

 Thoughts?


 'Lint' as a plugin ? Probably easier than as a standalone program.
Jun 14 2002
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Matthew Wilson wrote:


 I've had an idea that may be helpful, as well as exciting all the inveterate
 tinkerers amongst us (I imagine that describes everyone on this newsgroup).
 Why don't we have the compiler provide a plug-in (D plug-ins, of course!)
 architecture, such that the compiler would emit absolutely every last
 error/warning/criticism/whinge to this component, which would filter out the
 ones (obviously not errors) that the particular plug-in developer/user did
 not want to see, enabling every last personal preference to be accomodated.
 By default, there would be a default filter that filters whatever Walter
 deems appropriate?

 This relies on a D dynamic-loading facility - which I've not heard anyone
 mention - but other than that I cannot imagine why it cannot be implemented.

 The specification of the filter could be a simple config file, or its
 presence in the dmd\bin directory, or registry, or whatever is the most
 appropriate.


This is a very intriguing idea!  Hard to get right and get workable, but Very
Cool if it worked.

However, I think that this should be included into the source files themselves;
provide the compiler extensions that you need along with the source that uses
them!

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Jun 14 2002
parent reply "anderson" <anderson firestar.com.au> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D09F496.887AD880 deming-os.org...

 Matthew Wilson wrote:


<Snip>

 However, I think that this should be included into the source files


themselves;

 provide the compiler extensions that you need along with the source that


uses

 them!


<Snip>

Although I think, the customisability idea seems to go a bit out of scope of
D. I agree that if one were to implement it, the style of coding should be
included in the source (vir linking to another file). Just imagine all the
unsusable code flying around the web if each person had there own style, and
we had know way of knowing which they used.
Jun 14 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
 Although I think, the customisability idea seems to go a bit out of scope


of

 D. I agree that if one were to implement it, the style of coding should be
 included in the source (vir linking to another file). Just imagine all the
 unsusable code flying around the web if each person had there own style,


and
we had no way of knowing which they used.





 Jun 15 2002



prev sibling  parent reply "Matthew Wilson" <dmd synesis.com.au>  writes:


Nope, disagree.

Part of the ethos of D seems to be to answer many of the questions that
other languages/compilers have left to be "implementation dependent". C &
C++, for example, do not even have warnings mentioned in their standards,
beyond saying that a compiler may provide warnings! D aims to answer many of
these previously imponderables and tie up the loose ends.

Coding standards are constraints placed on code by development
organisations, and are a necessary and important part of working effectively
in teams (or on one's own, for that matter). They are just as important on a
practical basis as the constraints imposed by a language, such as rejecting
uninitialised variables.

The thing with coding standards is that they differ being subject to
fashions and whims in their detail. This does not mean they are not as
important, just that their nature is variable. Thus it is entirely in
keeping with D to facilitate tight control of code's conformance to coding
standards, whilst being mindful of the varied nature of such.

Walter, I'd be interested in hearing your opinion on the idea

Matthew

"anderson" <anderson firestar.com.au> wrote in message
news:aee96l$1au2$1 digitaldaemon.com...

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D09F496.887AD880 deming-os.org...

 Matthew Wilson wrote:


 <Snip>

 However, I think that this should be included into the source files


 themselves;

 provide the compiler extensions that you need along with the source that


 uses

 them!


 <Snip>

 Although I think, the customisability idea seems to go a bit out of scope


of

 D. I agree that if one were to implement it, the style of coding should be
 included in the source (vir linking to another file). Just imagine all the
 unsusable code flying around the web if each person had there own style,


and

 we had know way of knowing which they used.





 Jun 17 2002



 next sibling parent reply "anderson" <anderson firestar.com.au>  writes:


Oh, your talking about style guide plugs not language change plugging.  I
won't mind them if they were in or out, I never said that. How are we to
know what the standard things are when the language itself is still in it's
preliminary stages (no offence Walter)? I suppose an iterative approach
could be taken that would change as the language changes.

I still think that it should be in a file, but referenced in the code
initial lines (like imports). Why, so that styles guide is centralized and
doesn't need to be changed/retyped, much.  Perhaps there could be one for
beginners that force users not to be-able to go array.length++ and the
advanced users would be allowed to so that. But there still needs to be a
default that allows everything.

On the other hand, of course if you find some code on the web you've go'ta
have some way to convert it into your standard.

In the first post (although it didn't come across that way), I was trying to
be indifferent and commenting on what I though some of the problems (that
mite be solved) were. I'm at  least attempting to so again here.

Perhaps I still on the wrong track and I'm talking about something
completely different.


"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:aeko4c$20jb$1 digitaldaemon.com...

 Nope, disagree.


Sounds like a flammer to me.


 Part of the ethos of D seems to be to answer many of the questions that
 other languages/compilers have left to be "implementation dependent". C &
 C++, for example, do not even have warnings mentioned in their


standards,Ho

 beyond saying that a compiler may provide warnings! D aims to answer many


of

 these previously imponderables and tie up the loose ends.

 Coding standards are constraints placed on code by development
 organisations, and are a necessary and important part of working


effectively

 in teams (or on one's own, for that matter). They are just as important on


a

 practical basis as the constraints imposed by a language, such as


rejecting

 uninitialised variables.



 The thing with coding standards is that they differ being subject to
 fashions and whims in their detail. This does not mean they are not as
 important, just that their nature is variable. Thus it is entirely in
 keeping with D to facilitate tight control of code's conformance to coding
 standards, whilst being mindful of the varied nature of such.

 Walter, I'd be interested in hearing your opinion on the idea

 Matthew





 Jun 17 2002



  parent  "Matthew Wilson" <mwilson thedjournal.com>  writes:


Not quite

What I was talking about was the ability to (i) hook compiler messages in
order to provide more fulsome explanations and (ii) promote
undisplayed-by-default warnings (eg. non-boolean as conditional expression)
to displayed warnings, and promote some warnings to errors. At no point have
I envisaged demoting any errors (would be ridiculous!) or any warnings
(possibly useful, depending on the default nature of the compiler).

I think the best thing about this point is if I put together a properly
argued proposal. Alas this may take me a few weeks, as workload is a bit
crazy ... More later.

Matthew

"anderson" <anderson firestar.com.au> wrote in message
news:ael0aj$28vt$1 digitaldaemon.com...

 Oh, your talking about style guide plugs not language change plugging.  I
 won't mind them if they were in or out, I never said that. How are we to
 know what the standard things are when the language itself is still in


it's

 preliminary stages (no offence Walter)? I suppose an iterative approach
 could be taken that would change as the language changes.

 I still think that it should be in a file, but referenced in the code
 initial lines (like imports). Why, so that styles guide is centralized and
 doesn't need to be changed/retyped, much.  Perhaps there could be one for
 beginners that force users not to be-able to go array.length++ and the
 advanced users would be allowed to so that. But there still needs to be a
 default that allows everything.

 On the other hand, of course if you find some code on the web you've go'ta
 have some way to convert it into your standard.

 In the first post (although it didn't come across that way), I was trying


to

 be indifferent and commenting on what I though some of the problems (that
 mite be solved) were. I'm at  least attempting to so again here.

 Perhaps I still on the wrong track and I'm talking about something
 completely different.


 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:aeko4c$20jb$1 digitaldaemon.com...

 Nope, disagree.


 Sounds like a flammer to me.


 Part of the ethos of D seems to be to answer many of the questions that
 other languages/compilers have left to be "implementation dependent". C




&

 C++, for example, do not even have warnings mentioned in their


 standards,Ho

 beyond saying that a compiler may provide warnings! D aims to answer




many

 of

 these previously imponderables and tie up the loose ends.

 Coding standards are constraints placed on code by development
 organisations, and are a necessary and important part of working


 effectively

 in teams (or on one's own, for that matter). They are just as important




on

 a

 practical basis as the constraints imposed by a language, such as


 rejecting

 uninitialised variables.



 The thing with coding standards is that they differ being subject to
 fashions and whims in their detail. This does not mean they are not as
 important, just that their nature is variable. Thus it is entirely in
 keeping with D to facilitate tight control of code's conformance to




coding

 standards, whilst being mindful of the varied nature of such.

 Walter, I'd be interested in hearing your opinion on the idea

 Matthew







 Jun 17 2002



prev sibling  parent reply "Walter" <walter digitalmars.com>  writes:


"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:aeko4c$20jb$1 digitaldaemon.com...

 Nope, disagree.

 Part of the ethos of D seems to be to answer many of the questions that
 other languages/compilers have left to be "implementation dependent". C &
 C++, for example, do not even have warnings mentioned in their standards,
 beyond saying that a compiler may provide warnings! D aims to answer many


of

 these previously imponderables and tie up the loose ends.

 Coding standards are constraints placed on code by development
 organisations, and are a necessary and important part of working


effectively

 in teams (or on one's own, for that matter). They are just as important on


a

 practical basis as the constraints imposed by a language, such as


rejecting

 uninitialised variables.

 The thing with coding standards is that they differ being subject to
 fashions and whims in their detail. This does not mean they are not as
 important, just that their nature is variable. Thus it is entirely in
 keeping with D to facilitate tight control of code's conformance to coding
 standards, whilst being mindful of the varied nature of such.

 Walter, I'd be interested in hearing your opinion on the idea


I think style is a matter of personal taste. Although I think everyone
should use my personal favorite style <g>, about 20 years ago I gave up on
the style wars as being a problem with no solution. With D, I have opted for
a "D Style Guide" as a recommendation for people looking for a style to
adopt, but not as a requirement for using the language.



 Jul 02 2002



  parent reply ben <zander echotech.ca>  writes:


Walter wrote:


 
 "Matthew Wilson" <dmd synesis.com.au> wrote in message
 news:aeko4c$20jb$1 digitaldaemon.com...

 Nope, disagree.

 Part of the ethos of D seems to be to answer many of the questions that
 other languages/compilers have left to be "implementation dependent". C &
 C++, for example, do not even have warnings mentioned in their standards,
 beyond saying that a compiler may provide warnings! D aims to answer many


 of

 these previously imponderables and tie up the loose ends.

 Coding standards are constraints placed on code by development
 organisations, and are a necessary and important part of working


 effectively

 in teams (or on one's own, for that matter). They are just as important
 on


 a

 practical basis as the constraints imposed by a language, such as


 rejecting

 uninitialised variables.

 The thing with coding standards is that they differ being subject to
 fashions and whims in their detail. This does not mean they are not as
 important, just that their nature is variable. Thus it is entirely in
 keeping with D to facilitate tight control of code's conformance to
 coding standards, whilst being mindful of the varied nature of such.

 Walter, I'd be interested in hearing your opinion on the idea


 
 I think style is a matter of personal taste. Although I think everyone
 should use my personal favorite style <g>, about 20 years ago I gave up on
 the style wars as being a problem with no solution. With D, I have opted
 for a "D Style Guide" as a recommendation for people looking for a style
 to adopt, but not as a requirement for using the language.



Hello,
There is a D style guide.. Were can I find this, I am sure it would be 
helpfull.. Come to think of it, I am sure that following your style guide 
would help with optimization in code gen :)... 

Ben



 Jul 03 2002



  parent  "anderson" <anderson firestar.com.au>  writes:


"ben" <zander echotech.ca> wrote in message
news:afupkr$1is8$2 digitaldaemon.com...


 Hello,
 There is a D style guide.. Were can I find this, I am sure it would be
 helpfull.. Come to think of it, I am sure that following your style guide
 would help with optimization in code gen :)...

 Ben


http://www.digitalmars.com/d/dstyle.html

or

on the D website under "Style Guide".



 Jul 03 2002