- Glasgow-haskell-users

RE: ghc and hierarchical module names
by Simon Marlow 03 Dec '01

03 Dec '01

[ thread moved from glasgow-haskell-users(a)haskell.org to libraries(a)haskell.org ] > "Simon Marlow" <simonmar(a)microsoft.com> writes: > > > You must give the full module name in the header, eg. > > > module A.B.C where > > This surprised me somewhat, and I must have missed any > discussion/rationale. Could you elaborate/point me at the relevant > information? The discussion was on libraries(a)haskell.org (take a look at the archives), and the motivation was to make the smallest change possible to Haskell itself. With the current proposal, no changes are required to the Haskell report except for the 1-character change required to the lexical syntax of module names. I agree that it might be useful to be able to abbreviate module names by leaving out an initial prefix, so that entire subtrees can be moved without changing the source code. However, there are reasons why this approach is not so nice: as you point out, this introduces a dependency between the source code and the external environment, such that the meaning of a program depends on the directory layout and options to the compiler (currently the meaning depends on just the source to the collection of modules constituting the program), and also there is an inconsistency in that you would declare a module as 'C' but import it as 'A.B.C'. Cheers, Simon

1 0

Re: ghc and hierarchical module names
by Ketil Z Malde 03 Dec '01

03 Dec '01

"Simon Marlow" <simonmar(a)microsoft.com> writes: > You must give the full module name in the header, eg. > module A.B.C where This surprised me somewhat, and I must have missed any discussion/rationale. Could you elaborate/point me at the relevant information? It seems to me that A.B could be implicit (leaving "module C where"), from the path. This might help resolve point 3.2[0] Renaming of Subtrees, since one could add -I (or equivalent options, or modify a path in an env var) for commonly used directories. (Okay, so it would introduce a dependency between the importing source and the build process. Is that it?) -kzm [0] ...suggesting a syntax along import Org.Com.Microsoft.* as Microsoft.* import Microsoft.Foo import Microsoft.J++ as Java giving a shorthand access to deeply nested libraries. -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: ghc and hierarchical module names
by Simon Marlow 03 Dec '01

03 Dec '01

> The release notes for ghc 5.02.1 say: > > 1.4.4. New experimental features > > Partial support for hierarchical module names. > > - but I could not find a document describing how to use this feature. > > Is it possible to use hierarchical module names with ghc at > present, and if so, > how does one write and use a hierarchically-named module ? Module names may include the '.' character with -fglsagow-exts on. Searching for interfaces to include is extended as follows: if our search path contains directories D1...Dn, then a module A.B.C is searched for in D1/A/B/C.hi ... Dn/A/B/C.hi. You must give the full module name in the header, eg. module A.B.C where This support *is* experimental though, so it is subject to change. Also note that certain parts of the hierarchy are reserved for system-supplied libraries - see the current proposal at http://www.haskell.org/~simonmar/libraries/libraries.html Cheers, Simon

1 0

Re: GHC 5.02.1 on Mac OS X
by Ashley Yakeley 02 Dec '01

02 Dec '01

At 2001-12-02 14:39, Nicolas Oury wrote: >do you know if there is a port of gh 5.02.1 on MacOSX? The latest I know of is GHC 5.00.2. And even that is incomplete, it doesn't seem to include a createAdjustor for 'foreign export dynamic' functions (if you happen to need that, as I do). -- Ashley Yakeley, Seattle WA

1 0

GHC 5.02.1 on Mac OS X
by Nicolas Oury 02 Dec '01

02 Dec '01

Hi everybody, do you know if there is a port of gh 5.02.1 on MacOSX? How difficult is it to do a port? Just compiling the source or modifying code of the RTS and the code generation? Is this support planned to be kept in the future? Best regards, Nicolas Oury

1 0

Re: FORTRAN and HASKELL
by Sigbjorn Finne 02 Dec '01

02 Dec '01

Hi, you're in luck then, as the basic ABI is identical that of C (gcc), since g77 shares the same backend. Here's the simple example I tested it with: foo$ cat square.f SUBROUTINE SQUARE(N,M) C COMPUTES THE SQUARE OF N, RETURNS IN M M=N*N RETURN END C foo$ cat main.hs module Main where import Ptr import Storable import MarshalUtils import MarshalAlloc foreign import "square_" unsafe square_ :: Ptr Int -> Ptr Int -> IO Int square :: Int -> IO Int square x = withObject x $ \ ptr_x -> alloca $ \ ptr_res -> do square_ ptr_x ptr_res peek ptr_res main = square 11 >>= print {- --------------------- -} foo$ g77 -c square.f foo$ ghc -o main main.hs square.o -fglasgow-exts -package lang To get the name mangling and the details of passing arguments to the Fortran subroutine right, I looked at the output of "f2c -P", which gives back C prototypes for Fortran function/subs. You could certainly imagine a tool that would automate all this.. hth --sigbjorn ----- Original Message ----- From: "Heron" <heron_carvalho(a)bol.com.br> To: "Sigbjorn Finne" <sof(a)galois.com> Sent: Sunday, December 02, 2001 02:43 Subject: Re: FORTRAN and HASKELL > Thank you for your comments. Answering your question ... > > > you don't say what platform this is on (or what Fortran compiler > > you're using). > > We are using GNU Fortran 77 Compiler (f77) on a Linux PC cluster based > on Red Hat 6.2. The GHC version used is 5.02. > > Best Regards, > Heron de Carvalho

