[Barrelfish] [Barrelfish-users] Design question

[C K Kashyap]

Thanks Pierre-Evariste,

This detailed explanation helped!
Btw ... is there any way, I could get the tic-tac-toe source?
Regards,
Kashyap

On Mon, Feb 15, 2010 at 11:50 PM, Pierre-Evariste Dagand <pedagand at gmail.com
> wrote:

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



-- 
Regards,
Kashyap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/barrelfish-users/attachments/20100217/58b33c53/attachment.html