Thanks Pierre-Evariste,<div><br></div><div>This detailed explanation helped!</div><div>Btw ... is there any way, I could get the tic-tac-toe source?</div><div>Regards,</div><div>Kashyap<br><br><div class="gmail_quote">On Mon, Feb 15, 2010 at 11:50 PM, Pierre-Evariste Dagand <span dir="ltr"><<a href="mailto:pedagand@gmail.com">pedagand@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
Here's my *personal* take on that.<br>
<div class="im"><br>
> I have some follow on questions -<br>
> Q1. Are there any theoretical limitations to the kinds of C targets that<br>
> could be generated with FoF like DSL backend?<br>
<br>
</div>In my opinion, there is no theoretical limitation. FoF is<br>
Turing-complete, after all. Moreover the abstraction layer introduced<br>
by FoF is quite thin, so it should not be a problem. Even if it were,<br>
FoF is extensible: you can introduce your own idiom, extend the<br>
compiler, and keep going.<br>
<div class="im"><br>
> Q2. If the answer to Q1 is no, then are there situations where the "C" code<br>
> would be more readable or verifiable than the logic implemented in DSL?<br>
<br>
</div>When you say "logic implemented in DSL", this is actually a<br>
*compiler*. A compiler comes with its own complexity, such as<br>
parsing, AST manipulation, translation to FoF code. I can think of<br>
thousands of examples where writing a piece of code is better than<br>
implementing a compiler to generate the equivalent code. It needs to<br>
be worth the effort.<br>
<br>
It is worth the effort when the DSL captures some high-level semantics<br>
properties, and/or enforces some invariants, and/or scraps some<br>
boilerplate, etc. Otherwise, designing a DSL and the corresponding the<br>
compiler to avoid writing some random C code is a bit extreme. I will<br>
not improve readability, as instead of "some" lines of C, you now have<br>
maybe 200 lines of Haskell. I will hardly improve verifiability as<br>
you're not capturing any major invariant, hence the compiler cannot<br>
enforce or test any property.<br>
<br>
> [...]<br>
<div class="im">> Later however, I began to realize that doing the translation from the spec to C was an utterly mechanical<br>
> task!<br>
<br>
</div>You should take a look at the Devil system I pointed to you. Or,<br>
equivalently, Mackerel in Barrelfish's source code.<br>
<div class="im"><br>
> So, in theory, we could have a set of N components written in M DSL's (or perhaps<br>
> just one DSL) and all of them output a set of N c files that get compiled<br>
> and linked into one big executable monolithic kernel.<br>
<br>
</div>Yes, that's the theory. Shall I mention the theoretical difference<br>
between the theory and the practice? :-) More practically, what about<br>
the following scenario:<br>
<br>
"You have a set of N strongly-specified components written in M DSL's<br>
and you have a low-level language to glue these components together.<br>
At compile time, the components are compiled into the glue language,<br>
the resulting files are linked into an executable kernel."<br>
<br>
This is precisely the view we have defended in the FoF paper.<br>
<br>
When building a system, you've no clue of what kind of problem you'll<br>
encounter. So, you just solve them as you go, using your favorite<br>
weapon, such as C for example. However, as time goes, you've a better<br>
understanding of the problems: you've built a mental abstraction of<br>
the raw C code. In programming language terminology, this is called a<br>
semantics: you've understood the high-level semantics of this C code.<br>
If that abstraction is pervasive in your system, it is worth writing a<br>
compiler, hence formalizing that semantics.<br>
<br>
<br>
Hope this answer your questions,<br>
<font color="#888888"><br>
--<br>
Pierre-Evariste DAGAND<br>
<a href="http://perso.eleves.bretagne.ens-cachan.fr/~dagand/" target="_blank">http://perso.eleves.bretagne.ens-cachan.fr/~dagand/</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br>Kashyap<br>
</div>