On Fri, 2007-02-16 at 13:28 -0500, Chris King wrote:
> On 2/16/07, skaller <[EMAIL PROTECTED]> wrote:
> > What are the key features of Felix? Why are you interested?
>
> To me, this question reads "what does Felix do that O'Caml doesn't do?"
> (O'Caml being my current favorite language).
Mine too, though I'm tending to take Haskell seriously now.
> From this perspective, what's
> gotten me interested in Felix is the following:
>
> * Performance at least as good as O'Caml
It isn't: it does some things faster, but for serious
functional programming Ocaml is way ahead .. at the moment.
Ocaml has a real gc .. Felix doesn't.
However score one point for writing up what I consider
a non-negotiable goal.
> * Transparent C FFI
>
> I LOVE that Felix's datatypes are fully abstract and can represent any C
> datatype under the sun. Being able to access existing C libraries with
> little extra work (thanks to flxcc) opens up a world of possibilities not
> readily available in other languages. I've longed for a language with a C
> FFI such as Felix's. The only languages I know of that even come close are
> Pyrex (Python's C extension language) and C-like languages such as Cyclone
> and D.
and of course C++ :)
yep, you score another point.
> * An eye toward verification
>
> Felix is the first general-purpose language I know of aiming to directly
> support code verification. While some languages such as Nice support
> ensures / requires annotations (and about every language supports assert),
> Felix supports more (e.g. axiom and reduce) and they are intended for the
> support of automated code verification utilities. (I haven't had a chance
> to check it out yet but the recent addition of support for Why is exactly
> what I'm looking for!)
This goal is less solid because it just isn't clear if a C++ like
language is capable of supporting it.
Why only generates proof obligations: it can't handle actual
proofs. So if you were trying to prove something and using
Coq as a proof assistant back end you'd have to annotate
your Felix theorem with a Coq proof.
Still .. actually embedding such a proof IN the language
is better than editing the Why file afterwards.
I wish to make as much progress in this area as possible.
I strongly believe this proving stuff is the major
source of optimisation opportunites: you can write
correct high level code without any proofs .. but there
is no way a compiler can optimise it without them.
> * Typeclasses
>
> I'm addicted to O'Caml's solid module system, and typeclasses are even
> better.
No they're not :)
Modules are stronger and more expressive IMHO.
But typeclasses are more convenient for the end user for
simple things.
I heard a conversation on Ocaml list about this .. someone
commented that whilst modules were better, people seemed to
love typeclasses more. So I decided .. we need something
C++ programmers will find easy to use, and typeclasses
are just classes one level up. They have the same problems
as OO (covariance problem etc), but this is unlikely to
be noticed much for basic programming.
And there's no reason we can't have modules too!
[What I mean is modular functors of course]
> * Easy-to-use syntax extension
>
> I often work with DSLs. camlp4 is great, but it's a bear to learn. Felix's
> macro system looks very promising, though I haven't yet had a chance to play
> with it. I think Felix's built-in syntaxes for lexers and parsers is a
> great example of this system.
This is another non-negotiable goal. In particular, the development
methodology is based on it. [I wonder if anyone will ever read this ..]
Felix looks messy and overloaded with features .. and that is
*deliberate*. If you want a feature .. ADD IT.
The point is to get enough real 'I want that feature' features
to badly bloat the system .. and provide use cases for testing
a method of moving it all out into the library.
I don't think one can design (or perhaps choose between available
designs) without use cases.
The integration of the syntax extensions with the syntax macro
processor is quite cool .. but macro processing is not.
It sucks. Ask Erick .. he had trouble getting it to work.
I have had some trouble too (and I wrote the dang thing).
I think perhaps Omega:
http://web.cecs.pdx.edu/~sheard/
is the solution: multi-staged symmetric kinding system.
But I'm still reading the papers.
Anyhow, the bullet point here is that Felix is designed to
allow people to implement DSSL's within the language.
[DSSL = Domain Specific Sub Language]
The 'Sub' means, your DSL is actually part of Felix not
a standalone language.
This is one reason why Felix contains a builtin lexer
and parser.
> If Felix did not have these things (especially the first two) then I would
> see little reason to switch to it from O'Caml (since many of their other
> features overlap). What makes Felix attractive to me is that, besides being
> a decent general-purpose multiparadigm language (which many languages can
> claim), it goes above and beyond to support features found only in niche
> academic languages (e.g. verification and typeclasses) and low-level
> imperative languages (e.g. good performance and transparent FFI) without
> compromising its overall design.
If you can write your app in Ocaml, you should. It is more
stable and probably a better language at the moment.
But there is a lot it does not support, such as
fibres, continuation passing, multi and parallel
processing .. and of course convenient C++ interface.
You will note that whilst Felix now has roughly the same
semantic power as Ocaml .. the compiler is still written
in Ocaml .. :)
Bootstrapping is at least 10 more developers away .. :)
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
