Re: Some Questions

[Andy Wingo]

Hi Michael,

On Mon 29 Mar 2010 08:18, Michael Lucy <address@hidden> writes:

> I'll probably apply to work on Python then.

Cool.

> 1. How fast would you need it to be? (i.e. am I going to be writing C
> code or can I stick with straight Scheme?)

Scheme! Depending on how it's compiled, the resulting code probably
won't run quite as fast as CPython (though it could in the future) --
due to the need for many calls to go through GOOPS dispatch -- but the
speed of the compiler is ~unimportant, because the compiler's output
will be cached.

> 2. I was thinking of compiling Python into Scheme code, but you
> suggest in that link compiling to Tree-IL instead.  Could you
> elaborate on the logic behind that more?  Does it just result in
> faster programs?

Tree-IL is the right thing IMO, mostly because it allows you keep source
location information, but it also allows you to express more precisely
what you want to compile to. You don't want to run your compiler's
output through the Scheme syntax expander, that's unnecessary.

Also tree-il is the right place to hook into Guile's compiler
infrastructure. 

>> Hm, another thought, project-wise: have you heard of parsing expression
>> grammars before? Here are a couple links:
>>
>>   http://en.wikipedia.org/wiki/Parsing_expression_grammar
>>   http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html
>>
>> Writing a good PEG parser library, together with docs and example
>> grammars, sounds like about a 1.5-2 month project -- just about right
>> for the SOC.
>>
>> We do have a LALR parser generator; I said something else about it in
>> the mail to guile-devel.
>
> A PEG parser seems like a shorter project than two months, but maybe
> writing one that's up to GNU standards would take a while.  Would you
> prefer this over a python compiler?  I'd be up for it; I mostly want
> to be writing something intellectually interesting in Scheme.

Ah, I should have responded to you before I responded to "No Itisnt"; if
you're down for this, let's do it then. I suspect that it's a project
that would take 2 months to do *well*:

  * Compile PEG grammars at syntax time using a macro
    - into state-machine-like lexically-bound closures
    - see LPEG VM for example
      http://www.inf.puc-rio.br/~roberto/docs/peg.pdf
    - potentially augment Guile's VM with needed instructions
  * Procedural, LPEG-like interface?
    - run the compiler at runtime?
  * PEG grammars as text?
    - Guile PEG language, parsed by PEG itself?
  * Benchmarking
    - LPEG benchmarks would be a good first start
  * Test suite
  * Docs
  * Stream parsing?

If you finished the first tasks, figuring out an efficient way to do
stream parsing could well take all the rest of the time. (The LPEG paper
works on strings.)

So if you're down with it, perhaps you can do the PEG stuff, and No
Itisnt can work on Lua. There's definitely enough work for everyone :)
Hopefully the GOOG comes through with funding.

> Anyway, sorry I haven't written for the last 3 days.

NP!

> You said you wanted to see some code so I wrote some, but I kinda got
> caught up in it. I hosted things up at
> http://people.cs.uchicago.edu/~mlucy/ if you want to take a look.

Wow, that's great stuff! Working code is often a precursor to clean
working code, so that's great.

> peg.scm is a PEG parser.  It works on the things I've tested it on,
> but I'd be amazed if there weren't any bugs lurking there.  It's also
> in need of a serious refactoring--please don't think my finished code
> looks like parse-expression.  It works but I wouldn't consider it
> finished by any standard, I just ran out of time (applications open
> tomorrow).

Ah right, the GOOG moves quickly. I think it's a great starting point,
though we really want it to be a PEG compiler rather than (in addition
to?) an interpreter, so I think the LPEG paper should be helpful here.

> rvector.scm is a resizable vector library--not terribly useful, but I
> wrote it to get familiar with guile before writing peg.scm (and as
> evidence that I do, in fact, produce reasonably clean code once the
> bugs are ironed out).

Nice. I'm impressed that you managed to parse the doc sections on
structs, they're quite obtuse. FWIW, it's usually clearer to use a
higher-level abstraction, like records, as in srfi-9. And excellent that
you found a bug, too.


So, let me know what you think about PEG, if you think it's the right
size for summer. I think it has great potential, and implementing it
well (as a compiler and procedurally) will be of great use. Otherwise we
can go ahead with Python, if that's to your liking.

Cheers,

Andy
-- 
http://wingolog.org/