From: | "Pascal J. Bourguignon" <pjb@informatimago.com> |
Newsgroups: | comp.programming,comp.compilers,comp.editors |
Date: | Sun, 10 Apr 2011 20:53:32 +0200 |
Organization: | Informatimago |
References: | 11-04-009 11-04-014 |
Keywords: | tools, editor |
Posted-Date: | 11 Apr 2011 11:29:19 EDT |
Hans-Peter Diettrich <DrDiettrich1@aol.com> writes:
> HiramEgl schrieb:
>
>> Therefore, I see all these elements as branches and leaves of a big
>> tree-structure (the SOURCE-STRUCTURE).
>
> Where do you want to start and stop building that tree?
>
> To start you need kind of a project, that contains a number of source
> modules, which then refer to other modules or interfaces, depending on
> the source language; C uses #include for importing external
> declarations, Pascal dialects have "uses" for the same purpose. How
> shall your editor find the related files? In the case of C, where
> shall your editor find the definitions, related to the imported
> declarations? At least you'll need according parsers, for every
> supported language and compiler.
>
> Do you want to recurse down into every additional external
> declaration, including all libraries used in the project? In the case
> of Free Pascal this requires to add not only a compiler attribute and
> related search pathes to the configuration, but also for the target
> machine, OS and (Lazarus) widgetset.
>
> Your approach looks nice, as soon as such a structure tree exists, but I
> see the biggest problems just in the construction of that tree.
Indeed, it's much easier to do it when your environment is really
Integrated, that is, Image based, like Smalltalk systems or Lisp Machines.
But it's not impossible with thicker external components. After all,
even on a Lisp Machine or in a Smalltalk environment, the hardware is
not included in the environment. And it could be argued that having
access to the kernel (being able to see its sources, its state, and
being able to modify it while it's running), while fine when developing
this kernel, would not be too wise for an application programmmer.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.