Re: F#

2004-05-21 Thread Alastair Reid 

> > Purely functional languages like Haskell are excellent
> > within certain niches, but non-trivial problems exist with language
> > interoperability between lazy and strict languages.
> >
> > I believe that is uncontroversial.

Actually, I think Haskell has one of the better language interoperability 
stories going and that lazy-vs-strict is a very well solved problem.

Problems that do crop up in interfacing to foreign languages are:

1) Differences in type system.
   Any two languages are bound to have some differences 
   between their type systems and there's always going to be
   some problems dealing with that.  OO and type-classes happen
   to be superficially similar and yet radically different.

   These happen with any two languages.  Thought they are
   probably more of an issue because of...

2) Attitudes to type safety.
   C programmers overcome any type incompatibility with void*
   and type casts.  Haskell programmers look for ways to avoid
   doing so.  This can occupy many a happy evening :-)

   (I don't know if the situation has changed but the SML-NJ
   folks used to have a very simple foreign function interface
   which made type errors appallingly easy to make.  This
   seemed to be quite acceptable to them whereas Haskell's ffi
   was designed to make type errors much harder to make. Which
   approach is the right one?)

3) Attitudes to grunge.
   C programmers are used to having complicated, fragile-looking
   interfaces so it's quite common to do things like passing 
   a function an array and a count of how many things are in
   the array.  Haskell programmers look for ways to avoid such
   fragility but, of course, it takes more up-front effort
   to develop a safer interface and gives you a good solid
   push down that slippery slope of perfectionism on which 
   Haskell folk so often find themselves.

And, in the specific case of GUI programming, I think there's been a problem 
of not enough people, too many ideas on how GUI programming should be done, 
and too many GUI libs to try interfacing to.  (Obviously, if we'd worked on 
Windows exclusively, there would have been less choice so we'd have been more 
focused.)

--
Alastair Reid
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Statically linked binary?

2004-05-21 Thread Glynn Clements 

Jochen L. Leidner wrote:

> sorry for an urgent newbie question: how can I create a statically 
> compiled version of a Haskell program on Linux with GHC that does not rely 
> on external shared libs (also for any of its libraries it uses)?

Possibly with a great deal of difficulty, depending upon which
functions you need to use.

GNU libc 2.x dynamically loads shared libraries (with dlopen()) for
various "database" lookups (passwd, group, hosts etc). This applies
even when using a static libc (libc.a).

If you need to call (directly or indirectly) any of the functions
which use this mechanism, then you have to either:

a) have (the correct versions of) the relevant libnss_*.so libraries
installed on the target system, or

b) you have to compile your own libc.a using the --enable-static-nss
switch.

The most common functions which require this mechanism are those which
access the passwd database (getpwnam, getpwuid, etc) and those which
perform hostname/domain lookups (gethostbyname etc). Even if you don't
use these functions directly from your program, the libraries which
you use might use them. E.g.:

+ X needs to resolve the hostname part of $DISPLAY, so anything
which uses X is affected.

+ Anything which supports the "~user" syntax to refer to a specific
user's home directory will need to use getpwnam().

+ Anything which needs to translate between UIDs and usernames will
need to use getpwnam() and/or getpwuid().

+ Etc.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghci and ld scripts

2004-05-21 Thread Sven Panne 
Simon Peyton-Jones wrote:
We've no idea what to do here.  In your case it'd be possible to just
ignore the script, but presumably not so in general. [...]
I've just made a quick test on my SuSE 9.1 Linux and it seems to be the
case that an explicit "-lpthread" is not necessary anymore, even for
programs using pthread calls. Strange, but handy. :-) Could you try if
things work for you without adding "pthread" to extra_libraries?
Another way would be using some kind of autoconf/shell magic to test
for the linker script and install a link to /lib/libpthread.so.0 with
the name "myownpthread.so" to the installation directory of your package
and add "myonwpthread" to extra_libraries. Ugly...
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping, undecidable, incoherent -- or worse?

2004-05-21 Thread Alex Ferguson 
On Fri, May 21, 2004 at 11:04:53AM +0100, Simon Peyton-Jones wrote:
> Nothing difficult in principle, but the constraint solver is one of
> the more delicate parts of GHC because GHC's constraint language has
> become so complex.

Well, as my day job is working for a constraints lab, I feel it's my
bounded duty to say, "all the better":  more cross-disciplinary synergy.
;-)

For my part I must admit the current restrictions aren't _that_ irksome:
they're just the sort of thing I run into every so often, have to remind
myself they're the way they are, and end up writing a few more instance
declarations by hand than I initially imagined I 'ought' to have to.


On the point of complexity:  it's not immediately obvious to me that
(setting aside the Hugs-style extension to H98 in the form of the
instance decls.) it would cause any blowup here in principle.  Granted
there's a combinatorial issue, but the breadth and depth of alternatives
are necessarily finite, so it seems finitely bound overall, and since HM
typing is D-Exp anyway, I'd be surprised if it made it worse than that
in toto.

Hideousness of implementation's another matter, and certainly I don't
want to be biting the hand that feeds...

Cheers,
Alex.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping, undecidable, incoherent -- or worse?

