Re: [Haskell-cafe] TH clause Pat selection

[Geoffrey Mainland]

Have you tried dataToPatQ and dataToExpQ?

http://hackage.haskell.org/packages/archive/template-haskell/latest/doc/html/Language-Haskell-TH-Quote.html

Geoff

On 06/19/2013 11:23 PM, Brian Lewis wrote:
> I want to use TH to generate functions like
> foo :: c -> h
> foo ... = ...
> foo ... = ...
> ...
> from lists of pairs :: [(c, h)]
>
> For example, $(genFoo ''Int ''Bool [(0,False), (1,True)])
> would generate
> foo 0 = False
> foo 1 = True
>
> The problem is, I don't know how to generate the function's clauses.
> "foo 0 = ..." seems to be a LitP pattern. But "foo True = ..." seems to
> be a ConP pattern. The appropriate pattern depends on type c.
>
> Here's code with more explanation and examples:
> http://hpaste.org/90163
>
> ___
> 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] install cuda

[Geoffrey Mainland]

Fantastic, glad you got it working! Maybe it's time for me to send
Trevor a pull request...

Geoff

On 04/01/2013 04:27 PM, Peter Caspers wrote:
> indeed, not very helpful ...
>
> When I installed Cuda the latest driver (296.0) that was running on my
> laptop (a W520 ThinkPad) was not sufficient for version 5.0. However
> as I noticed today in February Lenovo released a driver update (311.0)
> and with that 5.0 is in fact running. :-)
>
> With that the Haskell bindings work well.
>
> Thanks again very much, Geoff
> Peter
>
>
>
> Am 01.04.2013 12:25, schrieb Geoffrey Mainland:
>> That is not a very elucidating crash message, so I don't see how to
>> proceed. After ghci print "Loading package cuda-0.5.0.0 ... linking
>> ... done." it just exits? No error dialog, nothing? Did you try building
>> any of the examples in the cuda package that don't require ghci?
>>
>> Is your graphics card incompatible with CUDA 5.0, or do you just not
>> want to update your driver?
>>
>> Geoff
>>
>> On 04/01/2013 10:33 AM, Peter Caspers wrote:
>>> yes, the installation seems to work fine now. However, doing the
following test in ghci
>>>
>>> Prelude> :m +Foreign.CUDA
>>> Prelude Foreign.CUDA> props 0
>>> Loading package bytestring-0.9.2.1 ... linking ... done.
>>> Loading package cuda-0.5.0.0 ... linking ... done.
>>>
>>> results in a crash. The CUDA version I am using is 4.1.28. You think
>> there is something I could try to analyze this further ?
>>> Thanks a lot for your help
>>> Peter
>>>
>>> Am 31.03.2013 21:48, schrieb Geoffrey Mainland:
>>>> You need to generate the configure script using autoconf:
>>>>
>>>>
>>
https://www.gnu.org/software/autoconf/manual/autoconf.html#autoconf-Invocation
>>>> On 03/31/2013 08:27 PM, Peter Caspers wrote:
>>>>> Hmm, I get
>>>>>
>>>>> Configuring cuda-0.5.0.0...
>>>>> setup.exe: configure script not found.
>>>>>
>>>>> can you help ?
>>>>>
>>>>> Peter
>>>>>
>>>>>> I was able to install the cuda package under 32-bit GHC 7.4.2
using the
>>>>>> 5.0 SDK and use it from within ghci. This required using my fork
of the
>>>>>> cuda repo and following the instructions in my WINDOWS.md. Make sure
>>>>>> nvcc is in your path (the CUDA installer should have made this
so) and
>>>>>> try 'cabal configure'.
>



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] install cuda

[Geoffrey Mainland]

That is not a very elucidating crash message, so I don't see how to
proceed. After ghci print "Loading package cuda-0.5.0.0 ... linking
... done." it just exits? No error dialog, nothing? Did you try building
any of the examples in the cuda package that don't require ghci?

Is your graphics card incompatible with CUDA 5.0, or do you just not
want to update your driver?

