Thread overview
Spelling suggestion on wrong identifier
Dec 16, 2003
J Anderson
Dec 17, 2003
The Lone Haranguer
Dec 17, 2003
Ilya Minkov
Dec 18, 2003
J Anderson
Dec 19, 2003
J C Calvarese
Dec 19, 2003
J Anderson
Dec 19, 2003
Sean L. Palmer
Dec 19, 2003
Felix
Dec 19, 2003
Juan C.
Dec 19, 2003
Sean L. Palmer
December 16, 2003
The ada compiler would suggest a possible identifier that might be the correct one when you misspelled a word.  Even a case check would be very useful. Could we please have that :)  It also means you don't have to know the case to use someone else class (just try the wrong one, and the compiler will give you alternatives).

-Anderson

December 17, 2003
Please! No more bloat!


In article <bro570$2vva$1@digitaldaemon.com>, J Anderson says...
>
>The ada compiler would suggest a possible identifier that might be the correct one when you misspelled a word.  Even a case check would be very useful. Could we please have that :)  It also means you don't have to know the case to use someone else class (just try the wrong one, and the compiler will give you alternatives).
>
>-Anderson
>


December 17, 2003
I think that should be the job of the IDE. Especially IBM Eclipse users are used to this kind of service. ;)

J Anderson wrote:
> The ada compiler would suggest a possible identifier that might be the correct one when you misspelled a word.  Even a case check would be very useful. Could we please have that :)  It also means you don't have to know the case to use someone else class (just try the wrong one, and the compiler will give you alternatives).
> 
> -Anderson
> 

December 18, 2003
Ilya Minkov wrote:

> I think that should be the job of the IDE. Especially IBM Eclipse users are used to this kind of service. ;)
>
I thought about that also, although it means that the IDE also has to phase the code.  It would be nice if D could spit out all of the identifiers into a text file (in categories). Although that'd mean another compiler switch, which Walter hates.

> J Anderson wrote:
>
>> The ada compiler would suggest a possible identifier that might be the correct one when you misspelled a word.  Even a case check would be very useful. Could we please have that :)  It also means you don't have to know the case to use someone else class (just try the wrong one, and the compiler will give you alternatives).
>>
>> -Anderson
>>
>

December 19, 2003
J Anderson wrote:
> Ilya Minkov wrote:
> 
>> I think that should be the job of the IDE. Especially IBM Eclipse users are used to this kind of service. ;)
>>
> I thought about that also, although it means that the IDE also has to phase the code.  It would be nice if D could spit out all of the identifiers into a text file (in categories). Although that'd mean another compiler switch, which Walter hates.

I doubt that Walter is going to add this to DMD anytime soon, but it may not be that hard for one of us to create a tool just to parse the source to reach your goal.  Case in point:  I just added a feature to my version of D2HTML to output a raw list of identifiers in addition to an .html file.  They're unsorted, uncategorized, and redundant, but it's a start.

I thought you might be curious to see it in action: http://jcc_7.tripod.com/d/

Justin
December 19, 2003
J C Calvarese wrote:

> J Anderson wrote:
>
>> Ilya Minkov wrote:
>>
>>> I think that should be the job of the IDE. Especially IBM Eclipse users are used to this kind of service. ;)
>>>
>> I thought about that also, although it means that the IDE also has to phase the code.  It would be nice if D could spit out all of the identifiers into a text file (in categories). Although that'd mean another compiler switch, which Walter hates.
>
>
> I doubt that Walter is going to add this to DMD anytime soon, but it may not be that hard for one of us to create a tool just to parse the source to reach your goal.  Case in point:  I just added a feature to my version of D2HTML to output a raw list of identifiers in addition to an ..html file.  They're unsorted, uncategorized, and redundant, but it's a start.
>
> I thought you might be curious to see it in action: http://jcc_7.tripod.com/d/
>
> Justin

Cool

December 19, 2003
This is the reason why Walter is trying so hard to keep the parsing and semantic phases separate in D.  That will allow all kinds of tools to be written that can deal with D source without having to know anything about the types or the identifiers that are present.

In other words, it really won't be all that hard to write a tool that parses D source.  You could probably do it in like 3 pages of Perl.  ;)   There will probably be a Perl library for parsing D soon.

A full optimizing compiler, on the other hand, is a significant engineering effort.  Some of those algorithms are pretty complicated!

Sean

