On Aug 30, 2006, at 4:54 PM, skaller wrote: >> at least to me, Felix is an >> easy functional handler for C++ (although Felix does not have any low >> level operators--you have to know C or C++ to do that). > > Well things like closures, variants, and pattern matching smack > of an FPL .. but really they have very little to do with functional > programming. Advanced languages like ML and Haskell provides these > features not because they're functional .. but because people who > knew some basic theory knew these features were essential in > *any* language.
I was not talking about closures, variants or pattern matching. I was talking about functions as first class values, currying and partial application. Unfortunately, no functional language outside of Haskell (or a Haskell clone) has quite the ease of functional composition. Point-free style is exceptionally succinct. The downside is that everyone may freely create new operators (operators are simply infix-functions) so you may see all kinds of crazy stuff and even overlap between modules. (A notorious overlap is the "standard" (!) --index subscript function-operator, which works like array[1] for things like Lists, Sets, Trees and Finite Maps (aka. Maps).) Felix has the abilities to return a function as a result and to take functions as arguments. Higher order functions, currying and partial application are difficult operations in C++: Lambda, FC++ and FACT! go to great lengths to overload standard C++ operators (though in my opinion FC++ has shown restraint and done so more elegantly) and to derive return- types using nested, recursive templates. The important point to remember is that Templates are feature of C++ that are a functional language only as a side-effect: as far as I know (you are the one who should know the best), Templates were designed to give C++ a standard generic library similar to Ada's, without resorting to macros. > ML isn't a functional language: it has mutable store. So does > Ocaml. These days even Haskell does :) According to the definition I gave above, ML is a functional language. I simply isn't a "pure" functional language. Lisp isn't a "pure" functional language, either, but never claimed to be. Haskell attempts to be pure and to a large extent does. Mutable variables (and Arrays) are not succinct and are not necessarily fast-- like any complex programming language you may use features contrary to how they were intended to be used, but you may also make things difficult for yourself. I might explain the reason functional languages eventually move to mutable variables abstractly: functions do not operate without something to operate on--eventually it all gets down to data and variables. On a practical level, mutable variables were a necessity in Haskell for concurrency and programmers pulled them out of that realm--why? because functional languages are hard! Normal people don't think so abstractly. > Any procedural, imperative, or other language should have > all these things: imperative languages still have expressions: > they still have a functional component. One of C's most powerful features is the variable-length parameter list. Printf is a function but it is practically used as an operator. (How many people check the return value of printf to see how many characters were printed?) A curious programmer using GCC with GNU extensions and C99 might be able to tweak something of a functional-seeming program by using __func__ and typeof(), but it would be static at best, like an internal version of the standard 'calculator' exercise. The point I am trying to make is that having one or a few functional components may be a necessary condition but it is insufficient. You might verify this yourself--functional languages have a different feel to them. > If there's anything 'novel' in Felix, it is actually > the user space high performance 'microthreading' or fibration .. > and that's entirely a procedural/imperative construction: > Felix fthread can only be procedures and they can only > be spawned by procedures not contained in functions. The only other languages that have attempted that kind of built-in microthreading seem to have been functional--maybe I'm wrong. Sisal, for example was one of the first languages with built-in parallelism and is essentially a functional language. Too bad Sisal never caught on: it has elegant syntax. > [The machine stack .. it gets in the way, the fthreads are > continuations, which won't work unless the machine stack > is empty] Interesting. >> In other >> words, on top of C++, Felix is a real programming language, capable >> of being used in real-time embedded systems. > > Indeed .. it was designed originally for a telco application. Now there's an interesting bit of history. That should probably go on the wiki :) > But then again, parallelism and real time behaviour are no > longer special requirements. Almost all modern applications > require these facilities because most of them play with networking. True. The thing for making a programming language popular is how easy it is to work with things like parallelism. Applications may require real time behavior but few programming languages can deliver truly real-time performance. >> The (relatively) new Felix wiki you put up seems to target library >> designers. > > Of course. Everything is a library. Even C programs are just > libraries, with one distinguished functions, main(). Here is an analogy: what is the knowledge in books worth if you never put it into practice? Don't take my note on the design of Felix askance, however. I'm glad Felix targets libraries (both dynamic and static) because libraries should be fast, stable and multithreaded, or at least thread-safe, and Felix provides that with ease. >> I would be very happy if something displaced Java-- >> Microsoft basically answered that with C#, another despicable >> language-- > > C# version 1 was just a Java clone. However the latest C# is > getting much better. It is worth looking at. Remember MS actually > has real academics and researchers working for them. Recall the > lead developer of Haskell .. Simon Peyton Jones .. actually works > for Microsoft :) > > C# has true generics (unlike Java) and version 3 actually has > advanced features like type inference -- as well as overloading, > which is some mean feat! The algorithms are quite advanced. I agree. I have followed F# a bit. It's the general C# syntax and the .NET system I hate. Programs should be stand-alone, leaving the operating system to manage resources. As for type inference and overloading, I have heard praise of that elsewhere as well. I have played with Mono a little (partly out of respect) but I can't get around the unaesthetic quality of having a program that is completely tied to a system outside the OS. At least with Haskell you can have stand-alone binaries; the same with OCaml and MLton (SMLNJ can have stand-alone binaries, but they are *huge* because they carry the entire standard library and runtime system with them--kind of like Lisp, that way). Scripting languages are different, but C# is not a scripting language. >> The big downside to Haskell is how extremely >> difficult it is for a programmer to debug memory leaks and make code >> efficient (complaints #2 and #1, respectively). > > This is a temporary state of affairs. Haskell is very slow at > some things. But it is getting better. Haskell will improve. It seems to be gaining in popularity, especially among the post-graduate crowd, due in part to how accessible it is (more so than ML) and chiefly due to its style and elegance. > I'd say the main problem with Haskell is really portability. > Haskell code is portable .. what I mean is the availability > of the compiler. It's a real pain to get running. Fortunately for you, the Linux port seems to be particularly stable :) > This too will change, IMHO, but the world just isn't ready > for Haskell yet, and Haskell isn't ready for it. > >> The key is programmer productivity. > > Program performance matters too. C/C++ proves that. Definitely. >> Java has taken off because it >> has a gigantic base of easy, cross-platform libraries and it was one >> of the first languages with good library support to be garbage >> collected: without those, no one would use it. > > I agree. The key library was Swing, the GUI. > >> Felix could go head- >> to-head with functional languages on one singular basis, the same >> reason programmers new to functional programming migrate to OCaml >> (besides the speed): Felix can be both procedural and functional. >> Going pure functional is a big hurdle. > > I don't believe in it. Neither do Haskell people: STM monad, > I/O etc. The fact is, people think in terms of both environment > (declarations) and action (procedures). Any real programming > language needs both. I didn't mean the programming language--to interact with the outside world, at least sequencing is certainly a necessary feature for any language. I meant the difficulty people seem to have learning to program in a (mostly) pure functional language--especially learning to program well in a functional language. Too many people who learn OCaml use the functional aspects for things like parsing and rely heavily on the imperative/procedural features because that is how they are used to thinking. Haskell may have some mutable variables but for the most part you have to change your mind set to work with the standard, immutable variables. > The big problem has always been how to integrate them. > The way ML does it is just wrong. Agreed. > The 'right' way to do this is with coalgebras, but the theoreticians > haven't provided enough stuff yet :) I think coalgebras are good way for a compiler to reason about sequential procedural operations but stating such an operations in a programming language would be difficult at best. > Unfortunately, D is basically a souped up object oriented language. > In my view it misses the boat: the future is in functional programming > and parallelism along with plain old procedures: there's a place > for OO in there, but it should be a 'feature' not a fundamental. Agreed. > Ocaml's FFI is not that hard to understand, but it is > very laborious to construct the bindings, and doesn't > seem amenble to automation. Laborious. That is a very good description. My personal problem has been the 30-bit Int. > SDL. It's not a GUI library. That's the point :) SDL is great for games, but you would essentially have to write your own GUI library to work with it. > The problem is, most GUI are brain dead. They're all based on > callbacks. Agreed. > Good libraries, such as Microsoft Windows, don't hide this. > Windows actually isn't callback driven: you have to dispatch > messages yourself. If Felix had a .NET binding it might help with the Windows GUI. > Unfortunately, wxWidgets seems to hide the event loop. > Felix provides its own scheduler/event loop: I don't see > any way to merge the event loops. There are ways to call wxWidgets from your own main() routine--but you have to do without macros. Once you have main, you can manually call wxWidgets events or take control of wxWidgets events by deriving your own event class and re-defining the events, putting your controls in the middle. In the end, the GUI library should only handle the user interface. > Of course, it is easy in theory to solve this problem with > a client/server interface .. the problem is GUI's are typically > HUGE and we'd have to wrap a lot of functions. Yep. GUIs are a big project. There is a wxPython--maybe you could get some pointers from there? >> If you want a good >> basic GUI to work with, you might try FLTK, at http://www.fltk.org/ . > > Unfortunately .. doesn't seem to be re-entrant: from a tutorial, > these lines condemn it: It Ultimte++ is also not thread-safe. Probably due to the problem of integrating threads into an event loop. > Gak. First rule of programming: everything should > be re-entrant unless it cannot be (eg signal handlers > must access static variables). Definitely. -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
