[nem-en] Completion thoughts

[NoiseEHC]

Now I looked at the completion engine's source and seems that I really 
did not know anything about that... :(

So my little theory is meaningless. As I now see it, that is just 3 .n 
files which just use the AST tree creating stuff.
(I somehow supposed that this completion stuff is inside the AST tree 
but never mind.)

Vlad, if you want to speed up the compiling you should just leave those 
3 .n files out from the .nproj file it would work.
However currently on my P4 3000 MHz machine it takes ~40 sec to do a 
"msbuild Nemerle.Compiler.nproj" with
NGEN'd "/boot" files so I do not think you could win that much time.

Regarding the compilation I realized that we can do only one 
optimization: if none of the sources change and none
of the references then we could skip the compilation. As I realized if a 
macro change in a referenced library then it could
generate different code. Another thing is that if some type changes in a 
referenced library then it can yield a different
type inference in a nonchanged source file. So it seems that even if no 
source file changes in a project, we cannot
optimize the compilation to a relinking process... Any thoughts?

vc wrote:
> I categorically do not agree.
>
> #if is evil. Completion engine must be mode of compiler. 
>
> Compiler have public interface. Completion engine must use it.
>
> Keep It Simple, ... :)  
>
> Vlad.
>
>   
>> -----Original Message-----
>> From: devel-en-bounces at nemerle.org [mailto:devel-en-bounces at nemerle.org]
>> On Behalf Of NoiseEHC
>> Sent: Thursday, June 01, 2006 6:23 PM
>> To: devel-en at nemerle.org
>> Subject: Re: [nem-en] Completion thoughts
>>
>> As a side note there is a suggestion (note that I have no idea about the
>> completion code):
>> 1. We should decouple the completion logic from the compiler as much as
>> possible:
>> - that way it will be less likely that some hack in the completion logic
>> will break the compiler (as the latter is the more important IMHO)
>> - we could compile two versions of the source (with or without
>> completion/syntax coloring/code analysis baggage)
>> 2. We should create some more or less nonvolatile interface to the stuff
>> so when compiler internals change we would not change the IDE editors.
>> IMHO since currently we have only 2 editors I think we can assume that
>> we will rather do the extra work to remain in sync with the Nemerle SVN
>> than to block developing the compiler. All in all, the compiler has a
>> higher preference than the interface to the completion engine.
>> 3. The idea is that we should define some extra interfaces which shall
>> be implemented by the compiler internal classes and the IDE's should use
>> only these interfaces. Of course if it would be a subset of the internal
>> interfaces we should not over engineer the stuff and just use the
>> internal one. But in cases when the completion engine requires some
>> filtering and caching then we would split this logic to a partial class
>> or simply to an #ifdef. Another option is to define some macros which
>> compile to nothing in case of a compiler build without the completion
>> engine.
>> So here is a hypothetical example (and keep in mind that I have no idea
>> about the completion code):
>> interface ICompletionClass {
>>   PublicMethods : List<ICompletionMethod> {get;}
>> }
>>
>> class InternalCompilerClass : ICompletionClass {
>> ...
>>   [JustForCompletion]
>>   _CachedMethodList : List<ICompletionMethod>;
>>   PublicMethods : List<ICompletionMethod> {
>>     get {
>>         // generate filtered list if needed
>>        _CachedMethodList;
>>     }
>>   }
>> }
>>
>> So it can seem trivial but it is how I see the thing.
>>
>>
>> _______________________________________________
>> https://nemerle.org/mailman/listinfo/devel-en
>>     
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>
>
>