Re: Designing a Domain-specific language

On 25/05/2017 20:51, dror.openu@gmail.com wrote:
> On Thursday, May 25, 2017 at 5:58:28 PM UTC+3, bartc wrote:
>> On 23/05/2017 15:12, dror.openu@gmail.com 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 ]


> The purpose of this language is to configure jobs we have in our system.
> (the compiler will convert it to "byte code" that will be executed by the interpreter).
> A good example is when you want to share configuration between group of jobs (or want to "inherit" configuration from a job).
> You want to be able to create a "base" file, and use it somewhere in the project (I want to parse the "base" file only once, even if it imported multiple times).


A lot more information is still needed.


Presumably you can't split a file at arbitrary points, as in the
middle of a token, or in the middle of an expression or statement.


The separate files must make sense by themselves. But, could they then
meaningfully be parsed as independent files? If file A refers to 'X',
but X is now declared in file B, how is that going to work? That is, if
knowing X is necessary to successfully processing A.




>> 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.
>>
>
> I prefer to parse each file separately, and only once.
> it will also give a good, readable errors (file name + line number.)


You mean, only once during the processing of the whole program?


Is there any output resulting from processing each file? A traditional
compiler turns a source file into an object file. Then it won't need
compiling again until the source changes (or the compiler does).


Or is the output into memory? That sounds like all the files must be
processed, perhaps in a particular order.


Perhaps you can give a simple exercise of a short program in the source
language, and what it looks like split into two or three files.


--
bartc

Return to the comp.compilers page.
Search the comp.compilers archives again.