Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Francesco Mazzoli]

At Fri, 26 Apr 2013 21:21:48 -0800,
Christopher Howard wrote:
> Hi. I've got this work situation where I've got to do all my work on
> /ancient/ RHEL5 systems, with funky software configurations, and no root
> privileges. I wanted to install GHC in my local account, but the gnu
> libc version is so old (2.5!) that I can't even get the binary packages
> to install.
> 
> I've had success installing some other simple functional languages (like
> CLISP) on these same systems, so I was wondering if there was perhaps
> another language very similar to Haskell (but presumably simpler) with a
> super portable compiler easily built from source, which I could try.
> 
> I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick
> description didn't make it sound much more portable than GHC, but I
> guess I could try it if I heard some good reasons to think it would be
> more portable.

Hugs is ANSI C, and it doesn’t really get more portable than that.  However it
is only an interpreter, if you want a compiler you might might want to try
nhc98, which aims to be very portable as well .

The problem with both of these solutions (Hugs a bit less than nhc98) is that
you won’t be able to enjoy the ecosystems that has grown in the recent years
around GHC.  But if you just want to write some standard Haskell programs, they
should be OK.

Francesco

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

Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)

[Adam Gundry]

Hi AntC,

Thanks for the feedback!


On 26/04/13 09:55, AntC wrote:
>> Adam Gundry  strath.ac.uk> writes:
>> 
>> Hi,
>> 
>> I am hoping to do a GSoC project this year working on GHC, and
>> have been pointed in the direction of the records issue (in
>> particular, the desire to overload field names).
> 
> Heck you're brave!

Or possibly stupid. ;-) That's what I'm trying to figure out. There are
certainly other, less controversial, things I might work on!

Your questions are the kind of detailed issue that I'm tempted to
postpone for the time being, although I guess I can state my prejudices:

> Are you sure you want to step into the aggravated issue of changing 
> the dot operator from being function composition?

I'd prefer to leave dot alone and add a new operator for record
field projection, mostly because I don't relish trying to modify the
parser, but I am open to other opinions.

> Are you going to use explicit type application? ("The type of get is 
> very odd.")

GHC desperately needs explicit type application, but that's another
syntactic minefield; I don't think it matters much for this proposal, in
that it's an implementation detail rather than something that should be
exposed to the user.

> Are you going to handle type-changing update?

I think we need to, though the right solution might well be to punt for
now and implement non-overloaded update alone (i.e. require the user to
explicitly specify the record type being updated when there is
ambiguity). This also works for multiple update, which is an issue
otherwise.


>> The plan would be to implement a solution to the "narrow issue" of
>>  overloaded field names, along the lines of Simon PJ's SORF 
>> proposal
> 
> So has  decided that SORF is the best of those many 
> proposals? I guess it's because it comes with the SPJ ring of 
> confidence?

I should have phrased my message more carefully. By "along the lines of"
SORF I didn't mean to exclude adapting it to take into account your work
on DORF/TPDORF. As I understand it, they both set out to solve the same
basic problem (that Johan outlines so clearly) but differ in the
implementation details. I rather meant to contrast the SORF/DORF
approach with an approach based solely on name-spacing.

Perhaps I should have mentioned that SPJ suggested I look at this,
although I don't think we want to be dictatorial about the final result.


> Before jumping to that decision, I suggest you/your sponsors
> consider the implications of the "NewAxioms" stuff in GHC Head [2] to
> support 'controlled' overlap.
> 
> I think overlap is the only extra feature needed to support the DORF 
> or TPDORF proposals. (Plus the syntactic sugar already outlined in 
> that proposal.)
>
>> This would provide a basis for experimentation with first-class
>> record types.
>
> No: first-class record types needs much more than the SORF proposal.
> In particular it needs a way to extend an existing record to make a
> new one; project a subset of fields; and most important to merge two
> records with some fields in common avoiding doubling-up those fields
> (aka Relational Natural Join).
>
> The DORF/TPDORF proposals are aimed much better as a step towards
> first- class record types. [IMO **]
>
> Oleg/Ralf's HList paper covers all the ground for first-class
> records. It depends heavily on overlaps, which is why the NewAxioms
> stuff would work in really well.

While the NewAxioms stuff looks interesting, it's at an early stage.
Moreover, I'm worried that a records implementation based on desugaring
to an encoding (in the style of HList) will inevitably reveal details of
that encoding to the user. Petr rightly points out the need for good
error messages: these are much easier to generate if the constraints
arising from records are solved in GHC, rather than a library like HList.

There is certainly a long way from this proposal to full-blown
extensible records, and I don't expect to get there in a summer.


> AntC
> 
> 
> [2] http://hackage.haskell.org/trac/ghc/wiki/NewAxioms
> 
> [**] Declaration of interest: I wrote the DORF and TPDORF proposals.

Thanks again for your efforts. From reading the list archives I can see
that a lot of thought and work has gone in to the different proposals,
which definitely will inform the final design.  It would be good if we
could finally make progress on the implementation!

Best regards,

Adam

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

Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)

[Adam Gundry]

Hi Petr,


On 26/04/13 19:53, Petr Pudlák wrote:
> Hi Adam,
> 
> very nice idea. As the others, I'm curious why you chose to implement
> SORF in favor of the other ideas?

As I've commented in a message just now [1], by mentioning SORF I didn't
mean to exclude taking on board the other proposals (particularly
DORF/TPDORF). I do think a type-based approach is the way forward, with
a new sort of constraint that gives a polymorphic type to record
projection. The plans based on changing the name-spacing rules either
need type-based resolution as well, or require field names to be
prefixed with the relevant data type (so they don't fully solve the
problem).

Also, I'm a type theorist, so obviously the type-based solution is the
best one. ;-)


> I just read the SORF proposal, and I'm a bit concerned about what error
> messages would GHC issue when someone would type incorrect code
> involving such records. Currently Haskell's error messages already pose
> a barrier for newcomers (like "No instance for (Num (a -> a))"), and if
> records are converted into those very complicated `Has` instances, type
> errors would be probably undecipherable even for moderate skilled
> Haskell users. Considering that records are a basic feature of Haskell
> and something that  people with OOP background are familiar with, this
> could result in a feature that would without doubts deter many (if not
> most) newcomers. So do you think it would be possible to implement it in
> such a way that users get sensible type error messages?

You're right to raise this as an issue. I think it is essential to get
good error messages, or at least no worse than we have already! Rather
than "No instance for Has r l t" we want it to say something like "Type
r has no field l".  This justifies special treatment of Has constraints
by the compiler, rather than simply desugaring to an encoding.
Constraint-based type inference means this shouldn't be too difficult.

The current description of SORF doesn't really distinguish between the
user's perspective and the implementer's. This is something that we
should change (so it's clear how much users will need to understand);
but perhaps I'll wait and see if my GSoC proposal is accepted first!


>   Best regards,
>   Petr

Thanks for your comments,

Adam

[1] http://www.haskell.org/pipermail/haskell-cafe/2013-April/107876.html

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

Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)

[Adam Gundry]

Hi Johan,


On 26/04/13 20:46, Johan Tibell wrote:
> Hi Adam,
> 
> Since we have already had *very* long discussions on this topic, I'm
> worried that I might open a can of worms be weighing in here, but the
> issue is important enough to me that I will do so regardless.

I'm the one busily opening this particular can. It's good to know it's
an important one though!

Thanks for characterising the problem so neatly:

> Instead of endorsing one of the listed proposals directly, I will
> emphasize the problem, so we don't lose sight of it. The problem people
> run into *in practice* and complain about in blog posts, on Google+, or
> privately when we chat about Haskell over beer, is that they would like
> to write a record definition like this one:
> 
> data Employee = Employee { id :: Int, name :: String }
> 
> printId :: Employee -> IO ()
> printId emp = print $ id emp
> 
> but since that doesn't work well in Haskell today due to name
> collisions, the best practice today is to instead write something like:
> 
> data Employee = Employee { employeeId :: Int, employeeName :: String }
> 
> printId :: Employee -> IO ()
> printId emp = print $ employeeId emp
> 
> The downsides of the latter have been discussed elsewhere, but briefly
> they are:
> 
>  * Overly verbose when there's no ambiguity.
>  * Ad-hoc prefix is hard to predict (i.e. sometimes abbreviations of the
> data type name are used).
> 
> The important requirement, which might seem a bit obvious, is that any
> solution to this problem better not be *even more* verbose than the
> second code snippet above. If I understand the SORF proposal correctly,
> you would write:
> 
> data Employee = Employee { id :: Int, name :: String }
> 
> printId :: Employee -> IO ()
> printId emp = print $ emp.id 
> 
> Is that correct or do you have to replace 'Employee' with 'r { id :: Int
> }' in the type signature of 'printId'?