1 0

Re: FORTRAN and HASKELL
by heron_carvalho 30 Nov '01

30 Nov '01

Hello GHC users, We want to reuse FORTRAN libraries within Haskell code. How can we use FFI to implement this interface directly ? We know that we can use C to implement it indirectly with FFI, but how can we do this directly ? Any suggestion ? Thanks, Heron de Carvalho > --- clusterpoli <clusterpoli(a)bol.com.br> wrote: > > Somebody works with together FORTRAN and Haskell. Exists > > some funcao to transform codigo FORTRAN into codigo > > HASKELL? > > TXL might help, but it's its own functional language. > It can probably convert FORTRAN to Haskell given the > EBNF for each language, but I'm not sure how it works... > http://www.research.avayalabs.com/user/wadler/realworld/l s2000.html > http://gatekeeper.dec.com/pub/misc/txl/ > > Otherwise, I would look at what algorithm the FORTRAN is > implementing, the either write it in Haskell, or look for it > on the Internet using http://www.google.com/ > > For example: http://www.cs.chalmers.se/pub/haskell/library/ > http://www.cs.chalmers.se/pub/haskell/library/bevan/index > > __________________________________________________ > Do You Yahoo!? > Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. > http://geocities.yahoo.com/ps/info1 > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow- haskell-users > __________________________________________________________________________ AcessoBOL, só R$ 9,90! O menor preço do mercado! Assine já! http://www.bol.com.br/acessobol

2 1

ghc and hierarchical module names
by Tim Barbour 30 Nov '01

30 Nov '01

The release notes for ghc 5.02.1 say: 1.4.4. New experimental features Partial support for hierarchical module names. - but I could not find a document describing how to use this feature. Is it possible to use hierarchical module names with ghc at present, and if so, how does one write and use a hierarchically-named module ? Tim -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin

1 0

[qforeign] CursesTest segfaults
by Jens Petersen 29 Nov '01

29 Nov '01

I built qforeign from cvs under Linux. Any idea why tests/CursesTest segfaults? Is my ncurses too new? (I have had it working previously - 6 months ago or so.) version info: ghc-5.02.1 ncurses-5.02 glibc-2.2.4 gmp-3.1.1 readline-4.2 If you need more info or traces, please let me know. Jens

1 0

Re: Casting dynamic values
by Marcin 'Qrczak' Kowalczyk 28 Nov '01

28 Nov '01

27 Nov 2001 17:31:10 -0700, Alastair David Reid <reid(a)cs.utah.edu> pisze: > If GHC is able to inline these functions, construction and > deconstruction of the pair can probably be eliminated. cast is compiled to something similar to this: coerce :: a -> b -- this generates no runtime code type Typeable a = a -> TypeRep cast :: Typeable a -> Typeable b -> a -> Maybe b cast t1 t2 x = case t1 x of rep1 -> case t2 (coerce x) of rep2 -> case eqTypeRep rep1 rep2 of True -> Just (coerce x) False -> Nothing Instances of Typeable should not look at their argument to determine TypeRep of its type but unfortunately the compiler can't in general assume that. > But I don't think GHC can do this because AFAIK, GHC will not reduce > literal string comparisions at compile time. Since Oct 1 it tries to. Unfortunately string literals seem to be floated out to toplevel before there are recognized as literals being arguments of (==), and the rule doesn't work. > [This is assuming that GHC's implementation of Typeof still uses > strings. This may not be true though since there was talk of adding > direct compiler support to make the implementation of typeof more > efficient and, more importantly, less prone to programmer error. It doesn't use strings for comparison but uniquely generated numbers. But it's not safe either: uniqueness of these numbers relies on TyCon objects being defined at the toplevel, with {-# NOINLINE #-}, and I'm not sure if common subexpression elimination doesn't mess this up (it corrupts similar cases). Anyway equality on statically known TypeRep is not done at compile time. I don't know why. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

1 0