hi! On Sun, May 20, 2012 at 2:55 AM, Vasily Chekalkin <[email protected]> wrote: > Hello. > > Welcome back :)
thanks :-) > > For the record, current nqp-rx based ops compiler does parse subset of > C already. In opsc_llvm branch it does parse even more. I would > suggest to join efforts in defining "C subset" which we are going to > use as m1 ops language. > > Most problematic parts iirc was: > 1. Macros. C macros are pure evil. If we are going to support > free-defined C macros it will require a lot of work. Limiting them to > VTABLE macros will reduce this issue to trivial. > 2. Ambiguous casting. > 3. Implicit string concatenation. Thanks for sharing. I can see how scattered efforts are not helpful. It wasn't so much an effort to implement parts of C per se, more that it's inspired by C: it's easy to read, easy to learn, and easy to implement so far. Also, my efforts so far were an expression of my self indulgence in some good hacking sessions, which I hadn't done for a long time. It's been fun :-) In my opinion, for M1, we shouldn't strive for a subset of C per se. There's many things wrong with C, and those things cause a lot of pain and bugs. If there's going to be a language M1 or Lorito to implement most of parrot (incl PMCs) it would be a good idea to define a language that prevents many of those bugs, to create a language that's really stable, clearly defined, and so on, and that forbids bad constructs. For instance, no goto statement! (I'm even no fan of break and continue statements). C's preprocessor is a cheap way of doing modules properly, but it's kindof awful. There's better ways I'm sure to support multi-file programs. I think it would be a good idea to think well about how to encourage sound programming practices (C doesn't really), and implement a language that does that well, while still being easy to learn by C programmers. Meanwhile, my goal was to (1) indulge in my need for some hacking creativity, and (2) create a clean and simple language implementation that targets M0. Consider it a prototyping effort to identify gaps in M0 and see how far we can get with little effort. cheers kjs > > -- > Bacek > > > -- > Vasily > > On Sat, May 19, 2012 at 6:15 AM, kjstol <[email protected]> wrote: >> hi there, >> >> I've indulged in some hacking time, and implemented a simple subset of C. >> Attached is a zip file, just type "make" and it should work (assuming >> you have bison and flex). >> >> What it currently does, it generates the parsed code from the AST (mostly). >> Not everything of the language is supported yet (e.g., parameters >> etc.) The parser would have to be fixed a bit, it has some known >> limitations. >> >> The idea next is to implement a simple code generator to generate the >> M0 ops that have been spec'ed so far. >> There are many todos (e.g, thread-safety of the compiler), >> register-allocator, etc.) most of which would be easy to implement. >> For now, the focus would be on a simple and clean language >> implementation that generate M0. >> >> Comments welcome, >> kjs >> >> _______________________________________________ >> http://lists.parrot.org/mailman/listinfo/parrot-dev >> _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