That's correct. The most general type (inferred if the annotation is
omitted) will be something like

printId :: r { id :: Int } => r -> IO ()

but you are free to declare a more specific type in the usual way, much
as if the constraint was 'Show r', say.


> The discussions about an overhauled record system also involve lots of
> talk about record sub-typing, extensible records, and other more
> advanced features. I'd like to point out that there doesn't seem to be a
> great demand for these features. They might be nice-to-haves or might
> fall out naturally from a solution to the namespacing problem above, but
> they are in fact not needed to solve the common problem people have with
> the Haskell record system.

Thanks, I take your point. My proposal is to implement a good solution
to the problem you've outlined; I don't think we should go all the way
to extensible records just yet, if at all.


> Cheers,
>   Johan
> 

All the best,

Adam

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

Re: [Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs

[Alberto G. Corona]

I created a ticket for the feature request:

Ticket #7870

Teachers, newbies and people working in Industry: Please push it!


2013/4/24 Alberto G. Corona 

>
> Maybe it is possible to do something In a google summer of code. Nothing
> as sophisticated as  the Helium paper ("Scripting the Type Inference
> Process", but maybe a partial implementation of the techniques mentioned,
> so that the development can be enhanced in the future.
>
> Maybe some kind of  library that permits postprocessing of GHC errors
> and/or the identification of points in the current type checker where some
> kind of rules can be defined by the programmer can be the first step.
>
>
> 2013/4/23 Brent Yorgey 
>
>> On Tue, Apr 23, 2013 at 12:49:59PM +0200, Alberto G. Corona  wrote:
>> > Hi
>> >
>> > I ever was worried about the barrier that the complexity of the Haskell
>> > errors impose to users of DSLs. Many DSLs look so simple that even
>> someone
>> > without knowledge of Haskell can make use of them for some domains.
>> >
>> > However when the program is compiled then al the monsters of the
>> > deep appear in the surface: polymorphisms, undefined instances, type
>> errors
>> > reported in a line produced by a type assumption in another,  etc. This
>> is
>> > a problem for an industrial use of Haskell in the large scale. For
>> obvious
>> > reasons.
>>
>> Indeed.  For example, in my experience this is a big problem for diagrams.
>>
>> >
>> >
>> > The question: Is it possible to develop a GHC extension that attach (or
>> > prepend) such an explanation to the ghc error?
>> >
>> > Or any other alternative that carry out the same functionality.
>>
>> Surely it is possible.  I have wanted this too.  I guess the majority
>> of the work would just be in coming up with a good, general design
>> which is useful but not too difficult to implement.  If anyone wanted
>> to undertake such a project I would be happy to contribute some ideas.
>>
>> -Brent
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Alberto.
>



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

Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Andrew Cowie]

On Fri, 2013-04-26 at 21:21 -0800, Christopher Howard wrote:
> Hi. I've got this work situation where I've got to do all my work on
> /ancient/ RHEL5 systems, with funky software configurations, and no root
> privileges. I wanted to install GHC in my local account, but the gnu
> libc version is so old (2.5!) that I can't even get the binary packages
> to install.

Silly question, but have you tried *building GHC from source*?

Building GHC is non-trivial, but basically boils down to having an
existing ghc that runs enough to bootstrap, right? So you can take a
(quite old, sure, no problem) ghc out of the RHEL 5 repositories and use
that to build a current GHC 7.6 say. That _would_ be linked against
whatever library stack you have present, and you should be ok from
there.

AfC
Sydney



-- 
Andrew Frederick Cowie
http://www.andrewcowie.com/
+61 4 1079 6725



signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project

[Alistair Bayley]

How's about Creole?
http://wikicreole.org/

Found it via this:
http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/

If you go with Markdown, I vote for one of the Pandoc implementations,
probably Pandoc (strict):
http://johnmacfarlane.net/babelmark2/

(at least then we're not creating yet another standard...)

Alistair



On 24 April 2013 07:23, Mateusz Kowalczyk  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Greetings,
>
> In light of fairly recent discussion, on this mailing list, I decided
> to investigate the topic of Markdown support for Haddock. The archives
> of the recent discussion can be seen at [1]. This post aims to
> summarise the current state of discussion. I do aim to file a proposal
> for a GSoC project on this issue but it'd be foolish to file a
> proposal for a project aiming to benefit the community without
> consulting the community itself.
>
> Here are some main points and ideas gathered:
> * reSt seems to have a small following - quite a bit smaller than the
> Markdown community. In fact, there seems to be a significant amount of
> people pushing for Markdown which contrasts what we can read in a
> topic from 2008 at [2]. I guess it just shows how much Markdown has
> gained in popularity in recent years.
> * There are issues with using Markdown even before we attempt to use
> it for Haskell documentation:
>   * There exists no formal specification or semantics. It would seem
> that a significant number of Markdown parsers are creating by reverse
> engineering an already existing parser. This is bad because we end up
> propagating the bugs and workarounds around ambiguity that the
> original parser has.
>   * As a follow-up to the previous point, the (vanilla) Markdown is
> ambiguous and there is nothing to resolve it. As Richard A. O'Keefe
> pointed out, there exist situations where it's not possible to infer
> the semantics of Markdown from its official implementation and the
> result is parser/writer-specific [6].
> * John MacFarlane has already written a Markdown parser in Haskell. It
> can be read at [3]. This means that the new extension would not need
> to rely on Pandoc. He says ``I have an experimental thing here that
> could be used as a basis (it's 7x faster than pandoc and uses 1/5 the
> memory, BSD licensed)''. This is great! The post can be seen in full
> at [4].
> * An alternative idea was to simply write a writer module for Pandoc
> for Haddock.
>   * A reader module is already present.
>   * According to John MacFarlane, Haddock is not expressive enough to
> take advantage of this. Furthermore, Pandoc doesn't have some
> constructions that Haddock does [4].
>   * Comes back to the problem on relying on such a large package as
> Pandoc.
> * Yet another proposal was rather than introducing Markdown to
> concentrate on fixing current issues and adding features to Haddock as
> it stands [8]. This is one of the options listed at the short blog
> post at [14] by Johan Tibell.
>   * David Waern, one of Haddock maintainers admits that Haddock lacks
> active development and it has been that way for a longer time. Having
> said that, he seems to believe that Markdown integration is a project
> that can realistically be completed over summer. Such project would be
> able to use the existing HTML backend in Haddock. [9].
> * Math expressions were requested and MathJAX was suggested as a
> solution at [5]. math.stackexchange.com uses MathJAX and it works
> quite well. Personally, I believe that Haskell documentation would
> benefit from this simply due to the academic nature of the language.
> * Support for Literate Haskell would be a welcome addition as
> suggested by Andrew Butterfield at [7].
> * There are issues with CPP and LHS in regards to using Markdown in
> documentation. They are pointed out at [10] by John MacFarlane and
> others that he's replying to.
> * As pointed out 5 years ago at [11], we'd have to do some
> preprocessing on current, fairly critical sections of comments used by
> Haddock. I believe these are fairly useful and it would be a shame to
> see them go.
>
>
> I hope I haven't missed anything of high importance in a list above.
> When researching the topic, issues with Markdown quickly become
> apparent. Today, there are tens of different Markdown flavours: each
> company has different needs and each company interprets the vague
> original documentation in a way that's convenient to them. In these
> situations, topics, e-mails and blog posts like this one happen. There
> is a call to action from October 2012 at [12] but there seems to be
> absolutely no progress on any of the miraculous things mentioned in
> the post. As a result of that post, a W3C community was formed at
> [13]. It's clear that the community is inactive and no progress
> towards a solution was made.
>
> Having considered all information gathered here, I believe this would
> make a good GSoC project. There has been interest in this for Hask

Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)

[AntC]

> Johan Tibell  gmail.com> writes:
> 
> Instead of endorsing one of the listed proposals directly, I will 
emphasize the problem, so we don't lose sight of it. The problem people 
run into *in practice* and complain about in blog posts, on Google+, or 
privately when we chat about Haskell over beer, is that they would like to 
write a record definition like this one:
> 
>     data Employee = Employee { id :: Int, name :: String }
> 
>     printId :: Employee -> IO ()
>     printId emp = print $ id emp
> 
> but since that doesn't work well in Haskell today due to name
> collisions, ...

[I've a bit more to say on that record definition below.]


Thank you Johan, I agree we should keep clear sight of the problem. So 
let's be a bit more precise: it's not exactly the record declaration that 
causes the name collisions, it's the field selector function that gets 
created automatically. (Note that we can use xDisambiguateRecordFields to 
access fields to, errm, disambiguate.)

So I did put in a separate proposal [3] (and ticket) on that very narrow 
issue. (Simon M pointed out that I probably didn't name it very well!)

Even if we do nothing to advance the "records swamp", PLEASE can we 
provide a compiler option to suppress that function.

I envisage it might facilitate a 'cottage industry' of Template Haskell 
solutions (generating Has instances), which would be a cheap and cheerful 
way to experiment in the design space.


[3] 
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFi
elds/NoMonoRecordFields
(There are bound to be some fishhooks, especially around export/import of 
names from a module with no selector functions to one that's expecting 
them.)



[cont from above]
> ... the best practice today is to instead write something like:
> 
>     data Employee = Employee { employeeId :: Int, employeeName :: 
String }
> 
>     printId :: Employee -> IO ()
>     printId emp = print $ employeeId emp
> 
> The downsides of the latter have been discussed elsewhere, but briefly 
they are:
> 
>  * Overly verbose when there's no ambiguity.
>  * Ad-hoc prefix is hard to predict (i.e. sometimes abbreviations of the 
data type name are used).

I don't entirely agree with your analysis.
 * fields named `id' or `name' are very likely to clash,
   so that's a bad design (_too_ generic).
 * If you've normalised your data model [**],
   you are very likely to want exactly the same field
   in several records
   (for example employeeId in EmployeeNameAddress,
and in EmployeePay and in EmployeeTimeSheet.)

[And this use case is what TP/DORF is primarily aimed at.]

[**] Do I need to explain what data model normalisation is? I fear that so-
called XML 'databases' mean academics don't get taught normalisation any 
more(?)

AntC



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

Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)

[AntC]

> Johan Tibell  gmail.com> writes:
> 
> The discussions about an overhauled record system also involve lots of 
talk about record sub-typing, extensible records, and other more advanced 
features. I'd like to point out that there doesn't seem to be a great 
demand for these features. ...

Sorry, Johan, I really have to disagree with that.

There's lot's of Haskell to SQL interfaces that build on HList and its 
extensible record ideas (HDBC for example).

But the usability is not good (as Petr points out, and as Oleg/Ralf 
admitted back in the paper). The type error messages are long and obscure. 



> ... They might be nice-to-haves or might fall out naturally from a 
solution to the namespacing problem above, but they are in fact not needed 
to solve the common problem people have with the Haskell record system.

"the common problem people have" is that the record system is unusable 
[IMO] so doesn't get 'stretched' to see what other difficulties it has. 
There are all sorts of alternative systems (including Lenses) built with 
Template Haskell (and chewing gum and gaffer tape: that's how desperately 
bad is the current situation ;-).

I'm saying that many people find the Haskell record system 'as is' so 
dysfunctional that they give up on it! I feel strongly that as soon as we 
get past the name collissions, there'll be other blockages to using it.

I'd be interested to hear if there are any who can remember the Trex 
system, and how (un)usable it was?

AntC



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

Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Daniel Fischer]

On Saturday 27 April 2013, 19:18:35, Andrew Cowie wrote:
> On Fri, 2013-04-26 at 21:21 -0800, Christopher Howard wrote:
> > Hi. I've got this work situation where I've got to do all my work on
> > /ancient/ RHEL5 systems, with funky software configurations, and no root
> > privileges. I wanted to install GHC in my local account, but the gnu
> > libc version is so old (2.5!) that I can't even get the binary packages
> > to install.
> 
> Silly question, but have you tried *building GHC from source*?
> 
> Building GHC is non-trivial, but basically boils down to having an
> existing ghc that runs enough to bootstrap, right? So you can take a
> (quite old, sure, no problem) ghc out of the RHEL 5 repositories and use
> that to build a current GHC 7.6 say.

It's not quite as convenient as that, since you need a new enough GHC to build 
7.6 (not sure which version is required).

So you'd probably need to build one or two intermediate GHCs from source, 
depending on what you can directly install.

Building from source isn't so difficult, you need a gcc, you need to install 
happy and alex (sufficiently old versions for the start, install the newest 
versions before you build the final GHC), and of course a working GHC.

./configure --prefix=$HOME
(or where you want to install GHC)
make && make install

You then have a lot of time to drink tea.

> That _would_ be linked against whatever library stack you have present,
> and you should be ok from there.


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

Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Joe Quinn]

