Skip to content

Latest commit

 

History

History
37 lines (22 loc) · 2.99 KB

README.md

File metadata and controls

37 lines (22 loc) · 2.99 KB
Raw

XPC Calc

The world's worst RPN calculator, powered by XPC and Haskell

This is actually less insane than it sounds. Haskell and XPC actually make a good fit:

  • Haskell is a lazy, pure, statically-typed functional language which has a strong foreign function interface to C.
  • XPC is an IPC and daemon management library for building out-of-process, stateless services which communicate via typed, asynchronous messages.

It should be fairly easy to see how these two technologies line up.

OK, so what is this?

XPC Calc is an RPN calculator which performs the requested mathematical operations out-of-process, specifically in an XPC service. Included are two XPC services -- one written in Objective-C and one written in Haskell.

How does it work?

XPC Calc itself maintains the current stack in the main process. When the user requests an addition, subtraction, multiplication or division operations, XPC Calc sends an XPC message with the stack and the operation to an XPC service which performs the operation and returns the stack.

The Objective-C service has a straightforward implementation, dealing directly with the native XPC types.

The Haskell service is fairly primitive at this point. It has does some limited marshaling and unmarshaling of XPC types, allowing the main calculating functions to be written as pure Haskell functions, rather than in the IO monad.

No really, the world's worst RPN calculator

All that said, XPC Calc is quite a terrible calculator. As it only supports integers, it only implements integer division, for one. Issuing +, for example, does not push any text in the input field onto the stack. And so on.

Areas to improve

I'm primarily focused on improving the Haskell bits, as those are the most interesting. It would be cool if a general framework for writing XPC services in Haskell could come out of this simple project.

  • The marshaling code dealing with XPC types should be extended to support a richer variety of types. At first brush, creating XPCable and UnXPCable typeclasses seems like a good place to start.
  • The C bits should be reduced as much as possible. In theory, the only thing that should be necessary is glue for xpc_connection_set_event_handler which takes a block. (Blocks are not supported in the Haskell FFI yet, although there has been some interesting dicussion about how to add support.)
  • The Xcode build system is already pretty good, but it would be nice if we instead issued a single call to ghc, instead of two. The additional call seems necessary "prime" the stub header files needed to build the C program.
  • It appears that the xpc_array_* functions do not allow you to remove elements or insert elements anywhere other than the end of the list. Because of this restriction the Haskell code for implementing calculation is uglier than it should be.
  • The Objective-C version should either be changed to pure C, or use some Objective-C features. (Shared marshaling code?)