Haskell is still a very dynamic language - there is still much room for
it to grow and improve. In that sense, it is still young.
Perl and Python and Ruby have hit middle age - no more growing, just
more bulk accumulating around the middle.
Matt
On Wednesday, December 8, 2004, at 08:06 AM, Gou
> Is there a standard Haskell trick for checking run-time assignment to
> data types? I'd like a data type of Probability that ensures its
> Double argument is between 0 and 1.
>
> Jim
A fairly common technique to achieve this is smart constructors
(apparently also called factory functions).
ht
Paul Hudak ([EMAIL PROTECTED]) wrote:
> Does Python not have warts? Or Pearl, or Java, or C#? I don't think
> that a few warts prevent a language from becoming a "success".
I agree.
> But you may be right that it is too late... Haskell is getting old!
> Sometimes I think that for a language
Hi,
I have recently come across the curious phenomenon that ghci is sometimes much
slower than hugs. The occasion that gave rise to it was in connection with
continued fractions, where, having a continued fraction with quotients a(n),
n >= 0, you get the numerators of the convergents by the recu
Graham & All,
Graham Klyne wrote:
1. The lack of variables in Haskell isn't a problem so much as an
opportunity to think in new and interesting ways.
What I was trying to say: where in imperative languages there is a
boundary between in-memory computations and I/O, equivalent semantic
boundary i
Is there a standard Haskell trick for checking run-time assignment to
data types? I'd like a data type of Probability that ensures its Double
argument is between 0 and 1.
Jim
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailma
On Dec 6, 2004, at 11:05 PM, Tom Pledger wrote:
import Data.Char(isSpace)
import Data.List(groupBy)
(op `on` f) x y = f x `op` f y
wordsAndSpaces = groupBy ((==) `on` isSpace)
`on` is a handy little function in this instance.
Does it have a technical name?
Have you used it elsewhere?
-
On 2004-12-06, Gour <[EMAIL PROTECTED]> wrote:
> However, these projects are mostly done by few individuals working hard and
> there is also "A Bus Hits Simon Peyton Jones" problem referred during the
> CUFP workshop.
>
> Any idea how to make a (more organize) community effort to bring Haskell ou
On 2004-12-07, Graham Klyne <[EMAIL PROTECTED]> wrote:
> I'd say that any attempt to proselytize Haskell (or any new technology)
> needs to start from a clear view of one kind of application that it is
> particularly good for. Then, focus on building a "bridgehead" for that
> narrow application
On Tue, Dec 07, 2004 at 11:30:11AM +0100, Henning Thielemann wrote:
> What's unfortunate here is probably that the files are lying around in the
> same directory as the sources. E.g. the build system of Modula-3 uses a
> directory structure like this:
>
> Project
>LINUXLIBC6 - object files a
On Tue, 7 Dec 2004, Paul Hudak wrote:
> But you may be right that it is too late... Haskell is getting old!
> Sometimes I think that for a language to "succeed" it must do so in its
> infancy.
This is also my impression.
> Perhaps the thing to do is create a new language with a new name, but
On Tue, 7 Dec 2004, Brian Smith wrote:
> FWIW, I use a directory structure like:
> src/ source code
> build// intermediate files (.hi, .o)
> dist/ deliverables
> I execute GHC using:
> ghc --make Main -isrc -hidir build -odir build -o dist/program
> As a result, I nev
On Tue, Dec 07, 2004 at 01:58:59PM -0500, Paul Hudak wrote:
> Aaron Denney wrote:
> >I'd rather it didn't until a few warts were fixed. OTOH, it may be too
> >late already, barring a Haskell 2.
>
> Does Python not have warts? Or Pearl, or Java, or C#? I don't think
> that a few warts prevent a
Aaron Denney wrote:
On 2004-12-06, Gour <[EMAIL PROTECTED]> wrote:
Any idea how to make a (more organize) community effort to bring Haskell out?
I'd rather it didn't until a few warts were fixed. OTOH, it may be too
late already, barring a Haskell 2.
Does Python not have warts? Or Pearl, or Java,
On 2004-12-06, Gour <[EMAIL PROTECTED]> wrote:
> Applications like darcs are very important enabling newcomers to see some
> concrete & succesful non-academia-open-source project.
>
> Besides that, seeing the progress of projects working on the binding for
> gui-libraries (wxhaskell & gtk2hs) are
John Goerzen wrote:
>On Tue, Dec 07, 2004 at 12:43:27PM +0100, Lennart Augustsson wrote:
>>Yay! :) Dynamically linked libraries are slower than statically linked
>>ones in just about every implementation I know of. I don't care.
>
>My understanding was that this was mostly limited to x86 platform
John Goerzen wrote:
On Tue, Dec 07, 2004 at 12:43:27PM +0100, Lennart Augustsson wrote:
slightly slower than statically linked ones), but you still have the
versioning issue.
Yay! :) Dynamically linked libraries are slower than statically linked
ones in just about every implementation I know of.
What if (go with me here) we invent a new aggregate unit of haskell
code, and we call it a library, and we design libraries with the express
intent of allowing dynamic linking. We would desire:
1) True dynamic linking for reduced memory (and disk) footprint and
drop-in replacement
2) ABI vers
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.
html#NEWTYPE-DERIVING
| -Original Message-
| From: Graham Klyne [mailto:[EMAIL PROTECTED]
| Sent: 07 December 2004 10:46
| To: Simon Peyton-Jones; [EMAIL PROTECTED]
| Subject: RE: [Haskell-cafe] Classes in type declar
On Tue, Dec 07, 2004 at 12:43:27PM +0100, Lennart Augustsson wrote:
> >slightly slower than statically linked ones), but you still have the
> >versioning issue.
> Yay! :) Dynamically linked libraries are slower than statically linked
> ones in just about every implementation I know of. I don't ca
Well, looking at perl/python/PHP (as in LAMP), I would say the trick is
to pick
an application area and make it extreemely easy to use the language in
that area,
as well as trivial to install and maintain the language support.
Of course the fact that perl/python/php all picked web-services (acti
Simon Marlow wrote:
Dynamic linking is (almost) a separate issue. GHC 6.4 will have some
support for dynamic linking in the native code generator thanks to
Wolfgang Thaller, but it needs someone to push it the final mile on
x86/Linux and Windows. Dynamically linked libraries will work (albeit
sli
I find myself agreeing with the implied likely response to all of the
points you raise below.
I'd say that any attempt to proselytize Haskell (or any new technology)
needs to start from a clear view of one kind of application that it is
particularly good for. Then, focus on building a "bridgeh
At 10:15 06/12/04 +, Simon Peyton-Jones wrote:
| This is where I find ghc's newtype deriving to be incredibly useful.
|
| newtype CPError a = CPError (Either Error a)
| deriving(Monad,MonadError)
|
| now CPError is a monad and an instance of MonadError and you are free
to
| override or
I'm struggling to keep up with this list, so I'll make two brief responses
here. Sorry to not be more forthcoming:
1. The lack of variables in Haskell isn't a problem so much as an
opportunity to think in new and interesting ways.
2. I think that when you talk about "versioning", you come clos
On 06 December 2004 14:39, John Goerzen wrote:
> On 2004-12-06, Keith Wansbrough <[EMAIL PROTECTED]> wrote:
>> The static vs dynamic linking question has been discussed many times.
>> The summary is: GHC is a highly-optimising compiler, and the binary
>> interface _necessarily_ changes with every
On 06 December 2004 21:54, Sven Panne wrote:
> And just a remark: We don't need a new technique for a "no inline
> barrier": Just compile the library optimized and use a facade which
> re-exports your public API compiled without optimizations.
That probably won't work. GHC goes to the .hi file f
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> However if there is a desire to make Haskell more accessible to the majority
> of programmers then the first impressions that I, and those like me have is
> important.
Sure. I'm also pretty new to Haskell & ghc concerned to see Haskell used by
mor
On Mon, 6 Dec 2004, Sven Panne wrote:
> [EMAIL PROTECTED] wrote:
> > The original observation was that the compiler seems archaic. When
> > asked, I gave some general comments. What I should have just said was
> > that it was to much like a C compiler. Which, no matter how neat you
> > think it i
> > > > When I compile it I get three files, an actual runnable binary (at only
> > > > 5M in size), a .o file and a .hi file. I'm sure these additional files
> > > > are usefull in someway and as soon as I come across the right piece of
> > > > documentation everything should make sense. But as a
On 6 Dec 2004, at 21:56, Sven Panne wrote:
Jules Bean wrote:
I don't think it does, actually. You can imagine a compiler which has
access to not *only* the .so files, but also the haskell source.
Therefore it can still unroll (from the source), but it can choose to
link to an exported symbol if
31 matches
Mail list logo
