I just had a thought... Why doesn't somebody implement a spreadsheet
where
Haskell is the formula language? 8-)
http://sigfpe.blogspot.com/2006/11/from-l-theorem-to-spreadsheet.html
may interest.
...ok, and now my head hurts...
(Haskell seems to do that lots. I'm not sure why.)
Well,
Queuing theory is a very large and mature area of
research, with many important applications in
industry. It is not a coincidence that a certain
telephone company named a functional programming
language after Erlang, the founder of queuing
theory.
Erlang actually stands for Ericsson Language. I
Dan Piponi:
On 1/30/07, Lennart Augustsson [EMAIL PROTECTED] wrote:
Excel is what I like to call a 0:th order functional language,
i.e., you can't even define functions, just values. :)
Every cell with an expression in Excel is a function. The problem is
that the domains and codomains of these
Udo Stenzel:
Bjorn Lisper wrote:
- your definition of fromInteger will behave strangely with the elementwise
extended operations, like (+). 1 + [[1,2],[3,4]] will become
[[2,2],[3,5]] rather than [[2,3],[4,5]]. Array languages supporting this
kind of overloading invariably have
I wrote:
Here is one way to do it. First, you have to interpret operations on
matrices as being elementwise applied. E.g, (*) is interpreted as zipWith
(zipWith (*)) rather than matrix multiply, and similar for (+) etc. You then
obtain a lazy semantics for the operations, where the extent of the
Udo Stenzel:
Bjorn Lisper wrote:
Here is one way to do it. First, you have to interpret operations on
matrices as being elementwise applied. E.g, (*) is interpreted as zipWith
(zipWith (*)) rather than matrix multiply
What's this, the principle of greatest surprise at work? Nonono, (*)
should
Here is one way to do it. First, you have to interpret operations on
matrices as being elementwise applied. E.g, (*) is interpreted as zipWith
(zipWith (*)) rather than matrix multiply, and similar for (+) etc. You then
obtain a lazy semantics for the operations, where the extent of the
resulting
Are the values of infinite lists _|_ (bottom)?
No. _|_ represents total lack of information about the result, whereas in a
lazy language like Haskell an infinite list contains a lot of information:
you can observe arbitrary parts of such a list, access them, and compute
with them.
In section
Deokhwan Kim:
Bjorn Lisper wrote:
precisely the same as _|_. Only certain kinds of nontermination can be
modeled by _|_ in a non-strict language.
What kinds of nontermination are modeled by _|_ in Haskell?
Nonterminating computations that never return anything. For instance,
inf = inf
Björn
I finally got some time to answer Simon's posting:
Simon P-J:
| Between google searching and looking through the activity
| report, I take it that no one has really developed serious
| libraries for matrix manipulations, diff eqs, etc.
|
| Are there any practical reasons for this or is it just a
David Roundy:
On Mon, Feb 20, 2006 at 11:47:49AM +0100, Bjorn Lisper wrote:
(a) It's hard to compete with existing libraries. The obvious thing is
not to compete; instead, just call them. But somehow that doesn't seem
to be as motivating. Perhaps some bindings exist though?
Hard
Simon P-J:
Daniel is right, by definition. He is a new user. He had difficulty.
That much is incontrovertible.
While he may seem unusual, perhaps he is only unusual in that he's told
us about his experience rather than trying Perl instead. For which,
much thanks, Daniel!
Actually, I have
Simon:
Me:
| Actually, I have sometimes wished that the various interactive Haskell
| interfaces had the possibility to enter also declarations interactively
GHCi does.
Ah, I see! Does it open a let-environment with a local definition?
ghci let f x = hello
ghci f True
True
Hmm, an interesting
John Meacham
I have started working on jhc more recently and have come across some
places where I think my algorithms could be improved but was not sure
exactly where to start so thought I would ask the list since perhaps
someone here has some insight.
After a long time of trying various methods
Hi all,
Finally I found some time to reply to this posting. A couple of years ago we
did something called Data Field Haskell, which is Haskell extended with a
generalized form of arrays called data fields. Much of the purpose was to
investigate convenient and general syntax for array
I'm surprised that nobody has yet mentioned the ICFP2000 paper Composing
Contracts: An Adventure in Financial Engineering by SPJ, Jean-Marc Eber,
and Julian Seward. It seems to me that it could provide quite relevant
reading.
Björn Lisper
Paul Hudak:
I wouldn't write off Haskell so quickly.
--- Keith Wansbrough [EMAIL PROTECTED] wrote:
Christopher Milton [EMAIL PROTECTED] writes:
I think Haskell can be used to solve several, if not all, of
the seven problems.
Now I have to decide which problem to tackle first.
(a joke, I assume...)
Cagdas Ozgenc:
That's right. I was thinking of the following syntax. I orginally had the
idea for C++, where you can't do partial application at all.
f x y z=...
f # 3 4
omitting the first parameter, and
Array languages with true multidimensional arrays often have a this kind of
syntax
Zhanyong Wan:
Here here. I think that the poor compiler error messages in Haskell are a
very major hurdle to learning the language.
Adrian Hey:
Which compiler are you talking about? Bad error messages are not a valid
critisism of the Haskell Language IMHO.
But there are language features in
Tom Pledger:
Brian Boutel writes:
:
| Having Units as types, with the idea of preventing adding Apples to
| Oranges, or Dollars to Roubles, is a venerable idea, but is not in
| widespread use in actual programming languages. Why not?
There was a pointer to some good papers on this in a
20 matches
Mail list logo