If you are feeling brave, you can also bootstrap GHC. For operating 
systems that are already supported, it should not be too hard.
Last time I tried on a fresh install of Debian, the process was to 
install the dependencies, and then something like this:


sh configure
make
make install

Disclaimer: this was with 7.4.1, which was a while ago. I don't remember 
if that's all there was to it.


On 4/27/2013 7:12 AM, Daniel Fischer wrote:

On Saturday 27 April 2013, 19:18:35, Andrew Cowie wrote:

On Fri, 2013-04-26 at 21:21 -0800, Christopher Howard wrote:

Hi. I've got this work situation where I've got to do all my work on
/ancient/ RHEL5 systems, with funky software configurations, and no root
privileges. I wanted to install GHC in my local account, but the gnu
libc version is so old (2.5!) that I can't even get the binary packages
to install.

Silly question, but have you tried *building GHC from source*?

Building GHC is non-trivial, but basically boils down to having an
existing ghc that runs enough to bootstrap, right? So you can take a
(quite old, sure, no problem) ghc out of the RHEL 5 repositories and use
that to build a current GHC 7.6 say.

It's not quite as convenient as that, since you need a new enough GHC to build
7.6 (not sure which version is required).

So you'd probably need to build one or two intermediate GHCs from source,
depending on what you can directly install.

Building from source isn't so difficult, you need a gcc, you need to install
happy and alex (sufficiently old versions for the start, install the newest
versions before you build the final GHC), and of course a working GHC.

./configure --prefix=$HOME
(or where you want to install GHC)
make && make install

You then have a lot of time to drink tea.


That _would_ be linked against whatever library stack you have present,
and you should be ok from there.


___
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] Request for help: Recompile of ghc producing "...-ghc7.4.2.so"s, which break project builds.

[Captain Freako]

Recently, I had to recompile ghc, in order to get the "-dyn" versions of
the standard libraries installed. (The standard Ubuntu 12.10 64-bit Linux
distribution doesn't include them in its "haskell-platform" package, and
you can't upgrade "base" using the normal "cabal iinstall" approach, from
what I understand.)

When I did this, the "-dyn" versions of the standard libraries were, in
fact, installed. However, they were given names with a "-ghc7.4.2.so"
suffix. And this is causing the build of a previously working project to
break, thusly:

ghc -o libami.so -shared -dynamic -package parsec *-lHSrts* -lm -lffi -lrt
AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o

