|
On 2015-07-08 17:39, Sven Efftinge
wrote:
On
2015-07-07 8:11, Sven Efftinge wrote:>
> That
might work if that work is super cheap, but that is
usually not
> the case.
Running
external parsers (actually having a parser service
running,
that got
notified when files are changing) worked 25 years ago
quite
well, when
workstations had single core processors running at 20Mhz.
Today each of
the 8 or 16 cores is 100 times faster, why should this
suddenly be a
problem ;-)….
If you still work with the same tools and the same amount of
code, than that’s not a problem ;-)
Most of the time, you have to only parse the file that has changed.
In case of languages like C/C++ that use a preporcessor, you
have to parse all files that depend on the changed file. But
there have been tricks to make that efficient form the time
when computers were slow...
The
real problem starts with the fact that each *DT maintains
its own
index and
there is no higher level structure that allows defining
dependencies
between sub-parts of the system. In some way there has to
be a hierarchy
of scopes that goes beyond a single language.
Xtext has that and so does IntelliJ.
That is great! That's why IntelliJ can propose _javascript_ in HTML
etc.
>
IMHO it is a good idea having a dedicated plug-in that is
> tailored
to leverage exactly that (like Max mentioned) rather than
> building
a generic framework for possibly existing external tools.
Both
approaches have their use cases....
In some way
each *DT is a silo in eclipse. There is almost no code
sharing
between them. There is not even a common index or a common
way
to integrate
external tools that provide information about file
locations that
works with all *DTs. Xtext simplifies that process by
generating a
good portion of that silo for each new language. But
it's still
silos….
That’s simply not true. Xtext provides a generic
infrastructure for many languages, to play nicely together.
YES! I was wrong! I have been creating a few Xtext languages that
nicely work together. :-D
So, then all Xtext languages are a single silo ;-)
As I said before keys to that are a common notion of ASTs
and an index.
Yes, you are right!
Michael
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
|