"J C Calvarese" <jcc7@cox.net> wrote in message news:bru2n8$2t1e$1@digitaldaemon.com...
> J Anderson wrote:
> > Ilya Minkov wrote:
> >
> >> I think that should be the job of the IDE. Especially IBM Eclipse users are used to this kind of service. ;)
> >>
> > I thought about that also, although it means that the IDE also has to phase the code.  It would be nice if D could spit out all of the identifiers into a text file (in categories). Although that'd mean another compiler switch, which Walter hates.
>
> I doubt that Walter is going to add this to DMD anytime soon, but it may not be that hard for one of us to create a tool just to parse the source to reach your goal.  Case in point:  I just added a feature to my version of D2HTML to output a raw list of identifiers in addition to an .html file.  They're unsorted, uncategorized, and redundant, but it's a start.
>
> I thought you might be curious to see it in action: http://jcc_7.tripod.com/d/
>
> Justin


December 19, 2003
I agree with everything you say (and with Walter's conception, too).


In article <brubl2$9m0$1@digitaldaemon.com>, Sean L. Palmer says...
>
>This is the reason why Walter is trying so hard to keep the parsing and semantic phases separate in D.  That will allow all kinds of tools to be written that can deal with D source without having to know anything about the types or the identifiers that are present.
>
>In other words, it really won't be all that hard to write a tool that parses D source.  You could probably do it in like 3 pages of Perl.  ;)   There will probably be a Perl library for parsing D soon.
>
>A full optimizing compiler, on the other hand, is a significant engineering effort.  Some of those algorithms are pretty complicated!
>
>Sean
>
>"J C Calvarese" <jcc7@cox.net> wrote in message news:bru2n8$2t1e$1@digitaldaemon.com...
>> J Anderson wrote:
>> > Ilya Minkov wrote:
>> >
>> >> I think that should be the job of the IDE. Especially IBM Eclipse users are used to this kind of service. ;)
>> >>
>> > I thought about that also, although it means that the IDE also has to phase the code.  It would be nice if D could spit out all of the identifiers into a text file (in categories). Although that'd mean another compiler switch, which Walter hates.
>>
>> I doubt that Walter is going to add this to DMD anytime soon, but it may not be that hard for one of us to create a tool just to parse the source to reach your goal.  Case in point:  I just added a feature to my version of D2HTML to output a raw list of identifiers in addition to an .html file.  They're unsorted, uncategorized, and redundant, but it's a start.
>>
>> I thought you might be curious to see it in action: http://jcc_7.tripod.com/d/
>>
>> Justin
>
>


December 19, 2003
And therefore it ought to lead to removing much of the compile-time "safety" checks to other tools. I refer, of course, to flagging when a switch is missing a default break, the  if ( x = y )  problem, etc. Then the compiler can focus on compiling.

In article <brubl2$9m0$1@digitaldaemon.com>, Sean L. Palmer says...
>
>This is the reason why Walter is trying so hard to keep the parsing and semantic phases separate in D.  That will allow all kinds of tools to be written that can deal with D source without having to know anything about the types or the identifiers that are present.
>
>In other words, it really won't be all that hard to write a tool that parses D source.  You could probably do it in like 3 pages of Perl.  ;)   There will probably be a Perl library for parsing D soon.
>
>A full optimizing compiler, on the other hand, is a significant engineering effort.  Some of those algorithms are pretty complicated!
>
>Sean
>
>"J C Calvarese" <jcc7@cox.net> wrote in message news:bru2n8$2t1e$1@digitaldaemon.com...
>> J Anderson wrote:
>> > Ilya Minkov wrote:
>> >
>> >> I think that should be the job of the IDE. Especially IBM Eclipse users are used to this kind of service. ;)
>> >>
>> > I thought about that also, although it means that the IDE also has to phase the code.  It would be nice if D could spit out all of the identifiers into a text file (in categories). Although that'd mean another compiler switch, which Walter hates.
>>
>> I doubt that Walter is going to add this to DMD anytime soon, but it may not be that hard for one of us to create a tool just to parse the source to reach your goal.  Case in point:  I just added a feature to my version of D2HTML to output a raw list of identifiers in addition to an .html file.  They're unsorted, uncategorized, and redundant, but it's a start.
>>
>> I thought you might be curious to see it in action: http://jcc_7.tripod.com/d/
>>
>> Justin
>
>


December 19, 2003
True, Dlint would be pretty sophisticated.  hehe

Sean

"Juan C." <Juan_member@pathlink.com> wrote in message news:brvcag$1r70$1@digitaldaemon.com...
> And therefore it ought to lead to removing much of the compile-time
"safety"
> checks to other tools. I refer, of course, to flagging when a switch is
missing
> a default break, the  if ( x = y )  problem, etc. Then the compiler can
focus on
> compiling.
>
> In article <brubl2$9m0$1@digitaldaemon.com>, Sean L. Palmer says...
> >
> >This is the reason why Walter is trying so hard to keep the parsing and semantic phases separate in D.  That will allow all kinds of tools to be written that can deal with D source without having to know anything about the types or the identifiers that are present.