As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As evidenced by the Typeclassopedia, the current stack of classes imported from category theory is a bit of a tangled accident of history, rather than a beautiful coherent whole.
In particular, this makes it rather difficult to follow what's happening.
What should this stuff look like, if petty concerns like backwards compatibility, code duplication or tractably short type signatures were not an issue?
For some subsets of the standard classes there have been attempts to give revised hierarchies.
Numeric Typeclasses
The Numeric Prelude. An experimental alternative hierarchy of numeric type classes
In particular, it provides a much richer set of mathematical abstractions.
Besides this, there are many other alternate designs:
Yet Another Prelude - a notable alternate prelude from Ross Paterson:
prelude-extras - higher order prelude functions
classy-prelude - a prelude with more classes
Categoric Typeclasses
There's been less work on the category-inspired classes, such as Functor, Monad, Monoid, Applicative and of course, Category.
The most important work is the
category-extras package, which provides a very rich library indeed, including the famous zygohistoprepromorphism.
Regarding the "categorical" classes, there is also The Other Prelude.
The class hierarchy outlined there has been implemented in Frege.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking for a Haskell linear algebra library that has the following features:
Matrix multiplication
Matrix addition
Matrix transposition
Rank calculation
Matrix inversion is a plus
and has the following properties:
arbitrary element (scalar) types (in particular element types that are not Storable instances). My elements are an instance of Num, additionally the multiplicative inverse can be calculated. The elements mathematically form a finite field (𝔽2256). That should be enough to implement the features mentioned above.
arbitrary matrix sizes (I'll probably need something like 100x100, but the matrix sizes will depend on the user's input so it should not be limited by anything else but the memory or the computational power available)
as fast as possible, but I'm aware that a library for arbitrary elements will probably not perform like a C/Fortran library that does the work (interfaced via FFI) because of the indirection of arbitrary (non Int, Double or similar) types. At least one pointer gets dereferenced when an element is touched
(written in Haskell, this is not a real requirement for me, but since my elements are no Storable instances the library has to be written in Haskell)
I already tried very hard and evaluated everything that looked promising (most of the libraries on Hackage directly state that they wont work for me). In particular I wrote test code using:
hmatrix, assumes Storable elements
Vec, but the documentation states:
Low Dimension : Although the dimensionality is limited only by what GHC will handle, the library is meant for 2,3 and 4 dimensions. For general linear algebra, check out the excellent hmatrix library and blas bindings
I looked into the code and the documentation of many more libraries but nothing seems to suit my needs :-(.
Update
Since there seems to be nothing, I started a project on GitHub which aims to develop such a library. The current state is very minimalistic, not optimized for speed at all and only the most basic functions have tests and therefore should work. But should you be interested in using or helping out developing it: Contact me (you'll find my mail address on my web site) or send pull requests.
well, I'm note really sure how much relevant my answer is but Im having good experiences with GNU GSL library and there is a wrapper for haskel:
http://hackage.haskell.org/package/bindings-gsl
Check it out, maybe it will help you
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I prefer Haskell.
I already know How to create my own language with Procedural Language (for example: C, Java, Python, etc).
But, I know How to create my own language with Functional Language (for example Haskell, Clojure and Scala).
I've already read:
Internet Resources
Write Yourself a Scheme in 48 Hours
Real World Haskell - Chapter 16.Using Persec
Writing A Lisp Interpreter In Haskell
Parsec, a fast combinator parser
Implementing functional languages: a tutorial
Books
Introduction Functional Programming Using Haskell 2nd Edition -- Haskell
StackOverflow (but with procedural language)
Learning to write a compiler
create my own programming language
Source
Libraries and tools/HJS -- Haskell
Are there any other good links/sources? I would like to get some more.
Programming Languages: Application and Interpretation is frequently used in programming language classes, and is available online for free. It uses Scheme.
Types and Programming Languages is another incredible book dealing with type systems (including implementation), though only available in dead tree format. It uses ML (which represents a significant family of functional languages that I noticed was missing from your list).
Racket (formerly called PLT Scheme) is a functional language that emphasizes making your own sub-language.
read also:
Christian Queinnec's Lisp In Small Pieces book,
Andrew Appel's Compile with Continuations (and also his book Modern compiler implementation in ML isbn:0521582741)
I also think that Jacques Pitrat's latest book Artificial Beings - the conscience of a conscious machine will give you very interesting insights.
Take also a look at Compiler.HOOPL and Control.Unification libraries, and uuagc attribute grammar preprocessor. You also can read https://wiki.ittc.ku.edu/lambda/images/e/e3/Modular-interpreters.pdf on writing modular interpreters in Haskell. Also note that Parsec is not very fast and for non-toy projects Happy/Alex may be suited better.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I read in the book: "Masterminds of programming" , the the interview with Guido Van Rossum says:
The more fundamental property Python shares with Lisp ( not a functional language either! ) is that functionas are first-class objects...
So, Lisp is not a functional programming language?
Is Guido wrong? What is it then?
Pretty much every Lisp I know of can be used to program in a functional style (all you really need are first-class functions, after all!)
However, Lisps are more like multi-language toolkits: you can do functional programming, OOP, logic programming, define your own DSL for some whacky new paradigm etc.
The Lisp that is probably closest to a functional programming style is Clojure (it has lazy evaluation, discourages OOP, uses immutable data structures throughout, restricts uncontrolled mutation (via STM), has quite a lot of pure / higher order functions in the core library etc.)
There are languages that allow and encourage functional programming paradigms. Both Python and Lisp are among these. Lisp in particular was the first one to apply theoretical concepts derived from lambda calculus. In the late 1950s, when almost only FORTRAN and Lisp existed, Lisp was highlighted as the functional one, where FORTRAN, with a fully static memory management, would never be considered functional.
However, neither Python nor Lisp enforce pure functionality, allowing mutable variables, states and imperative constructs. A mixture of styles can always be handy in practice, so probably you will not find many example of pure concepts in very successful tools.
Among purely functional languages, Haskell, Clean and Miranda are listed examples, but I cannot say anything about them.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Please, gurus, give me a detailed explanation of, in the Object-Oriented programming world, what is lightweight object? And in other computer science fields, what does lightweight means then? Is lightweight a design pattern? Is lightweight good, is bad?
There are many meanings for lightweight, but normally it means the object which has less amount of data or which process less amount of data. Sometimes a thread is called as a lightweight process as it does a less things than a process do. Its processing is also fast than the process. A lightweight object is one which has less amount members and which are of basic types (int, float) as member variables. A light function is the one which does very less things compared to others. Normally these are inline functions. (in C context).
There is no such patterns as lightweight pattern. But Normally the systems should be consists of lightweight objects so that the maintaining those objects could be easy.
The advantages are simple debugging, maintenance and easy understanding of code. The disadvantage could be lots of objects.
There is no lightweight pattern as such but the term is fairly used in the industry.
Lightweight X tend to be used in the case where we have a somewhat well known structure X. Lightweight X is then a version of X using fewer resources in some way or the other - or is subtly different from X in some way.
The term, as is the case for most computer science, is not well-defined and is loosely used.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In the spirit of the other common mistakes in questions, what are the most common mistakes that Haskell programmers make? I've been teaching myself Haskell for a little while and I am starting to feel comfortable enough with the language to start applying it in the real world.
The most common mistake I know of is introducing a space leak through lazy evaluation. There are lots of ways to achieve this mistake, but one that especially nails programmers with other functional-programming experience is to put a result in an accumulating parameter, thinking that the accumulating parameter will take constant space. In many cases the accumulating parameter takes linear space because parameters are not evaluated.
Another common mistake is to forget that let is always recursive. An unintentional
let x = ... x ...
can lead to baffling outcomes.
Most other common bad experiences manifest not as mistakes but as trouble getting programs past the type checker, or difficulty understanding the monadic I/O model. Difficulties with list comprehensions and with do notations occur occasionally.
In general the difficulties faced by beginning Haskell programmers include
Large language with many dark corners, especially in the type system
Trouble getting programs to compile, especially when they do I/O
Doing everything in the IO monad
Great difficulty predicting the time and space behavior of lazy functional programs
A common mistake for beginning Haskell programmers is to forget the difference between constructor and type namespaces. That was such a beginner's mistake that I'm about embarrassed to have my name attached to it, but I'm pretty confident that others will stumble upon that answer when they have a similar problem, so may as well keep it out there.
The difference between [] and [[]]: the empty list and the list with 1 element, namely the empty list. This one especially pops up in base cases of recursive functions.
Use non tail-recursive functions or not strict folds occurring to stack overflow.