Where it fits

[Philip Herron]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Andrew,

Thanks for that really great reply!

Andrew Whitworth wrote:
> Hello Philip,
>
> There are two paths you could go down, depending on your level of
> interest and your free time to write code:
>
> 1) Write your language compiler using Parrot's PCT tools. This has
> the great advantage of running on Parrot (garbage collectable,
> memory-managed, exception handling, etc) and is written in a subset
> of Perl 6 (which is very high level compared to C/lex/yacc).
> Obviously requires you to rewrite almost everything from the ground
> up, but you'd be surprised how much faster development goes using
> these tools. This is especially true if you already have the
> grammar rules handy because you can transcribe them pretty quickly,
> usually. PCT is part of the Parrot repo and can help insulate you
> from changes to PIR/PBC. So when we do change things, you won't
> need to change your compiler.

This seems interesting, though i am not sure if i want to maintain 2
separate things but I'll see how it fairs out.

>
> 2) Have your compiler output PIR or PBC code which executes with
> Parrot. You keep most of your existing code but need to build a
> PIR/PBC codegen backend and link against libparrot. Parrot executes
>  that generated output. If you wanted to have runtime code
> evaluation you would also need to write the bindings so that Parrot
> could call back into your compiler, which might be non-trivial
> depending on how everything is designed. Parrot was specifically
> designed to allow this kind of stuff (C/lex/yacc front-ends),
> although there aren't a lot of existing examples of languages that
> use it so you may run into some rough patches as you develop (which
> will help us to find and fix them!).
>

This sounds like the solution i would like to try. I could reuse more
of my stuff that way i think. And if i shows how to use parrot in a
different way it could be an interest way of doing it! Maybe creating
a libparrot-code-gen might be an interesting subproject to help this?

> If I may ask, what language are you writing the compiler for?

Its a language I've designed from the ground up it was originally for
a really specific purpose, but i wanted to learn more so its become a
proper language now i guess (as in it does stuff ;) ). Only way i can
describe it is as a mix of Python, Haskell and GNU/make. I am working
on a thesis with it but its really out dated now the language has
changed a little more since i last worked on it then and the
interpreter design is different now, as the garbage collector wouldn't
work that well in my older designs.

I've re-write and redesigned the language and interpreter so many
times now but its finally sorted out this last month and i am happy
with it finally. I'll probably post a link to it all on comp.compilers
when i fix some of the major bugs at the moment, I've been changing
how conditionals and loops work. I would be embarrassed if i posted it
around now because its still early days really, though a lot of the
fundamentals already work fairly good.

Also, if
> you're interested Parrot does need more hackers working on things
> like improved garbage collectors and other subsystems, so your
> expertise in those areas would always be helpful.

This does sound interesting to me, i remember seeing some links to
parrot some time ago, but when i heard the interview that Dan Lynch
from Linux Outlaws did with Allison Randal and Chromatic it sounds
really cool! :) I might try and see if i can help parrot in any way if
i find where i can be useful ;). I was working on a new GCC-front-end
in my spare-spare time there but putting it on hold to concentrate on
this project more*.
*
- --Phil

>
> --Andrew Whitworth
>
>
> On Mon, Oct 5, 2009 at 2:18 PM, Philip Herron
> <herron.philip at googlemail.com> wrote: Hey guys,
>
> I've been looking around your wiki's tutorials etc and it all seems
>  pretty interesting, I've been developing my own interpreter for a
> language I've been designing for some time now. Just not quite sure
>  how it could all fit together if i wanted to create byte-code
> using parrot.
>
> What i mean is, I've been parsing and doing my own runtime and
> garbage collection etc as an interpreter written in C using some
> things like yacc and lex, readline, gnu/mp, mpfr ... . But if i was
> to make an implementation to produce byte-code to run on parrot,
> what do i do?
>
> Can i still use my own parser from the examples I've been looking
> at it seems to be you have your own parser tools? Or am i thinking
> about how it all works wrong. And if i am still able to use my own
> parser i guess it means i must have to try and link against .pir
> stuff, so that probably doesn't work.
>
> Another idea might be if i was still to use my own parser and bits
> and pieces, is it safe to just produce byte-code manually from a
> program i make on my side and run it on parrot if i see more what
> the byte-code looks like.
>
> Anyways parrot seems like a cool project :) i should really start
> playing with the examples now. So i understand it all a bit better.
>
>
> --Phil
>>
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrKSMQACgkQAhcOgIaQQ2HrcACfT5jqW8DY9cWnGHbDCFZI88ki
NNIAmwQw3cX3rL2rmoeSXpRu/PB8zYtd
=u2Sr
-----END PGP SIGNATURE-----