Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
How about having a `ghci` command for cabal? Or does the automatic
requirement really need to be part of ghc to work the way you want?
(BTW, cabal-dev does have a `ghci` command, but I haven't tested to
see if it does the hsc - hs conversion.)
I don't think cabal can provide that. Let's say you're inside a 'cabal
ghci' session. If you modify the hsc file and reload it in ghci, you'd
expect to load the updated version — yet cabal hasn't even been called
since 'cabal ghci', and have had no chance to re-generate the hs file.
To answer the subject question — hsc2hs is not a single preprocessor
available. There are also c2hs and greencard, and maybe something else.
It is (or, at least, was) not clear which one should be generally
preferred. Perhaps by now hsc2hs is a clear winner — I don't know.
Another option is to add a generic preprocessor option to GHC, something
like -pgmX cmd. Then, for hsc2hs one would write something like
{-# OPTIONS_GHC -pgmX hsc2hs #-}
This is a better option, IMO.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
On 5 June 2013 17:34, Roman Cheplyaka r...@ro-che.info wrote:
* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
How about having a `ghci` command for cabal? Or does the automatic
requirement really need to be part of ghc to work the way you want?
(BTW, cabal-dev does have a `ghci` command, but I haven't tested to
see if it does the hsc - hs conversion.)
I don't think cabal can provide that. Let's say you're inside a 'cabal
ghci' session. If you modify the hsc file and reload it in ghci, you'd
expect to load the updated version — yet cabal hasn't even been called
since 'cabal ghci', and have had no chance to re-generate the hs file.
To answer the subject question — hsc2hs is not a single preprocessor
available. There are also c2hs and greencard, and maybe something else.
It is (or, at least, was) not clear which one should be generally
preferred. Perhaps by now hsc2hs is a clear winner — I don't know.
Another option is to add a generic preprocessor option to GHC, something
like -pgmX cmd. Then, for hsc2hs one would write something like
{-# OPTIONS_GHC -pgmX hsc2hs #-}
Isn't this what -pgmF is
for?http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/options-phases.html#replacing-phases
{-# OPTIONS_GHC -F -pgmF hsc2hs #-}
This is a better option, IMO.
Roman
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
* Ivan Lazar Miljenovic ivan.miljeno...@gmail.com [2013-06-05 17:47:40+1000]
On 5 June 2013 17:34, Roman Cheplyaka r...@ro-che.info wrote:
* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
How about having a `ghci` command for cabal? Or does the automatic
requirement really need to be part of ghc to work the way you want?
(BTW, cabal-dev does have a `ghci` command, but I haven't tested to
see if it does the hsc - hs conversion.)
I don't think cabal can provide that. Let's say you're inside a 'cabal
ghci' session. If you modify the hsc file and reload it in ghci, you'd
expect to load the updated version — yet cabal hasn't even been called
since 'cabal ghci', and have had no chance to re-generate the hs file.
To answer the subject question — hsc2hs is not a single preprocessor
available. There are also c2hs and greencard, and maybe something else.
It is (or, at least, was) not clear which one should be generally
preferred. Perhaps by now hsc2hs is a clear winner — I don't know.
Another option is to add a generic preprocessor option to GHC, something
like -pgmX cmd. Then, for hsc2hs one would write something like
{-# OPTIONS_GHC -pgmX hsc2hs #-}
Isn't this what -pgmF is
for?http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/options-phases.html#replacing-phases
{-# OPTIONS_GHC -F -pgmF hsc2hs #-}
Indeed! I should've read the whole section.
Problem solved, then?
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
Hi, Roman Cheplyaka wrote: My preferred solution would be to have ghc/ghci automatically run hsc2hs [...] when necessary. How about having a `ghci` command for cabal? I don't think cabal can provide that. Let's say you're inside a 'cabal ghci' session. If you modify the hsc file and reload it in ghci, you'd expect to load the updated version — yet cabal hasn't even been called since 'cabal ghci', and have had no chance to re-generate the hs file. Maybe ghci could be changed to call some kind of hook everytime a file is called, and cabal could then provide an implementation for this hook that regenerates the files if necessary? Maybe this is even possible today using: :def r somethingCleverHere A quick test shows some minor problems, like :def r (const (return :r)) :r looping. But maybe this could be figured out. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
On Wed, Jun 5, 2013 at 3:56 PM, Roman Cheplyaka r...@ro-che.info wrote:
* Ivan Lazar Miljenovic ivan.miljeno...@gmail.com [2013-06-05
17:47:40+1000]
On 5 June 2013 17:34, Roman Cheplyaka r...@ro-che.info wrote:
* Jason Dagit dag...@gmail.com [2013-06-04 21:00:25-0700]
My preferred solution would be to have ghc/ghci automatically run
hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the
implementation.
How about having a `ghci` command for cabal? Or does the automatic
requirement really need to be part of ghc to work the way you want?
(BTW, cabal-dev does have a `ghci` command, but I haven't tested to
see if it does the hsc - hs conversion.)
I don't think cabal can provide that. Let's say you're inside a 'cabal
ghci' session. If you modify the hsc file and reload it in ghci, you'd
expect to load the updated version — yet cabal hasn't even been called
since 'cabal ghci', and have had no chance to re-generate the hs file.
To answer the subject question — hsc2hs is not a single preprocessor
available. There are also c2hs and greencard, and maybe something else.
It is (or, at least, was) not clear which one should be generally
preferred. Perhaps by now hsc2hs is a clear winner — I don't know.
Another option is to add a generic preprocessor option to GHC,
something
like -pgmX cmd. Then, for hsc2hs one would write something like
{-# OPTIONS_GHC -pgmX hsc2hs #-}
Isn't this what -pgmF is
for?
http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/options-phases.html#replacing-phases
{-# OPTIONS_GHC -F -pgmF hsc2hs #-}
Indeed! I should've read the whole section.
Problem solved, then?
Pretty close. For anyone who wants to use hsc2hs in this way, the first
step is to create a wrapper script to handle the arguments appropriately
(otherwise the output doesn't go to the proper location)
file ghc_hsc2hs.sh
#!/bin/sh
hsc2hs $2 -o $3
Put the wrapper in your path, and add
{-# OPTIONS_GHC -F -pgmF ghc_hsc2hs.sh #-}
to the top of the source file. The source file must have a .hs extension
for ghci to load it, but hsc2hs will ignore that and process it anyway.
With this you can load the file in ghci, and if you modify the file
reloading in ghci will pick up the changes, so it works pretty nicely.
There are a couple drawbacks though. First, this isn't good for
distribution because other people won't have your wrapper script. Second,
this preprocessor stage comes after CPP, which might impose some
difficulties in certain cases.
I can see this working well for internal projects etc. If hsc2hs (and
other preprocessors) were distributed in a fashion suitable for use with
-F, either directly or by providing a wrapper, I think this could become
the preferred workflow. I'm not entirely pleased that a non-Haskell file
gets a .hs extension, but c'est la vie.
I think it would generally be useful if ghc's -F phase were to support
non-Haskell files, but that's probably a bit more work than just
distributing a pgmF-friendly hsc2hs.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
While hsc2hs is a popular FFI preprocessor, it is not the only one.
There is also greencard and a few others.
While hsc2hs can usually get the job done -- it's not clear that it is
really the best choice. I think the Haskell FFI got to the point that
it was 'just good enough' and then people lost interest in doing
anything more. Let's face it -- working on the FFI is just not that
exciting :)
So, basically, we are stuck with stuff that is 'good enough' but no so
great that we want to make it official.
We can bind to C fairly easily, but for C++, Python, Ruby, Javascript,
Java, etc, we have never really made much headway.
I think the efforts to make cabal-ghci work nicely could really be the
best solution for now. That is more extensible, and makes it easy to
solve the problem you actually care about (being able to easily
load/compile .hs files) with out giving priority to any particular FFI
system.
- jeremy
On Tue, Jun 4, 2013 at 9:02 PM, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the intermediate step of calling hsc2hs? This would be exactly
like the CPP extension. I don't have to call cpp manually. All I have
to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of
the rest. This would also mean that there would be no need to have a
separate file extension. Surely I must not be the first person to have
that thought, so there must be a good reason why this hasn't happen
yet, but what is it?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
I agree that preprocessing code shouldn't be hsc2hs specific. I prefer
c2hs myself. But hsc2hs is distributed with ghc, which makes it as
official as a good many other parts of modern Haskell.
I also agree that making cabal-ghci work nicely would be ideal, but I don't
think it can be done without either adding hooks into ghci or wrapping
stdin. As Roman points out, if you use :r in ghci, cabal-ghci wouldn't
pick up changes in the source file. Using ghc's support for custom
preprocessors seems like a very straightforward solution: it already
exists, can be used today, and isn't tied to hsc2hs.
Not that this should stop anyone from working on cabal-ghci of course.
On Thu, Jun 6, 2013 at 11:43 AM, Jeremy Shaw jer...@n-heptane.com wrote:
While hsc2hs is a popular FFI preprocessor, it is not the only one.
There is also greencard and a few others.
While hsc2hs can usually get the job done -- it's not clear that it is
really the best choice. I think the Haskell FFI got to the point that
it was 'just good enough' and then people lost interest in doing
anything more. Let's face it -- working on the FFI is just not that
exciting :)
So, basically, we are stuck with stuff that is 'good enough' but no so
great that we want to make it official.
We can bind to C fairly easily, but for C++, Python, Ruby, Javascript,
Java, etc, we have never really made much headway.
I think the efforts to make cabal-ghci work nicely could really be the
best solution for now. That is more extensible, and makes it easy to
solve the problem you actually care about (being able to easily
load/compile .hs files) with out giving priority to any particular FFI
system.
- jeremy
On Tue, Jun 4, 2013 at 9:02 PM, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the intermediate step of calling hsc2hs? This would be exactly
like the CPP extension. I don't have to call cpp manually. All I have
to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of
the rest. This would also mean that there would be no need to have a
separate file extension. Surely I must not be the first person to have
that thought, so there must be a good reason why this hasn't happen
yet, but what is it?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the intermediate step of calling hsc2hs? This would be exactly
like the CPP extension. I don't have to call cpp manually. All I have
to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of
the rest. This would also mean that there would be no need to have a
separate file extension. Surely I must not be the first person to have
that thought, so there must be a good reason why this hasn't happen
yet, but what is it?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
On 5 June 2013 12:02, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the intermediate step of calling hsc2hs? This would be exactly
like the CPP extension. I don't have to call cpp manually. All I have
to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of
the rest. This would also mean that there would be no need to have a
separate file extension. Surely I must not be the first person to have
that thought, so there must be a good reason why this hasn't happen
yet, but what is it?
Isn't this done automatically when you have files with the .hsc extension?
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
On Tue, Jun 4, 2013 at 10:15 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Isn't this done automatically when you have files with the .hsc extension? No, it is not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
On Wed, Jun 5, 2013 at 10:15 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 5 June 2013 12:02, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the intermediate step of calling hsc2hs? This would be exactly
like the CPP extension. I don't have to call cpp manually. All I have
to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of
the rest. This would also mean that there would be no need to have a
separate file extension. Surely I must not be the first person to have
that thought, so there must be a good reason why this hasn't happen
yet, but what is it?
Isn't this done automatically when you have files with the .hsc extension?
cabal handles this transparently, but not ghc. It's frustrating when you
want to develop a project with ghci.
I don't think it's a good idea to merge hsc2hs syntax into Haskell files.
In particular, it's often useful to inspect the intermediate .hs file
produced by hsc2hs during development or debugging. Also it would
complicate ghc's parser, etc...
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
On Tue, Jun 4, 2013 at 8:45 PM, John Lato jwl...@gmail.com wrote:
On Wed, Jun 5, 2013 at 10:15 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 5 June 2013 12:02, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the intermediate step of calling hsc2hs? This would be exactly
like the CPP extension. I don't have to call cpp manually. All I have
to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of
the rest. This would also mean that there would be no need to have a
separate file extension. Surely I must not be the first person to have
that thought, so there must be a good reason why this hasn't happen
yet, but what is it?
Isn't this done automatically when you have files with the .hsc extension?
cabal handles this transparently, but not ghc. It's frustrating when you
want to develop a project with ghci.
I don't think it's a good idea to merge hsc2hs syntax into Haskell files.
In particular, it's often useful to inspect the intermediate .hs file
produced by hsc2hs during development or debugging. Also it would
complicate ghc's parser, etc...
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
How about having a `ghci` command for cabal? Or does the automatic
requirement really need to be part of ghc to work the way you want?
(BTW, cabal-dev does have a `ghci` command, but I haven't tested to
see if it does the hsc - hs conversion.)
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why isn't hsc2hs functionality provided by ghc?
cabal-dev ghci does work with hsc2hs, but only because it doesn't interpret
your source. Rather, cabal-dev ghci loads ghci using the sandbox install
of your package, which is less useful for a variety of reasons.
Aside from that detail, I wouldn't gain any benefit from having this
feature built in to ghci instead of accessing ghci via cabal (or
cabal-dev). cabal seems like a better location, and it's aware of several
preprocessors already.
On Wed, Jun 5, 2013 at 12:00 PM, Jason Dagit dag...@gmail.com wrote:
On Tue, Jun 4, 2013 at 8:45 PM, John Lato jwl...@gmail.com wrote:
On Wed, Jun 5, 2013 at 10:15 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 5 June 2013 12:02, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the intermediate step of calling hsc2hs? This would be exactly
like the CPP extension. I don't have to call cpp manually. All I have
to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of
the rest. This would also mean that there would be no need to have a
separate file extension. Surely I must not be the first person to have
that thought, so there must be a good reason why this hasn't happen
yet, but what is it?
Isn't this done automatically when you have files with the .hsc
extension?
cabal handles this transparently, but not ghc. It's frustrating when you
want to develop a project with ghci.
I don't think it's a good idea to merge hsc2hs syntax into Haskell files.
In particular, it's often useful to inspect the intermediate .hs file
produced by hsc2hs during development or debugging. Also it would
complicate ghc's parser, etc...
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
How about having a `ghci` command for cabal? Or does the automatic
requirement really need to be part of ghc to work the way you want?
(BTW, cabal-dev does have a `ghci` command, but I haven't tested to
see if it does the hsc - hs conversion.)
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
