Am Mittwoch, 7. Januar 2004 20:37 schrieb Alastair Reid:
> > I want to use Haskell files with #ifdef, #else and #endif preprocessor
> > directives. I tried hugs -F "cpp -P" but cpp
> > complains about unterminated character constants. What is wrong?
>
> ANSI C preprocessors tend to get confused
Hi Wolfgang,
Thanks for your informative reply. At first I didn't
understand it, but a search on "StateT" lead me to the
paper "Monad Transformers and Modular Interpreters" by
Liang, Hudak and Jones, which clarified some of the
ideas for me.
The state transformer approach seems to have
advantage
> How do I instruct Haddock to preprocess the Haskell files.
> From your mail I
> thought that Haddock would do so by default but it complains
> at the first
> #ifdef it sees. Unfortunately, I didn't find any Haddock
> option similar to Hugs' -F.
I should really put this in the manual, si
Am Donnerstag, 8. Januar 2004 03:20 schrieben Sie:
> [...]
> Thanks for your informative reply.
You're welcome.
> [...]
> One disadvantage is that it lacks symmetry in that one monad is arbitrarily
> chosen to sit inside the other.
Yes, I see this as a disadvantage, too.
> I found another app
Am Donnerstag, 8. Januar 2004 11:02 schrieb Simon Marlow:
> > How do I instruct Haddock to preprocess the Haskell files. From your mail
> > I thought that Haddock would do so by default but it complains at the
> > first #ifdef it sees. Unfortunately, I didn't find any Haddock option
> > similar to
Hi Mark,
The state transformer approach seems to have
advantageous in that it provides a framework for
building new monads from old, and accessing the
components. One disadvantage is that it lacks
symmetry in that one monad is arbitrarily chosen
to sit inside the other.
You may want to read "comp
!! We apologize for multiple copies of this message !!
SECOND CALL FOR PAPERS
ESSLLI-2004 STUDENT SESSION
9-20 August, 2004 in Nancy, France
Deadline: February 22, 2004
Am Mittwoch, 7. Januar 2004 21:46 schrieb Wolfgang Jeltsch:
> [...]
> I tried hugs -F "cpp -P -traditional" but got the same error message as
> without -traditional. This message is, suprisingly,
> sh: line 1: /usr/lib/hugs/libraries/Hugs/Prelude.hs: Permission denied
> ERROR "/usr/lib/hug
Am Donnerstag, 8. Januar 2004 11:02 schrieben Sie:
> [...]
> Anyway, you can use GHC to preprocess your source files before feeding
> them to Haddock:
>
>$ ghc -E -cpp -D__HADDOCK__ Foo.hs -o Foo.raw-hs
This only replaces all __HADDOCK__ occurences with 1 but doesn't process
#ifdefs.
> [...
> Am Donnerstag, 8. Januar 2004 11:02 schrieben Sie:
> > [...]
>
> > Anyway, you can use GHC to preprocess your source files
> before feeding
> > them to Haddock:
> >
> >$ ghc -E -cpp -D__HADDOCK__ Foo.hs -o Foo.raw-hs
>
> This only replaces all __HADDOCK__ occurences with 1 but
> doesn't
> > Am Donnerstag, 8. Januar 2004 11:02 schrieben Sie:
> > > [...]
> >
> > > Anyway, you can use GHC to preprocess your source files
> > before feeding
> > > them to Haddock:
> > >
> > >$ ghc -E -cpp -D__HADDOCK__ Foo.hs -o Foo.raw-hs
> >
> > This only replaces all __HADDOCK__ occurences w
Am Donnerstag, 8. Januar 2004 17:39 schrieb Simon Marlow:
> [...]
> > >$ ghc -E -cpp -D__HADDOCK__ Foo.hs -o Foo.raw-hs
> >
> > This only replaces all __HADDOCK__ occurences with 1 but doesn't process
> > #ifdefs.
>
> Are you sure? It works for me, and it's what we use in GHC's libraries.
I
Am Donnerstag, 8. Januar 2004 17:44 schrieb Simon Marlow:
> [...]
> One thing I forgot to mention is that you also need to remove the pesky
> lines beginning with '#' that the C preprocessor leaves behind. Here's what
> we do in GHC:
>
> $ ghc -D__HADDOCK__ -E -cpp Foo.hs -o Foo.tmp
>
is there a function, related to getProgName, which returns the (absolute)
path to the current program?
basically, i want to be able to read a file which i know will be in the
same directory as the current program, but not necessarily in the same
directory that we're running it from.
--
Hal D
Sadly, this doesn't seem to work:
9:26am albini:SVMseq/ cat Foo.hs
module Main where
import System.Environment
main = getEnv "_" >>= putStrLn
9:27am albini:SVMseq/ ghc Foo.hs -o foo
9:27am albini:SVMseq/ ./foo
Fail: does not exist
Action: getEnv
Reason: no environment variable
File: _
On Thu,
On Thu, Jan 08, 2004 at 09:06:44AM -0800, Hal Daume III wrote:
> is there a function, related to getProgName, which returns the (absolute)
> path to the current program?
A non-portable Linux solution:
System.Posix.readSymbolicLink "/proc/self/exe"
Best regards,
Tom
--
.signature: Too many
On Thursday 08 January 2004 18.06, Hal Daume III wrote:
> is there a function, related to getProgName, which returns the (absolute)
> path to the current program?
>
> basically, i want to be able to read a file which i know will be in the
> same directory as the current program, but not necessarily
On Thu, Jan 08, 2004 at 07:02:04PM +0100, Tomasz Zielonka wrote:
> On Thu, Jan 08, 2004 at 09:06:44AM -0800, Hal Daume III wrote:
> > is there a function, related to getProgName, which returns the (absolute)
> > path to the current program?
>
> A non-portable Linux solution:
>
> System.Posix
Hal Daume III wrote:
is there a function, related to getProgName, which returns the (absolute)
path to the current program?
Well, the absolute path name is not necessarily unique, nor is it
guaranteed to exist. :)
-- Lennart
___
Haskell mailing list
[E
True. Replace "the" with "a" and "?" with ", if it exists?".
On Thu, 8 Jan 2004, Lennart Augustsson wrote:
> Hal Daume III wrote:
> > is there a function, related to getProgName, which returns the (absolute)
> > path to the current program?
> Well, the absolute path name is not necessarily uniq
Hal Daume III <[EMAIL PROTECTED]> writes:
> True. Replace "the" with "a" and "?" with ", if it exists?".
>
> On Thu, 8 Jan 2004, Lennart Augustsson wrote:
>
>> Hal Daume III wrote:
>>
>>> is there a function, related to getProgName, which
>>> returns the (absolute) path to the current program?
>>
21 matches
Mail list logo
