On Sep 6, 2006, at 9:01 PM, skaller wrote: >> I would help with the documentation problems but >> since I have little idea of what is available in this language I am >> rather stuck. > > Yup, the tutorial and regression tests are the best source.
Hmmm... I haven't looked closely at the regression tests. I have worked through the Reference Manual, Tutorial, some of the Grammar and some of the source code--especially the parts you referred me to and a bit of poking around in lpsrc/flx_types.ipk. In case you couldn't tell from the emails, somehow the expectations I have--in this case I must make certain assumptions--on the capabilities or behavior if the system have been tempered a bit by fully-developed languages. (Once you get into the open source world, of course, you get to see things in libraries only company employees and hackers would see otherwise. Take the renowned GMP, for example: poke around a bit and eventually you will follow a function to a header file with one line of text "not implemented yet.") The bigger the system, the bigger the mess. >> On the matter of using a C++ list<>, I meant implement your own >> container (I could at least help with that). > > We could, but why? The Felix one should generate good code. > If it doesn't, we need to fix Felix so it does. It should > be faster than both Ocaml and Haskell (once the GC overhead > is removed) because Felix products are not boxed. Well I can't argue about Haskell-speed but going head-on with OCaml is a high aspiration. >> The gcc-STL does allow >> you to override the allocator but you would still run into the >> problem of storing higher-level values (such as a list of lambda >> expressions) in it. > > Yup. Overriding the allocator doesn't help: we need shapes > for all the structs, which tell where pointers are: hard to > know that for foreign code. > >> As for syntax, > > Indeed. There's a tradeoff. Being able to point at Felix code > and say "See, it's really an upgrade of C++" is part of the > design goal: bosses need convincing too, and they only see > concrete syntax. Just watch out for names like "union" that may create undue expectations. You know better than I do what to watch out for: C++ had to worry about that when working from C. > You could .. there's also a reglex facility and a ready made > lexer in the library. Yes. It is very good. > There's ALSO a GLR parser but it's been > adandoned. ... and I just spent a little while reading through that stuff... > One day we'll bootstrap. A sure sign of maturity. > Yeah, you miss a 'minor' detail here: pattern calculus is only > implemented for *type expressions*. That's why my examples > look like > > var x : typecase .. endcase (int + long) = 1; > > .. the typecase is a *type* case, applied to types. > > The reason: it's experimental, and the implementation for type > expressions is done entirely at compile time (since there is > no dependent typing). I was under the impression from a prior email that you had implemented the constructor-match. Ho hum. In that case the typecase construct can't be used for generic functions, at least not in a type-safe fashion. > When you think about, for example, path polymorphic searching, > it would seem some of the pattern calculus operations would > have to be done at run time.. which means a run time representation > of patterns .. this sounds hard compared to calculations with > Ocaml combinators at compile time .. :) It might not be that hard for the general language--although you might run into trouble for the runtime system. The main thing to remember is that the language *must* carry types as real instantiations or it is not type-safe because once you get into more complex programs (i.e., databases, bootstrapping, named message senders and receivers, anything dynamic) you must be able to work with types at run-time. You know at least as well as I do that type safety goes a long way towards controlling program behavior; type systems are also great for reasoning: take a look at reasoners like Isabelle (uses PolyML) ( at http://www.cl.cam.ac.uk/Research/HVG/ Isabelle/ (PolyML is an interpreter-only ML system, at http:// www.polyml.org/) and outrageously interactive systems like Epigram (in Epigram you write a program by interacting with an interpreter and filling in the details it can't figure out for you), at http:// www.e-pig.org/ . You could always defer the 'real' type system to the C++ runtime but then you would always have to fight the C++ system where it conflicted with Felix's categorical set. Try reading: http:// research.microsoft.com/~simonpj/Papers/pj-lester-book/ . It's basic, on a lazy functional language, but there is some stuff in there. For other references--the ones I know about--see http:// www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ (more on GHC, but you might find some neat ideas in the sections, "The Real Story about Variables, Ids, TyVars, and the like" and "Data types and constructors." For some top-notch simplifier programming see http:// repetae.net/computer/jhc/ (JHC compiles Haskell into pure C with no runtime system). See "Match Compiler Notes," at http://www.smlnj.org/ compiler-notes/matchcomp.ps for SML/NJ's pattern matching system-- there is also a paper there on SML/NJ's "High-Performance Garbage Collector," in case you get overwhelmed trying to comprehend OCaml's, at http://www.smlnj.org/compiler-notes/93-tr-reppy.ps . And definitely, do not forget to take a look at http://www.cs.chalmers.se/ ~rojemo/thesis.html on garbage collection and memory efficiency in lazy functional languages--good to look at the other side (this if from the nhc98 compiler; another great bit of source code to look through because a fair bit of it is in C, see http://haskell.org/ nhc98/ ; the successor to nhc98, yhc, http://www.haskell.org/ haskellwiki/Yhc is written mostly in Haskell but is also working on an interactive interpreter written in Python (pyhi). (BTW, interpreters seem to be all the rage, these days.) These are just sources of ideas; using a type system based *not* on name-tables but on category theory Felix may take a fully numeric approach--but you might need a reasoner system to really handle it well; graph reduction for simplification may not be powerful enough. -Pete ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
