Hi Janek,
On 6 May 2015 at 14:55, Jan Stolarek wrote:
> Yes, and that's what gets me worried. I suppose the problem was somehow
> related to my locale
> settings although we were unable to track down the cause. I also recall
> someone else reported
> being affected by the same problem.
AFIK, t
> I want to emphasize that cpphs is actively maintained as it's pointed
> out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The
> Agda team has found some cpphs bugs which have been *quickly* fixed by
> cpphs's author, Malcolm Wallace.
Yes. It was not my intention to imply in any way
On Wed, May 6, 2015 at 11:36 AM, Stephen Paul Weber <
singpol...@singpolyma.net> wrote:
> Yes. This is one of my favourite things in GHC-land -- that an existing,
> good-enough, standardised, and widely-deployed solution was chosen over a
> NiH reinvention of preprocessing
I have to assume my i
On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote:
>>As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
>>currently relies on the system's C-compiler bundled `cpp` program to
>>provide a "traditional mode" c-preprocessor.
>
> Yes. This is one of my favourite things in GHC
On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge <_deepf...@feelingofgreen.ru>
wrote:
> Why *shouldn't* TH fill that role? What can be done about it?
For one, it's difficult to make it available in cross compilers (granted,
work is being done on this) and not available on some platforms (ARM has
On Wed, May 6, 2015 at 10:59 AM, Bardur Arantsson
wrote:
> (I'm not going to be doing any of the work, so this is just armchairing,
> but this seems like an 80/20 solution would be warranted.)
>
Only if you're convinced it will remain 80/20 for the foreseeable future. I
do not want to bet on Lin
2015-05-06 16:21 GMT+02:00 Bardur Arantsson :
> +1, I'll wager that the vast majority of usages are just for version
> range checks.
The OpenGL-related packages used macros to generate some binding magic
(a "foreign import" plus some helper functions for each API entry),
not just range checks. I h
Herbert,
what about to extend plan (1) to also include cpphs as a bundled option
with all cpphs advantages except no more fork/exec as the bundle will be
in a form of binary application and not library?
Shall I add it? I would not like to make a mess from your page...
Thanks,
Karel
I want to emphasize that cpphs is actively maintained as it's pointed
out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The
Agda team has found some cpphs bugs which have been *quickly* fixed by
cpphs's author, Malcolm Wallace. Unfortunately I have not been able to
track down the prob
On 6 May 2015 at 14:25, Austin Seipp wrote:
> 2) The lexing rules for C and Haskell simply are not the same in
> general.
One area where this is irritating is that it makes it impossible to
use Haskell multiline strings together with CPP.
___
Glasgow-
On Wed, May 6, 2015 at 6:08 AM, Herbert Valerio Riedel
wrote:
> Hello *,
>
> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
> currently relies on the system's C-compiler bundled `cpp` program to
> provide a "traditional mode" c-preprocessor.
>
> This has caused several proble
One thing to keep in mind is that while cpphs will solve some problems of
system-cpp, it will also
bring problems of its own. I, for one, have run into problems with it when
installing Agda. There
is a very long thread here:
https://lists.chalmers.se/pipermail/agda/2014/006975.html
and twice
Hello *,
As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a "traditional mode" c-preprocessor.
This has caused several problems in the past, since parsing Haskell code
with a preprocessor mode designe
13 matches
Mail list logo
