# News aggregator

### ANNOUNCE: BOB Conference 2015 Berlin

### Functional Programming Job Opportunities

### Using `jack` on Windows, sounds realistic?

### Ken T Takusagawa: [leuzkdqp] Units

Some notes on dimensional quantities and type systems:

Addition, subtraction, assignment, and comparison should fail if the units are incompatible.

Multiplication, division, and exponentiation by a rational dimensionless power always work. These operations assume commutativity.

Distinguishing addition from multiplication vaguely reminds me of the difference between floating point and fixed point.

Unit conversion: a quantity can be read in one set of units then shown in another set. Abstractly it does not exist as a real number in either.

Converting between different families of units requires exact linear algebra on rational numbers.

In some functions, units pass through just fine. Others, e.g., trigonometric, require dimensionless numbers.

Not all dimensionless numbers are the same unit: adding an angle to the fine structure constant seems as meaningless as adding a foot to a volt. But multiplying them could be reasonable.

One can take any compound type with a dimensionless internal type and turn it into a new compound type with that internal type having units. But should this be considered a "new" type? Of course, this is useless unless the internal type defined arithmetic operations: "True" miles per hour seems meaningless.

Creating such compound types is analogous to the "function" idea above by viewing a compound type as a data constructor function of a base type. Constructors do not do operations which can fail, like addition, so the function always succeeds.

Creating a list populated by successive time derivatives of position seems like a useful thing to be able do. But every element of the list will have different dimensions, which violates the naive idea of a list being items all of the same type.

We would like to catch all dimensionality errors at compile time, but this may not be possible. The extreme example would be implementing the "units" program. Is that an anomaly?

It is OK to add a vector to a coordinate (which has an origin) but not a coordinate to a coordinate. There seems to be a concept of units and "delta" units.

It is OK to subtract coordinates to get a delta.

Maybe multiplying coordinates is also illegal.

Coordinates versus vectors, units versus delta units, seems like an orthogonal problem to "regular" units. Separate them in software so one can use either concept independently, for example, distinguishing dimensionless from delta dimensionless.

Go further than just "delta" to distinguish first, second, etc., differences.

An X component and Y component of a vector might have the same units, say, length, but one wants to avoid adding them, as this is typically a typo. But sometimes, for rotations, one does add them.

A Haskell Wiki page: http://www.haskell.org/haskellwiki/Physical_units. The units package seems promising.

### [PROPOSAL] Add `FiniteBits(count{Leading,Trailing}Zeros)`

### APLAS 2014: Call for Posters and Demo

### Asking for help on MVC, pure Models and IO. Partially related to the mvc library.

Hello,

I'm currently writing a small program based upon the MVC pattern. I noticed that many of my design choices in terms of Controller => Model => View resemble the mvc library. However, I have a problem which I don't know how to solve. I tried to get some hints from the mvc library, but from what I understand I would face the same problem there, too. The problem goes as follows.

This should be window management system. The Model is a representation of all windows as clients. A Client contains the window id and additional information like coordinates, size and maybe title, etc. Controllers produce events and Views draw or render the Model.

A Controller produces an event, notifying that a window was created. This event includes x and y coordinates as well as width and height. Now I can wrap this window into a client and add it to the model *purely*. However, for deciding if I should add the window I need to do an *impure* query. In addition, for client information like the title I also need *impure* methods.

I came up with some solutions but in my opinion they are all unsatisfactory:

- Allow IO for modifying the Model
- Use the Interpreter pattern to purify the Model and still get IO
- Work around the issue by having the Views decide which Client should be drawed and which additional information needs to be gathered (defies the idea of using the Model to cache information instead of querying it every time)
- Give up on the Model entirely and abstract the Controller using the Interpreter pattern. The Interpreter would then become the View.

Downside: Every Controller would have to keep a Model on its own if necessary possibly duplicating some code.

I'm a bit at a loss here. Having a pure Model is nice and makes sense, there are practical needs for impure IO. How could I improve this?

submitted by jrk-[link] [5 comments]

### HaskellWiki page about SDL

### maintainer needed: extensible-effects

### Cannot install the Haskell Platform on GNU/Linux (possible Cabal issue)

### haskell (and beyond) in education

### 'import ccall unsafe' and parallelism

### Haskell Freecell Library

I created a library for playing freecell in Haskell. It includes a rudimentary solver that works (some of the time!). Improvements are welcome. You can also, of course, use it just to play text-based freecell (more fun than you think).

Be gentle, please, I'm new.

https://github.com/tdees40/Freecell

submitted by tdees40[link] [10 comments]

### Haskell SDL2 FRP games working on Android

### Understanding ((->) r) as a functor.

I'm reading "learn you a haskell" and after the chapter on applicative functors I had some confusion:

In haskell the Functor instance of ( (->) r) is defined as:

instance Functor ((->) r) where fmap f g = (\x -> f (g x))A category is a set of objects K along together with a set of morphisms M (K,M). As far as I understand it a Functor is a categorical homomorphism. So The set of all functions along together with functional composition should be a homomorphism between a category.

I'm assuming in this category, kinds of type * are the objects and the morphisms are normal Haskell functions.

As far as I can gather (->) is considered to be the morphism between objects (since a->b still has kind *) and functional composition is the morphism between functions. However this doesn't make much since to me. Since in this case the set ( ((->) r), <$> ) would be the Functor, not the set of functions. ((->) r) is something completely different and separate from functions? It's obviously a Funtor, but why the claim "Functions ARE functors" makes sense is still beyond me. To me, Functions are morphisms of a category who's Functor is the type class associated with functions. You don't call (Just 5) a functor, you call Maybe a functor.

What am I missing? If someone could explain this to me like I was 5, no 3, I would be extremely happy.

submitted by yyttr3[link] [4 comments]