On Tue, May 26, 2009 at 7:17 PM, john skaller <skal...@users.sourceforge.net> wrote: > > How would this be used without a line editor? > As it is, I haven't got line editing in Python and it sucks.
I'm using a program called rlwrap (http://utopia.knoware.nl/~hlub/uck/rlwrap/), which is a readline wrapper that at least adds history to an interactive commandline tool. It's pretty handy to use with repls that don't use readline. > Binding etc must then proceed from the symtab to executable every > input. > > The easiest way to do this is for Felix to loop in the driver > after creating the C++ code, pausing for more input. > It should make some file like "go.flag" when ready. Once I get to the backend, I'm planning on writing an llvm jit backend instead of using c++. That'll be a big project in of itself though. > Inside the compiler you will need to delete the caches. > These are mostly Hashtbl so they should be easy to clear > even if they're member of immutable data structure. Yeah, that's something that I'll need to be careful of. I'm not sure how we'll be able to do things like roll back a symbol if there's a type error. I tried to make the macro_state/desugar_state be functional but it was too much work, so I left it stateful. > Note: in principle, it should be possible to "increment" > the fully bound symbol table, that is, bind the whole standard > library once, then just each input of the user is added. > > At present the binding code binds everything, then does > a garbage collection pass: you can't do the garbage collection > since subsequent inputs might use the code. Yeah, we'll have to be able to turn that off. > It would actually be useful to modify flxg so that when you say > > flxg std file > > it compiles "std" right up to the bound symbol table, and then > stores it to disk. Next time it just reloads std, already bound. > Keep this in mind during REPL development. Yeah, I noticed that this whole process seems to be working towards being able to incrementally handle imported files. It's not that much of a leap from incremental binding to just loading a cached bound table. > Finally: I don't really see what this REPL buys. A simpler way to > implement one is a Python script that grabs some text, saves it > to a file, runs Felix on that file, then grabs more text, adds it > to the end of the file, and does it all again. > > In fact, such a script has been written by me using TkInter, > it should still be in the repository, but it uses a graphics window > instead of a line editing loop. And allows load/save etc. I use REPLs a lot with the way I work. With certain problems, I really like being able to throw together an algorithm via a REPL, or test out a library to see how it works. At work, we make heavy use of maya's python interface in which much of the functionality is exposed through the python REPL, so it's easy to modify the app via little commands. I also think it's a great learning tool. For instance, I learned ocaml through the REPL. And while I haven't personally experienced this, erlang makes extensive use of it's REPL to control what's going on across it's network, and that could be useful for us if we ever do a distributed system. And finally, I'm having a lot of fun trying to figure out how to do it. It's a great way to learn the innards of felix, and good preparation for that llvm backend I've been dreaming about :) ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
