Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language
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 http://www.haskell.org/nhc98/. 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)
Hi AntC, Thanks for the feedback! On 26/04/13 09:55, AntC wrote: Adam Gundry adam.gundry at 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 someone 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)
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)
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 http://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
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 agocor...@gmail.com 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 byor...@seas.upenn.edu 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
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
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 fuuze...@fuuzetsu.co.uk 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 Haskell since 2008 judging by the size of the last thread,
Re: [Haskell-cafe] Diving into the records swamp (possible GSoC project)
Johan Tibell johan.tibell at 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)
Johan Tibell johan.tibell at 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
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
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.sos, which break project builds.
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 *.sos 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.sos, which break project builds.
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 *.sos 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.sos, which break project builds.
On Sat, Apr 27, 2013 at 11:47 AM, David Banas capn.fre...@gmail.com 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
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 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] Looking for portable Haskell or Haskell like language
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
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
On Sat, Apr 27, 2013 at 12:55 PM, Corentin Dupont corentin.dup...@gmail.com 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
-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
On Sat, Apr 27, 2013 at 2:23 AM, Alistair Bayley alist...@abayley.orgwrote: 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
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
Re: [Haskell-cafe] Display an inferred type during compilation
В письме от 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
Oops, forgot to reply all. -- Forwarded message -- From: Chris Smith cdsm...@gmail.com Date: Apr 27, 2013 12:04 PM Subject: Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project To: Bryan O'Sullivan b...@serpentine.com 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 b...@serpentine.com wrote: On Sat, Apr 27, 2013 at 2:23 AM, Alistair Bayley alist...@abayley.orgwrote: 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
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 sir...@khandkar.netwrote: 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
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
Hi, On 27 April 2013 10:07, Alberto G. Corona agocor...@gmail.com 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
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 paratribulati...@free.fr 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
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: https://github.com/bitonic/kant/blob/master/src/Data/LGraph.hs. 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
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 alist...@abayley.org 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
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
On Sat, Apr 27, 2013 at 1:47 PM, Ben midfi...@gmail.com 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
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
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
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 paratribulati...@free.fr 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
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
-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
Re: [Haskell-cafe] text-icu on Windows
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 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]: 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
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 fryguy...@gmail.com 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 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]: 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, 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