Geoff

On 04/01/2013 10:33 AM, Peter Caspers wrote:
> yes, the installation seems to work fine now. However, doing the following 
> test in ghci
>
> Prelude> :m +Foreign.CUDA
> Prelude Foreign.CUDA> props 0
> Loading package bytestring-0.9.2.1 ... linking ... done.
> Loading package cuda-0.5.0.0 ... linking ... done.
>
> results in a crash. The CUDA version I am using is 4.1.28. You think
there is something I could try to analyze this further ?
>
> Thanks a lot for your help
> Peter
>
> Am 31.03.2013 21:48, schrieb Geoffrey Mainland:
>> You need to generate the configure script using autoconf:
>>
>>
https://www.gnu.org/software/autoconf/manual/autoconf.html#autoconf-Invocation
>>
>> On 03/31/2013 08:27 PM, Peter Caspers wrote:
>>> Hmm, I get
>>>
>>> Configuring cuda-0.5.0.0...
>>> setup.exe: configure script not found.
>>>
>>> can you help ?
>>>
>>> Peter
>>>
>>>> I was able to install the cuda package under 32-bit GHC 7.4.2 using the
>>>> 5.0 SDK and use it from within ghci. This required using my fork of the
>>>> cuda repo and following the instructions in my WINDOWS.md. Make sure
>>>> nvcc is in your path (the CUDA installer should have made this so) and
>>>> try 'cabal configure'.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] install cuda

[Geoffrey Mainland]

You need to generate the configure script using autoconf:

https://www.gnu.org/software/autoconf/manual/autoconf.html#autoconf-Invocation

On 03/31/2013 08:27 PM, Peter Caspers wrote:
> Hmm, I get
>
> Configuring cuda-0.5.0.0...
> setup.exe: configure script not found.
>
> can you help ?
>
> Peter
>
>> I was able to install the cuda package under 32-bit GHC 7.4.2 using the
>> 5.0 SDK and use it from within ghci. This required using my fork of the
>> cuda repo and following the instructions in my WINDOWS.md. Make sure
>> nvcc is in your path (the CUDA installer should have made this so) and
>> try 'cabal configure'.
>


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] install cuda

[Geoffrey Mainland]

