estanford - Developer IT

Type-conditional controls in Haskell

- by estanford

I'm going through the 99 Haskell problems to build my proficiency with the language. On problem 7 ("Flatten a nested list structure"), I found myself wanting to define a conditional behavior based on the type of argument passed to a function. That is, since *Main> :t 1 1 :: (Num t) => t *Main> :t [1,2] [1,2] :: (Num t) => [t] *Main> :t [[1],[2]] [[1],[2]] :: (Num t) => [[t]] (i.e. lists nested at different levels have different data types) it seems like I should be able to write a function that can read the type of the argument, and then behave accordingly. My first attempt was along these lines: listflatten l = do if (:t l) /= ((Num t) => [t]) then listflatten (foldl (++) [] l) else id l But when I try to do that, Haskell returns a parse error. Is Haskell flexible enough to allow this sort of type manipulation, do I need to find another way?

Read the article

Abstracting boxed array structures in J

- by estanford

I've been working on a J function for a while, that's supposed to scan a list and put consecutive copies of an element into separate, concatenated boxes. My efforts have taken me as far as the function (<;. 2) ((2&(~:/\)),1:) which tests successive list entries for inequality, returns a list of boolean values, and cuts the list into boxes that end each time the number 1 appears. Here's an example application: (<;. 2) ((2&(~:/\)),1:) 1 2 3 3 3 4 1 1 1 +-+-+-----+-+-----+ |1|1|0 0 1|1|0 0 1| +-+-+-----+-+-----+ The task would be finished if I could then replace all those booleans with their corresponding values in the input argument. I've been looking for some kind of mystery function that would let me do something like final =: mysteryfunction @ (<;. 2) ((2&(~:/\)),1:) final 1 2 3 3 3 4 1 1 1 +-+-+-----+-+-----+ |1|2|3 3 3|4|1 1 1| +-+-+-----+-+-----+ In an ideal situation, there would be some way to abstractly represent the nesting pattern generated by (<;. 2) ((2&(~:/\)),1:) to the original input list. (i.e. "This boxed array over here has the first element boxed at depth one, the second element boxed at depth one, the third, fourth, and fifth elements boxed together at depth one,..., so take that unboxed list over there and box it up the same way.") I tried fooling around with ;. , S: , L:, L. and &. to produce that behavior, but I haven't had much luck. Is there some kind of operator or principle I'm missing that could make this happen? It wouldn't surprise me if I were overthinking the whole issue, but I'm running out of ideas.

Read the article

How to install new modes in emacs 23 on OS X?

- by estanford

I just downloaded the Haskell and J modes off of SourceForge, and I'm having trouble figuring out how to make them interface with emacs 23. Google searches yield detailed instructions for emacs 22, but it looks like changes have been made that make it hard to figure out where I'm supposed to stick the binaries. The internal documentation seems to assume more experience with emacs internals than I currently have, and the problem has resisted solution for several days. Does anyone know how to get these modes up and running?

Read the article

Best strategies for reading J code

- by estanford

I've been using J for a few months now, and I find that reading unfamiliar code (e.g. that I didn't write myself) is one of the most challenging aspects of the language, particularly when it's in tacit. After a while, I came up with this strategy: 1) Copy the code segment into a word document 2) Take each operator from (1) and place it on a separate line, so that it reads vertically 3) Replace each operator with its verbal description in the Vocabulary page 4) Do a rough translation from J syntax into English grammar 5) Use the translation to identify conceptually related components and separate them with line breaks 6) Write a description of what each component from (5) is supposed to do, in plain English prose 7) Write a description of what the whole program is supposed to do, based on (6) 8) Write an explanation of why the code from (1) can be said to represent the design concept from (7). Although I learn a lot from this process, I find it to be rather arduous and time-consuming -- especially if someone designed their program using a concept I never encountered before. So I wonder: do other people in the J community have favorite ways to figure out obscure code? If so, what are the advantages and disadvantages of these methods?

Developer IT