|Designing a Domain-specific language email@example.com (2017-05-23)|
|Re: Designing a Domain-specific language firstname.lastname@example.org (bartc) (2017-05-23)|
|Re: Designing a Domain-specific language DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2017-05-24)|
|Re: Designing a Domain-specific language email@example.com (firstname.lastname@example.org) (2017-05-24)|
|Re: Designing a Domain-specific language email@example.com (2017-05-25)|
|Re: Designing a Domain-specific language firstname.lastname@example.org (bartc) (2017-05-27)|
|Date:||Tue, 23 May 2017 20:39:34 +0100|
|Injection-Info:||miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="63122"; mail-complaints-to="email@example.com"|
|Posted-Date:||25 May 2017 10:58:26 EDT|
On 23/05/2017 15:12, firstname.lastname@example.org wrote:
> I'm implementing right now a "compiler" for a DSL that used at my work, and I'd like to get your advice for a dilemma I have.
> One of the requirements at the begging was that the compiler should get an input only one file.
> But, it's changed and I asked to add two more capabilities. and they are:
> [ some sort of multiple input file ]
This depends on lots of things. Are you taking something that would have
been one big file, and simply allowing it to be split?
Do the STD common parts, something that would have been part of one
file, now have to be part of each of the multiple files?
How does each file know about what's in the other files, when it's
something not in those STD common included files?
One easy solution (assuming having to compile all the sources is not an
issue) might be to just load all the files into memory and combine them
into one file. Then compile as a single file, dealing with possible
multiple includes, or out-of-order references, if that would be a problem.
But it really depends on how this language works.
(All the compiler projects I do now aim to compile all modules of a
project together. Some will have a hierarchical module system and that
can help: there is one symbol table, with the whole program as the root,
and (as I do it with modules sharing a flat namespace), each source file
or module at the next level.
Below that, whatever is defined within each module. This however is the
symbol table tree, not the parse tree. Individual parse trees exist per
function. This is why it depends a great deal on the language.)
Return to the
Search the comp.compilers archives again.