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

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. But please, don't even mention using the  !?*#$!  registry!

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. But please, don't even mention using the  !?*#$!  registry!
>
>
>
>

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. But please, don't even mention using the  !?*#$!  registry!

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))) ]

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

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

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

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

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