As an author of HSQL and Visual Haskell I do agree that there is still
a lot to be done in order to make Haskell as popular as C++/Java in
the industry. We need strong support for GUI, Database, XML and many
other libraries that the other languages already have. The existing
development
Paul Johnson wrote:
- Little integration with mainstream software development. No
analysis or design methods or notations. Haskell development appears
to be primarily a matter of paying a bunch of very bright developers
to cut code.
Writing a functional specification is a very good
- Concerns about support and maintenance. Those bright developers may
not be around in the long term.
This seems to be a hen egg problem.
Students do not study functional programming deeply because it seems
irrelevant to finding a job. Decision makers, on the other hand, either
have
Neil Mitchell wrote:
- Larger memory footprint
You are talking about GHC, not Haskell. Take a look at nhc98, which
has a small memory footprint.
We should be clear about whether we're talking about the footprint of
the compiler or the generated binary. I can well believe that GHC needs
a
Donald Bruce Stewart [EMAIL PROTECTED] writes:
In general I would say GHC/Haskell was very very fast, as long as you
know what you're doing.
I have created programs that fill an array with the first 100
prime numbers using erathostenes sieve.
I have done this in lisp, c++, ocaml and
So far all the responses apart from the one by jake have taken issue
with one or other of my assessments of Haskell's weaknesses. Curiously,
nobody seems to be arguing with my assessments of its strengths.
I know the feeling: Haskell is so obviously great that it becomes a kind
of spinal
Paul Johnson [EMAIL PROTECTED] wrote:
Is there a market that is poorly served by the incumbent languages for
which Haskell would be an absolute godsend?
Yes. Safety critical systems, encompassing everything from avionics to
railway signalling equipment, to medical devices. These markets are
Paul Johnson wrote:
Is there a market that is poorly served by the incumbent languages for
which Haskell would be an absolute godsend?
yes - teaching principles of programming (and languages).
E. g. I have my students (2nd year) learn (some) Haskell first,
so they will hopefully understand
Malcolm Wallace wrote:
Paul Johnson [EMAIL PROTECTED] wrote:
Is there a market that is poorly served by the incumbent languages for
which Haskell would be an absolute godsend?
Yes. Safety critical systems, encompassing everything from avionics to
railway signalling equipment, to
On 3/27/06, Paul Johnson [EMAIL PROTECTED] wrote:
Is there a market that is poorly served by the incumbent languages for
which Haskell would be an absolute godsend?
As far as I'm concerned, yes almost every market. At least soon.
Within a few years (say, five) we will have tens of cores on
* Analysing and guaranteeing performance characteristics (time,
memory) is something we still can't do well with Haskell.
Seconded. I think all three of:
specification, prediction and post-morten analysis
of resource consumption of Haskell programs
are largely uncharted territory.
I
Dusan Kolar [EMAIL PROTECTED] wrote:
Yes. Safety critical systems, encompassing everything from avionics
to railway signalling equipment, to medical devices. These markets
are relatively small / low-volume, with needs for high assurance,
and better development times.
Well, the
Dusan Kolar wrote:
Malcolm Wallace wrote:
Paul Johnson [EMAIL PROTECTED] wrote:
Is there a market that is poorly served by the incumbent languages for
which Haskell would be an absolute godsend?
Yes. Safety critical systems, encompassing everything from avionics to
railway
Paul Johnson [EMAIL PROTECTED] writes:
So I tried to summarise the Haskell value proposition compared to the
incumbent languages. Thats what it looks like to me, and I am not exactly
ignorant on the subject, so I suggest we take it as a given for now and look
at the real question:
Is
On Mar 27, 2006, at 9:03 AM, Sebastian Sylvan wrote:
On 3/27/06, Paul Johnson [EMAIL PROTECTED] wrote:
Is there a market that is poorly served by the incumbent languages
for
which Haskell would be an absolute godsend?
As far as I'm concerned, yes almost every market. At least soon.
Hi Andres. I just successfully installed tested lhs2TeX on cygwin. The only hitch was in an inconsistent translation of /usr/local into c:/cygwin/usr/local (I guess bash vs Haskell). The fix was very simple: ./configure --prefix=c:/cygwin/usr/local before make and make install. I suggest you add
Paul Johnson wrote:
I've never used Visual Haskell, but from the web page two things stand out:
1: Its version 0.0. This is not for production use.
Also: You may not use or distribute this Software or any derivative
works in any form for commercial purposes.
Robert Dockins wrote:
All we have to do is be ready for it when it arrives.
When people see that, using Haskell, they can write programs using 1)
fewer man-hours with 2) fewer bugs which 3) scale effortlessly to
highly parallel hardware to beat the pants off C/C++/Java/what-have-
you,
G'day all.
Quoting Immanuel Litzroth [EMAIL PROTECTED]:
I have created programs that fill an array with the first 100
prime numbers using erathostenes sieve.
I have done this in lisp, c++, ocaml and haskell. Lisp and c++ win
hands down, being approximately 5x faster than ocaml, haskell.
Visual Haskell is now with BSD license and it is open sourced. See
http://darcs.haskell.org/vshaskell/
Cheers,
Krasimir
2006/3/28, Ashley Yakeley [EMAIL PROTECTED]:
Paul Johnson wrote:
I've never used Visual Haskell, but from the web page two things stand out:
1: Its version 0.0.
Thanks for the analysis Duncan. Would you mind submitting a ticket for
this?
What does the crash look like in gdb? Does it look like it has jumped
into the middle of nowhere, or is it a crash in some actual code that
you can disassemble? To find out what was happening just before the
Hi Simon,
On Mon, 2006-03-27 at 10:29 +0100, Simon Marlow wrote:
Thanks for the analysis Duncan. Would you mind submitting a ticket for
this?
What does the crash look like in gdb? Does it look like it has jumped
into the middle of nowhere, or is it a crash in some actual code that
you
More on the porting theme,
We've had an unregisterised alpha port in gentoo for some time and two
of our alpha devs with an interest in ghc decided to try to get the
registerised build working.
They started by turning off the mangler and trying to get the register
bit working. This is ghc-6.4.1.
#734: Spurious type variable scope error report
--+-
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: closed
Priority: normal
Am Freitag, 24. März 2006 15:55 schrieb Duncan Coutts:
I built yesterday's ghc-6.4.2 snapshot (2006/03/23) and had a problem
building the docs. [...]
Things have improved, but make html still fails, this time when building the
Haddock documentation for the base package:
haddock: modules
Some days ago I reported a regression in GHC:
http://www.haskell.org//pipermail/cvs-all/2006-March/046637.html
I've fixed Happy to produce correct code, so the 2nd problem mentioned is
already solved. Nevertheless, the regression remains even in yesterday's GHC
built from darcs HEAD (what's
#735: Missing case in fgl/Data/Graph/Inductive/Internal/RootPath.hs
--+-
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug| Status: new
Priority: normal
Sven Panne wrote:
Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley:
I've found a workaround to the problem below: instead of trying to use
hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function
freeHaskellFunPtr into my DLL, and use this to free everything, finally
using it to
Michael Marte wrote:
Hello *,
when building ghc 6.5 with ghc 6.4 and alex 2.0.1, the build fails as
follows:
make -C ghc/compiler stage=2
make[2]: Entering directory `/home/marte/fptools/ghc/compiler'
../../ghc/compiler/ghc-inplace -H16m -O -istage2/utils
-istage2/basicTypes
Thorkil Naur wrote:
Thanks a lot, that removed some obstacles. Unfortunately, not all. Following
successful make clean and make all in ghc/compiler and
libraries/base, a make all in the top-level directory reported:
../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.4.1 -H16m -O
...
Krasimir Angelov wrote:
Hi Brian,
The problem is that hs_free_fun_ptr is defined in a static library
(the Haskell RTS) while you have declared it with
__declspec(dllimport). In this case the compiler is tring tp optimize
the call and it is using __imp__hs_free_fun_ptr instead of
Sven Panne wrote:
Am Samstag, 25. März 2006 20:00 schrieb Brian Hulley:
I've found a workaround to the problem below: instead of trying to
use hs_free_fun_ptr, I instead pass a FunPtr to the Haskell function
freeHaskellFunPtr into my DLL, and use this to free everything,
finally using it to
Simon Marlow wrote:
Michael Marte wrote:
Hello *,
when building ghc 6.5 with ghc 6.4 and alex 2.0.1, the build fails as
follows:
make -C ghc/compiler stage=2
make[2]: Entering directory `/home/marte/fptools/ghc/compiler'
../../ghc/compiler/ghc-inplace -H16m -O -istage2/utils
Am Montag, 27. März 2006 14:27 schrieb Brian Hulley:
[...] For example, in:
foreign import ccall wrapper mkIO :: IO () - IO (FunPtr (IO ()))
foreign import ccall set_callback :: FunPtr (IO ()) - IO ()
foreign import ccall run :: IO ()
foo1 :: IO ()
foo1 = do
Hello Simon,
Monday, March 27, 2006, 2:57:47 PM, you wrote:
quotInteger2Expzh_fast is the function you are adding to PrimOps.cmm to
Thorkil, i can't understand why you can't just use FFI to import
functions you required? why you need to patch the PrimOps list?
--
Best regards,
Bulat
Michael Marte wrote:
Yes, I synced my working copy of ghc 6.5 yesterday with darcs pull.
Are there any requirements as to which exact version of ghc 6.4 I am
supposed to use?
I am using the plain 6.4 release but I am able to build the head of the
6.4 branch.
BTW. Am I supposed to run
Sven Panne wrote:
[snip]
being executed. The technical reason for this is that after returning
from Haskell land, the adjustor code might need to do some cleanup:
C - adjustor - stub - Haskell - stub - adjustor - C
It could be the case that the adjustor tail-jumps to the stub, but
this is
C - adjustor - stub - Haskell - stub - adjustor - CIt could be the case that the adjustor tail-jumps to the stub, but this is not guaranteed to be the case for all platforms.Hmmm, I thought it was.Well, the FFI addendum is rather vague on this point; this seems to be all it says about
Hi,
I'm designing an API for a simple graphics window, and am trying to make the
correct usage of the API functions explicit and visible to the type system
by using different monads which ultimately just wrap the IO monad. For
example, in a callback for rendering stuff to the screen, only
Brian Hulley wrote:
Hi,
I'm designing an API for a simple graphics window, and am trying to make
the correct usage of the API functions explicit and visible to the type
system by using different monads which ultimately just wrap the IO
monad. For example, in a callback for rendering stuff to
Chris Kuklewicz wrote:
Brian Hulley wrote:
Hi,
I'm designing an API for a simple graphics window, and am trying to
[snip]
There should be no overhead for a newtype. The above can be
shortened to one line:
newtype VertexM a = VertexM (IO a) deriving (Functor,Monad,MonadIO)
Thanks - that
On Mon, Mar 27, 2006 at 08:14:40PM +0100, Brian Hulley wrote:
However I'm wondering if I can rely on all this monad stuff being optimized
out at compile time. A sample monad is below:
newtype VertexM a = VertexM (IO a)
in GHC you can actually guarentee there is no overhead with the
On Tue, 2006-03-28 at 01:37 +0100, Brian Hulley wrote:
Hi Duncan -
I just declared duma_vertex3f (in another module) by:
foreign import ccall duma_vertex3f :: Float - Float - Float - IO ()
I thought this means that the C function prototype must be:
void duma_vertex3f(HsFloat,
John Goerzen [EMAIL PROTECTED] wrote:
On Fri, Mar 24, 2006 at 11:07:53AM +, Malcolm Wallace wrote:
I assume that since a non-concurrent implementation has
only one thread, that thread will be trying to MVar-synchronise with
something that does not exist, and hence be
I am not sure how this look in other people's editors and mail-
readers, but on my machine (Mac OS X Tiger) there
is significantly more white space after the symbol than before. Is
that normal?
For emacs, just bind a key (C-. say) to (ucs-insert
#X2218). ucs-insert comes from ucs-tables.
FYI, Cayenne used the center dot as composition. See the System$HO module.
http://www.cs.chalmers.se/~augustss/cayenne/system.html
I remember liking it but I think the ring operator would be closer to
mathematics notation and indeed the best choice.
Cheers,
/Josef
On 3/25/06, Dylan Thurston
On 26 March 2006 02:31, isaac jones wrote:
Possible Interests:
1. I can write tools like filesystems, web servers, and GUIs in
Haskell'
2. Libraries that I use are thread-safe
3. I can compile my code with any Haskell' compiler
4. Tools such as debuggers and tracers that claim to
it's too hard to implement (and it's not always hard
- the YHC guys
managed it in a matter of days
Tom is the one who implemented it in Yhc, and details can be found
http://www.haskell.org/haskellwiki/Yhc/RTS/Concurrency
but some of the reasons that it was easier than in other compilers are:
On Mon, Mar 27, 2006 at 09:36:28AM +0100, Simon Marlow wrote:
On 26 March 2006 03:44, Ross Paterson wrote:
[...] the key point is that
a Haskell' module that does not use concurrency, but is thread-safe,
ought to work with non-concurrent implementations too.
To make that work, we'd
On 3/27/06, Ross Paterson [EMAIL PROTECTED] wrote:
How about STM (minus retry/orElse) and TVars as the portable interface?
They're trivial for a single-threaded implementation, and provide a
comfortable interface for everyone.
+1 on STM as the core interface. Why do you suggest omitting
On 2006-03-28, Taral [EMAIL PROTECTED] wrote:
On 3/27/06, Ross Paterson [EMAIL PROTECTED] wrote:
How about STM (minus retry/orElse) and TVars as the portable interface?
They're trivial for a single-threaded implementation, and provide a
comfortable interface for everyone.
+1 on STM as the
I have rewritten the Huffman benchmark (see
http://cse.unl.edu/~sjanssen/huffman.hs), resulting in a significant
performance increase. On my computer it completes one iteration in
about 0.9 seconds. In comparison, the O'Caml version takes around 3.1
seconds. These samples seem to indicate that
It seems I have spoken too soon!
There is one infidelity in my implementation: the program writes the
output once per iteration, and this IO is included in the measured
time.
Due to a few changes, this caveat no longer applies. As a result
Haskell performs just a bit better. The code is
On Fri, Mar 24, 2006 at 06:54:54PM +, Aaron Denney wrote:
Without breaking compatibility?
But class instances become invalid if the hierarchy is modified.
No, compatibility will be broken. Hopefully not for most uses -- I
don't think most people define new instances, and those that do
On Mar 26, 2006, at 4:35 PM, Daniel McAllansmith wrote:
[Discussion of positive integers and Words]
I was thinking about several things in this thread, torsors, overflow
semantics, bounds checking...
I wonder if there would be any merit in being able to define
constrained
subsets of
For example, take UNIX nice levels -20 to 19. You could have
data ConstrainedInteger = CI {distToMax :: Natural, distToMin :: Natural}
this would ensure only the 40 integers can be represented.
Then you could have _something_ that defined what happened on overflow,
whether it wraps,
On Mon, Mar 27, 2006 at 05:02:20AM -0800, John Meacham wrote:
well, in interfaces you are going to end up with some specific class or
another concretely mentioned in your type signatures, which means you
can't interact with code that only knows about the alternate class. like
genericLength
Doesn't Ada have constrained number types which have similar behaviour?
Yes. Just for comparison, the behaviour of the Ada number is to throw
an exception at runtime if a number overflows its bounds. If these
checks can be eliminated statically, then they are. If an operation
will always give a
On Mon, 27 Mar 2006, Neil Mitchell wrote:
Doesn't Ada have constrained number types which have similar behaviour?
Yes. Just for comparison, the behaviour of the Ada number is to throw
an exception at runtime if a number overflows its bounds. If these
checks can be eliminated statically, then
Hi
Thanks to everyone that have helped, the runtimes for the haskell
programs have decreased significantly, presently they look like this
compared to O'Caml:
Benchmark haskell ocaml
drop3 5.786 3.151
five11 8.657 7.692
huffman 7.134 18.593
uudecode
On Mon, Mar 27, 2006 at 02:53:58PM +1200, Daniel McAllansmith wrote:
Is there a consensus on how anticipatable failure situations should be
handled?
There was a thread, haskell programming guidelines, from 2006-02-25 where
John Meacham and Cale Gibbard had a bit of back-and-forth about
How do I perform multiple computations on a long lazy list without introducing a space leak?Doing a single computation like this works great:
f = show . filter ( 1)But if I do something like this: f lst = show (filter ( 1) lst, filter ( 2) lst)then it looks like GHC won't garbage collect list
Hi Greg,
But if I do something like this:
f lst = show (filter ( 1) lst, filter ( 2) lst)
then it looks like GHC won't garbage collect list elements
until the first
filter has completely finished
There is a very good reason for this, show (a,b) is essentially
show (a,b) = ( ++ show a
hold a part of the data in memory while you show the first one,Here would be a better example then. f lst = show (sum (filter ( 1) lst), sum (filter ( 2) lst))It ought to be *possible* to compute both operations without holding onto any of the list elements.
In the imperative world, you'd say:
Hi, folks.
I've got a working class and instances thereof. I would now like to change
the class such that error behaviour is specified by MonadError, for the
moment throwing String errors. When I try to add MonadError into the types I
eventually hit the requirement for
John Hughes wrote:
...
Indeed, error messages in common cases would be worsened significantly,
because as Ross says, common errors (such as forgetting a parameter in a
recursive call) would lead to legal definitions that cause a type error
when applied. Partly for this reason, OCaml
Hi,
Here would be a better example then.
f lst = show (sum (filter ( 1) lst), sum (filter ( 2) lst))
I suspected that you actually wanted to do something cleverer with
the list, for the sake of argument, I'm going to change 1 to p1 and
2 to p2 - to show how this can be done in the general
Neil Mitchell wrote:
I suspected that you actually wanted to do something cleverer with
the list, for the sake of argument, I'm going to change 1 to p1 and
2 to p2 - to show how this can be done in the general case. With the
specific information you know about 1 vs 2 you can do better, but
Thanks Neil. How do I add in another ~10 computations, or map a list of a 100 computations to the same input?Isn't there a way to do this without one computation having to be aware of the other? This feels like a situation Parsec users would find themselves in all the time. When you have a bunch
Thanks Neil. How do I add in another ~10 computations, or map a list of a
100 computations to the same input?
Isn't there a way to do this without one computation having to be aware of
the other?
I guess they have to be aware at some level, perhaps arrows generalise
the awareness they need,
On 3/28/06, Neil Mitchell [EMAIL PROTECTED] wrote:
This feels like a situation Parsec users would find themselves in all the
time. When you have a bunch of parsers in a 'choice', does the start of the
input stream linger until the last parser is executed?
No, as soon as one token is
On Tuesday 28 March 2006 11:12, Daniel McAllansmith wrote:
Hi, folks.
I've got a working class and instances thereof. I would now like to change
the class such that error behaviour is specified by MonadError, for the
moment throwing String errors. When I try to add MonadError into the types
I'm working through Pierce's Types and Programming Languages on my own. I'm attempting to write the typecheckers in Haskell, instead of ML. However, when it comes to his eval function, I'm a little stuck. The original is
let rec eval t = try let t' = eval1 t in eval t' with NoRuleApplies - tWhere
Steve Downey wrote:
It makes eval1 a bit more complicated, and not as straightforward
translation from the type system being described, though.
e.g reducing If looks more like
eval1 (TmIfExpr t1 t2 t3) =
let t1' = eval1 t1
in case t1' of
{ Just t1'' - Just $ TmIfExpr t1''
On Mon, Mar 27, 2006 at 03:10:18PM -0800, Greg Fitzgerald wrote:
hold a part of the data in memory while you show the first one,
Here would be a better example then.
f lst = show (sum (filter ( 1) lst), sum (filter ( 2) lst))
It ought to be *possible* to compute both operations
Tomasz Zielonka wrote:
I wonder if it would be possible to remove the space-leak by running both
branches concurrently, and scheduling threads in a way that would
minimise the space-leak. I proposed this before
http://www.haskell.org/pipermail/haskell-cafe/2005-December/013428.html
Steve Downey wrote:
] I'm considering changing eval1 to be ArithExpr-Maybe ArithExpr
]
] If the expression is reducible, then I return Just t, and if it's not
] reducible, then Nothing
]
] It makes eval1 a bit more complicated, and not as straightforward
] translation from the type system being
77 matches
Mail list logo
