Monday, November 30, 2009

Functional C

I've been toying around with the idea of a new language and the functional paradigm is definitely where I want to focus my efforts, but the question is, what would make it stand out from the rest of the field? I haven't looked at all of them, but my impression is they typically are oriented to more application-style programming. In other words, they focus on writing applications vs. something more low-level, like operating systems and embedded systems.

So, what I'm thinking is that we need a good functional programming language that can be used for systems development. This is a bit iffy as one of the key features of C, for example, is that it has very predictable behavior. Functional languages, however, don't have this as they typically have garbage collection. Also, Haskell has laziness, which isn't very predictable as well.

Can this be done? I think so, but it has to be done carefully. Without garbage collection, I'm not really sure how to best do this. Granted, a very smart compiler could translate any recursive functions into loops, but I'm not sure if that's enough. It may be as there's nothing that says you couldn't have loops in functions where mutable variables are localized and can only be used within the loop.

Now, what would the benefits of this be? Well, the fact that functions will, by default, be pure allows programs written in this hypothetical language to be run concurrently without worrying about concurrency issues as much as with C. This will be nice in applications which inspired me to think about this language: high performance computing. A recent article stated that using Haskell instead of C for one system resulted in a significant performance increase. My guess is that this is due to better concurrency.

One may think that this means that Haskell is good enough, but what about embedded systems that require more predictability? I'm guessing that robotics falls into this category. Random garbage collection could prove interesting. In fact, I recall someone stating that they built a robot or something similar that had software written in Java. If true, it garbage collected itself into a wall.

Now, some other things that I think should be in the language before I sign off:
  • Support for all of the different data types as C so that we can perform the same kind of bit manipulation as we can easily do in C.
  • Arbitrary precision arithmetic. Large number crunching and ensuring that the results are accurate, especially for financial systems, are common enough that I don't see why these shouldn't be part of any new language.
  • Good string processing. Processing data is a very important reason to use computers, so let's make it easy.
  • Fail-fast capabilities. This is one of the great features of Erlang and it should be incorporated if possible. How this will work will be an issue because I don't want this to run on a VM, which is how Erlang works.
  • Good threading with message passing/STM/something. Perhaps a combination of one or more as they both have their benefits.
That's all for now. I'm sure I've forgotten something I thought of, but I wanted to get this out. I think it's an important idea because if this can be done, I think it'll be a great boon for proponents of functional programming as it now can be used where C has been the best if not the only choice for developing systems. As for the name of the post, well, that's my unofficial code-name for this particular language as it encompasses what I believe it needs to be. Of course, this also led me to think of something else: can we program in C in a functional manner? Perhaps all this language has to be is a high-level language that gets translated into C written in a functional manner? Time will tell.

Labels: , , ,

Sunday, November 08, 2009

Last post and more...

Well, I got through the problem I was having with Haskell. It was just a little type mismatch, so it ended up being no biggie. I think the tutorial just confused me a bit.

Now, while doing some work around the house, I was doing some thinking and I don't know if anyone has thought of this yet, but I think we can leverage multi-core processors to enhance single-threaded apps. Now, don't take anything I say as gospel as I'm not a chip designer; I'm just throwing out some ideas that at least I thought were pretty cool.

First, instead of branch prediction, could we instead have multiple cores pre-loaded with the instructions for each branch and just switch to the correct core depending on the result of the branching? In fact, if the processor/compiler is smart enough, it could keep those branches in cores for an extended period of time and just switch between them. This could make processors simpler as you wouldn't have to worry about good branch prediction algorithms and how much space they take up on a CPU.

Second, keeping along those lines, how about pre-loading the bytecode for different functions on different cores? Now when I call a function, I don't have to worry about loading the function every time I call it; it's already in a single core's cache and ready to go.

Lastly, should we look into making multi-core processors more interesting? I'm thinking of mixing one or more specialized cores with multiple general purpose cores. For example, a useful core would be one that can do arbitrary precision math without relying on a normal floating-point unit. Or perhaps a crypto core which is optimized for the various operations that cryptographic algorithms use? Now even if our software isn't threaded/forked, we can leverage multi-core capabilities.

Now, I'm thinking that if the first and second ideas are good that we'd want to have instruction caches on a per-core level and a shared data cache. Also, I'm thinking that many simple cores will work better than few complex cores, which is where we are today with Intel and AMD processors. Regardless, the third idea could be incorporated with either type of multi-core processor.


Labels: , , ,

Saturday, November 07, 2009

Haskell Revisited

Yeah, I'm back to looking at it and it really wasn't by choice. You see, I created a small program using D to launch scripts based on some parameters specified in a config file. We need this at work to be able to run some scripts on Windows and Linux. Instead of having to maintain two sets of scripts and batch files are very limited in what they can do, so using a small program seemed like the best way to go. It worked very well except it was compiled against a different version of glibc than what was on the target system. I guess that's not too bad considering it was the only bug found :-)

So, why the visit back to Haskell land? Well, outside of LDC, there's no real 64-bit compiler. This confuses me a bit since 64-bit systems are becoming more popular, so why wouldn't Digital Mars have an official 64-bit compiler? Yeah, got me. So, I figured I'd switch to a language that does have 64-bit support, but something newer that has facilities to write safer and better programs without needing a VM. Haskell seemed to be a good choice, so figured it would be a good choice. Also, I was listening to some presentations related to Erlang, Haskell, and functional programming, so I guess I drank some of the functional programming kool-aid :-)

Well, so far I'm hating it. Perhaps I'm just not in the right frame of mind, but it seems to be a pain so far to get command-line parameters working. I'm just following a tutorial with some changes to make it work the way I want to, however I'm getting a type error that's baffling me. Perhaps I just need to read the documentation some more, but it's frustrating that something that was very straight-forward in D isn't as nice to implement in Haskell.

Perhaps I'm jumping the gun, but command-line parameters should be easy to do in any language now. It's been done for years and, hell, just steal the GetOpt::Long from Perl like D did and be done with it. It works very well and is easy to use. However, I will say this much: Haskell at least supports the correct Unix/Posix style parameter format.

On a slightly different note, after listening to a presentation on Haskell, I'm wondering if perhaps D, which does have the concept of purity if you explicitly enable it for a function, should have functions be pure by default and explicitly make them impure. It's more consistent with their new thread local storage model and in reality, it's probably best to have the compiler assume and verify that functions are pure unless the programmer explicitly states otherwise. The big problem I see is that I/O becomes more difficult.

Labels: , , , ,