/usr/bin/ld: /usr/lib/ghc-7.4.2/*libHSrts.a*(RtsAPI.o): relocation
R_X86_64_32S against `ghczmprim_GHCziTypes_Czh_con_info' can not be used
when making a shared object; recompile with -fPIC

The problem is this: the linker is picking up the "*.a" version of the *
HSrts* library, instead of the "*.so" version, which is what it really
needs. And the reason it's doing this is the "*.so" version has been given
a "-ghc7.4.2" suffix:

dbanas@dbanas-lap:~/prj/AMI-Tool$ l /usr/lib/ghc-7.4.2/libHSrts*
/usr/lib/ghc-7.4.2/libHSrts.a

{snip}

/usr/lib/ghc-7.4.2/libHSrts*-ghc7.4.2*.so*

{snip}


So, it seems to me that I need to either:

   1. Tell the linker about the possibility of a "-ghc7.4.2" file name
   suffix, or
   2. rebuild my "*.so"s without that suffix.

*Can anyone tell me:*

   - *How to accomplish either #1 or #2, above?*
   - *Which one is the preferred solution to the problem?*
   - *Am I completely off in the weeds?*
   - *If so, what should I really be doing, in order to fix this issue?*

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

Re: [Haskell-cafe] Request for help: Recompile of ghc producing "...-ghc7.4.2.so"s, which break project builds.

[David Banas]

I am able to fix my build problem, by creating a link to *
libHSrts-ghc7.4.2.so, *named *libHSrts.so*:

dbanas@dbanas-lap:~/prj/AMI-Tool$ ll /usr/lib/ghc-7.4.2/libHSrts*
-rw-r--r-- 1 root root  980950 Apr 23 20:08 /usr/lib/ghc-7.4.2/libHSrts.a
{snip}
-rwxr-xr-x 1 root root  429218 Apr 23 20:08 
/usr/lib/ghc-7.4.2/libHSrts-ghc7.4.2.so*
{snip}
lrwxrwxrwx 1 root root  20 Apr 27 08:20 /usr/lib/ghc-7.4.2/*libHSrts.so*-> 
libHSrts-ghc7.4.2.so*

{snip}

 

dbanas@dbanas-lap:~/prj/AMI-Tool$ make
rm -f libami.so
ghc -o libami.so -shared -dynamic -package parsec -lHSrts -lm -lffi -lrt 
AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o
dbanas@dbanas-lap:~/prj/AMI-Tool$ 


However, I'm a little confused as to why the "-package parsec" isn't 
triggering the same issue, since the parsec dynamic libraries were given 
the same "-ghc7.4.2" suffix:

dbanas@dbanas-lap:~/prj/AMI-Tool$ ll ~/.cabal/lib/parsec-3.1.3/ghc-7.4.2/
total 5816
{snip}
-rw-r--r-- 1 dbanas dbanas 1006668 Apr 24 16:37 HSparsec-3.1.3.o
-rw-r--r-- 1 dbanas dbanas 1340698 Apr 24 16:37 libHSparsec-3.1.3.a
-rwxr-xr-x 1 dbanas dbanas 1061317 Apr 24 16:37 libHSparsec-3.1.3*-ghc7.4.2*
.so*

{snip}


*Any thoughts?*

Thanks,
-db


On Saturday, April 27, 2013 6:37:43 AM UTC-7, David Banas wrote:
>
> Recently, I had to recompile ghc, in order to get the "-dyn" versions of 
> the standard libraries installed. (The standard Ubuntu 12.10 64-bit Linux 
> distribution doesn't include them in its "haskell-platform" package, and 
> you can't upgrade "base" using the normal "cabal iinstall" approach, from 
> what I understand.)
>
> When I did this, the "-dyn" versions of the standard libraries were, in 
> fact, installed. However, they were given names with a "-ghc7.4.2.so" 
> suffix. And this is causing the build of a previously working project to 
> break, thusly:
>
> ghc -o libami.so -shared -dynamic -package parsec *-lHSrts* -lm -lffi 
> -lrt AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o
>
> /usr/bin/ld: /usr/lib/ghc-7.4.2/*libHSrts.a*(RtsAPI.o): relocation 
> R_X86_64_32S against `ghczmprim_GHCziTypes_Czh_con_info' can not be used 
> when making a shared object; recompile with -fPIC
>
> The problem is this: the linker is picking up the "*.a" version of the *
> HSrts* library, instead of the "*.so" version, which is what it really 
> needs. And the reason it's doing this is the "*.so" version has been given 
> a "-ghc7.4.2" suffix:
>
> dbanas@dbanas-lap:~/prj/AMI-Tool$ l /usr/lib/ghc-7.4.2/libHSrts*
> /usr/lib/ghc-7.4.2/libHSrts.a
>
> {snip}
>
> /usr/lib/ghc-7.4.2/libHSrts*-ghc7.4.2*.so*
>
> {snip}
>
>
> So, it seems to me that I need to either:
>
>1. Tell the linker about the possibility of a "-ghc7.4.2" file name 
>suffix, or
>2. rebuild my "*.so"s without that suffix.
>
> *Can anyone tell me:*
>
>- *How to accomplish either #1 or #2, above?*
>- *Which one is the preferred solution to the problem?*
>- *Am I completely off in the weeds?*
>- *If so, what should I really be doing, in order to fix this issue?*
>
> Thanks!
> -db
>
>___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Request for help: Recompile of ghc producing "...-ghc7.4.2.so"s, which break project builds.

[Brandon Allbery]

On Sat, Apr 27, 2013 at 11:47 AM, David Banas  wrote:

> dbanas@dbanas-lap:~/prj/AMI-Tool$ make
> rm -f libami.so
> ghc -o libami.so -shared -dynamic -package parsec -lHSrts -lm -lffi -lrt
> AMIParse.o AMIModel.o ami_model.o ExmplUsrModel.o Filter.o
> dbanas@dbanas-lap:~/prj/AMI-Tool$
>
>
> However, I'm a little confused as to why the "-package parsec" isn't
> triggering the same issue, since the parsec dynamic libraries were given
> the same "-ghc7.4.2" suffix:
>

That would be because the parsec library contains the correct invocation
already, but above you are telling the linker to look for libHSrts.{so,a}
with the explicit -l option. You would need to change it to
```-lHSrts-ghc7.4.2```.

Perhaps ghc needs an option to include the correct runtime support
libraries in this case; certainly, having to specify all of those in the
build command is ugly and fragile even without mangled shared object names.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Jeremy Shaw]

Have you considered installing on older version of GHC? Such as GHC
6.10.4 or GHC 6.8.3?

http://www.haskell.org/ghc/download_ghc_6_10_4
http://www.haskell.org/ghc/download_ghc_683

They won't have all the latest extensions.. but they still have more
features than any other alternative.

Also, once you have a version installed, you can, with enough
patience, upgrade to the latest version if you really need some
feature.

- jeremy

On Sat, Apr 27, 2013 at 12:21 AM, Christopher Howard
 wrote:
> Hi. I've got this work situation where I've got to do all my work on
> /ancient/ RHEL5 systems, with funky software configurations, and no root
> privileges. I wanted to install GHC in my local account, but the gnu
> libc version is so old (2.5!) that I can't even get the binary packages
> to install.
>
> I've had success installing some other simple functional languages (like
> CLISP) on these same systems, so I was wondering if there was perhaps
> another language very similar to Haskell (but presumably simpler) with a
> super portable compiler easily built from source, which I could try.
>
> I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick
> description didn't make it sound much more portable than GHC, but I
> guess I could try it if I heard some good reasons to think it would be
> more portable.
>
> --
> frigidcode.com
>
>
> ___
> 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] Looking for portable Haskell or Haskell like language

[Jerzy Karczmarczuk]

Christopher Howard:

I was wondering if there was perhaps
another language very similar to Haskell (but presumably simpler) with a
super portable compiler easily built from source, which I could try.

I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick
description didn't make it sound much more portable than GHC, but I
guess I could try it if I heard some good reasons to think it would be
more portable.

Is the portability which worries you, or the age of your system?

Hugs (and Gofer before) are simply sufficiently old... I used them on 
Red Hat in one of my previous lives.

Do you really need to compile your system from sources?

There are binaries everywhere. If you want a *simpler* language, perhaps 
try Miranda? Also a quite ancient language...


Or, perhaps a newer one, in some aspects simpler than Haskell (but far 
from any simplicity): Clean.


Perhaps it might help to know what do you need it for...

The best

Jerzy Karczmarczuk


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

[Haskell-cafe] Display an inferred type during compilation

[Corentin Dupont]

Hi Cafe,
can I ask the compiler to display the type of an inferred value during
compile time?
It would be great if I can output a string during compilation with the type.
A little bit like running :type in GHCi, but without GHCi... Because
running GHCi is sometime painful (I have to clean my code first).

I'm thinking of something like:

main :: IO ()
main = do
   a <- someCode
   displayTypeAtCompileTime a
   return ()

$ ghc -c test.hs
test.hs:4:3: your type is: Foo

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

Re: [Haskell-cafe] Display an inferred type during compilation

[Gwern Branwen]

On Sat, Apr 27, 2013 at 12:55 PM, Corentin Dupont
 wrote:
> can I ask the compiler to display the type of an inferred value during
> compile time?
> It would be great if I can output a string during compilation with the type.
> A little bit like running :type in GHCi, but without GHCi... Because running
> GHCi is sometime painful (I have to clean my code first).

You could try floating a value to the top level; then I believe -Wall
will make ghc print out the inferred type since you didn't give a type
signature.

-- 
gwern
http://www.gwern.net

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

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project

[Mateusz Kowalczyk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/04/13 10:23, Alistair Bayley wrote:
> How's about Creole? http://wikicreole.org/
> 
> Found it via this: 
> http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/
>
>  If you go with Markdown, I vote for one of the Pandoc
> implementations, probably Pandoc (strict): 
> http://johnmacfarlane.net/babelmark2/
> 
> (at least then we're not creating yet another standard...)
> 
> Alistair

I'd very much like to avoid creating yet another Markdown flavour but
I don't think it will be possible to use an existing one in its entirety.
The issue (?) with Creole is [1], where you're allowed to tack on
anything you want in the parts not covered in the spec. If you ask me,
this sounds exactly like what the case was with the original
`specification' of Markdown: the documentation was just too damn vague
and ambiguous so we ended up with every company interpreting it
themselves in a way that was favourable to them.

Is there any reason in particular why you'd like Pandoc (strict)
Markdown rather than any other flavour?


- -- 
Mateusz K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRfAZrAAoJEM1mucMq2pqX9vgQAKdOnxJgMoT7GpUEyWGZqNt5
2k2yANgjDIcCDcmK+g8B6USTDAV/guDXyLxK6b/gfGYApBqxzyegE/ogxh6zquoq
bdaa0BoIQCRsguHy136WX+uwgNH8KN6L684bVpW0960yrtuRK3ow0uklM6wkvQR3
5V8BU7vhKyVxldgEkPQMLMI+u8ppVDUp6RUW/7EQctunmgWwzaO3LMhrc8eBjumc
saee0SR9yUlpFq8zEQIw+EGqsokY5lPbbhfUJwDYbqtm/LRgL5rw+NhptIf1GgFm
hGvLqsUsdRRLx5GH/FN2PoQNt4xnqjoPEOXL60p5SYtBvDmfFOFkJ+1oGCrM0JLl
Yy4BtcXJpRxFEaWYq/TGaDWdIRSpRZ2JvSwlnHW+EpnXKnPVnReKOzIa4iPD94qS
WdX+uK/v6ikmRbht1rkNvV3a+oWYpwx7dIhk+XzcMKxsb1DJ5bmI2/SxfhARcWxJ
zXhhYJSB/TpsvPAlKcT3emLJUwaigxr59JxlDmnq9goYl/MZVZDe4ihCH8JwC/hE
oHrG7TL5HPLxWjiJ/cmyOsoVgcwgu0SxH4vsHqtFs66uYZ1gPahw6ILJlS0y3lbb
XH9w4dkZybXUYPohD5ZZZXtWTKP+xGGNPdvC8D2K0yYNDTXBvXhl9R6S+oBRFIZs
G/VgHSOw3givgsrQT+BZ
=vZF9
-END PGP SIGNATURE-

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

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project

[Bryan O'Sullivan]

On Sat, Apr 27, 2013 at 2:23 AM, Alistair Bayley wrote:

> How's about Creole?
> http://wikicreole.org/
>
> Found it via this:
>
> http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/
>
> If you go with Markdown, I vote for one of the Pandoc implementations,
> probably Pandoc (strict):
> http://johnmacfarlane.net/babelmark2/
>
> (at least then we're not creating yet another standard...)
>

Probably the best way to deal with this is by sidestepping it: make the
support for alternative syntaxes as modular as possible, and choose two to
start out with in order to get a reasonable shot at constructing a suitable
API.

I think it would be a shame to bikeshed on which specific syntaxes to
support, when a lot of productive energy could more usefully go into
actually getting the work done. Better to say "prefer a different markup
language? code to this API, then submit a patch!"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Siraaj Khandkar]

On Apr 27, 2013, at 1:21 AM, Christopher Howard 
 wrote:

> Hi. I've got this work situation where I've got to do all my work on
> /ancient/ RHEL5 systems, with funky software configurations, and no root
> privileges. I wanted to install GHC in my local account, but the gnu
> libc version is so old (2.5!) that I can't even get the binary packages
> to install.
> 
> I've had success installing some other simple functional languages (like
> CLISP) on these same systems, so I was wondering if there was perhaps
> another language very similar to Haskell (but presumably simpler) with a
> super portable compiler easily built from source, which I could try.

I successfully built and used OCaml 4.0.0 on a 32 bit RHEL 5 box a few months 
ago.

https://github.com/ocaml/ocaml


> I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick
> description didn't make it sound much more portable than GHC, but I
> guess I could try it if I heard some good reasons to think it would be
> more portable.
> 
> -- 
> frigidcode.com
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

-- 
Siraaj Khandkar
.o.  o.o  ..o  o..  .o.
..o  .oo  o.o  .oo  ..o
ooo  .o.  .oo  oo.  ooo



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

Re: [Haskell-cafe] Display an inferred type during compilation

[Ilya Portnov]

В письме от 27 апреля 2013 18:55:16 пользователь Corentin Dupont написал:


Hi Cafe,can I ask the compiler to display the type of an inferred value during 
compile 
time?It would be great if I can output a string during compilation with the 
type.A little 
bit like running :type in GHCi, but without GHCi... Because running GHCi is 
sometime 
painful (I have to clean my code first).

I'm thinking of something like:

main :: IO ()main = do   a <- someCode   displayTypeAtCompileTime a   return ()

$ ghc -c test.hstest.hs:4:3: your type is: Foo

Thanks,Corentin


Hi.

What about TemplateHaskell? Smth like:

{-# LANGUAGE TemplateHaskell #-}
module DisplayType where

import Language.TH

displayTypeAtCompileTime :: Name -> Q Exp
displayTypeAtComileTime name = do
reified <- reify name
  -- inspect reified structure, see TH haddock documentation
runIO $ putStrLn $ show theType
 [| undefined |] -- you need to return some expression; since you are not 
to use it's 
value, it may be even undefined, it seems.

###

{-# LANGUAGE TemplateHaskell #-}
module Main where


import DisplayType

main = do
...
$displayTypeAtCompileTime 'a
...



WBR, Ilya Portnov.


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

[Haskell-cafe] Markdown extension for Haddock as a GSoC project

[Chris Smith]

Oops, forgot to reply all.
-- Forwarded message --
From: "Chris Smith" 
Date: Apr 27, 2013 12:04 PM
Subject: Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
To: "Bryan O'Sullivan" 
Cc:

I don't agree with this at all.  Far more important than which convention
gets chosen is that Haskell code can be read and written without learning
many dialects of Haddock syntax.  I see an API for pluggable haddock syntax
as more of a liability than a benefit.  Better to just stick to what we
have than fragment into more islands.

I do think that changing Haddock syntax to include common core pieces of
Markdown could be a positive change... but not if it spawns a battle of
fragmented documentation syntax that lasts a decade.
On Apr 27, 2013 11:08 AM, "Bryan O'Sullivan"  wrote:

> On Sat, Apr 27, 2013 at 2:23 AM, Alistair Bayley wrote:
>
>> How's about Creole?
>> http://wikicreole.org/
>>
>> Found it via this:
>>
>> http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/
>>
>> If you go with Markdown, I vote for one of the Pandoc implementations,
>> probably Pandoc (strict):
>> http://johnmacfarlane.net/babelmark2/
>>
>> (at least then we're not creating yet another standard...)
>>
>
> Probably the best way to deal with this is by sidestepping it: make the
> support for alternative syntaxes as modular as possible, and choose two to
> start out with in order to get a reasonable shot at constructing a suitable
> API.
>
> I think it would be a shame to bikeshed on which specific syntaxes to
> support, when a lot of productive energy could more usefully go into
> actually getting the work done. Better to say "prefer a different markup
> language? code to this API, then submit a patch!"
>
> ___
> 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] Looking for portable Haskell or Haskell like language

[Hong Yang]

I had similar work situation before. What I did was: install a CentOS
virtual machine on Windows at home (CentOS version should be compatible to
your RHEL5 version, and do not update it), then play with Haskell within
CentOS. Your executables will be runnable on RHEL5.


On Sat, Apr 27, 2013 at 1:20 PM, Siraaj Khandkar wrote:

>
> On Apr 27, 2013, at 1:21 AM, Christopher Howard <
> christopher.how...@frigidcode.com> wrote:
>
> > Hi. I've got this work situation where I've got to do all my work on
> > /ancient/ RHEL5 systems, with funky software configurations, and no root
> > privileges. I wanted to install GHC in my local account, but the gnu
> > libc version is so old (2.5!) that I can't even get the binary packages
> > to install.
> >
> > I've had success installing some other simple functional languages (like
> > CLISP) on these same systems, so I was wondering if there was perhaps
> > another language very similar to Haskell (but presumably simpler) with a
> > super portable compiler easily built from source, which I could try.
>
> I successfully built and used OCaml 4.0.0 on a 32 bit RHEL 5 box a few
> months ago.
>
> https://github.com/ocaml/ocaml
>
>
> > I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick
> > description didn't make it sound much more portable than GHC, but I
> > guess I could try it if I heard some good reasons to think it would be
> > more portable.
> >
> > --
> > frigidcode.com
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> --
> Siraaj Khandkar
> .o.  o.o  ..o  o..  .o.
> ..o  .oo  o.o  .oo  ..o
> ooo  .o.  .oo  oo.  ooo
>
>
>
> ___
> 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] partially applied data constructor and corresponding type

[TP]

Hello,

I ask myself if there is a way to do the following.
Imagine that I have a dummy type:

data Tensor = TensorVar Int String

where the integer is the order, and the string is the name of the tensor.
I would like to make with the constructor TensorVar a type "Vector", such 
that, in "pseudo-language":

data Vector = TensorVar 1 String

Because a vector is a tensor of order 1.

Is this possible? I have tried type synonyms and newtypes without any success.

Thanks a lot,

TP

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

Re: [Haskell-cafe] Haskell compilation errors break the complexity encapsulation on DSLs

[Ozgur Akgun]

Hi,

On 27 April 2013 10:07, Alberto G. Corona  wrote:

> I created a ticket for the feature request:
>
> Ticket #7870
>
> Teachers, newbies and people working in Industry: Please push it!
>

A link to the ticket may be helpful for the lazy.

http://hackage.haskell.org/trac/ghc/ticket/7870

I quite like this idea, and I think this is one thing people use TH for now
instead.
(Using quasi-quotes, you can produce any compilation error you like...)
It would be great if we didn't have to pull in the full power of TH (or QQ)
for this.


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

Re: [Haskell-cafe] partially applied data constructor and corresponding type

[Yury Sulsky]

Hi TP,

Are you looking to use a phantom types here? Here's an example:

data One
data Two

data Tensor ndims a = Tensor { dims :: [Int], items :: [a] }
type Vector = Tensor One
type Matrix = Tensor Two

etc.


On Sat, Apr 27, 2013 at 3:33 PM, TP  wrote:

> Hello,
>
> I ask myself if there is a way to do the following.
> Imagine that I have a dummy type:
>
> data Tensor = TensorVar Int String
>
> where the integer is the order, and the string is the name of the tensor.
> I would like to make with the constructor TensorVar a type "Vector", such
> that, in "pseudo-language":
>
> data Vector = TensorVar 1 String
>
> Because a vector is a tensor of order 1.
>
> Is this possible? I have tried type synonyms and newtypes without any
> success.
>
> Thanks a lot,
>
> TP
>
> ___
> 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] Operations on functional graphs

[Francesco Mazzoli]

At Wed, 24 Apr 2013 13:02:39 +0100,
Francesco Mazzoli wrote:
> Hi list,
> 
> I’ve been lately thinking about how to implement an algorithm efficiently, 
> and I
> need a directed graph that can perform the following tasks:
> 
>   1. Finding the strongly connected components
>   2. Condensing strongly connected components
>   3. Contract single edges
> 
> The condensing shouldn’t prevent successive operations to work with the
> condensed vertices (treating them all as the same), but should get rid of the
> edges.
> 
> Point one is easy, for example as described in [1].  I’m wondering if a nice 
> way
> to implement the other two with functional structures has been described.  I’d
> guess it would be a mix of a graph and disjoint sets data structure...

In the end I solved point 2 the ‘stupid’ way: I have a ‘representative’ node for
each condensed SCC, and when I condense I chose a new representative for all the
members of the SCC in question and then I traverse the all the successors list
updating and merging stale representatives.  The code is here, in case anyone’s
interested: .

Francesco

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

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project

[Ben]

asciidoc has been mentioned a few times in comments, i think it's worth looking 
at.  

* mature, over 10 years old (predates markdown i think), not "just another 
markdown clone"
* human readable, but it has a lot of advanced features including mathematical 
formulas.  
* github supports it (they were sufficiently impressed with it to make a ruby 
implementation called asciidoctor)
* several o'reilly books have been written in it, and the git documentation is 
written in it.

roughly, asciidoc is to docbook as markdown is to html.  i'm no expert in this 
area but it seems to be a good alternative.

http://asciidoc.org/
http://asciidoctor.org/docs/what-is-asciidoc-why-use-it/

best, ben

On Apr 27, 2013, at 11:06 AM, Bryan O'Sullivan wrote:

> On Sat, Apr 27, 2013 at 2:23 AM, Alistair Bayley  wrote:
> How's about Creole?
> http://wikicreole.org/
> 
> Found it via this:
> http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/
> 
> If you go with Markdown, I vote for one of the Pandoc implementations, 
> probably Pandoc (strict):
> http://johnmacfarlane.net/babelmark2/
> 
> (at least then we're not creating yet another standard...)
> 
> Probably the best way to deal with this is by sidestepping it: make the 
> support for alternative syntaxes as modular as possible, and choose two to 
> start out with in order to get a reasonable shot at constructing a suitable 
> API.
> 
> I think it would be a shame to bikeshed on which specific syntaxes to 
> support, when a lot of productive energy could more usefully go into actually 
> getting the work done. Better to say "prefer a different markup language? 
> code to this API, then submit a patch!"
> ___
> 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] text-icu on Windows

[John MacFarlane]

Hello café:

I'd very much like to get text-icu working on Windows, as then I could ship
pandoc binaries that do proper unicode collation in bibliographies.  But I'm
having a devil of a time.  This may be due to my very limited Windows
knowledge.  Any help would be appreciated, especially from someone who actually
has text-icu working on Windows.

I was able to cabal install text-icu without errors. I used --extra-lib-dirs
and --extra-include-dirs to point to the lib and include directories in the
32-bit binary distribution of icu4c.  I'm using the latest Haskell Platform,
2012.4.0.0 with ghc 7.4.2.

I was also able to build the following simple program that uses text-icu, by
doing ghc --make icu.hs:

~~~
-- icu.hs
import Data.Text.ICU
main = print $ Locale "tr-TR"
~~~

No errors or warnings in either of these steps. But when I try to run the
compiled program, icu.exe, I get no output at all. I expected to get a line
with 'Locale "tr-TR"', but instead I get nothing -- not even an error or 
warning.
This remains the case if I try

~~~
main = do
  print "Start"
  print $ Locale "tr-TR"
  print "Done"
~~~

'echo $?' yields False.

Any ideas?

John

(I've posted a similar question to StackOverflow [1], but it hasn't gotten
an answer yet there, so I thought I'd try here.)

[1]: 
http://stackoverflow.com/questions/16127710/how-do-i-get-text-icu-working-on-windows)


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

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project

[Bryan O'Sullivan]

On Sat, Apr 27, 2013 at 1:47 PM, Ben  wrote:

> asciidoc has been mentioned a few times in comments, i think it's worth
> looking at.
>

This is the problem I was afraid of: for every markup syntax under the sun,
someone will come along to champion it.

The choice of one or N syntaxes is ultimately up to the discretion of the
student, guided by their mentor. It is in our collective interest to avoid
prolonging a bikeshed discussion on this, as a long inconclusive discussion
risks dissuading any sensible student or mentor from wanting to pursue the
project in the first place.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Christopher Howard]

On 04/27/2013 08:36 AM, Jerzy Karczmarczuk wrote:
> Christopher Howard:
> Is the portability which worries you, or the age of your system?
> 

Actually getting a successful build and installation would be great.
Also, there are multiple systems I work with, both of which have ancient
software, but unfortunately are not the same configuration. I often find
software that builds on one, but not the other.

> Hugs (and Gofer before) are simply sufficiently old... I used them on
> Red Hat in one of my previous lives.
> Do you really need to compile your system from sources?
> 

I guess not, if I can get one to install successfully to a local
(non-root) user account. As mentioned, GHC Linux binaries failed me
here, because apparently the gnu libc version is too old. With most
software, I generally have had more success installing from source than
trying to work with pre-built.

> There are binaries everywhere. If you want a *simpler* language, perhaps
> try Miranda? Also a quite ancient language...
> 
> Or, perhaps a newer one, in some aspects simpler than Haskell (but far
> from any simplicity): Clean.
> 

To be clearer, I do not really want any language other than Haskell. I
just imagined that a simpler language might have a simpler and more
portable compiler.

> Perhaps it might help to know what do you need it for...
> 

In brief, I have access to some large super computer systems. Sadly,
nobody in my academic or work circles seems to have the slightest
interest in applying functional languages to parallel computing problems
(C and Fortran seem to be the languages of choice.) So, I've been poking
around with some functional languages, trying to see what I could get
installed (without any admin assistance whatsoever) and how I might be
able to use them with the MPI or even GPGPU infrastructure we have. But
I keep running into problems, because the software infrastructure is
quite ancient (for compatibility purposes, I'm told), or there are other
mysterious configuration issues.

-- 
frigidcode.com



signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project

[John MacFarlane]

I agree with Chris that it would be better to have a standard syntax for
Haskell documentation.  Especially if the alternative is ten different
markup languages. (Remember, all of these need to be supported in
haddock, which is a basic piece of infrastructure.)

Here's a thought.  Instead of adding support for markdown, why not
enhance the existing haddock markup, making it more expressive, so that
it could encode the same range of structural features as markdown?

If this were done, we could add a haddock writer to pandoc.  There is
already a haddock reader in the development version, but a writer is
difficult because haddock is so much less expressive than other formats.
For example, unless I'm mistaken, it doesn't allow list items with
multiple paragraphs or other block elements, or nested lists, or images,
or blockquotes.

With a pandoc reader and writer for haddock, it would be easy to write
your documentation in any format you choose (several variants of
markdown, reST, textile, LaTeX, HTML, mediawiki) and produce equivalent
haddock markup to paste into the source file.

It would also be easy to convert the documentation in your source file
to any of the formats supported by pandoc.  So, you could generate a man
page from your haddock markup, or a web page or blog entry, or a LaTeX
document.

It seems to me that this would provide most of the advantages people
who want a markdown extension for haddock are looking for.  But it would
not require taking sides in markdown/reST/asciidoc/creole wars,
and it would not lead to the fragmentation of documentation formats
in Haskell source code.  If the extensions to haddock markup were done
carefully, it wouldn't even require a special PRAGMA, since all existing
markup would have the same interpretation in the extended markup.

John

+++ Chris Smith [Apr 27 13 12:05 ]:
>I don't agree with this at all. Far more important than which
>convention gets chosen is that Haskell code can be read and written
>without learning many dialects of Haddock syntax. I see an API for
>pluggable haddock syntax as more of a liability than a benefit. Better
>to just stick to what we have than fragment into more islands.
> 
>I do think that changing Haddock syntax to include common core pieces
>of Markdown could be a positive change... but not if it spawns a battle
>of fragmented documentation syntax that lasts a decade.
>On Apr 27, 2013 11:08 AM, "Bryan O'Sullivan" <[3]b...@serpentine.com>
>wrote:
> 
>On Sat, Apr 27, 2013 at 2:23 AM, Alistair Bayley
><[4]alist...@abayley.org> wrote:
> 
>How's about Creole?
>[5]http://wikicreole.org/
>Found it via this:
>[6]http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favo
>urite-language/
>If you go with Markdown, I vote for one of the Pandoc implementations,
>probably Pandoc (strict):
>[7]http://johnmacfarlane.net/babelmark2/
>(at least then we're not creating yet another standard...)
> 
>Probably the best way to deal with this is by sidestepping it: make the
>support for alternative syntaxes as modular as possible, and choose two
>to start out with in order to get a reasonable shot at constructing a
>suitable API.
>I think it would be a shame to bikeshed on which specific syntaxes to
>support, when a lot of productive energy could more usefully go into
>actually getting the work done. Better to say "prefer a different
>markup language? code to this API, then submit a patch!"
> 
>  ___
>  Haskell-Cafe mailing list
>  [8]Haskell-Cafe@haskell.org
>  [9]http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> References
> 
>1. mailto:cdsm...@gmail.com
>2. mailto:b...@serpentine.com
>3. mailto:b...@serpentine.com
>4. mailto:alist...@abayley.org
>5. http://wikicreole.org/
>6. 
> http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/
>7. http://johnmacfarlane.net/babelmark2/
>8. mailto:Haskell-Cafe@haskell.org
>9. 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

Re: [Haskell-cafe] partially applied data constructor and corresponding type

[TP]

Thanks Yury,

The problem with this solution is that if I have written a method for the 
Tensor type (for example a method of a typeclass of which Tensor is an 
instance) that uses the order of the tensor (your "ndims") in a general way, I 
cannot reuse it easily for a vector defined like that.

In fact, my problem is to be able to define:
* from my type "Tensor", a type "Vector", by specifying that the dimension 
must be one to have a "Vector" type.
* from my constructor "TensorVar", a constructor "VectorVar", which 
corresponds to TensorVar with the integer equal to 1.

The idea is to avoid duplicating code, by reusing the tensor type and data 
constructor. At some place in my code, in some definition (say, of a vector 
product), I want vectors and not more general tensors.

TP

On Saturday, April 27, 2013 16:16:49 Yury Sulsky wrote:

Hi TP,


Are you looking to use a phantom types here? Here's an example:


data One
data Two


data Tensor ndims a = Tensor { dims :: [Int], items :: [a] }
type Vector = Tensor One
type Matrix = Tensor Two


etc.



On Sat, Apr 27, 2013 at 3:33 PM, TP  wrote:

Hello,

I ask myself if there is a way to do the following.
Imagine that I have a dummy type:

data Tensor = TensorVar Int String

where the integer is the order, and the string is the name of the tensor.
I would like to make with the constructor TensorVar a type "Vector", such
that, in "pseudo-language":

data Vector = TensorVar 1 String

Because a vector is a tensor of order 1.

Is this possible? I have tried type synonyms and newtypes without any success.

Thanks a lot,

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

Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Aaron Tomb]

I recently built a binary installer for GHC 7.6.3 to run on CentOS 5.9,
which should be compatible with RHEL 5. It uses glibc 2.5, at least. I
don't have a good place to host it long-term, but would be happy to make it
available to you (or anyone else who's interested).

Aaron


On Fri, Apr 26, 2013 at 10:21 PM, Christopher Howard <
christopher.how...@frigidcode.com> wrote:

> Hi. I've got this work situation where I've got to do all my work on
> /ancient/ RHEL5 systems, with funky software configurations, and no root
> privileges. I wanted to install GHC in my local account, but the gnu
> libc version is so old (2.5!) that I can't even get the binary packages
> to install.
>
> I've had success installing some other simple functional languages (like
> CLISP) on these same systems, so I was wondering if there was perhaps
> another language very similar to Haskell (but presumably simpler) with a
> super portable compiler easily built from source, which I could try.
>
> I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick
> description didn't make it sound much more portable than GHC, but I
> guess I could try it if I heard some good reasons to think it would be
> more portable.
>
> --
> frigidcode.com
>
>
> ___
> 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] Markdown extension for Haddock as a GSoC project

[Mateusz Kowalczyk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/04/13 22:18, John MacFarlane wrote:
> I agree with Chris that it would be better to have a standard
> syntax for Haskell documentation.  Especially if the alternative is
> ten different markup languages. (Remember, all of these need to be
> supported in haddock, which is a basic piece of infrastructure.)
> 
> Here's a thought.  Instead of adding support for markdown, why not 
> enhance the existing haddock markup, making it more expressive, so
> that it could encode the same range of structural features as
> markdown?
> 
> If this were done, we could add a haddock writer to pandoc.  There
> is already a haddock reader in the development version, but a
> writer is difficult because haddock is so much less expressive than
> other formats. For example, unless I'm mistaken, it doesn't allow
> list items with multiple paragraphs or other block elements, or
> nested lists, or images, or blockquotes.
> 
> With a pandoc reader and writer for haddock, it would be easy to
> write your documentation in any format you choose (several variants
> of markdown, reST, textile, LaTeX, HTML, mediawiki) and produce
> equivalent haddock markup to paste into the source file.
> 
> It would also be easy to convert the documentation in your source
> file to any of the formats supported by pandoc.  So, you could
> generate a man page from your haddock markup, or a web page or blog
> entry, or a LaTeX document.
> 
> It seems to me that this would provide most of the advantages
> people who want a markdown extension for haddock are looking for.
> But it would not require taking sides in
> markdown/reST/asciidoc/creole wars, and it would not lead to the
> fragmentation of documentation formats in Haskell source code.  If
> the extensions to haddock markup were done carefully, it wouldn't
> even require a special PRAGMA, since all existing markup would have
> the same interpretation in the extended markup.
> 
> John
> 
> ___ Haskell-Cafe
> mailing list Haskell-Cafe@haskell.org 
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
I was under the impression that Markdown specifically was requested
due to its high popularity, ease of writing and being very readable to
a human. As you mention, currently Haddock is not expressive enough to
have a writer and would need extending first.

The advantages of extending Haddock this way are obvious: people write
the documentation in whatever they want and then use Pandoc to convert
it to a format they want to distribute in.

I'm unsure however whether such an extension is strictly a good thing:
what's more readable in source: Haddock with even more stuff tacked on
or Markdown with some already present Haddock constructs? There are a
fair few complaints about how unwieldy Haddock currently is and I'm
worried that extending it for the sake of (a really nice) ability of
conversion between formats with Pandoc might make it even more
unwieldy. Yes, you can write the docs in any of the billion formats
Pandoc supports and then convert it but many people simply want to
write docs right into their source files, right as they write actual
code without reliance on external tools -- something Markdown would
excel at if implemented.

So in the end, it just comes down to to what the community _really_
wants: more expressive core Haddock with ability to convert between
the formats or yet another Markdown flavour tacked onto Haddock as an
extension. It should be noted that this would probably end up serving
as a basis for the Pandoc module anyway so why duplicate the effort?
Pandoc already handles Markdown, as Christopher Howard pointed out.


Discussion on the topic will is most welcome. I am one of the students
interested in this project and I have already written a draft proposal
with the idea of implementing Markdown as an extension because that's
what it seems the community wanted in previous threads and
discussions. Is this _really_ what we want though?

Personally, I think the benefits of extending Haddock itself and
writing a writer module for Pandoc not only cover everything a new,
Haskell specific Markdown could do but provide even greater
flexibility. I'd also prefer to work on extending Haddock rather than
just tacking an extension to it that might not get used because some
people might dislike Markdown and would miss out on any new features.

The SoC proposal deadlines are on 3rd of May so it'd be great to hear
some opinions on this within the next 3 days or so, after which point
I will adjust my proposal accordingly, cross my fingers and hope for
the best ;)

- -- 
Mateusz K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRfFXcAAoJEM1mucMq2pqX8kkQAI+xRwMOVsq9T14bKLZ3Wiv7
citbn/hWDYSC8zpSnFIGW87On9/phBIhXaBA5F878mao0AAOMmN0S2ZfcTusaRjk
zXm2Dfof6ZKa38xTTjcoBuNWvv7mNwY8592krRPKden2if+II+2bXEd8kqSOX2zi
JibaTlXE1ud8sKiUB9hMlE+dcYm3J/G5FJqTFJv45kX2XeApni7J4/4M6ST0X/8z
bR

Re: [Haskell-cafe] text-icu on Windows

[Ryan Yates]

Hi John,

I just tried this out and if I copied all of the .dll files from the icu4c
bin folder into the same folder as the test icu.exe it works as expected.
 You can see what dlls are missing with the dependency walker program
http://www.dependencywalker.com/.  Perhaps with a mingw based build of
icu4c (the one I used said it was built with Visual Studio 10) you could
avoid this.

Ryan Yates

On Sat, Apr 27, 2013 at 4:56 PM, John MacFarlane  wrote:

> Hello café:
>
> I'd very much like to get text-icu working on Windows, as then I could ship
> pandoc binaries that do proper unicode collation in bibliographies.  But
> I'm
> having a devil of a time.  This may be due to my very limited Windows
> knowledge.  Any help would be appreciated, especially from someone who
> actually
> has text-icu working on Windows.
>
> I was able to cabal install text-icu without errors. I used
> --extra-lib-dirs
> and --extra-include-dirs to point to the lib and include directories in the
> 32-bit binary distribution of icu4c.  I'm using the latest Haskell
> Platform,
> 2012.4.0.0 with ghc 7.4.2.
>
> I was also able to build the following simple program that uses text-icu,
> by
> doing ghc --make icu.hs:
>
> ~~~
> -- icu.hs
> import Data.Text.ICU
> main = print $ Locale "tr-TR"
> ~~~
>
> No errors or warnings in either of these steps. But when I try to run the
> compiled program, icu.exe, I get no output at all. I expected to get a line
> with 'Locale "tr-TR"', but instead I get nothing -- not even an error or
> warning.
> This remains the case if I try
>
> ~~~
> main = do
>   print "Start"
>   print $ Locale "tr-TR"
>   print "Done"
> ~~~
>
> 'echo $?' yields False.
>
> Any ideas?
>
> John
>
> (I've posted a similar question to StackOverflow [1], but it hasn't gotten
> an answer yet there, so I thought I'd try here.)
>
> [1]:
> http://stackoverflow.com/questions/16127710/how-do-i-get-text-icu-working-on-windows
> )
>
>
> ___
> 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] text-icu on Windows

[Ryan Yates]

Also note that running in the console produces no error message, but
running by double-clicking from explorer does produce an error message that
specifies one of the missing dlls:

---
icu.exe - System Error
---
The program can't start because icuin51.dll is missing from your
computer. Try reinstalling the program to fix this problem.
---
OK
---


Ryan Yates

On Sat, Apr 27, 2013 at 7:53 PM, Ryan Yates  wrote:

> Hi John,
>
> I just tried this out and if I copied all of the .dll files from the icu4c
> bin folder into the same folder as the test icu.exe it works as expected.
>  You can see what dlls are missing with the dependency walker program
> http://www.dependencywalker.com/.  Perhaps with a mingw based build of
> icu4c (the one I used said it was built with Visual Studio 10) you could
> avoid this.
>
> Ryan Yates
>
>
> On Sat, Apr 27, 2013 at 4:56 PM, John MacFarlane  wrote:
>
>> Hello café:
>>
>> I'd very much like to get text-icu working on Windows, as then I could
>> ship
>> pandoc binaries that do proper unicode collation in bibliographies.  But
>> I'm
>> having a devil of a time.  This may be due to my very limited Windows
>> knowledge.  Any help would be appreciated, especially from someone who
>> actually
>> has text-icu working on Windows.
>>
>> I was able to cabal install text-icu without errors. I used
>> --extra-lib-dirs
>> and --extra-include-dirs to point to the lib and include directories in
>> the
>> 32-bit binary distribution of icu4c.  I'm using the latest Haskell
>> Platform,
>> 2012.4.0.0 with ghc 7.4.2.
>>
>> I was also able to build the following simple program that uses text-icu,
>> by
>> doing ghc --make icu.hs:
>>
>> ~~~
>> -- icu.hs
>> import Data.Text.ICU
>> main = print $ Locale "tr-TR"
>> ~~~
>>
>> No errors or warnings in either of these steps. But when I try to run the
>> compiled program, icu.exe, I get no output at all. I expected to get a
>> line
>> with 'Locale "tr-TR"', but instead I get nothing -- not even an error or
>> warning.
>> This remains the case if I try
>>
>> ~~~
>> main = do
>>   print "Start"
>>   print $ Locale "tr-TR"
>>   print "Done"
>> ~~~
>>
>> 'echo $?' yields False.
>>
>> Any ideas?
>>
>> John
>>
>> (I've posted a similar question to StackOverflow [1], but it hasn't gotten
>> an answer yet there, so I thought I'd try here.)
>>
>> [1]:
>> http://stackoverflow.com/questions/16127710/how-do-i-get-text-icu-working-on-windows
>> )
>>
>>
>> ___
>> 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] text-icu on Windows

[John MacFarlane]

Ryan,

Many thanks for your reply.  I was assuming ghc would statically link
against the library files instead of relying on the dll's.  I will see
if I can build the library from source under mingw.  An alternative
would be to distribute the needed dlls with the binary.

John

+++ Ryan Yates [Apr 27 13 19:53 ]:
>Hi John,
> 
>I just tried this out and if I copied all of the .dll files from the
>icu4c bin folder into the same folder as the test icu.exe it works as
>expected. You can see what dlls are missing with the dependency walker
>program[1]http://www.dependencywalker.com/. Perhaps with a mingw based
>build of icu4c (the one I used said it was built with Visual Studio 10)
>you could avoid this.
> 
>Ryan Yates
>On Sat, Apr 27, 2013 at 4:56 PM, John MacFarlane <[2]j...@berkeley.edu>
>wrote:
> 
>  Hello caf:
>  I'd very much like to get text-icu working on Windows, as then I
>  could ship
>  pandoc binaries that do proper unicode collation in bibliographies.
>  But I'm
>  having a devil of a time. This may be due to my very limited Windows
>  knowledge. Any help would be appreciated, especially from someone
>  who actually
>  has text-icu working on Windows.
>  I was able to cabal install text-icu without errors. I used
>  --extra-lib-dirs
>  and --extra-include-dirs to point to the lib and include directories
>  in the
>  32-bit binary distribution of icu4c. I'm using the latest Haskell
>  Platform,
>  2012.4.0.0 with ghc 7.4.2.
>  I was also able to build the following simple program that uses
>  text-icu, by
>  doing ghc --make icu.hs:
>  ~~~
>  -- icu.hs
>  import Data.Text.ICU
>  main = print $ Locale "tr-TR"
>  ~~~
>  No errors or warnings in either of these steps. But when I try to
>  run the
>  compiled program, icu.exe, I get no output at all. I expected to get
>  a line
>  with 'Locale "tr-TR"', but instead I get nothing -- not even an
>  error or warning.
>  This remains the case if I try
>  ~~~
>  main = do
>  print "Start"
>  print $ Locale "tr-TR"
>  print "Done"
>  ~~~
>  'echo $?' yields False.
>  Any ideas?
>  John
>  (I've posted a similar question to StackOverflow [1], but it hasn't
>  gotten
>  an answer yet there, so I thought I'd try here.)
>  [1]:
>  [3]http://stackoverflow.com/questions/16127710/how-do-i-get-text-icu
>  -working-on-windows)
>  ___
>  Haskell-Cafe mailing list
>  [4]Haskell-Cafe@haskell.org
>  [5]http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> References
> 
>1. http://www.dependencywalker.com/
>2. mailto:j...@berkeley.edu
>3. 
> http://stackoverflow.com/questions/16127710/how-do-i-get-text-icu-working-on-windows
>4. mailto:Haskell-Cafe@haskell.org
>5. 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