Hi Michael, On Mon 29 Mar 2010 08:18, Michael Lucy <michaelgl...@gmail.com> 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/
