I find modern functional programming languages and the paradigm in general to be very interesting. A lot of functional programming languages are able to generate efficient native code either by using C as an intermediate language or with their own code generators. I'm talking about languages like Haskell, OCaml, LISP or Scheme (SBCL, Chiken, Gambit and etc). But knowing that functional programming languages requires a big runtime library, that is usually implemented in C (for garbage collection for example), I'd like to ask is it really possible to create bare metal code in such language and only using it without the need to go back to C (for example for OS development, or for running native code on embedded device without operating system)? Is there any functional programming language that doesn't depend on runtime (even if it would be a language subset)? Is there any functional language in which I can reimplement the runtime that it needs (for example languages like Ada, D, Nimrod, Pascal has runtimes that are written in the language itself)? What alternative functional languages do I have for bare metal development these days?
Why such hate for C? Functional languages have to use a lower-level language for producing machine-level code.
And you can also write C in a very pure functional way. C offers to the developer the freedom to follow any programming style she wishes.
You can easily follow the functional paradigm in C by applying principles that you have learned from other functional languages, i.e.:
No mutation.
No malloc.
Avoid state.
Model in terms of verbs rather than nouns.
Use recursion instead of iteration.
et.c.
There is a book with an intro to Functional C.
I'd like to ask is it really possible to create bare metal code in
such language and only using it without the need to go back to C
Bare metal/machine-level/object code are 1GL (1st generation programming languages) made of binary numbers, represented by 1s and 0s.
Most 3GL or 4GL that use a compiler can generate object code.
Is there any functional programming language that doesn't depend on
runtime (even if it would be a language subset)
Well, every application that runs on top of an OS has to use the OS's API. Nearly all popular OSes are written in C/C++. That includes Windows, Linux, MacOS, Android et.c.
So, when creating an app for an OS, you may have to depend on the OS's runtime environment (that is usually written in C/C++).
Is there any functional language in which I can reimplement the
runtime that it needs (for example languages like Ada, D, Nimrod,
Pascal has runtimes that are written in the language itself)
Yeap, you can write your own runtime library for any language you wish, but that's not an easy task to do.
What alternative functional languages do I have for bare metal
development these days?
I suggest that you choose your favorite functional language (Haskell, F#, Scala or whatever) and just forget about the runtime. There are many and good reason that it is written in C. And AFAIK that isn't going to change anytime soon.
By programming in Scala you use the JVM and with F# the CLR or the WinRT. Maybe these options could help you.
EDIT: If what you really want to ask is if it is possible to write an OS in a functional language, then the answer is yes.
House is an OS written in Haskell. The FFI provides the necessary functionality for (a) calling low-level routines for accessing hardware, and (b) managing memory explicitly.
MirageOS is in OCaml, and there have been OSs implemented in ML.
Generally, any "Turing Complete" programming language can be used to create an operating system, and most functional languages like LISP, Haskell, OCaml, and so on are Turing Complete.
I'm thinking there will be very few (if any) alternatives since the primitives will then be system dependent and your object file needs to have it's own GC. (functional languages need a runtime GC)
You can make your own domain specific language in your favorite functional language, perhaps Scheme, that utilize some sort of assembler, like Sassy, to eventually output raw machine code. But really this is just making your own compiler.
A much simpler option to use C as an intermediate. Many does this since most systems have a C compiler. Devices comes with reference implementations in C.
A different alternative is to make a system like SBCL cross compile to your architecture and use it as the runtime OS of your device.
BTW: SBCL has very little implemented in other languages than Common Lisp. The main part is probably the GC. The GC code could have been implemented in CL, but that would have made debugging far more complex and with a buggy GC you get all sorts of strange behaviour.
Related
I was told this to be the case by someone but never quite understood why and didn't believe it. Doing a check of https://en.wikipedia.org/wiki/Foreign_function_interface it seems to be the case. Is this true? And if so why?
No. A functional programming language is simply one which encourages the treatment of functions as values in their own right. This is orthogonal to whether it integrates well with other languages. Indeed, Clojure, Scala, and F# are designed to interoperate with Java, Java (again), and C# respectively.
It might take some work to adapt the API to the idioms of the target language. But this issue isn't unique to functional languages—most C interfaces won't look great as-is in Python either! And this work is optional: the Haskell network package is but a thin wrapper around Berkeley sockets, yet people are more than happy to use it.
I think 100% pure functional language can by its definition not interface at all with the outside world
That's a common misconception.
A pure functional language does not ban side effects; it annotates them—whether it be through an IO monad (Haskell), linear types (Mercury), or algebraic effects (Idris). In such a language, calling a foreign function would feel no different to any other I/O operation.
Moreover, if the programmer knows that the foreign function is pure (e.g. an LAPACK routine) then they can overrule the compiler and declare it as such. In Haskell, this can be done by omitting IO from the function's signature.
I'm trying to calculate a Student-t probability. I really need the incomplete beta function for this, but I can't find any good function in Lua. Does it exist?
I've ported over the code from Numerical Recipes in C, and it works, but it's not open source license. I need something with a real license, like GPL, MIT, etc.
There's also Apophenia, at http://apophenia.info/ . It doesn't yet have Lua bindings, but I'd even be willing to work with you on developing one. It's plain C and its only complication for binding is the setup for variadic functions. Even this is not especially complicated; just push a lot of extra nils onto the stack as needed.
Lua Fun is a high-performance practical programming library designed for LuaJIT tracing just-in-time compiler. The library affords a set of extra than 50 programming primitives usually determined in languages like Standard ML, Haskell, Erlang, JavaScript, Python and even Lisp.
I am curious how functional languages compare (in general) to more "traditional" languages such as C# and Java for large programs. Does program flow become difficult to follow more quickly than if a non-functional language is used? Are there other issues or things to consider when writing a large software project using a functional language?
Thanks!
Functional programming aims to reduce the complexity of large systems, by isolating each operation from others. When you program without side-effects, you know that you can look at each function individually - yes, understanding that one function may well involve understanding other functions too, but at least you know it won't interfere with some other piece of system state elsewhere.
Of course this is assuming completely pure functional programming - which certainly isn't always the case. You can use more traditional languages in a functional way too, avoiding side-effects where possible. But the principle is an important one: avoiding side-effects leads to more maintainable, understandable and testable code.
Does program flow become difficult to follow more quickly than if a >non-functional language is used?
"Program flow" is probably the wrong concept to analyze a large functional program. Control flow can become baroque because there are higher-order functions, but these are generally easy to understand because there is rarely any shared mutable state to worry about, so you can just think about arguments and results. Certainly my experience is that I find it much easier to follow an aggressively functional program than an aggressively object-oriented program where parts of the implementation are smeared out over many classes. And I find it easier to follow a program written with higher-order functions than with dynamic dispatch. I also observe that my students, who are more representative of programmers as a whole, have difficulties with both inheritance and dynamic dispatch. They do not have comparable difficulties with higher-order functions.
Are there other issues or things to consider when writing a large
software project using a functional language?
The critical thing is a good module system. Here is some commentary.
The most powerful module system I know of the unit system of PLT Scheme designed by Matthew Flatt and Matthias Felleisen. This very powerful system unfortunately lacks static types, which I find a great aid to programming.
The next most powerful system is the Standard ML module system. Unfortunately Standard ML, while very expressive, also permits a great many questionable constructs, so it is easy for an amateur to make a real mess. Also, many programmers find it difficult to use Standard ML modules effectively.
The Objective Caml module system is very similar, but there are some differences which tend to mitigate the worst excesses of Standard ML. The languages are actually very similar, but the styles and idioms of Objective Caml make it significantly less likely that beginners will write insane programs.
The least powerful/expressive module system for a functional langauge is the Haskell module system. This system has a grave defect that there are no explicit interfaces, so most of the cognitive benefit of having modules is lost. Another sad outcome is that while the Haskell module system gives users a hierarchical name space, use of this name space (import qualified, in case you're an insider) is often deprecated, and many Haskell programmers write code as if everything were in one big, flat namespace. This practice amounts to abandoning another of the big benefits of modules.
If I had to write a big system in a functional language and had to be sure that other people understood it, I'd probably pick Standard ML, and I'd establish very stringent programming conventions for use of the module system. (E.g., explicit signatures everywhere, opague ascription with :>, and no use of open anywhere, ever.) For me the simplicity of the Standard ML core language (as compared with OCaml) and the more functional nature of the Standard ML Basis Library (as compared with OCaml) are more valuable than the superior aspects of the OCaml module system.
I've worked on just one really big Haskell program, and while I found (and continue to find) working in Haskell very enjoyable, I really missed not having explicit signatures.
Do functional languages cope well with complexity?
Some do. I've found ML modules and module types (both the Standard ML and Objective Caml) flavors invaluable tools for managing complexity, understanding complexity, and placing unbreachable firewalls between different parts of large programs. I have had less good experiences with Haskell
Final note: these aren't really new issues. Decomposing systems into modules with separate interfaces checked by the compiler has been an issue in Ada, C, C++, CLU, Modula-3, and I'm sure many other languages. The main benefit of a system like Standard ML or Caml is the that you get explicit signatures and modular type checking (something that the C++ community is currently struggling with around templates and concepts). I suspect that these issues are timeless and are going to be important for any large system, no matter the language of implementation.
I'd say the opposite. It is easier to reason about programs written in functional languages due to the lack of side-effects.
Usually it is not a matter of "functional" vs "procedural"; it is rather a matter of lazy evaluation.
Lazy evaluation is when you can handle values without actually computing them yet; rather, the value is attached to an expression which should yield the value if it is needed. The main example of a language with lazy evaluation is Haskell. Lazy evaluation allows the definition and processing of conceptually infinite data structures, so this is quite cool, but it also makes it somewhat more difficult for a human programmer to closely follow, in his mind, the sequence of things which will really happen on his computer.
For mostly historical reasons, most languages with lazy evaluation are "functional". I mean that these language have good syntaxic support for constructions which are typically functional.
Without lazy evaluation, functional and procedural languages allow the expression of the same algorithms, with the same complexity and similar "readability". Functional languages tend to value "pure functions", i.e. functions which have no side-effect. Order of evaluation for pure function is irrelevant: in that sense, pure functions help the programmer in knowing what happens by simply flagging parts for which knowing what happens in what order is not important. But that is an indirect benefit and pure functions also appear in procedural languages.
From what I can say, here are the key advantages of functional languages to cope with complexity :
Functional programming hates side-effects.
You can really black-box the different layers
and you won't be afraid of parallel processing
(actor model like in Erlang is really easier to use
than locks and threads).
Culturally, functional programmer
are used to design a DSL to express
and solve a problem. Identifying the fundamental
primitives of a problem is a radically
different approach than rushing to the brand
new trendy framework.
Historically, this field has been led by very smart people :
garbage collection, object oriented, metaprogramming...
All those concepts were first implemented on functional platform.
There is plenty of literature.
But the downside of those languages is that they lack support and experience in the industry. Having portability, performance and interoperability may be a real challenge where on other platform like Java, all of this seems obvious. That said, a language based on the JVM like Scala could be a really nice fit to benefit from both sides.
Does program flow become difficult to
follow more quickly than if a
non-functional language is used?
This may be the case, in that functional style encourages the programmer to prefer thinking in terms of abstract, logical transformations, mapping inputs to outputs. Thinking in terms of "program flow" presumes a sequential, stateful mode of operation--and while a functional program may have sequential state "under the hood", it usually isn't structured around that.
The difference in perspective can be easily seen by comparing imperative vs. functional approaches to "process a collection of data". The former tends to use structured iteration, like a for or while loop, telling the program "do this sequence of tasks, then move to the next one and repeat, until done". The latter tends to use abstracted recursion, like a fold or map function, telling the program "here's a function to combine/transform elements--now use it". It isn't necessary to follow the recursive program flow through a function like map; because it's a stateless abstraction, it's sufficient to think in terms of what it means, not what it's doing.
It's perhaps somewhat telling that the functional approach has been slowly creeping into non-functional languages--consider foreach loops, Python's list comprehensions...
I search for a programming language for which a compiler exists and that supports self modifying code. I’ve heared that Lisp supports these features, but I was wondering if there is a more C/C++/D-Like language with these features.
To clarify what I mean:
I want to be able to have in some way access to the programms code at runtime and apply any kind of changes to it, that is, removing commands, adding commands, changing them.
As if i had the AstTree of my programm. Of course i can’t have that tree in a compiled language, so it must be done different. The compile would need to translate the self-modifying commands into their binary equivalent modifications so they would work in runtime with the compiled code.
I don’t want to be dependent on an VM, thats what i meant with compiled :)
Probably there is a reason Lisp is like it is? Lisp was designed to program other languages and to compute with symbolic representations of code and data. The boundary between code and data is no longer there. This influences the design AND the implementation of a programming language.
Lisp has got its syntactical features to generate new code, translate that code and execute it. Thus pre-parsed code is also using the same data structures (symbols, lists, numbers, characters, ...) that are used for other programs, too.
Lisp knows its data at runtime - you can query everything for its type or class. Classes are objects themselves, as are functions. So these elements of the programming language and the programs also are first-class objects, they can be manipulated as such. Dynamic language has nothing to do with 'dynamic typing'.
'Dynamic language' means that the elements of the programming language (for example via meta classes and the meta-object protocol) and the program (its classes, functions, methods, slots, inheritance, ...) can be looked at runtime and can be modified at runtime.
Probably the more of these features you add to a language, the more it will look like Lisp. Since Lisp is pretty much the local maximum of a simple, dynamic, programmable programming language. If you want some of these features, then you might want to think which features of your other program language you have to give up or are willing to give up. For example for a simple code-as-data language, the whole C syntax model might not be practical.
So C-like and 'dynamic language' might not really be a good fit - the syntax is one part of the whole picture. But even the C syntax model limits us how easy we can work with a dynamic language.
C# has always allowed for self-modifying code.
C# 1 allowed you to essentially create and compile code on the fly.
C# 3 added "expression trees", which offered a limited way to dynamically generate code using an object model and abstract syntax trees.
C# 4 builds on that by incorporating support for the "Dynamic Language Runtime". This is probably as close as you are going to get to LISP-like capabilities on the .NET platform in a compiled language.
You might want to consider using C++ with LLVM for (mostly) portable code generation. You can even pull in clang as well to work in C parse trees (note that clang has incomplete support for C++ currently, but is written in C++ itself)
For example, you could write a self-modification core in C++ to interface with clang and LLVM, and the rest of the program in C. Store the parse tree for the main program alongside the self-modification code, then manipulate it with clang at runtime. Clang will let you directly manipulate the AST tree in any way, then compile it all the way down to machine code.
Keep in mind that manipulating your AST in a compiled language will always mean including a compiler (or interpreter) with your program. LLVM is just an easy option for this.
JavaScirpt + V8 (the Chrome JavaScript compiler)
JavaScript is
dynamic
self-modifying (self-evaluating) (well, sort of, depending on your definition)
has a C-like syntax (again, sort of, that's the best you will get for dynamic)
And you now can compile it with V8: http://code.google.com/p/v8/
"Dynamic language" is a broad term that covers a wide variety of concepts. Dynamic typing is supported by C# 4.0 which is a compiled language. Objective-C also supports some features of dynamic languages. However, none of them are even close to Lisp in terms of supporting self modifying code.
To support such a degree of dynamism and self-modifying code, you should have a full-featured compiler to call at run time; this is pretty much what an interpreter really is.
Try groovy. It's a dynamic Java-JVM based language that is compiled at runtime. It should be able to execute its own code.
http://groovy.codehaus.org/
Otherwise, you've always got Perl, PHP, etc... but those are not, as you suggest, C/C++/D- like languages.
I don’t want to be dependent on an VM, thats what i meant with compiled :)
If that's all you're looking for, I'd recommend Python or Ruby. They can both run on their own virtual machines and the JVM and the .Net CLR. Thus, you can choose any runtime you want. Of the two, Ruby seems to have more meta-programming facilities, but Python seems to have more mature implementations on other platforms.
Will there be a functional language which does for the Java community what F# does for the .NET community?
What functional programming languages are available, or in development, for the JVM?
Scala would be the language.
Though not strictly functional (it's a mix of functional and object-oriented) and it is not strictly for Java (there is a .NET version of Scala), that would be the closest analog to F# in the JVM.
The first thing that came to my mind was Scala but really Ocaml-Java comes closer as F# is a variant of Ocaml. See this post that compares Ocaml-Java to Scala:
OCaml programmers are typically over 10x as productive as Java or C++
programmers for a wide range of practical tasks. Despite being based upon a
fundamentally OOP platform, F# goes a long way to capturing the productivity-
boosting benefits of OCaml (and the whole ML family). In contrast, Scala
fails to capture many of the benefits including some really basic ones and,
consequently, writing correct code is much more difficult in Scala than in
any real ML.
Moreover, the ML family of languages are designed to be succinct but Scala is
needlessly verbose for everything from "Hello world!" upwards. The ML family
of languages provide extensive type inference (OCaml more than most) but
Scala has only rudimentary inference by comparison. OCaml has an unusually
expressive type system but Scala adds little to OOP that is of practical
importance.
Perhaps Clojure. It's not statically typed, but it has more of an emphasis on immutability and concurrency than F#. However, like F# (and unlike Common Lisp), it is intended to be a primarily functional language that is good at consuming OO libraries from the underlying platform.
For now I would say Scala. But for the future, I'd have a look at Fortress. The first implementation of the spec was released on April 1, 2008. And no, that is not a joke. Key featues are:
Statically typed, but a lot of type inference to avoid clutter
Unicode and 2d rendering of mathematical functions
Designed for parallel execution (for each defaults to it)
Strong support for custom libraries (Guy Steele's influence)
Operator overloading, including the juxtaposition operator
More info at the Project Fortress Community website and the Wikipedia Fortress page.
Arguably none because the JVM lacks tail calls and they are required to make almost all functional code robust with respect to stack consumption.
The nearest thing to functional language implementations on the JVM are Clojure, Scala and the OCaml-Java project. Although there are workarounds for the lack of tail calls (e.g. trampolining), none of these language implementations do this because the workarounds introduce even more serious problems, e.g. crippling performance and completely obfuscating debugging.
Sun have been talking about tail calls for years and, more recently, have indicated that they intend to implement them imminently. As soon as that is done, I am sure we will see a lot more language diversity on the JVM and, in particular, some production-quality functional language implementations. Until then, I regard all of these languages as toys.
Cheers,
Jon Harrop.
There's a good list of programming languages for JVM, including functional programming paradigm and other paradigm languages on:
en.wikipedia.org/wiki/List_of_JVM_languages
My first pick is Scala (multi-paradigm; OO & FP), I spent a 5+ months studing Scala in 2009, and created a quick reference sheet: bchiprog.blogspot.com/2009/05/scala-cheat-sheet.html
I noticed there are other programming paradigms that are interesting, other focuses on parallel processing such as X10, Fortress, and Chapel. X10 is implemented on top of Scala - http://www.scala-lang.org/sites/default/files/odersky/scalaliftoff2009.pdf
It's really based on what problem you need to solve then pick the language that can best solve it. I think it's developers' wish that there's one language that can solve any type of problem easily and doing it simply.
#Marc Gravell - functional languages are increasingly used in the guts of enterprise grade financial systems. We use many functional (pure or "semi-pure") at the bank I work for...
Meanwhile, there is Frege, a pure functional, non-strict language in the spirit of Haskell that compiles to Java, which then is compiled further with javac or the eclipse compiler, depending on the environment (command-line or eclipse).
Actually, I might be wrong, but I don't expect F# to be as mainstream as the other .NET languages; useful in a few circles (academic, compilers, a few other scenarios) - however, don't forget that C# offers FP usage - and it gets better each time: C# 1.2 has delegates; C# 2.0 has anonymous methods and captures/closures; C# 3.0 has lambdas for simplicity, and Expression for abstraction. Anonymous types (C# 3.0) share some similarity with tuples (in terms of convenience), but obviously are very different beasts, so definitely not a like-for-like comparison.
Maybe not quite as optimised as F#, but for most day-to-day FP use-cases, more than sufficient.
It is also quite clear that better support for immutability (especially for threading) is very much on the minds of the C# language team for future consideration.
My money is on C# getting better at FP, and being the .NET FP offering for most day-to-day purposes. Of course, there will be some F# usage - but (purely subjective) I simply don't see there being a huge migration.
I would add https://eta-lang.org to the suggestions -- it's basically a Haskell for the JVM. I think the question is in line with the fact that F# is an ML language, while Clojure is a dialect of LISP.