On 03/31/2013 05:55 PM, Peter Caspers wrote:
>>
>> The environment variable should probably be LIBRARY_PATH; I use a
semicolon as separator.
>> See also LD_LIBRARY_PATH vs LIBRARY_PATH[0].
>>
>
> yes, it's LIBRARY_PATH. The x64 version of cuda.lib is not recognized
> at all (same error message as if the file was not existent). The Win32
> version "works", but results in
>
> configure:3627: c:\HaskellPlatform\2012.4.0.0\mingw\bin\gcc.exe -o
conftest.exe -Wl,--hash-size=31 -Wl,--reduce-memory-overheads
-I/c/CUDA/NVIDIA_GPU_Computing_Toolkit/CUDA/v4.1/include
-L/c/CUDA/NVIDIA_GPU_Computing_Toolkit/CUDA/v4.1/lib  conftest.c
-lcuda   >&5
> C:\Users\Peter\AppData\Local\Temp\ccOwCQ6n.o:conftest.c:(.text+0xc):
undefined reference to `cuDriverGetVersion'
> collect2: ld returned 1 exit status
>
> I ran nm on cuda.lib and got the entry
>
> nvcuda.dll:
>  I .idata$4
>  I .idata$5
>  I .idata$6
>  T .text
>  U _IMPORT_DESCRIPTOR_nvcuda
>  I _imp__cuDriverGetVersion@4
>  T cuDriverGetVersion@4
>
> this looks ok so far. Running nm on the x64 version of the lib file
> results in rubbish output (consistent with the observation above).

You're using a version of GHC that targets 32-bit x86, so the 64-bit
library is not going to do you any good. cuDriverGetVersion@4 is the
stdcall-mangled version of cuDriverGetVersion. The CUDA headers (at
least in the 5.0 toolkit) do not properly declare all CUDA functions as
stdcall under gcc, even though they are. This is why you get an
undefined reference---gcc see cuDriverGetVersion' declared ccall in the
header, so it looks for the wrong symbol. I would guess that the 4.1
toolkit has this same problem the same.

In general, there is no support for using the CUDA SDK with the mingw
tools. I hacked around this enough to get it to work for the driver API,
but you have to use my fork.

> I understand that LD_LIBRARY_PATH is used to look up to dll when
> running the program (is that correct?). However we are not at this
> point yet, are we, since the error occurs on the gcc invocation ?
>
>> Try my fork:
>>
>> https://github.com/mainland/cuda
>>
>> In particular, read WINDOWS.md.
>
> I also read Geoffreys WINDOWS.md and understood that configuring dll
> names are only necessary when using ghci, not for compiled programs
> (nothing to do for this case ?) and in particular not for installing
> the package ?

There's more to it than reading my WINDOWS.md. If you want to build the
cuda package at all, you also need to use my fork.

> Actually the dll is not named nvcuda.dll as indicated in the nm
> output, but rather cudart32_41_28.dll I suppose and this file is
> located in the bin subfolder. I should set LD_LIBRARY_PATH to the bin
> folder, yes ? Should I configure this dll name for package
> installation already (i.e. in addition to what is mentioned in
> WINDOWS.md) ? If yes, how ?

There are two dlls you need. nvcuda.dll corresponds to libcuda on Linux,
and its .lib file on Windows is cuda.lib. cudart32_41_28.dll corresponds
to libcudart on Linux, and its .lib file on Windows is cudart.lib. You
will need them both.

I was able to install the cuda package under 32-bit GHC 7.4.2 using the
5.0 SDK and use it from within ghci. This required using my fork of the
cuda repo and following the instructions in my WINDOWS.md. Make sure
nvcc is in your path (the CUDA installer should have made this so) and
try 'cabal configure'.

LD_LIBRARY_PATH is used on most UNIX flavors. I don't believe it does
anything in Windows. You will instead need to modify your Path
environment variable from the System Settings->Advanced System Settings
control panel.

Geoff


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] install cuda

[Geoffrey Mainland]

Try my fork:

https://github.com/mainland/cuda

In particular, read WINDOWS.md.

Geoff

On 03/31/2013 07:54 AM, Stephen Tetley wrote:
> It looks like you are using Cygwin for a Unix-alike environment. For
> building Haskell bindings to C libraries you are better off with MinGW
> + MSYS.
> 
> On 30 March 2013 19:43, Peter Caspers  wrote:
> 
>> I am trying to install the cuda package on a Windows 7 enviroment. However I
>> run into an error and can not figure out, what it is.
>>
>> Can someone help ?



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Template Haskell antiquotation in user-defined quasiquoters

[Geoffrey Mainland]

On 05/25/2012 21:46, Antoine Latter wrote:
> On Fri, May 25, 2012 at 2:51 PM, Sam Lindley  wrote:
>> Template Haskell supports antiquotation for built-in quasiquotes, e.g.:
>>
>>  [| \x -> x + $([|3 * 4|]) |]
>>
>> However, as far as I can tell, there is no way of supporting antiquotation
>> in user-defined quasiquoters, because the only way to specify a new
>> quasiquoter is through a quoteExp function of type String -> Q Exp. Of
>> course, it is perfectly possible to write a parser for some fragment of
>> Haskell inside your quoteExp function, but that seems crazy given that
>> Template Haskell or rather GHC already implements a parser for the whole
>> language.
>>
>> I know about Language.Haskell.Exts.Parser in haskell-src-exts, which
>> provides parseExp :: String -> ParseResult Exp, but that Exp is a different
>> type to the one provided by Template
>> Haskell.
>> I'm also aware of Dominic Orchard's syntax-trees package, which supports
>> converting between the two representations using a cunning hack that
>> pretty-prints the haskell-src-exts representation to a string and uses
>> Template Haskell to parse it back.
>>
>> Is there a saner way of simulating antiquotation in user-defined
>> quasiquoters?
>>
> 
> Have you looked at:
> 
> http://hackage.haskell.org/package/haskell-src-exts-qq
> http://hackage.haskell.org/package/haskell-src-meta
> 
> The might help you pull something together.
> 
> 
> Antoine
> 
>> Sam

I use haskell-src-meta in language-c-quote (also on hackage) to support
antiquotation and heartily endorse it. I have not used haskell-src-exts-qq.

Geoff


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GSoC and Data Parallel Haskell

[Geoffrey Mainland]

Taking advantage of GHC's SIMD support from within DPH is in the works.

I'd love to have some good target applications to help drive the work.
An application with DPH, plain C, C+SSE intrinsics, and, say, OpenCL
versions would be even better, but that's probably wishful thinking.
Dmitry, is your thesis about gas dynamics (I suspect it is) and you just
want to try using Haskell, or is it about using Haskell to implement
scientific code?

Geoff

On 03/21/2012 14:12, Ryan Newton wrote:
> The big topic would seem to be using Geoff Mainland's new simd-ghc support.
> 
> http://hackage.haskell.org/trac/ghc/wiki/SIMD
> 
> Geoff, is that already under way or is it too big a project for a GSOC?
> 
> Dmitry, do you already have GHC-internals hacking experience?
> 
>   -Ryan
> 
> 
> On Tue, Mar 20, 2012 at 8:52 PM, Dmitry Dzhus  > wrote:
> 
> How are you gentlemen.
> 
> I'm interested about what additions to DPH would really benefit
> the community.
> 
> The only ticket on DPH in GSoC Trac seems a bit stale:
> http://hackage.haskell.org/trac/summer-of-code/ticket/1537.
> Any new tips?
> 
> My field is currently molecular simulation. (I'm doing a Direct
> Simulation
> Monte-Carlo implementation for rarefied gas dynamics with application
> to space satellites&stuffs aerodynamics in Haskell for my Master's
> thesis,
> I believe using DPH as well would be my final goal as molecular
> simulations
> vectorize nicely. Simulation domain is partitioned into cells and
> stochastic
> collision sampling (as in DSMC) may be performed in every cell in
> parallel.)



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Generating Code

[Geoffrey Mainland]

On 12/09/2011 21:47, Stephen Tetley wrote:
> Geoffrey Mainland did significant work generating C with his GHC quasi
> quote extension. I'm not sure the status or availability of the code
> but there was a good Haskell Workshop paper describing it.

In case anybody is interested, language-c-quote on hackage is the
current version of the C quasiquoting library from the workshop paper.

Geoff

> For the specific problem of OpenGL - as the package already exists I'm
> not sure a generative approach would actually pay its way


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Generating Code

[Geoffrey Mainland]

On 12/10/2011 09:38, Iustin Pop wrote:
> On Fri, Dec 09, 2011 at 10:30:18PM +0100, L Corbijn wrote:
>> The major set of problems for using template haskell is that it
>> doesn't have the correct features, or better said it tries to solve
>> another problem. Template haskell generates code into an existing
>> module, while for this problem there is no module yet to generate it
>> into. Of course I could generate those modules and let template
>> haskell make the FFI imports, but then the problem remains how to
>> generate those modules. So template haskell seems (as I see it) to
>> solve the problem of writing almost the same code twice by generating
>> it from some parameters coded in some source file. Another problem is
>> that the export and import lists of the modules need to be generated
>> too and this seems not an option for TH.
> 
> On Fri, Dec 09, 2011 at 04:27:31PM -0600, Antoine Latter wrote:
>> For my case, template haskell can't create modules, and template
>> haskell solves a different problem - I've not interested in creating
>> Haskell declarations from Haskell declarations - I'm interested in
>> creating Haskell modules from an external, formal,  specification. In
>> a sense I'm compiling to Haskell.
> 
> This answer is for both the above quotes. While TH is not perfect (and
> sometimes tedious/difficult to write in), it's not restricted to simply
> generate code based on some parameters in an existing Haskell file.
> 
> It cannot generate modules, true, but other than that you could have a
> module simply like this:
> 
>   module Foo where
> 
>   import …
> 
>   $(myBuilder)
> 
> Where myBuilder doesn't take any parameters, just reads some external
> (XML, text file, whatever) and build the code from scratch.
> 
> I might misunderstand the problem, but I think that you _could_ use TH
> for "compiling" to Haskell, as long as you have a Haskell parser for the
> external/formal spec.
> 
> regards,
> iustin

There are the haskell-src-exts-qq and haskell-src-meta packages on
hackage that will get you partway to generating source code for a
Haskell module. Full support for Haskell quasiquotation would require a
modified version of haskell-src-exts (to properly handle antiquotation).

The problem with TH is that it runs when the module is compiled. Reading
a spec in from a file within a TH quote is possible, but it would be
much nicer to be able to write a code generator, which a full Haskell
quasiquoter would allow.

Maybe someone is interested in a side-project? :)

Geoff



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] How to mark a package obsolete on Hackage?

[Geoffrey Mainland]

How does one mark a package obsolete on Hackage? For example, monads-fd
no longer appears on the main web page listing available packages, but
it still exists on Hackage (but is marked obsolete [1]). I have several
package that are similarly obsolete due to mtl2 and would like to flag
them appropriately.

Thanks,
Geoff

[1] http://hackage.haskell.org/package/monads-fd


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Another Quasi-Quotation question

[Geoffrey Mainland]

On 11/24/2010 03:14, jean-christophe mincke wrote:
> Hello,
> 
> I am still playing with template-haskell...
> 
> I wonder, is there any reason why a quasiquoter cannot create haskell
> statements and declarations in addition to expressions and patterns? Or
> more generally create any legal Haskell syntax tree.

In GHC 7, quasiquotes can appear in place of expressions, patterns,
types and top-level declarations. The latter two are new (see [1]).

> I.e Suppose I would like to create a quasiquoter for the C language
> (please, imagine that it could be useful).

It is useful, and it already exists [2] :)

> I could write sth such as :
> 
> [$c|
> 
> int a = 6;
> int b = 7;
> int c = a +b;
> 
> struct S { int x; int y}
> |]
> 
> It could be nice to generate the appropriate haskell code:
> 
> a = 6
> b= 7
> c= a + b
> data S = S {  x::Int; y:Int}
> etc

language-c-quote doesn't translate C to Haskell, but lets you build C
abstract syntax trees using C's concrete syntax.

> That would allow to really embed any kind of language in a more or less
> easy way into haskell, provided that code can be translated into legal
> haskell.
>  
> Is there anything that prevent these features.

Check out GHC 7. The ability to quasiquote top-level definitions is
being used in the Haskell version of PADS [3].

> Thank you
> 
> Regards
> 
> J-C

Geoff

[1]
http://new-www.haskell.org/ghc/docs/7.0.1/html/users_guide/template-haskell.html#th-quasiquotation

[2] http://hackage.haskell.org/package/language-c-quote

[3] http://www.padsproj.org/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Handling platform- or configuration-specific code (or, my CPP complaints)

[Geoffrey Mainland]

On 09/09/2010 00:54, wren ng thornton wrote:
> On 9/7/10 3:10 PM, Ben Millwood wrote:
>> So I wonder what people
>> think of the use of CPP in Haskell code, what alternatives people can
>> propose, or what people hope to see in future to make conditional
>> compilation of Haskell code more elegant and simple?
> 
> The only thing I ever use CPP for in Haskell is top-level conditional
> definitions.
> 
> * That is, say I have a function foo which has a vanilla Haskell
> definition, but also has a special definition for GHC performance
> hackery, or which needs a special definition on some compilers in order
> to correct compiler-specific bugs. I'll use #ifdef here to give the
> different versions. I'll also occasionally do this for things like
> choosing whether to use the FFI vs a native definition, for debugging
> purposes.
> 
> * Another example is when using GeneralizedNewtypeDeriving in GHC, but
> still wanting to give normal definitions for other compilers to use.
> 
> * The only other example I can think of is when defining Applicative
> instances, since I only want to do that when linking against versions of
> base which are new enough to have it. Occasionally you can get similar
> issues re ByteString vs base.
> 
> In general, I think using CPP for actual macro processing is extremely
> poor style and can easily make code inscrutable (and no doubt
> bug-prone). If the Haskell spec were to add support for this sort of
> top-level compiler/compiletime-flag conditional definition, I'd switch
> over.
> 
> This matches the style in most of the code I've looked at. And it also
> means that the incompatibilities are localized and hidden from most
> client code. Depending on the nature of your library API conflict, if
> you can localize things into a few definitions of the core functions you
> use in the rest of your code, then that'd be best. But that's not always
> possible. I've yet to run into the case where I really need to support
> incompatible versions of a library when it's that closely integrated, so
> I don't have much advice there.

I'm afraid I instigated the CPP-vs-no-CPP issue with a patch I sent to
Ben that adds backwards compatibility for GHC 6.10 to the
haskell-src-meta package. Unfortunately the Template Haskell AST data
type changed between the version of the library that works with 6.10 and
the version that works with 6.12, and I used CPP and cabal's
MIN_VERSION_* macro to conditionally compile the appropriate code.

For example, unlike the previous version of the library, the AST data
type for patterns in the 6.12-compatible version of the template-haskell
package includes a case for bang patterns. I worked around this by using
CPP to conditionally compile the case that handles translating bang
patterns between the template-haskell and haskell-src-exts
representations only when the new version of the template-haskell
library is present. The problem with having completely separate
implementations in different source code files for different versions of
the template-haskell library instead of using CPP is that the rest of
the pattern translation function then has to be duplicated.

The question isn't whether or not to use CPP for macro expansion---I
think we all can agree that that is in bad taste ;) To quote Ben, the
choice is between the following two options:

> 1. Use CPP and the macros defined by Cabal to conditionally include or
> exclude code for each version.
> 2. Use Cabal file conditionals to select hs-source-dirs containing
> those parts of the code (or even TH to help generate those parts of
> the code) that are specific to each configuration.

I too dislike CPP, but I dislike duplicated code more. Within reason, I
would prefer to be able to find a function's implementation in a single
file even if that definition has a few conditionally-compiled parts.

Geoff
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Handling absent maintainers

[Geoffrey Mainland]

On 08/18/2010 02:25, Ben Millwood wrote:
> 2010/8/17 Geoffrey Mainland :
>> On 08/17/2010 12:28, Ben Millwood wrote:
>>> 2010/8/17 Jonas Almström Duregård :
>>>> Hi,
>>>>
>>>> Has there been any progress with this package? Like you I have also
>>>> tried to contact Matt and like you I have ended up making my own
>>>> version of src-meta :). When someone assumes maintainership of this
>>>> package I would like to discuss integrating some additions I made to
>>>> the Translation module.
>>>>
>>>> /Jonas
>>>>
>>>
>>> Hi Jonas,
>>>
>>> Sorry about the delay. In my version of haskell-src-meta I basically
>>> replaced the entire Language.Haskell.TH.Instances.Lift module with
>>> derivations from the th-lift package whose latest version currently
>>> doesn't build [1]. I had been in contact with the maintainer of the
>>> package who has prepared a version 0.5 and was waiting for them to
>>> upload it so that I could use it as a dependency, but I haven't heard
>>> from them in a week or so. I'll try emailing them again, and as soon
>>> as 0.5 is on hackage I will go ahead with my upload.
>>>
>>> I suppose since there's no reason why I deserve maintainership more
>>> than you you could just go ahead and upload your version instead. You
>>> can see exactly what I've done at my github repository [2].
>>>
>>> Yours,
>>> Ben Millwood
>>>
>>> [1] http://hackage.haskell.org/package/th-lift-0.4
>>> [2] http://github.com/benmachine/haskell-src-meta
>>
>> I'm also waiting on a 6.12-compatible version of haskell-src-meta so I
>> can release a version of my package for quasiquoting C/CUDA. I pulled
>> Mark's changes to create a version that maintains compatibility with
>> version 2.3 of the template-haskell library (and therefore with GHC
>> 6.10). Is there any chance we can keep backwards-compatibility? ;) I'm
>> happy to help with patches and/or maintainership, of course.
>>
>> Geoff
>>
> 
> I imagine maintaining compatibility across template-haskell versions
> might be tricky. Prior to template-haskell-2.4.0.0, I believe there
> was no TH support for kinds, and class contexts were simply Types
> rebranded (not supporting equality constraints). So some
> not-inconsiderable sections of code would need duplication, or we'd
> need to deal with CPP which always struck me as a fragile and
> inelegant solution. Of course, I welcome the patches to prove me wrong
> :) or well, if you just want to take maintainership yourself, the
> package is really as much yours as it is mine at this stage.
> 
> Ben

I have patches that main compatibility with 6.10, but now that
haskell-src-meta depends of th-lift, which requires
template-haskell>=2.4, I think it's a lost cause. Versioning for
template-haskell makes things a real mess now---if I want a package
using haskell-src-meta to work on both 6.10 and 6.12, I basically have
to test the version of GHC being used and set package dependencies
appropriately. Unless someone has a better way?

Geoff

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Handling absent maintainers

[Geoffrey Mainland]

On 08/17/2010 12:28, Ben Millwood wrote:
> 2010/8/17 Jonas Almström Duregård :
>> Hi,
>>
>> Has there been any progress with this package? Like you I have also
>> tried to contact Matt and like you I have ended up making my own
>> version of src-meta :). When someone assumes maintainership of this
>> package I would like to discuss integrating some additions I made to
>> the Translation module.
>>
>> /Jonas
>>
> 
> Hi Jonas,
> 
> Sorry about the delay. In my version of haskell-src-meta I basically
> replaced the entire Language.Haskell.TH.Instances.Lift module with
> derivations from the th-lift package whose latest version currently
> doesn't build [1]. I had been in contact with the maintainer of the
> package who has prepared a version 0.5 and was waiting for them to
> upload it so that I could use it as a dependency, but I haven't heard
> from them in a week or so. I'll try emailing them again, and as soon
> as 0.5 is on hackage I will go ahead with my upload.
> 
> I suppose since there's no reason why I deserve maintainership more
> than you you could just go ahead and upload your version instead. You
> can see exactly what I've done at my github repository [2].
> 
> Yours,
> Ben Millwood
> 
> [1] http://hackage.haskell.org/package/th-lift-0.4
> [2] http://github.com/benmachine/haskell-src-meta

I'm also waiting on a 6.12-compatible version of haskell-src-meta so I
can release a version of my package for quasiquoting C/CUDA. I pulled
Mark's changes to create a version that maintains compatibility with
version 2.3 of the template-haskell library (and therefore with GHC
6.10). Is there any chance we can keep backwards-compatibility? ;) I'm
happy to help with patches and/or maintainership, of course.

Geoff
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Case-insensitive lexing with Alex

[Geoffrey Mainland]

Joel Reymont wrote:
> 
> On Jan 28, 2008, at 2:44 PM, Geoffrey Mainland wrote:
> 
>> map toLower onto your input before you pass it to your lexer? Or do you
>> only want keywords to be case-insensitive?
> 
> 
> Just keywords. You can have "Array" or "array" or "aRrAy".

One old trick for reducing the size of lexers is to not put keyword
recognition into the lexer rules (that is, don't write rules to match
keywords explicitly), but to look up identifiers in a map from strings
to keyword tokens. In your case, apply toLower to the identifier before
you look it up in the map from keywords to tokens.

The C parsing library I gave you a link to off-list does its lexing
using this technique if you want a concrete example.

Geoff
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe