programming language idea

Post Reply New Topic

I like functional programming a lot, and Haskell is among the best implementations of this idea. However, in reality I end up using either Python or Lisp because I find Haskell difficult to work with. It manages non-referentially transparent behavior using monads, which are currently beyond my understanding of modern algebra. Fair enough, you don't really need category theory to understand (Haskell) monads. Still, they are difficult.

Overall, I like the ideas behind Haskell. However, I have another plan for managing non-referentially transparent code. It's very simple, and because it is very simple, it just might work very well. My idea is to assume that all functions are referentially transparent by default, until it is proven that they are 'tainted'. There are three rules for determining whether a function is 'tainted':

1. Any function explicitly marked tainted is, obviously
2. Any function whose dependency graph includes a tainted function is tainted
3. Any function that uses a non-referentially transparent built-in language feature (haven't determined how I want to include them yet) is tainted

An obvious advantage is that the inclusion of a comprehensive standard library ... something I would do because I don't want to create another Scheme ... would relieve the user of most of the burden of marking his own functions as 'tainted' if necessary. The standard library would include: I/O, random numbers, FFI, etc. and almost certainly an object system of some kind, all of which encompasses most non-referentially transparent behaviors in a program. In fact, I may limit imperative assignments entirely to the object system, in which case I will need one.

In essence, my proposal would be kind of like having 'ghost' monads.

The syntax and several deeper languages will be borrowed from Lisp, if only because I don't want to spend a lot of time on the parser or doing major updates of Vim and Emacs language support. In favor of lazy evaluation, I will not include macros.

Also, polymorphism and type inference are a must...and, uh, a few other things.

I don't know what the hell I'm going to implement this in, but it looks like I might be stuck with C if I want to reach a wide audience.

My goal is to create a functional programming language that doesn't need a lot of modern algebra to do anything besides make an infinite list of Fibonacci numbers. Imagine something that feels like Python or Common Lisp in terms of having everything there and being able to code without drops of blood forming on your forehead, and like Haskell, in terms of the feeling of not using something as hideous as Common Lisp. That is my aim. I'd like to start as soon as I achieve my BS.

this sounds pretty interesting actually. I'll think about it a bit more later.

as for the actual implementation, there are lots of shortcuts that'll get you a functional language (pardon the pun) pretty quickly. There are all sorts of tools like flex, antlr, bison, etc that let you generate the front-end parser/lexer automatically and if you make it a lot like haskell, most probably people have already written sample haskell stuff you can borrow easily.

alternatively, it's super easy to parse lisp, there are probably a million examples out there if you decide to do it yourself.

for the back end by far the simplest (if you know some compiler basics already) is to use LLVM as your back end. that is your "middle" code will take the output of your parser/lexer and generate LLVM IR from it, which is sort of an abstracted simpler assembly language. the LLVM backend is a heavy optimizer and can take care of all the work of building an optimizing compiler for you and then also abstract away the whole mess of generating machine code.

so basically, there are tools out there that will essentially do the whole front end and back end of the compilers for you - you just have to glue it together in the way you want.

edit: assuming you want some kind of static compiler, LLVM is perfect, that is. depending on how dynamic you want to get, LLVM may or may not be able to provide that.

Common Lisp, hideous? Really? I've never used it, but if it's anything like Scheme, I disagree completely. But ah well.

Good luck with it - I'm currently working on the basic outline for a language myself at the moment, which should be very fun.

Brain F*ck was very interesting as a programming language. Not very useful though!

wow u must be a genius to understand this

Common Lisp superficially resembles Scheme. Mainly only in the sense that they are both Lisps.



Tell us.



Not really.

"Real Programmers can write FORTRAN in any language." - Unknown

Couldn't you implement this as a base class in an object oriented functional language with polymorphism? The derived classes would inherit the taint status from it's parents. Of course that means every function needs to be in a class. I only know C++ though, Lisp is just weird when you've been using C for so long.

I want more integration than that.