2004-05-21 Thread Alex Ferguson 
On Thu, May 20, 2004 at 11:06:44PM +0100, MR K P SCHUPKE wrote:
> I agree, I have made it not terminate myself with undecidable-instances,

Congratulations. ;-)


> I also think prolog style backtacking would be a good idea... I think I said
> that  you either want full backtracking or you want to leave it how it is
> (with dependancies ignored) - I have yet to be convinced that any partial
> solution would have the elegance of full backtracking, yet would complicate
> the implementation and syntax. 

Oh, I don't think what I'm suggesting is a 'partial solution', short of
full dependency-based backtracking: I think it almost requires the
latter.  But having done such a thing, I'd imagine one is yet more
likely to encounter situations where it's ambiguous which of a number of
possible instance derivation routes is possible, which in turn is likely
to make specifying which is wanted more important -- the alternative
would seem to be verifying that only one possible instance can be
arrived at, or examing the possibilities in some arbitrary order (such as
that of the program text).

(I belatedly found the more full description of 'incoherent instances'
in the documentation, having initially only noticed the 'flags' section,
and can see that it indeed does nothing like what I was needing...)

Cheers,
Alex.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: F#

2004-05-21 Thread Simon Marlow 
On 21 May 2004 01:07, John Sharley wrote:

> I note this remark on the Microsoft Research site
> (http://research.microsoft.com/projects/ilx/fsharp.aspx)
> 
> Purely functional languages like Haskell are excellent within certain
> niches, but unfortunately some simple programming exercises can
> quickly turn into problems that require a PhD. to solve.
> 
> 
> Are the Microsoft Research people working on GHC or anyone else on
> this list also of this opinion? If so, why?
> 
> What if anything does the quoted remark mean for the prospects of
> seeing a production Haskell compiler from Microsoft?

A response from the author of that page (Don Syme, also here at MSRC):

On 21 May 2004 15:00, Don Syme wrote:

> I've removed the offending line, since I didn't mean to be
> inflammatory.  I believe it to be true - writing a GUI library
> wrapper for Win32 is fairly simple in C#, pretty hard in F#, and
> really quite researchy in Haskell - but others obviously don't agree.
> 
> Replaced with
> 
> Purely functional languages like Haskell are excellent
> within certain niches, but non-trivial problems exist with language
> interoperability between lazy and strict languages.
> 
> I believe that is uncontroversial.  Forward this to the Haskell list
> if you like.  Change should propagate to research.microsoft.com
> sometime soon.  
> 
> Cheers
> 
> Don
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: F#

2004-05-21 Thread Simon Marlow 
On 21 May 2004 01:07, John Sharley wrote:

> I note this remark on the Microsoft Research site
> (http://research.microsoft.com/projects/ilx/fsharp.aspx)
> 
> Purely functional languages like Haskell are excellent within certain
> niches, but unfortunately some simple programming exercises can
> quickly turn into problems that require a PhD. to solve.
> 
> 
> Are the Microsoft Research people working on GHC or anyone else on
> this list also of this opinion? If so, why?
> 
> What if anything does the quoted remark mean for the prospects of
> seeing a production Haskell compiler from Microsoft?

It's possible that the remark is referring to the use of monads to do IO
in Haskell, but I wouldn't read too much into it.

Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Statically linked binary?

2004-05-21 Thread Simon Marlow 
On 21 May 2004 14:17, Jochen L. Leidner wrote:

> sorry for an urgent newbie question: how can I create a statically
> compiled version of a Haskell program on Linux with GHC that does not
> rely on external shared libs (also for any of its libraries it uses)?
> 
> I would like to build a binary that works on a 3-processor machine
> with an older Linux SMP kernel as well as RH9/FC2.

The GHC flag '-optl-static' is your friend.  Note that it is still
possible to end up with a binary that is kernel-version-dependent.

Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Statically linked binary?

2004-05-21 Thread Jochen L. Leidner 
Hi,

sorry for an urgent newbie question: how can I create a statically 
compiled version of a Haskell program on Linux with GHC that does not rely 
on external shared libs (also for any of its libraries it uses)?

I would like to build a binary that works on a 3-processor machine with an 
older Linux SMP kernel as well as RH9/FC2.

Thanks in advance,
Jochen

-- 
Jochen L Leidner   <[EMAIL PROTECTED]>
ICCS   <[EMAIL PROTECTED]>
University of Edinburgh

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: ghci and ld scripts

2004-05-21 Thread Simon Peyton-Jones 
We've no idea what to do here.  In your case it'd be possible to just
ignore the script, but presumably not so in general.

If anyone who understands the problem properly would like to advise,
we'd be happy to hear from them. Parsing ld scripts seems beyond what
our linker is ever going to do!

Simon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Duncan Coutts
| Sent: 16 May 2004 16:48
| To: GHC-users list
| Subject: ghci and ld scripts
| 
| So here's the problem:
| 
| We have a Haskell binding to a C library (one of the gtk extension
libs)
| which uses the pthread library. So we put "pthread" in the
| extra_libraries section of our ghc package conf file.
| 
| This works fine when building standalone programs, however when we try
| and use this package in ghci we get this error:
| 
| ...
| Loading package gtk2 ... linking ... done.
| Loading package sourceview ... ghc-6.2.1: can't load .so/.DLL for:
| pthread (/usr/lib/libpthread.so: invalid ELF header)
| 
| Inspecting /usr/lib/libpthread.so we find that indeed it is not a .so
| file but a gnu ld script:
| 
| /* GNU ld script
|Use the shared library, but some functions are only in
|the static library, so try that secondarily.  */
| OUTPUT_FORMAT(elf32-i386)
| GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )
| 
| So we should get ghci to dynamically load /lib/libpthread.so.0,
however
| there is no way to specify this in the package.conf file.
| 
| It turns out that we don't need ghci to load this .so because it is a
| dep of another .so that we do load, however if I leave it out then
| building standalone progs would fail to link.
| 
| Has anyone come across this before? How do you deal with it?
| 
| Duncan
| 
| ___
| Glasgow-haskell-users mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: F#

2004-05-21 Thread MR K P SCHUPKE 
> but unfortunately some simple programming exercises can quickly turn
> into problems that require a PhD. to solve.

Of course you could say that the excersise is not actaully as simple
as you believe, and other languages will let you get away with stuff
you really shouldn't be doing.

A good example of this is threads. There are apparently very few programmers
that can do threads well, I heard of one survey that stated most programming
shops only have one 'threads expert' and problems inevitably get referred to
them. 

Haskell solves a lot of the problems you have in dealing nicely with threads
in other languages (no side effects - built in channels and MVars so no
visible mutexes). #

One of the biggest problems in software is dealing with complexity, so
anything that helps sort this out is a plus... 

Most large software projects are delivered late or not working due to 
complexity. I guess the person that wrote that article was thinking
about 'scripting' rather than programming (as in visual basic style
stuff) - Well thats my opinion at least...

Keean.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

F#

2004-05-21 Thread John Sharley 
I note this remark on the Microsoft Research site
(http://research.microsoft.com/projects/ilx/fsharp.aspx)

Purely functional languages like Haskell are excellent within certain
niches, but unfortunately some simple programming exercises can quickly turn
into problems that require a PhD. to solve.


Are the Microsoft Research people working on GHC or anyone else on this list
also of this opinion? If so, why?

What if anything does the quoted remark mean for the prospects of seeing a
production Haskell compiler from Microsoft?





___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc-devel for darwinports

2004-05-21 Thread David Leimbach 
Do we have enough Haskell now for it to have it's own category?
Python and other languages have their own category and it makes
it easier for folks like me to "browse the haskell library" of 
darwinports.

That is unless we can get some kind of decent query system in 
Darwinports
for finding out what's available.  I think a good enough query system 
would
make most categories somewhat superfluous.

dave
On May 20, 2004, at 9:05 AM, Gregory Wright wrote:
Hi,
Due to overwhelming popular demand (well, Sven asked), darwinports
now includes a port 'lang/ghc-devel', which builds from the head of 
the cvs.
The default build includes support for openGL, so this is a way to get
the latest OpenGL support for ghc, which now supports almost all of 
version 1.5.

The ghc-devel port installs as ghc-6.3. (All of the executables have 
the "-6.3"
suffix, so you can install ghc and ghc-devel without conflict. You 
invoke the
new compiler as ghc-6.3 and the interactive environment as ghci-6.3.)

ghc-devel depends on ghc, alex and happy, so if you have none of these
installed and say
sudo port install ghc-devel
you'll get a full bootstrap build of the released version of ghc, 
along with
builds of alex and happy (the lexer and parser generators, 
respectively),
followed by a build of ghc from cvs. This may take some time (about 10 
hours
on an 800 MHz G4), but what would you rather have your CPU doing?

Best Wishes,
Greg
Gregory Wright
Antiope Associates LLC
[EMAIL PROTECTED]
___
Darwinports mailing list
[EMAIL PROTECTED]
http://www.opendarwin.org/mailman/listinfo/darwinports
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Overlapping, undecidable, incoherent -- or worse?

2004-05-21 Thread MR K P SCHUPKE 
I have seen very compact Prolog implementations in Haskell, and I 
also know that constraints, modelled by CHRs can be evaluated directly
in Prolog. Why not just bolt one of these compact Prologs onto the
compiler, and just feed it the facts and rules...

Keean.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Overlapping, undecidable, incoherent -- or worse?

2004-05-21 Thread Simon Peyton-Jones 
| > I agree, I have made it not terminate myself with
| > undecidable-instances,
| > I also think prolog style backtacking would be a good idea...
| 
| For what it's worth, I'll AOL this ("me too").  I know that for the
| area of Haskell I'm exploring (integrating it with OO languages),
| putting backtracking into the type system would instantly enable us
| solve some significant problems.

I'll bear this in mind.  I think the main implementation difficulty concerns 
functional dependencies: when backtracking out one will have to undo any unifications 
triggered by functional dependencies. 

Nothing difficult in principle, but the constraint solver is one of the more delicate 
parts of GHC because GHC's constraint language has become so complex.

Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users