[Haskell-cafe] how to change a process name

[山本和彦]

Hello,

I would like to know how to change a process name in Haskell. When we
are programming in C, we can change it by overriding argv on Unix.
But I cannot find the same way to do in Haskell. Can anyone suggest
how in Haskell? I'm not talking about the result of
System.Environment.getProgName but talking about the process name
which we can see by the "ps" command.

Thanks.

--Kazu

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

[Haskell-cafe] GHC/ARM registerised port

[Karel Gardas]

Hello,

Stephen Blackheath, David Terei and me are working together on ARM 
registerised port of GHC. The port is using LLVM as a code generator and 
is kind of working already. (GHCi support still missing)


If you are curious and would like to try the code, please read last two 
paragraphs containing instructions what to do here[1]. This blog[2] is 
my personal attempt to document the project at least from my point of 
view. If you would just like to go straight to the code for code review 
or to follow progress directly, then github.com repo[3] is the right 
link for you.


Thanks for testing, bug reporting and/or patches!

Karel

[1]: 
http://ghcarm.wordpress.com/2011/07/06/armv7-thumb-vfpv3-support-and-github-com/

[2]: http://ghcarm.wordpress.com/
[3]: https://github.com/kgardas/ghc

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

Re: [Haskell-cafe] [Haskell-Cafe] Constructive Probability Theory and RandProc's σ-algebras

[David Banas]

Hi Edward,

Thanks for your interest in `RandProc`.

I'm very interested in continuing this conversation with you, but I think I'd 
better read the papers you recommend, below first, so that I can do so 
intelligently. ;-)

In the mean time, I do have these rather imprecise thoughts:
(Please, see in-line below.)

Looking forward to much more conversation with you (and others),
-db

On Jul 3, 2011, at 9:35 AM, Edward Kmett wrote:

> On Sun, Jul 3, 2011 at 11:05 AM, David Banas  wrote:
> v0.4 of `RandProc` has just been posted to Hackage:
> http://hackage.haskell.org/package/randproc
> 
> [NB: I transfered this discussion from haskell to haskell-cafe, and started 
> another thread]
> 
> I have been spending some time exploring constructive probability theory in 
> Haskell, and I have a couple of observations about working with random 
> processes in a constructive setting:
> 
> Necessarily because you are working in Haskell, a constructive setting, your 
> σ-algebras can't be actual σ-algebras! =/ 
Yes, I realize I've taken some rather arrogant liberty in calling my function 
`checkSigma`, for instance.

> 
> Notably, they aren't closed under countable union/intersection/complement, 
> but merely finite union/intersection/complement, and Gray and Davisson's 
> horrified objections from the bottom of page 39 on Random Processes applies:
> 
> If a class of sets is only a field rather than a σ-field, that is, if it 
> satisfies only (3.1) and (3.2), then there is no guarantee that the class 
> will contain all limits of sets. Hence, for example knowing that a class of 
> sets contains all half-open intervals of the form (a,b] for a and b finite 
> does not ensure that it will also contain points or singleton sets! In fact, 
> it is straightforward to show that the collection of all such half-open 
> intervals together with the complements of such sets and all finite unions of 
> the intervals and complements forms a field. The singleton sets, however, are 
> not in the field. (See exercise 3.4)
>  
> Thus if we tried to construct a probability theory based on only a field, we 
> might have probabilites defined for events such as (a,b) meaning "the output 
> voltage of a measurement is between a and b" yet not have probabilities 
> defined for a singleton set {a} meaning "the output voltage is exactly a." By 
> requiring that the event space be a σ-field instead of only a field, we are 
> assured that all such limits are indeed events.
> 
So, my hope was that, by providing for a `Point` sample, in addition to 
`Range`, I'd gotten around this issue, although I confess that I really haven't 
thought it through.

> This limitation, while from some perspective annoying is intrinsic to 
> tackling the problem intuitionistically. Practically, this means you need to 
> be careful when rederiving most of the later results, because you are limited 
> to what you can prove in a constructive measure theory.
> 
> In particular the approaches of YK Chan, Brian Weatherson, and Glenn Shafer 
> to intuitionistic probability theory are probably appropriate reading.
I will read these. Thanks for the references!

> 
> Personally, I don't think this is all that bad, we get some nice properties 
> by being in a constructive setting. Weatherson noted that your measure 
> becomes additive without problems from Dutch book arguments in an 
> intuitionistic setting, because P(A v not A) is not necessarily 1! 
I'm enforcing this condition in my `checkProbMeas` function; should I relax 
this?

> 
> You may recall that recall that additivity would imply that P(A v B) = P(A) + 
> P(B), given that A and B are disjoint, but that it tends to fall apart in 
> classical probability theory.
I've been assuming the above true, in general. I didn't realize that it was 
"fragile". Could you point me to a reference on this, please?

> 
> Intuitionistically, however, this is fine. That is to say that if you placed 
> bets that payed out with market rate interest at a rational booking agent on 
> both whether P = NP and P /= NP, it isn't just as good as having placed a bet 
> on truth, because intuitionistically it is possible that neither of those 
> bets may ever pay out, but in a classical setting P (P = NP v P /= NP) = 
> P(True) = 1, so we lose additivity to gain the excluded middle.
I'm sorry, but I'm lost here. Is there a simple example, which illustrates this?

> 
> The cost of additivity is giving up or refining a lot of results from that 
> text that talk about the limit of a random process. That and that the 
> "σ-fields" in question are mere fields. ;)
So, as I was writing this module and realizing that I wasn't really testing 
sigma fields, but only fields, I asked myself, "How might Haskell be used to 
prove, in a finite amount of time, some property of a countably infinite set of 
samples?" Obviously, it can't be done in the straight forward fashion, but is 
there some way to specify properties of the countably infinite set, as opposed 
to

Re: [Haskell-cafe] NLP libraries and tools?

[wren ng thornton]

On 7/6/11 8:46 PM, Richard O'Keefe wrote:
>> I've been working over the last year+ on an optimized HMM-based POS
>> tagger/supertagger with online tagging and anytime n-best tagging. I'm
>> planning to release it this summer (i.e., by the end of August), though
>> there are a few things I'd like to polish up before doing so. In
>> particular, I want to make the package less monolithic. When I release it
>> I'll make announcements here and on the nlp@ list.
>
> One of the issues I've had with a POS tagger I've been using is that it
> makes some really stupid decisions which can be patched up with a few
> simple rules, but since it's distributed as a .jar file I cannot add
> those rules.

How horrid. I assume the problem is really that the trained model is in
the jar and you can't do your own training? Or is this a Brill-like tagger
where you really mean to add new rules?

If an HMM-based tagger is amenable, you could try switching to Daniël de
Kok's Java port of TnT:

https://github.com/danieldk/jitar


The tagger I'm working on does support being hooked up to a Java client
(i.e., consumer of tagging info), but it's fairly ugly due to Java's
refusal to believe in IPC.

-- 
Live well,
~wren


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

Re: [Haskell-cafe] NLP libraries and tools?

[wren ng thornton]

On 7/6/11 6:45 PM, Aleksandar Dimitrov wrote:
> One hint, if you ever find yourself reading in quantitative linguistic
data with
> Haskell: forget lazy IO. Forget strict IO, except your documents aren't
ever
> bigger than a few hundred megs. In case you're not keeping the whole
document in
> memory, but you're keeping some stuff in memory, never keep it around in
> ByteStrings, but use Text or SmallString (ByteStrings will invariably
leak space
> in this scenario.) Learn how to use Iteratees and use them judiciously.

I definitely agree with the iteratees comment, but I'm curious about the
leaks you mention. I haven't run into leakiness issues (that I'm aware of)
in my use of ByteStrings for NLP.

-- 
Live well,
~wren


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

Re: [Haskell-cafe] NLP libraries and tools?

[wren ng thornton]

On 7/6/11 5:58 PM, Aleksandar Dimitrov wrote:
> On Wed, Jul 06, 2011 at 09:32:27AM -0700, wren ng thornton wrote:
>> On 7/6/11 9:27 AM, Dmitri O.Kondratiev wrote:
>>> Hi,
>>> Continuing my search of Haskell NLP tools and libs, I wonder if the
>>> following Haskell libraries exist (googling them does not help):
>>> 1) End of Sentence (EOS) Detection. Break text into a collection of
>>> meaningful sentences.
>>
>> Depending on how you mean, this is either fairly trivial (for English) or
>> an ill-defined problem. For things like determining whether the "."
>> character is intended as a full stop vs part of an abbreviation; that's
>> trivial.
>
> I disagree. It's not exactly trivial in the sense that it is solved. It is
> trivial in the sense that, usually, one would use a list of know
abbreviations
> and just compare. This, however, just says that the most common approach is
> trivial, not that the problem is.

Perhaps. I recall David Yarowsky suggesting it was considered solved (for
English, as I qualified earlier).

The solution I use is just to look at a window around the point and run a
standard feature-based machine learning algorithm over it[1]. Memorizing
known abbreviations is actually quite fragile, for reasons you mention.
This approach will give you accuracy in the high 90s, though I forget the
exact numbers.


[1] With obvious features like whether the following word is capitalized,
whether the preceding word is capitalized, length of the preceding word,
whether there's another period after the next word,...


>> But for general sentence breaking, how do you intend to deal with
>> quotations? What about when news articles quote someone uttering a few
>> sentences before the end-quote marker? So far as I'm aware, there's no
>> satisfactory definition of what the solution should be in all reasonable
>> cases. A "sentence" isn't really very well-defined in practice.
>
> As long as you have one routine and stick to it, you don't need a formal
> definition every linguist will agree on. Computational Linguists (and their
> tools,) more often than not, just need a dependable solution, not a
correct one.

But the problem is that what constitutes an appropriate solution for
computational needs is still very ill-defined. For example, the treatment
of quotations will depend on the grammar theory used in the tagger,
parser, translator, etc. The quality of output is often quite susceptible
to EOS being meaningfully[2] distributed. Thus, what constitutes a
"dependable" solution often varies depending on the task in question.[3]

Also, a lot of the tools in this area assume there's some sort of
punctuation marking the end of sentences, even if it's unreliable as an
EOS indicator. That works well enough for languages with European-like
orthographic traditions, but it falls apart quite rapidly when moving to
East Asian languages (e.g., Burmese, Thai,...). And languages like
Japanese or Arabic can have "sentences" that go on forever, but are best
handled by chunking them into clauses.


[2] In a statistical sense, relative to the structure of the model.

[3] Personally, I think the idea of having a single EOS type is the bulk
of the problem. If we allowed for different kinds of EOS in grammars then
the upstream tools could handle sentence fragments better, which would
make it easier to make fragment breaking reliable.


>> I've been working over the last year+ on an optimized HMM-based POS
>> tagger/supertagger with online tagging and anytime n-best tagging. I'm
>> planning to release it this summer (i.e., by the end of August), though
>> there are a few things I'd like to polish up before doing so. In
>> particular, I want to make the package less monolithic. When I release it
>> I'll make announcements here and on the nlp@ list.
>
> I'm very interested in your progress! Keep us posted :-)

Will do :)

-- 
Live well,
~wren



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

[Haskell-cafe] Haskell Weekly News: Issue 189

[Daniel Santa Cruz]

   Welcome to issue 189 of the HWN, a newsletter covering developments in
   the Haskell community during the week of June 26 to July 2, 2011.

   It seems that it was a pretty quiet week in the mailing list. There
   were no significant announcements made, and the number of threads was
   low by comparison. Hope everyone is having a great week!

   You can find the HTML version at:
   
http://contemplatecode.blogspot.com/2011/07/haskell-weekly-news-issue-189.html

Quotes of the Week

   * iwtu: [#haskell] is a good channel. Really. People are helpful and
 don't deserve killing or eating

   * [Cale] Finite dimensional vector spaces over a field F are
 algebras for the monad of F-linear combinations of elements of a
 set.
 [ivanm] h _now_ I get you!

   * [quicksilver] C++ templates can embed arbitrary computation at
 compile time
 [quicksilver] that alone tells you something about the
 complexity of the compiler
 [edwardk] yeah. they were accidentally turing complete. (whoops!) ;)
 [quicksilver] edwardk: OOPS I ACCIDENTALLY THE WHOLE TARPIT

   * bos: other companies use expensive firewalls and crypto hardware to
 protect their intellectual secrets. edwardk uses category theory!

   * ManuelChakravarty: After all, you can import any C function with a
 pure type which also allows you to wreak arbitrary havoc. We enable
 the user to disguise arbitrary machine code as a Haskell function
 of essentially arbitrary type. In comparison, `unsafePerformIO'
 seems angelic.

   * NihilistDandy: The best part of Haskell is that 80% of module names
 can be turned into clever blog titles.

   * AlanPerlis: We will never run out of things to program as long as
 there is a single program around.

Top Reddit Stories

   * Here be dragons: advances in problems you didn't even know you had
 Domain: serpentine.com, Score: 78, Comments: 8
 On Reddit: http://goo.gl/4RC1W
 Original: http://goo.gl/Pc0nd

   * A Gentle Introduction to Category Theory
 Domain: citeseerx.ist.psu.edu, Score: 33, Comments: 25
 On Reddit: http://goo.gl/nb6yJ
 Original: http://goo.gl/ItUef

   * Step-wise evaluation of simple Haskell code to hpaste (via Stepeval)
 Domain: chrisdone.com, Score: 33, Comments: 4
 On Reddit: http://goo.gl/VaPXN
 Original: http://goo.gl/NhWLC

   * Debugging compilers with optimization fuel
 Domain: blog.ezyang.com, Score: 30, Comments: 1
 On Reddit: http://goo.gl/uUEct
 Original: http://goo.gl/tSk0e

   * Fully-Funded PhD Studentship in Functional Programming
 Domain: cs.nott.ac.uk, Score: 23, Comments: 5
 On Reddit: http://goo.gl/Xa231
 Original: http://goo.gl/zIvZe

   * Using Snap in Production!
 Domain: cdsmith.wordpress.com, Score: 21, Comments: 20
 On Reddit: http://goo.gl/KgKxY
 Original: http://goo.gl/kZ5hp

   * Monads from Comonads
 Domain: comonad.com, Score: 19, Comments: 1
 On Reddit: http://goo.gl/1yxKe
 Original: http://goo.gl/R9PyX

   * Haskell plugin for IntelliJ IDEA
 Domain: code.google.com, Score: 18, Comments: 7
 On Reddit: http://goo.gl/DUiWy
 Original: http://goo.gl/H1goQ

   * Barnes & Hut simulator in Haskell!
 Domain: mortenlysgaard.com, Score: 16, Comments: 4
 On Reddit: http://goo.gl/qTKlT
 Original: http://goo.gl/a5EAb

   * How do you deal with "long" function bodies?
 Domain: self.haskell, Score: 12, Comments: 29
 On Reddit: http://goo.gl/sRQy0

Top StackOverflow Questions

   * Bentley-Ottmann Algorithm in Haskell?
 votes: 31, answers: 1
 Read on SO: http://goo.gl/wyJNY

   * Haskell approaches to error handling
 votes: 22, answers: 3
 Read on SO: http://goo.gl/I2dVG

   * is point free code more efficient, or just terser?
 votes: 16, answers: 2
 Read on SO: http://goo.gl/em3uu

   * Are distinct open and close delimiters syntactically necessary?
 votes: 9, answers: 7
 Read on SO: http://goo.gl/roNWE

   * How to persist large data for efficient deserialization in Haskell
 votes: 8, answers: 1
 Read on SO: http://goo.gl/ixalr

   * Building with runtime flags using cabal and ghc
 votes: 6, answers: 1
 Read on SO: http://goo.gl/UyrBs

About the Haskell Weekly News

   To help create new editions of this newsletter, please send stories to
   dstc...@gmail.com.

   Until next time,
   Daniel Santa Cruz

References

 1. 
http://www.reddit.com/r/haskell/comments/ic3qx/here_be_dragons_advances_in_problems_you_didnt/
 2. 
http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/
 3. 
http://www.reddit.com/r/haskell/comments/icogq/a_gentle_introduction_to_category_theory/
 4. 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.78.7317&rep=rep1&type=pdf
 5. 
http://www.reddit.com/r/haskell/comments/iezj6/stepwise_evaluation_of_simple_haskell_code_to/
 6. http://chrisdone.com/posts/2011-07-02-stepeval-hpaste.h

Re: [Haskell-cafe] NLP libraries and tools?

[Richard O'Keefe]

On 7/07/2011, at 7:04 AM, Dmitri O.Kondratiev wrote:
> I am looking for Haskell implementation of sentence tokenizer such as 
> described by Tibor Kiss and Jan Strunk’s in “Unsupervised Multilingual 
> Sentence Boundary Detection”,  which is implemented in NLTK:

That method is multilingual but relies on the text being written using
fairly modern Western conventions, and tackles the problem of "too many
dots" and not knowing which are abbreviation points and which full stops.

I don't suppose anyone knows something that might help with the problem
of too few dots?  Run on sentences are one example.
> 
> I've been working over the last year+ on an optimized HMM-based POS
> tagger/supertagger with online tagging and anytime n-best tagging. I'm
> planning to release it this summer (i.e., by the end of August), though
> there are a few things I'd like to polish up before doing so. In
> particular, I want to make the package less monolithic. When I release it
> I'll make announcements here and on the nlp@ list.

One of the issues I've had with a POS tagger I've been using is that it
makes some really stupid decisions which can be patched up with a few
simple rules, but since it's distributed as a .jar file I cannot add
those rules.



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

Re: [Haskell-cafe] NLP libraries and tools?

[Aleksandar Dimitrov]

On Wed, Jul 06, 2011 at 03:14:07PM -0700, Rogan Creswick wrote:
> Have you used that particular combination yet? I'd like to know the
> details of how you hooked everything together if that's something you
> can share.  (We're working on a similar Frankenstein at the moment.)

These Frankensteins, as your so dearly call them, are always very task-specific.
Here's a setup I've used:

- Take some sort of corpus you want to work with, and annotate it with, say,
  Java tools. This will probably require you to massage the input corpus into
  something your tools can read, and then call the tools to process it
- Let your Java stuff write everything to disk in a format that you can easily
  read in with Haskell. If your annotations are not interleaving, you're lucky,
  because you can probably just use a word-per-line with columns for markup
  format. That's trivial to read in with Haskell. More complicated stuff should
  probably be handled in XML-fashion. I like HXT for reading in XML, but it's
  slow (as are its competitors. Although it's been a while since I've used it;
  maybe it supports Text or ByteStrings by now.)
- Advanced mode: instead of dumping to files, use named pipes or TCP sockets to
  transfer data. Good luck

Shell scripting comes in *very* handy here, in order to automate this process.

Now, everything I've done so far is only *research*, no finished product that
the end user wants to poke on their desktop and have it work interactively. For
that, it might be useful to have some sort of standing server architecture: you
have multiple annotation servers (one that runs in Java, one that runs in
Haskell) and have them communicate the data.

At this point, the benefits might be outweighed by the drawbacks. My love for
Haskell only goes that far.

One hint, if you ever find yourself reading in quantitative linguistic data with
Haskell: forget lazy IO. Forget strict IO, except your documents aren't ever
bigger than a few hundred megs. In case you're not keeping the whole document in
memory, but you're keeping some stuff in memory, never keep it around in
ByteStrings, but use Text or SmallString (ByteStrings will invariably leak space
in this scenario.) Learn how to use Iteratees and use them judiciously.

Keep in touch on the Haskell NLP list :-)
Regards,
Aleks


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

Re: [Haskell-cafe] NLP libraries and tools?

[Rogan Creswick]

On Wed, Jul 6, 2011 at 3:03 PM, Aleksandar Dimitrov
 wrote:
>
> So you'd use, say, UIMA+OpenNLP to do sentence boundaries, tokens, tags,
> named-entities whatnot, then spit out some annotated format, read it in with
> Haskell, and do the logic/magic there.

Have you used that particular combination yet? I'd like to know the
details of how you hooked everything together if that's something you
can share.  (We're working on a similar Frankenstein at the moment.)

--Rogan

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

Re: [Haskell-cafe] NLP libraries and tools?

[Aleksandar Dimitrov]

On Wed, Jul 06, 2011 at 11:04:30PM +0400, Dmitri O.Kondratiev wrote:
> On Wed, Jul 6, 2011 at 8:32 PM, wren ng thornton  wrote:
> 
> > On 7/6/11 9:27 AM, Dmitri O.Kondratiev wrote:
> > > Hi,
> > > Continuing my search of Haskell NLP tools and libs, I wonder if the
> > > following Haskell libraries exist (googling them does not help):
> > > 1) End of Sentence (EOS) Detection. Break text into a collection of
> > > meaningful sentences.
> >
> > Depending on how you mean, this is either fairly trivial (for English) or
> > an ill-defined problem. For things like determining whether the "."
> > character is intended as a full stop vs part of an abbreviation; that's
> > trivial.
> >
> > But for general sentence breaking, how do you intend to deal with
> > quotations? What about when news articles quote someone uttering a few
> > sentences before the end-quote marker? So far as I'm aware, there's no
> > satisfactory definition of what the solution should be in all reasonable
> > cases. A "sentence" isn't really very well-defined in practice.
> >
> 
> I am looking for Haskell implementation of sentence tokenizer such as
> described by Tibor Kiss and Jan Strunk’s in “Unsupervised Multilingual
> Sentence Boundary Detection”,  which is implemented in NLTK:
> 
> http://nltk.googlecode.com/svn/trunk/doc/api/nltk.tokenize.punkt-module.html
> 
> 
> > > 2) Part-of-Speech (POS) Tagging. Assign part-of-speech information to
> > each
> > > token.
> >
> > There are numerous approaches to this problem; do you care about the
> > solution, or will any one of them suffice?
> >
> > I've been working over the last year+ on an optimized HMM-based POS
> > tagger/supertagger with online tagging and anytime n-best tagging. I'm
> > planning to release it this summer (i.e., by the end of August), though
> > there are a few things I'd like to polish up before doing so. In
> > particular, I want to make the package less monolithic. When I release it
> > I'll make announcements here and on the nlp@ list.
> 
> 
> I am looking for some already working POS tagging framework that can be
> customized for different pidgin languages.
> 
> 
> > > 3) Chunking. Analyze each tagged token within a sentence and assemble
> > > compound tokens that express logical concepts. Define a custom grammar.
> > >
> > > 4) Extraction. Analyze each chunk and further tag the chunks as named
> > > entities, such as people, organizations, locations, etc.
> > >
> > > Any ideas where to look for similar Haskell libraries?
> >
> > I don't know of any work in these areas in Haskell (though I'd love to
> > hear about it). You should try asking on the nlp@ list where the other
> > linguists and NLPers are more likely to see it.
> >
> >
> I will, though n...@projects.haskell.org. looks very quiet...

Quiet, yes, but, hey, we all start out… nevermind, humans start out loud.

Well anyhow, it's quiet, but it's gotta start somewhere. I wouldn't hold my
breath for a full-scale Haskell-native solution to your problem just yet though.

Here's what I'm doing: I usually use external programs to do the heavy lifting
for which there aren't Haskell programs. Then I use Haskell (where applicable)
to do the logic, and shell scripts to glue together everything.

So you'd use, say, UIMA+OpenNLP to do sentence boundaries, tokens, tags,
named-entities whatnot, then spit out some annotated format, read it in with
Haskell, and do the logic/magic there.

Complicated, yes. But it gets me around having to code too much in Java. That's
a gain if I've ever seen one.

Regards,
Aleks


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

Re: [Haskell-cafe] NLP libraries and tools?

[Aleksandar Dimitrov]

On Wed, Jul 06, 2011 at 09:32:27AM -0700, wren ng thornton wrote:
> On 7/6/11 9:27 AM, Dmitri O.Kondratiev wrote:
> > Hi,
> > Continuing my search of Haskell NLP tools and libs, I wonder if the
> > following Haskell libraries exist (googling them does not help):
> > 1) End of Sentence (EOS) Detection. Break text into a collection of
> > meaningful sentences.
> 
> Depending on how you mean, this is either fairly trivial (for English) or
> an ill-defined problem. For things like determining whether the "."
> character is intended as a full stop vs part of an abbreviation; that's
> trivial.

I disagree. It's not exactly trivial in the sense that it is solved. It is
trivial in the sense that, usually, one would use a list of know abbreviations
and just compare. This, however, just says that the most common approach is
trivial, not that the problem is.

There are cases where, for example, an abbreviation and a full stop will
coincide. In these cases, you'll often need full-blown parsing or at least a
well-trained maxent classifier.

There are other problems: ordinals, acronyms which themselves also have periods
in them, weird names (like Yahoo!) and initials, to name a few. This is only for
English and similar languages, mind you.

> But for general sentence breaking, how do you intend to deal with
> quotations? What about when news articles quote someone uttering a few
> sentences before the end-quote marker? So far as I'm aware, there's no
> satisfactory definition of what the solution should be in all reasonable
> cases. A "sentence" isn't really very well-defined in practice.

As long as you have one routine and stick to it, you don't need a formal
definition every linguist will agree on. Computational Linguists (and their
tools,) more often than not, just need a dependable solution, not a correct one.

> > 2) Part-of-Speech (POS) Tagging. Assign part-of-speech information to each
> > token.
> 
> There are numerous approaches to this problem; do you care about the
> solution, or will any one of them suffice?
> 
> I've been working over the last year+ on an optimized HMM-based POS
> tagger/supertagger with online tagging and anytime n-best tagging. I'm
> planning to release it this summer (i.e., by the end of August), though
> there are a few things I'd like to polish up before doing so. In
> particular, I want to make the package less monolithic. When I release it
> I'll make announcements here and on the nlp@ list.

I'm very interested in your progress! Keep us posted :-)

Regards,
Aleks


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

Re: [Haskell-cafe] unbuffered raw keyboard input on Windows

[David Barbour]

You could try the SDL package to support user input.

2011/7/6 José Romildo Malaquias 

> Hello.
>
> I want to write a Haskell console application (a game) in ghc where the
> user will interact using the keyboard. I need to read the keys as soon
> as they are typed and without echoing to the console.
>
> Although Haskell provides this capability in the standard libraries
> (using hSetEcho and hSetBuffering from System.IO), it does not work on
> Windows due to a bug (http://hackage.haskell.org/trac/ghc/ticket/2189).
>
> I have tried installing packages like vty, hscurses, and ncurses, but
> they did not install on Windows.
>
> Which workarounds are available for that?
>
> Romildo
>
> ___
> 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] unbuffered raw keyboard input on Windows

[José Romildo Malaquias]

Hello.

I want to write a Haskell console application (a game) in ghc where the
user will interact using the keyboard. I need to read the keys as soon
as they are typed and without echoing to the console.

Although Haskell provides this capability in the standard libraries
(using hSetEcho and hSetBuffering from System.IO), it does not work on
Windows due to a bug (http://hackage.haskell.org/trac/ghc/ticket/2189).

I have tried installing packages like vty, hscurses, and ncurses, but
they did not install on Windows.

Which workarounds are available for that?

Romildo

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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow  wrote:
> On 06/07/11 17:14, David Barbour wrote:
>>
>>
>> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow > > wrote:
>>
>>    On 06/07/2011 15:42, Jason Dagit wrote:
>>
>>        How can I make sure my library works from GHC (with arbitrary
>>
>>        user threads) and from GHCI?
>>
>>    Right, but usually the way this is implemented is with some
>>    cooperation from the main thread. [...] So you can't just do this
>>    from a library - the main thread has to be in on the game. I suppose
>>    you might wonder whether the GHC RTS could implement runInMainThread
>>    by preempting the main thread and running some different code on it.
>>      [...]
>>
>>
>> I think the real issue is that GHC has a different behavior than GHCi,
>> and I think this causes a lot of difficulties for people working on GUI
>> and other FFI integration.
>>
>> Perhaps it would be possible to reverse the default roles of threads in
>> GHCi: the main thread run user commands, and a second bound thread will
>> process user interrupts and such.
>
> Well, GHCi has no main, so it doesn't seem surprising (to me) that it's
> different.
>
> However, if -fno-ghci-sandbox doesn't have any drawbacks we could just make
> it the default.  I don't actually remember why we run each statement in a
> new thread, I think it just seemed like a prudent thing to do.

+1 for this change.  I'm not sure how we would know if there are drawbacks.

Jason

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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[David Barbour]

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow  wrote:
>
> I think the real issue is that GHC has a different behavior than GHCi,
>> and I think this causes a lot of difficulties for people working on GUI
>> and other FFI integration.
>>
>

Well, GHCi has no main, so it doesn't seem surprising (to me) that it's
> different.
>

If we start GHCi then run the function called 'main', we should ideally get
the same behavior as building with GHC then executing the process.
Variations make exploratory programming with GHCi very difficult, especially
with concurrent haskell.


> However, if -fno-ghci-sandbox doesn't have any drawbacks we could just make
> it the default.


That sounds good, too. I think it worth looking up what the drawbacks will
be. It might be an acceptable trade even if there are minor drawbacks. I
would imagine the main benefit of the sandbox is ability to interrupt a task
- i.e. job control from the GHCi shell.

Regards,

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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/11 17:19, Gábor Lehel wrote:

On Wed, Jul 6, 2011 at 5:24 PM, Jason Dagit  wrote:

On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:

On 06/07/2011 15:42, Jason Dagit wrote:


On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlowwrote:


On 06/07/2011 07:37, Jason Dagit wrote:


On Jul 5, 2011 1:04 PM, "Jason Dagit"mailto:dag...@gmail.com>>wrote:
  >
  >On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynaghmailto:ig...@earth.li>>wrote:
  >>On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
  >>>
  >>>In GHCi it's a different matter, because the main thread is
running
  >>>GHCi itself, and all the expressions/statements typed at the
prompt
  >>>are run in forkIO'd threads (a new one for each statement, in
fact).
  >>>If you want a way to run command-line operations in the main
thread,
  >>>please submit a feature request.  I'm not sure it can be done,
but
  >>>I'll look into it.
  >>
  >>We already have a way: -fno-ghci-sandbox
  >
  >I've removed all my explicit attempts to forkIO/forkOS and passed
the
  >command line flag you mention.  I just tried this but it doesn't
  >change the behavior in my example.

I tried it again and discovered that due to an argument parsing bug in
cabal-dev that the flag was not passed correctly. I explicitly passed it
and verified that it works. Thanks for the workaround. By the way, I did
look at the user guide for options like this and didn't see it. Which
part of the manual is it in?

Can I still make a feature request for a function to make code run on
the original thread? My reasoning is that the code which needs to run on
the main thread may appear in a library in which case the developer has
no control over how ghc is invoked.


I'm not sure how that would work.  The programmer is in control of what
the
main thread does, not GHC.  So in order to implement some mechanism to
run
code on the main thread, we would need some cooperation from the main
thread
itself.  For example, in gtk2hs the main thread runs an event handler
loop
which occasionally checks a queue for requests from other threads (at
least,
I think that's how it works).


What I'm wrestling with is the following.  Say I make a GUI library.
As author of the GUI library I discover issues like this where the
library code needs to execute on the "main" thread.  Users of the
library expect the typical Haskell environment where you can't tell
the difference between threads, and you fork at will.  How can I make
sure my library works from GHC (with arbitrary user threads) and from
GHCI?

As John Lato points out in his email lots of people bump into this
without realizing it and don't understand what the problem is.  We can
try our best to educate everyone, but I have this sense that we could
also do a better job of providing primitives to make it so that code
will run on the main thread regardless of how people invoke the
library.

In my specific case (Cocoa on OSX), it is possible for me to use some
Cocoa functions to force things to run on the main thread.  From what
I've read Cocoa uses pthreads to implement this. I was hoping we could
expose something from the RTS code in Control.Concurrent so that it's
part of an "official" Haskell API that library writers can assume.

Judging by this SO question, it's easier to implement this in Haskell
on top of pthreads than to implement it in C (here I'm assuming GHC's
RTS uses pthreads, but I've never checked):

http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

In fact, the it sounds like what Gtk2hs is doing with the postGUI
functions.


Right, but usually the way this is implemented is with some cooperation from
the main thread.  That SO answer explains it - the main thread runs some
kind of loop that periodically checks for requests from other threads and
services them.  I expect that's how it works on Cocoa.
So you can't just do this from a library - the main thread has to be in on
the game.


Yes.  From my perspective (that of a library writer) that's what makes
this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
perspective it's tricky too.


I suppose you might wonder whether the GHC RTS could implement
runInMainThread by preempting the main thread and running some different
code on it.


Yes, that's roughly what I was wondering about.



There's more than one reason why a (GUI) library might require
functions to be called only from the main thread. One is if the
library uses thread-local storage, in which case the code needs to run
in the right thread to see the right data. I've heard that OpenGL is
like this. Another (more common, as far as I know) reason is if (parts
of) the library aren't thread safe, and can't handle more than one
thread at a time simultaneously calling its functions and mutating its
members. I'm not sure if there are other reasons.


Yes, this we know (see the Concurrency/FFI paper I linked earli

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/11 17:14, David Barbour wrote:



On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow mailto:marlo...@gmail.com>> wrote:

On 06/07/2011 15:42, Jason Dagit wrote:

How can I make sure my library works from GHC (with arbitrary

user threads) and from GHCI?

Right, but usually the way this is implemented is with some
cooperation from the main thread. [...] So you can't just do this
from a library - the main thread has to be in on the game. I suppose
you might wonder whether the GHC RTS could implement runInMainThread
by preempting the main thread and running some different code on it.
  [...]


I think the real issue is that GHC has a different behavior than GHCi,
and I think this causes a lot of difficulties for people working on GUI
and other FFI integration.

Perhaps it would be possible to reverse the default roles of threads in
GHCi: the main thread run user commands, and a second bound thread will
process user interrupts and such.


Well, GHCi has no main, so it doesn't seem surprising (to me) that it's 
different.


However, if -fno-ghci-sandbox doesn't have any drawbacks we could just 
make it the default.  I don't actually remember why we run each 
statement in a new thread, I think it just seemed like a prudent thing 
to do.


Cheers,
Simon

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

Re: [Haskell-cafe] NLP libraries and tools?

[Dmitri O.Kondratiev]

On Wed, Jul 6, 2011 at 8:32 PM, wren ng thornton  wrote:

> On 7/6/11 9:27 AM, Dmitri O.Kondratiev wrote:
> > Hi,
> > Continuing my search of Haskell NLP tools and libs, I wonder if the
> > following Haskell libraries exist (googling them does not help):
> > 1) End of Sentence (EOS) Detection. Break text into a collection of
> > meaningful sentences.
>
> Depending on how you mean, this is either fairly trivial (for English) or
> an ill-defined problem. For things like determining whether the "."
> character is intended as a full stop vs part of an abbreviation; that's
> trivial.
>
> But for general sentence breaking, how do you intend to deal with
> quotations? What about when news articles quote someone uttering a few
> sentences before the end-quote marker? So far as I'm aware, there's no
> satisfactory definition of what the solution should be in all reasonable
> cases. A "sentence" isn't really very well-defined in practice.
>

I am looking for Haskell implementation of sentence tokenizer such as
described by Tibor Kiss and Jan Strunk’s in “Unsupervised Multilingual
Sentence Boundary Detection”,  which is implemented in NLTK:

http://nltk.googlecode.com/svn/trunk/doc/api/nltk.tokenize.punkt-module.html


> > 2) Part-of-Speech (POS) Tagging. Assign part-of-speech information to
> each
> > token.
>
> There are numerous approaches to this problem; do you care about the
> solution, or will any one of them suffice?
>
> I've been working over the last year+ on an optimized HMM-based POS
> tagger/supertagger with online tagging and anytime n-best tagging. I'm
> planning to release it this summer (i.e., by the end of August), though
> there are a few things I'd like to polish up before doing so. In
> particular, I want to make the package less monolithic. When I release it
> I'll make announcements here and on the nlp@ list.


I am looking for some already working POS tagging framework that can be
customized for different pidgin languages.


> > 3) Chunking. Analyze each tagged token within a sentence and assemble
> > compound tokens that express logical concepts. Define a custom grammar.
> >
> > 4) Extraction. Analyze each chunk and further tag the chunks as named
> > entities, such as people, organizations, locations, etc.
> >
> > Any ideas where to look for similar Haskell libraries?
>
> I don't know of any work in these areas in Haskell (though I'd love to
> hear about it). You should try asking on the nlp@ list where the other
> linguists and NLPers are more likely to see it.
>
>
I will, though n...@projects.haskell.org. looks very quiet...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context ofaspecific OS thread?

[Donn Cave]

Quoth Brandon Allbery ,
...
> I don't know about the general case, but OS X does treat the main
> thread specially here; the (native, not X11) framework sets up the
> connection to Core Graphics in the main thread before invoking the
> main program, so you can't make whatever it is (thread local storage
> seems likely) happen in a different thread.

For one general case, C++ static constructors run prior to main(),
so any thread dependency introduced by a static C++ object would
target the initial program thread.

Donn

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

Re: [Haskell-cafe] How to ensure code executes in the context of aspecific OS thread?

[Brandon Allbery]

2011/7/6 Gábor Lehel :
> Hmm. That does seem like a pretty strong "disproof". I wonder if my
> hypothesis is wrong in general, or if this particular library does in
> fact have other requirements (thread-local storage or such) (and in
> this case whether my other assumption was wrong and this is actually
> the usual case), or if there's something else we're missing.

I don't know about the general case, but OS X does treat the main
thread specially here; the (native, not X11) framework sets up the
connection to Core Graphics in the main thread before invoking the
main program, so you can't make whatever it is (thread local storage
seems likely) happen in a different thread.

-- 
brandon s allbery                                      allber...@gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

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

Re: [Haskell-cafe] (no subject)

[Thomas DuBuisson]

Ian,
This requires dynamic typing using Data.Dynamic (for application) and
Data.Typeable (to do the typing).   Namely, you are asking for the
"dynApply" function:

 START CODE
import Data.Dynamic
import Data.Typeable
import Control.Monad

maybeApp :: (Typeable a, Typeable b, Typeable c) => a -> b -> Maybe c
maybeApp a = join . fmap fromDynamic . dynApply (toDyn a) . toDyn
 END CODE

In the above we obtain representations of your types in the form of
"Dynamic" data types using toDyn.  Then, using dynApply, we get a
value of type "Maybe Dynamic", which we convert back into a "c" type
with fromDynamic.  The "join" is just there to collapse the type from
a "Maybe (Maybe c)" into the desired type of "Maybe c".

Cheers,
Thomas

P.S.
If I totally misunderstood, and you want static typing then you just
need to realize you _don't_ want types "a" and "b" (fully polymorphic)
but rather types (b -> c) and b:

apply :: (b -> c) -> b -> c
apply a b = a b

But this seems rather silly, so I hope you were looking for my first answer.


On Wed, Jul 6, 2011 at 2:12 AM, Ian Childs  wrote:
> Suppose I have two terms s and t of type "a" and "b" respectively, and I
> want to write a function that returns s applied to t if "a" is an arrow type
> of form "b -> c", and nothing otherwise. How do i convince the compiler to
> accept the functional application only in the correct instance?
>
> Thanks,
> Ian
>
> ___
> 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] How to ensure code executes in the context of aspecific OS thread?

[Gábor Lehel]

2011/7/6 Donn Cave :
> Quoth =?ISO-8859-1?Q?G=E1bor_Lehel?= ,
> ...
>> Stated another way: I suspect most GUI libraries don't really actually
>> care that you only execute GUI code from the main OS thread, as much
>> as they care that only one (thread-unsafe) GUI function is being
>> called at any given time. If you only ever call GUI code from the same
>> (main) OS thread, that fulfills this requirement, because an OS thread
>> is only capable of running one library function at a time;
>> alternately, if you only ever call GUI code from the same Haskell
>> thread, that also fulfills this requirement, because one Haskell
>> thread is also only capable of running one library function at a time,
>
> I thought in the present case, the program now works when compiled,
> but fails when run in GHCi, and we believe that the only difference
> here is that GHCi took the main thread and put the program, and hence
> the GUI, in some other thread?
>
> I.e., your requirement is indeed met, per the second alternative,
> but the program still fails, because this library really does need
> to execute in the initial "main" program thread.

Hmm. That does seem like a pretty strong "disproof". I wonder if my
hypothesis is wrong in general, or if this particular library does in
fact have other requirements (thread-local storage or such) (and in
this case whether my other assumption was wrong and this is actually
the usual case), or if there's something else we're missing.

>
>        Donn
>



-- 
Work is punishment for failing to procrastinate effectively.

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

Re: [Haskell-cafe] How to ensure code executes in the context of aspecific OS thread?

[Donn Cave]

Quoth =?ISO-8859-1?Q?G=E1bor_Lehel?= ,
...
> Stated another way: I suspect most GUI libraries don't really actually
> care that you only execute GUI code from the main OS thread, as much
> as they care that only one (thread-unsafe) GUI function is being
> called at any given time. If you only ever call GUI code from the same
> (main) OS thread, that fulfills this requirement, because an OS thread
> is only capable of running one library function at a time;
> alternately, if you only ever call GUI code from the same Haskell
> thread, that also fulfills this requirement, because one Haskell
> thread is also only capable of running one library function at a time,

I thought in the present case, the program now works when compiled,
but fails when run in GHCi, and we believe that the only difference
here is that GHCi took the main thread and put the program, and hence
the GUI, in some other thread?

I.e., your requirement is indeed met, per the second alternative,
but the program still fails, because this library really does need
to execute in the initial "main" program thread.

Donn

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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Gábor Lehel]

2011/7/6 Gábor Lehel :
> 2011/7/6 Gábor Lehel :
>> On Wed, Jul 6, 2011 at 5:24 PM, Jason Dagit  wrote:
>>> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
 On 06/07/2011 15:42, Jason Dagit wrote:
>
> On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:
>>
>> On 06/07/2011 07:37, Jason Dagit wrote:
>>>
>>> On Jul 5, 2011 1:04 PM, "Jason Dagit">> >  wrote:
>>>  >
>>>  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh>> >  wrote:
>>>  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
>>>  >  >>
>>>  >  >>  In GHCi it's a different matter, because the main thread is
>>> running
>>>  >  >>  GHCi itself, and all the expressions/statements typed at the
>>> prompt
>>>  >  >>  are run in forkIO'd threads (a new one for each statement, in
>>> fact).
>>>  >  >>  If you want a way to run command-line operations in the main
>>> thread,
>>>  >  >>  please submit a feature request.  I'm not sure it can be done,
>>> but
>>>  >  >>  I'll look into it.
>>>  >  >
>>>  >  >  We already have a way: -fno-ghci-sandbox
>>>  >
>>>  >  I've removed all my explicit attempts to forkIO/forkOS and passed
>>> the
>>>  >  command line flag you mention.  I just tried this but it doesn't
>>>  >  change the behavior in my example.
>>>
>>> I tried it again and discovered that due to an argument parsing bug in
>>> cabal-dev that the flag was not passed correctly. I explicitly passed it
>>> and verified that it works. Thanks for the workaround. By the way, I did
>>> look at the user guide for options like this and didn't see it. Which
>>> part of the manual is it in?
>>>
>>> Can I still make a feature request for a function to make code run on
>>> the original thread? My reasoning is that the code which needs to run on
>>> the main thread may appear in a library in which case the developer has
>>> no control over how ghc is invoked.
>>
>> I'm not sure how that would work.  The programmer is in control of what
>> the
>> main thread does, not GHC.  So in order to implement some mechanism to
>> run
>> code on the main thread, we would need some cooperation from the main
>> thread
>> itself.  For example, in gtk2hs the main thread runs an event handler
>> loop
>> which occasionally checks a queue for requests from other threads (at
>> least,
>> I think that's how it works).
>
> What I'm wrestling with is the following.  Say I make a GUI library.
> As author of the GUI library I discover issues like this where the
> library code needs to execute on the "main" thread.  Users of the
> library expect the typical Haskell environment where you can't tell
> the difference between threads, and you fork at will.  How can I make
> sure my library works from GHC (with arbitrary user threads) and from
> GHCI?
>
> As John Lato points out in his email lots of people bump into this
> without realizing it and don't understand what the problem is.  We can
> try our best to educate everyone, but I have this sense that we could
> also do a better job of providing primitives to make it so that code
> will run on the main thread regardless of how people invoke the
> library.
>
> In my specific case (Cocoa on OSX), it is possible for me to use some
> Cocoa functions to force things to run on the main thread.  From what
> I've read Cocoa uses pthreads to implement this. I was hoping we could
> expose something from the RTS code in Control.Concurrent so that it's
> part of an "official" Haskell API that library writers can assume.
>
> Judging by this SO question, it's easier to implement this in Haskell
> on top of pthreads than to implement it in C (here I'm assuming GHC's
> RTS uses pthreads, but I've never checked):
>
> http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread
>
> In fact, the it sounds like what Gtk2hs is doing with the postGUI
> functions.

 Right, but usually the way this is implemented is with some cooperation 
 from
 the main thread.  That SO answer explains it - the main thread runs some
 kind of loop that periodically checks for requests from other threads and
 services them.  I expect that's how it works on Cocoa.
 So you can't just do this from a library - the main thread has to be in on
 the game.
>>>
>>> Yes.  From my perspective (that of a library writer) that's what makes
>>> this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
>>> perspective it's tricky too.
>>>
 I suppose you might wonder whether the GHC RTS could implement
 runInMainThread by preempting the main thread and running some different
 code on it.
>>>
>>> Yes, that's roughly what I was wondering abou

Re: [Haskell-cafe] NLP libraries and tools?

[wren ng thornton]

On 7/6/11 9:27 AM, Dmitri O.Kondratiev wrote:
> Hi,
> Continuing my search of Haskell NLP tools and libs, I wonder if the
> following Haskell libraries exist (googling them does not help):
> 1) End of Sentence (EOS) Detection. Break text into a collection of
> meaningful sentences.

Depending on how you mean, this is either fairly trivial (for English) or
an ill-defined problem. For things like determining whether the "."
character is intended as a full stop vs part of an abbreviation; that's
trivial.

But for general sentence breaking, how do you intend to deal with
quotations? What about when news articles quote someone uttering a few
sentences before the end-quote marker? So far as I'm aware, there's no
satisfactory definition of what the solution should be in all reasonable
cases. A "sentence" isn't really very well-defined in practice.

> 2) Part-of-Speech (POS) Tagging. Assign part-of-speech information to each
> token.

There are numerous approaches to this problem; do you care about the
solution, or will any one of them suffice?

I've been working over the last year+ on an optimized HMM-based POS
tagger/supertagger with online tagging and anytime n-best tagging. I'm
planning to release it this summer (i.e., by the end of August), though
there are a few things I'd like to polish up before doing so. In
particular, I want to make the package less monolithic. When I release it
I'll make announcements here and on the nlp@ list.


> 3) Chunking. Analyze each tagged token within a sentence and assemble
> compound tokens that express logical concepts. Define a custom grammar.
>
> 4) Extraction. Analyze each chunk and further tag the chunks as named
> entities, such as people, organizations, locations, etc.
>
> Any ideas where to look for similar Haskell libraries?

I don't know of any work in these areas in Haskell (though I'd love to
hear about it). You should try asking on the nlp@ list where the other
linguists and NLPers are more likely to see it.

-- 
Live well,
~wren


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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Gábor Lehel]

2011/7/6 Gábor Lehel :
> On Wed, Jul 6, 2011 at 5:24 PM, Jason Dagit  wrote:
>> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
>>> On 06/07/2011 15:42, Jason Dagit wrote:

 On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:
>
> On 06/07/2011 07:37, Jason Dagit wrote:
>>
>> On Jul 5, 2011 1:04 PM, "Jason Dagit"> >  wrote:
>>  >
>>  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh> >  wrote:
>>  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
>>  >  >>
>>  >  >>  In GHCi it's a different matter, because the main thread is
>> running
>>  >  >>  GHCi itself, and all the expressions/statements typed at the
>> prompt
>>  >  >>  are run in forkIO'd threads (a new one for each statement, in
>> fact).
>>  >  >>  If you want a way to run command-line operations in the main
>> thread,
>>  >  >>  please submit a feature request.  I'm not sure it can be done,
>> but
>>  >  >>  I'll look into it.
>>  >  >
>>  >  >  We already have a way: -fno-ghci-sandbox
>>  >
>>  >  I've removed all my explicit attempts to forkIO/forkOS and passed
>> the
>>  >  command line flag you mention.  I just tried this but it doesn't
>>  >  change the behavior in my example.
>>
>> I tried it again and discovered that due to an argument parsing bug in
>> cabal-dev that the flag was not passed correctly. I explicitly passed it
>> and verified that it works. Thanks for the workaround. By the way, I did
>> look at the user guide for options like this and didn't see it. Which
>> part of the manual is it in?
>>
>> Can I still make a feature request for a function to make code run on
>> the original thread? My reasoning is that the code which needs to run on
>> the main thread may appear in a library in which case the developer has
>> no control over how ghc is invoked.
>
> I'm not sure how that would work.  The programmer is in control of what
> the
> main thread does, not GHC.  So in order to implement some mechanism to
> run
> code on the main thread, we would need some cooperation from the main
> thread
> itself.  For example, in gtk2hs the main thread runs an event handler
> loop
> which occasionally checks a queue for requests from other threads (at
> least,
> I think that's how it works).

 What I'm wrestling with is the following.  Say I make a GUI library.
 As author of the GUI library I discover issues like this where the
 library code needs to execute on the "main" thread.  Users of the
 library expect the typical Haskell environment where you can't tell
 the difference between threads, and you fork at will.  How can I make
 sure my library works from GHC (with arbitrary user threads) and from
 GHCI?

 As John Lato points out in his email lots of people bump into this
 without realizing it and don't understand what the problem is.  We can
 try our best to educate everyone, but I have this sense that we could
 also do a better job of providing primitives to make it so that code
 will run on the main thread regardless of how people invoke the
 library.

 In my specific case (Cocoa on OSX), it is possible for me to use some
 Cocoa functions to force things to run on the main thread.  From what
 I've read Cocoa uses pthreads to implement this. I was hoping we could
 expose something from the RTS code in Control.Concurrent so that it's
 part of an "official" Haskell API that library writers can assume.

 Judging by this SO question, it's easier to implement this in Haskell
 on top of pthreads than to implement it in C (here I'm assuming GHC's
 RTS uses pthreads, but I've never checked):

 http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

 In fact, the it sounds like what Gtk2hs is doing with the postGUI
 functions.
>>>
>>> Right, but usually the way this is implemented is with some cooperation from
>>> the main thread.  That SO answer explains it - the main thread runs some
>>> kind of loop that periodically checks for requests from other threads and
>>> services them.  I expect that's how it works on Cocoa.
>>> So you can't just do this from a library - the main thread has to be in on
>>> the game.
>>
>> Yes.  From my perspective (that of a library writer) that's what makes
>> this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
>> perspective it's tricky too.
>>
>>> I suppose you might wonder whether the GHC RTS could implement
>>> runInMainThread by preempting the main thread and running some different
>>> code on it.
>>
>> Yes, that's roughly what I was wondering about.
>
>
> There's more than one reason why a (GUI) library might require
> functions to be called only from the main thread. One is if 

Re: [Haskell-cafe] How to ensure code executes in the context of aspecific OS thread?

[Donn Cave]

Quoth Jason Dagit ,
...
> Yes.  From my perspective (that of a library writer) that's what makes
> this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
> perspective it's tricky too.

It seems to me that ideally, GHCi would do its thing in a child
thread, like the extra runtime threads, and let the program
execute in the main thread, as in a compiled program.  I mean,
ideal from the point of view of supporting the general case of
library functions that care what the main thread is doing.

I'm not saying that's possible - have no idea - but just that
where you're dealing with a possibly unconscious and probably
poorly documented expectation like that, it's better to not
break it in the first place, than to have to try to patch it
up at run time.  I have been wondering while reading this thread
if my Haiku API functions are subject to this restriction -
there is an application object that normally runs in main() -
but while that would be easy to verify empirically, it wouldn't
really tell me what I need to know.  A subsequent OS release
could easily introduce some thread sensitivity, and I guess if
my Haskell programs must run from a child thread under certain
circumstances, even if I could make them work I would have to
consider that success temporary and provisional.

Donn

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

Re: [Haskell-cafe] Arrow instance of function type [a] -> [b]

[David Barbour]

On Wed, Jul 6, 2011 at 6:04 AM, Markus Läll  wrote:

> Is it possible to define an Arrow instance of list to list functions?
>
> import Control.Arrow
> import Control.Category
>
> type X a b = [a] -> [b]
>

You need a newtype here. (->) is already an arrow.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[David Barbour]

On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:

> On 06/07/2011 15:42, Jason Dagit wrote:
>
>> How can I make sure my library works from GHC (with arbitrary
>
> user threads) and from GHCI?
>>
>

Right, but usually the way this is implemented is with some cooperation from
> the main thread. [...] So you can't just do this from a library - the main
> thread has to be in on the game. I suppose you might wonder whether the GHC
> RTS could implement runInMainThread by preempting the main thread and
> running some different code on it.  [...]
>

I think the real issue is that GHC has a different behavior than GHCi, and I
think this causes a lot of difficulties for people working on GUI and other
FFI integration.

Perhaps it would be possible to reverse the default roles of threads in
GHCi: the main thread run user commands, and a second bound thread will
process user interrupts and such.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Gábor Lehel]

On Wed, Jul 6, 2011 at 5:24 PM, Jason Dagit  wrote:
> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
>> On 06/07/2011 15:42, Jason Dagit wrote:
>>>
>>> On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:

 On 06/07/2011 07:37, Jason Dagit wrote:
>
> On Jul 5, 2011 1:04 PM, "Jason Dagit" >  wrote:
>  >
>  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh >  wrote:
>  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
>  >  >>
>  >  >>  In GHCi it's a different matter, because the main thread is
> running
>  >  >>  GHCi itself, and all the expressions/statements typed at the
> prompt
>  >  >>  are run in forkIO'd threads (a new one for each statement, in
> fact).
>  >  >>  If you want a way to run command-line operations in the main
> thread,
>  >  >>  please submit a feature request.  I'm not sure it can be done,
> but
>  >  >>  I'll look into it.
>  >  >
>  >  >  We already have a way: -fno-ghci-sandbox
>  >
>  >  I've removed all my explicit attempts to forkIO/forkOS and passed
> the
>  >  command line flag you mention.  I just tried this but it doesn't
>  >  change the behavior in my example.
>
> I tried it again and discovered that due to an argument parsing bug in
> cabal-dev that the flag was not passed correctly. I explicitly passed it
> and verified that it works. Thanks for the workaround. By the way, I did
> look at the user guide for options like this and didn't see it. Which
> part of the manual is it in?
>
> Can I still make a feature request for a function to make code run on
> the original thread? My reasoning is that the code which needs to run on
> the main thread may appear in a library in which case the developer has
> no control over how ghc is invoked.

 I'm not sure how that would work.  The programmer is in control of what
 the
 main thread does, not GHC.  So in order to implement some mechanism to
 run
 code on the main thread, we would need some cooperation from the main
 thread
 itself.  For example, in gtk2hs the main thread runs an event handler
 loop
 which occasionally checks a queue for requests from other threads (at
 least,
 I think that's how it works).
>>>
>>> What I'm wrestling with is the following.  Say I make a GUI library.
>>> As author of the GUI library I discover issues like this where the
>>> library code needs to execute on the "main" thread.  Users of the
>>> library expect the typical Haskell environment where you can't tell
>>> the difference between threads, and you fork at will.  How can I make
>>> sure my library works from GHC (with arbitrary user threads) and from
>>> GHCI?
>>>
>>> As John Lato points out in his email lots of people bump into this
>>> without realizing it and don't understand what the problem is.  We can
>>> try our best to educate everyone, but I have this sense that we could
>>> also do a better job of providing primitives to make it so that code
>>> will run on the main thread regardless of how people invoke the
>>> library.
>>>
>>> In my specific case (Cocoa on OSX), it is possible for me to use some
>>> Cocoa functions to force things to run on the main thread.  From what
>>> I've read Cocoa uses pthreads to implement this. I was hoping we could
>>> expose something from the RTS code in Control.Concurrent so that it's
>>> part of an "official" Haskell API that library writers can assume.
>>>
>>> Judging by this SO question, it's easier to implement this in Haskell
>>> on top of pthreads than to implement it in C (here I'm assuming GHC's
>>> RTS uses pthreads, but I've never checked):
>>>
>>> http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread
>>>
>>> In fact, the it sounds like what Gtk2hs is doing with the postGUI
>>> functions.
>>
>> Right, but usually the way this is implemented is with some cooperation from
>> the main thread.  That SO answer explains it - the main thread runs some
>> kind of loop that periodically checks for requests from other threads and
>> services them.  I expect that's how it works on Cocoa.
>> So you can't just do this from a library - the main thread has to be in on
>> the game.
>
> Yes.  From my perspective (that of a library writer) that's what makes
> this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
> perspective it's tricky too.
>
>> I suppose you might wonder whether the GHC RTS could implement
>> runInMainThread by preempting the main thread and running some different
>> code on it.
>
> Yes, that's roughly what I was wondering about.


There's more than one reason why a (GUI) library might require
functions to be called only from the main thread. One is if the
library uses thread-local storage, in which case the code needs to run
in the right thread to see the right data. I've heard that

Re: [Haskell-cafe] Automatic Reference Counting

[David Barbour]

On Tue, Jul 5, 2011 at 9:00 PM, steffen wrote:

> The important point about reference counting on idevices is the near
> realtime performance, since stops for collecting garbage are actually very
> short in comparison to collecting compilers (despite more frequent).


You can get near realtime performance from any collector if you structure
your application to only need a fixed amount of memory. I.e. you can make
guarantees about the amount of memory collected across any two GC cycles.

On Sat, Jul 2, 2011 at 16:51, Thomas Davie  wrote:

> Apple recently announced a new static analysis in Clang called ARC
> (Automatic Reference Counting).  The idea is to provide what GC provides
> (zero memory management code by the programmer), but not to incur the
> runtime penalty of having to have the GC run.
> I was wondering if any of the compiler gurus out there could comment on the
> applicability of this kind of analysis to Haskell.  Dropping the GC and
> hence stopping it blocking all threads and killing parallel performance
> seems like nirvana.


RC touches dead data, and GC touches live data. Look at the memory profile
of a typical Haskell program - i.e. live memory ranging in megabytes, dead
data ranging in hundreds of megabytes (if not gigabytes) per second. It is
unlikely that we'll get much better performance from reference counting,
though a hybrid model might be useful for the later generation (where
collections are rarer).

I think Haskell could do a lot to improve its concurrent GC. At the moment,
each processor has a space of its own that it can collect concurrently, plus
there is global collection that freezes all threads and cleans up all
garbage in the later generation. For very-large-memory apps, we could do a
lot to extend concurrent GC into later generations, do a more effective job
of either managing our own paging or integrating with OS virtual memory,
and avoid the global collection as a last resort. Pauses with paging-aware
collectors can be improved by over two orders of magnitude [1].

[1] Garbage Collection without Paging
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 8:51 AM, Simon Marlow  wrote:
> On 06/07/2011 16:24, Jason Dagit wrote:
>>
>> On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
>>>
>>> On 06/07/2011 15:42, Jason Dagit wrote:

 On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow
  wrote:
>
> On 06/07/2011 07:37, Jason Dagit wrote:
>>
>> On Jul 5, 2011 1:04 PM, "Jason Dagit"> >    wrote:
>>  >
>>  >    On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh> >    wrote:
>>  >    >    On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow
>> wrote:
>>  >    >>
>>  >    >>    In GHCi it's a different matter, because the main thread
>> is
>> running
>>  >    >>    GHCi itself, and all the expressions/statements typed at
>> the
>> prompt
>>  >    >>    are run in forkIO'd threads (a new one for each statement,
>> in
>> fact).
>>  >    >>    If you want a way to run command-line operations in the
>> main
>> thread,
>>  >    >>    please submit a feature request.  I'm not sure it can be
>> done,
>> but
>>  >    >>    I'll look into it.
>>  >    >
>>  >    >    We already have a way: -fno-ghci-sandbox
>>  >
>>  >    I've removed all my explicit attempts to forkIO/forkOS and
>> passed
>> the
>>  >    command line flag you mention.  I just tried this but it doesn't
>>  >    change the behavior in my example.
>>
>> I tried it again and discovered that due to an argument parsing bug in
>> cabal-dev that the flag was not passed correctly. I explicitly passed
>> it
>> and verified that it works. Thanks for the workaround. By the way, I
>> did
>> look at the user guide for options like this and didn't see it. Which
>> part of the manual is it in?
>>
>> Can I still make a feature request for a function to make code run on
>> the original thread? My reasoning is that the code which needs to run
>> on
>> the main thread may appear in a library in which case the developer
>> has
>> no control over how ghc is invoked.
>
> I'm not sure how that would work.  The programmer is in control of what
> the
> main thread does, not GHC.  So in order to implement some mechanism to
> run
> code on the main thread, we would need some cooperation from the main
> thread
> itself.  For example, in gtk2hs the main thread runs an event handler
> loop
> which occasionally checks a queue for requests from other threads (at
> least,
> I think that's how it works).

 What I'm wrestling with is the following.  Say I make a GUI library.
 As author of the GUI library I discover issues like this where the
 library code needs to execute on the "main" thread.  Users of the
 library expect the typical Haskell environment where you can't tell
 the difference between threads, and you fork at will.  How can I make
 sure my library works from GHC (with arbitrary user threads) and from
 GHCI?

 As John Lato points out in his email lots of people bump into this
 without realizing it and don't understand what the problem is.  We can
 try our best to educate everyone, but I have this sense that we could
 also do a better job of providing primitives to make it so that code
 will run on the main thread regardless of how people invoke the
 library.

 In my specific case (Cocoa on OSX), it is possible for me to use some
 Cocoa functions to force things to run on the main thread.  From what
 I've read Cocoa uses pthreads to implement this. I was hoping we could
 expose something from the RTS code in Control.Concurrent so that it's
 part of an "official" Haskell API that library writers can assume.

 Judging by this SO question, it's easier to implement this in Haskell
 on top of pthreads than to implement it in C (here I'm assuming GHC's
 RTS uses pthreads, but I've never checked):


 http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

 In fact, the it sounds like what Gtk2hs is doing with the postGUI
 functions.
>>>
>>> Right, but usually the way this is implemented is with some cooperation
>>> from
>>> the main thread.  That SO answer explains it - the main thread runs some
>>> kind of loop that periodically checks for requests from other threads and
>>> services them.  I expect that's how it works on Cocoa.
>>> So you can't just do this from a library - the main thread has to be in
>>> on
>>> the game.
>>
>> Yes.  From my perspective (that of a library writer) that's what makes
>> this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
>> perspective it's tricky too.
>>
>>> I suppose you might wonder whether the GHC RTS could implement
>>> runInMainThread by preempting the main thread and running some different
>>> code on it.
>>
>> Yes, that's

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/2011 16:24, Jason Dagit wrote:

On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:

On 06/07/2011 15:42, Jason Dagit wrote:


On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlowwrote:


On 06/07/2011 07:37, Jason Dagit wrote:


On Jul 5, 2011 1:04 PM, "Jason Dagit"mailto:dag...@gmail.com>>wrote:
  >
  >On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynaghmailto:ig...@earth.li>>wrote:
  >>On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
  >>>
  >>>In GHCi it's a different matter, because the main thread is
running
  >>>GHCi itself, and all the expressions/statements typed at the
prompt
  >>>are run in forkIO'd threads (a new one for each statement, in
fact).
  >>>If you want a way to run command-line operations in the main
thread,
  >>>please submit a feature request.  I'm not sure it can be done,
but
  >>>I'll look into it.
  >>
  >>We already have a way: -fno-ghci-sandbox
  >
  >I've removed all my explicit attempts to forkIO/forkOS and passed
the
  >command line flag you mention.  I just tried this but it doesn't
  >change the behavior in my example.

I tried it again and discovered that due to an argument parsing bug in
cabal-dev that the flag was not passed correctly. I explicitly passed it
and verified that it works. Thanks for the workaround. By the way, I did
look at the user guide for options like this and didn't see it. Which
part of the manual is it in?

Can I still make a feature request for a function to make code run on
the original thread? My reasoning is that the code which needs to run on
the main thread may appear in a library in which case the developer has
no control over how ghc is invoked.


I'm not sure how that would work.  The programmer is in control of what
the
main thread does, not GHC.  So in order to implement some mechanism to
run
code on the main thread, we would need some cooperation from the main
thread
itself.  For example, in gtk2hs the main thread runs an event handler
loop
which occasionally checks a queue for requests from other threads (at
least,
I think that's how it works).


What I'm wrestling with is the following.  Say I make a GUI library.
As author of the GUI library I discover issues like this where the
library code needs to execute on the "main" thread.  Users of the
library expect the typical Haskell environment where you can't tell
the difference between threads, and you fork at will.  How can I make
sure my library works from GHC (with arbitrary user threads) and from
GHCI?

As John Lato points out in his email lots of people bump into this
without realizing it and don't understand what the problem is.  We can
try our best to educate everyone, but I have this sense that we could
also do a better job of providing primitives to make it so that code
will run on the main thread regardless of how people invoke the
library.

In my specific case (Cocoa on OSX), it is possible for me to use some
Cocoa functions to force things to run on the main thread.  From what
I've read Cocoa uses pthreads to implement this. I was hoping we could
expose something from the RTS code in Control.Concurrent so that it's
part of an "official" Haskell API that library writers can assume.

Judging by this SO question, it's easier to implement this in Haskell
on top of pthreads than to implement it in C (here I'm assuming GHC's
RTS uses pthreads, but I've never checked):

http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

In fact, the it sounds like what Gtk2hs is doing with the postGUI
functions.


Right, but usually the way this is implemented is with some cooperation from
the main thread.  That SO answer explains it - the main thread runs some
kind of loop that periodically checks for requests from other threads and
services them.  I expect that's how it works on Cocoa.
So you can't just do this from a library - the main thread has to be in on
the game.


Yes.  From my perspective (that of a library writer) that's what makes
this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
perspective it's tricky too.


I suppose you might wonder whether the GHC RTS could implement
runInMainThread by preempting the main thread and running some different
code on it.


Yes, that's roughly what I was wondering about.


  In theory that's possible, but whether it's a good idea or not
is a different matter!  I think it amounts to the same thing as the gtk2hs
folks have been asking for - multiple Haskell threads bound to the same OS
thread.


I'm starting to realize that I don't understand the GHC threading
model very well :)  I thought that was already possible.  I may be
mixing GHC's thread model up with other language implementations, but
I thought that it had a pool of OS threads and that Haskell threads
ran on them as needed.  I think what you're saying is that the RTS has
bound threads and it has thread pooling, but what it doesn't have is
"bound 

Re: [Haskell-cafe] NVIDIA's CUDA and Haskell

[Johannes Waldmann]

Trevor L. McDonell  cse.unsw.edu.au> writes:

> hmm... so libcuda and libcudart are in /usr/local/cuda/lib ...

actually libcuda is in /usr/lib/nvidia-current ,
unbeknownst to ./configure.
I think this comes from package "nvidia-current(-dev)" in ubuntu.

I could solve this with

LDFLAGS='-L/usr/lib/nvidia-current ' cabal install

note the space after dirname - otherwise ./configure
(in cuda-0.3.2.2) fails.

It still feels strange that I can build the examples from
NVIDIA_GPU_Computing_SDK/C/src/  without modifying LDFLAGS.  
When running, I need to set LD_LIBRARY_PATH=/usr/local/cuda/lib64
but that's expected.

Anyway, when running "accelerate-examples --cuda" I get mixed results,

...
fold-maximum: Ok
fold-minimum: Ok
fold-2d-sum: Failed: stack overflow
fold-2d-product: Failed: stack overflow
scanseg-sum: Failed: 
*** Internal error in package accelerate ***
*** Please submit a bug report 
at https://github.com/mchakravarty/accelerate/issues
./Data/Array/Accelerate/CUDA.hs:58 (unhandled): 
CUDA Exception: unspecified launch failure

I guess I should report them as advertised.


Is there a way to find out the expected results/failures 
for a recent accelerate package install?
(So I can avoid reporting them.)

Thanks - Johannes.





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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlow  wrote:
> On 06/07/2011 15:42, Jason Dagit wrote:
>>
>> On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:
>>>
>>> On 06/07/2011 07:37, Jason Dagit wrote:

 On Jul 5, 2011 1:04 PM, "Jason Dagit">>> >  wrote:
  >
  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh>>> >  wrote:
  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
  >  >>
  >  >>  In GHCi it's a different matter, because the main thread is
 running
  >  >>  GHCi itself, and all the expressions/statements typed at the
 prompt
  >  >>  are run in forkIO'd threads (a new one for each statement, in
 fact).
  >  >>  If you want a way to run command-line operations in the main
 thread,
  >  >>  please submit a feature request.  I'm not sure it can be done,
 but
  >  >>  I'll look into it.
  >  >
  >  >  We already have a way: -fno-ghci-sandbox
  >
  >  I've removed all my explicit attempts to forkIO/forkOS and passed
 the
  >  command line flag you mention.  I just tried this but it doesn't
  >  change the behavior in my example.

 I tried it again and discovered that due to an argument parsing bug in
 cabal-dev that the flag was not passed correctly. I explicitly passed it
 and verified that it works. Thanks for the workaround. By the way, I did
 look at the user guide for options like this and didn't see it. Which
 part of the manual is it in?

 Can I still make a feature request for a function to make code run on
 the original thread? My reasoning is that the code which needs to run on
 the main thread may appear in a library in which case the developer has
 no control over how ghc is invoked.
>>>
>>> I'm not sure how that would work.  The programmer is in control of what
>>> the
>>> main thread does, not GHC.  So in order to implement some mechanism to
>>> run
>>> code on the main thread, we would need some cooperation from the main
>>> thread
>>> itself.  For example, in gtk2hs the main thread runs an event handler
>>> loop
>>> which occasionally checks a queue for requests from other threads (at
>>> least,
>>> I think that's how it works).
>>
>> What I'm wrestling with is the following.  Say I make a GUI library.
>> As author of the GUI library I discover issues like this where the
>> library code needs to execute on the "main" thread.  Users of the
>> library expect the typical Haskell environment where you can't tell
>> the difference between threads, and you fork at will.  How can I make
>> sure my library works from GHC (with arbitrary user threads) and from
>> GHCI?
>>
>> As John Lato points out in his email lots of people bump into this
>> without realizing it and don't understand what the problem is.  We can
>> try our best to educate everyone, but I have this sense that we could
>> also do a better job of providing primitives to make it so that code
>> will run on the main thread regardless of how people invoke the
>> library.
>>
>> In my specific case (Cocoa on OSX), it is possible for me to use some
>> Cocoa functions to force things to run on the main thread.  From what
>> I've read Cocoa uses pthreads to implement this. I was hoping we could
>> expose something from the RTS code in Control.Concurrent so that it's
>> part of an "official" Haskell API that library writers can assume.
>>
>> Judging by this SO question, it's easier to implement this in Haskell
>> on top of pthreads than to implement it in C (here I'm assuming GHC's
>> RTS uses pthreads, but I've never checked):
>>
>> http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread
>>
>> In fact, the it sounds like what Gtk2hs is doing with the postGUI
>> functions.
>
> Right, but usually the way this is implemented is with some cooperation from
> the main thread.  That SO answer explains it - the main thread runs some
> kind of loop that periodically checks for requests from other threads and
> services them.  I expect that's how it works on Cocoa.
> So you can't just do this from a library - the main thread has to be in on
> the game.

Yes.  From my perspective (that of a library writer) that's what makes
this tricky in GHCi.  I need GHCi's cooperation.  From GHCi's
perspective it's tricky too.

> I suppose you might wonder whether the GHC RTS could implement
> runInMainThread by preempting the main thread and running some different
> code on it.

Yes, that's roughly what I was wondering about.

>  In theory that's possible, but whether it's a good idea or not
> is a different matter!  I think it amounts to the same thing as the gtk2hs
> folks have been asking for - multiple Haskell threads bound to the same OS
> thread.

I'm starting to realize that I don't understand the GHC threading
model very well :)  I thought that was already possible.  I may be
mixing GHC's thread model up with other language imp

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/2011 15:42, Jason Dagit wrote:

On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:

On 06/07/2011 07:37, Jason Dagit wrote:


On Jul 5, 2011 1:04 PM, "Jason Dagit"mailto:dag...@gmail.com>>  wrote:
  >
  >  On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynaghmailto:ig...@earth.li>>  wrote:
  >  >  On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
  >  >>
  >  >>  In GHCi it's a different matter, because the main thread is running
  >  >>  GHCi itself, and all the expressions/statements typed at the prompt
  >  >>  are run in forkIO'd threads (a new one for each statement, in fact).
  >  >>  If you want a way to run command-line operations in the main thread,
  >  >>  please submit a feature request.  I'm not sure it can be done, but
  >  >>  I'll look into it.
  >  >
  >  >  We already have a way: -fno-ghci-sandbox
  >
  >  I've removed all my explicit attempts to forkIO/forkOS and passed the
  >  command line flag you mention.  I just tried this but it doesn't
  >  change the behavior in my example.

I tried it again and discovered that due to an argument parsing bug in
cabal-dev that the flag was not passed correctly. I explicitly passed it
and verified that it works. Thanks for the workaround. By the way, I did
look at the user guide for options like this and didn't see it. Which
part of the manual is it in?

Can I still make a feature request for a function to make code run on
the original thread? My reasoning is that the code which needs to run on
the main thread may appear in a library in which case the developer has
no control over how ghc is invoked.


I'm not sure how that would work.  The programmer is in control of what the
main thread does, not GHC.  So in order to implement some mechanism to run
code on the main thread, we would need some cooperation from the main thread
itself.  For example, in gtk2hs the main thread runs an event handler loop
which occasionally checks a queue for requests from other threads (at least,
I think that's how it works).


What I'm wrestling with is the following.  Say I make a GUI library.
As author of the GUI library I discover issues like this where the
library code needs to execute on the "main" thread.  Users of the
library expect the typical Haskell environment where you can't tell
the difference between threads, and you fork at will.  How can I make
sure my library works from GHC (with arbitrary user threads) and from
GHCI?

As John Lato points out in his email lots of people bump into this
without realizing it and don't understand what the problem is.  We can
try our best to educate everyone, but I have this sense that we could
also do a better job of providing primitives to make it so that code
will run on the main thread regardless of how people invoke the
library.

In my specific case (Cocoa on OSX), it is possible for me to use some
Cocoa functions to force things to run on the main thread.  From what
I've read Cocoa uses pthreads to implement this. I was hoping we could
expose something from the RTS code in Control.Concurrent so that it's
part of an "official" Haskell API that library writers can assume.

Judging by this SO question, it's easier to implement this in Haskell
on top of pthreads than to implement it in C (here I'm assuming GHC's
RTS uses pthreads, but I've never checked):
http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

In fact, the it sounds like what Gtk2hs is doing with the postGUI functions.


Right, but usually the way this is implemented is with some cooperation 
from the main thread.  That SO answer explains it - the main thread runs 
some kind of loop that periodically checks for requests from other 
threads and services them.  I expect that's how it works on Cocoa.
So you can't just do this from a library - the main thread has to be in 
on the game.


I suppose you might wonder whether the GHC RTS could implement 
runInMainThread by preempting the main thread and running some different 
code on it.  In theory that's possible, but whether it's a good idea or 
not is a different matter!  I think it amounts to the same thing as the 
gtk2hs folks have been asking for - multiple Haskell threads bound to 
the same OS thread.  runInMainThread then becomes the same as forking a 
temporary new thread bound to the main OS thread, or temporarily binding 
the current thread to the main OS thread.  If the main OS thread is off 
making a foreign call (e.g. in the GUI library's main loop) then it 
can't run any other Haskell threads anyway, and then I have to figure 
out what to do with all these Haskell threads waiting for their bound OS 
thread to come back from the foreign call.  My guess is that all this 
would be pretty complex to implement.


Still, I'm all for making things easier somehow.  At the least, we 
should have good diagnostics when you're using GHCi and this goes wrong. 
 Although I'm not sure how to do that, I think it's really something 
the gtk2hs or Cocoa binding needs to im

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 2:23 AM, Simon Marlow  wrote:
> On 06/07/2011 07:37, Jason Dagit wrote:
>>
>> On Jul 5, 2011 1:04 PM, "Jason Dagit" > > wrote:
>>  >
>>  > On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh > > wrote:
>>  > > On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
>>  > >>
>>  > >> In GHCi it's a different matter, because the main thread is running
>>  > >> GHCi itself, and all the expressions/statements typed at the prompt
>>  > >> are run in forkIO'd threads (a new one for each statement, in fact).
>>  > >> If you want a way to run command-line operations in the main thread,
>>  > >> please submit a feature request.  I'm not sure it can be done, but
>>  > >> I'll look into it.
>>  > >
>>  > > We already have a way: -fno-ghci-sandbox
>>  >
>>  > I've removed all my explicit attempts to forkIO/forkOS and passed the
>>  > command line flag you mention.  I just tried this but it doesn't
>>  > change the behavior in my example.
>>
>> I tried it again and discovered that due to an argument parsing bug in
>> cabal-dev that the flag was not passed correctly. I explicitly passed it
>> and verified that it works. Thanks for the workaround. By the way, I did
>> look at the user guide for options like this and didn't see it. Which
>> part of the manual is it in?
>>
>> Can I still make a feature request for a function to make code run on
>> the original thread? My reasoning is that the code which needs to run on
>> the main thread may appear in a library in which case the developer has
>> no control over how ghc is invoked.
>
> I'm not sure how that would work.  The programmer is in control of what the
> main thread does, not GHC.  So in order to implement some mechanism to run
> code on the main thread, we would need some cooperation from the main thread
> itself.  For example, in gtk2hs the main thread runs an event handler loop
> which occasionally checks a queue for requests from other threads (at least,
> I think that's how it works).

What I'm wrestling with is the following.  Say I make a GUI library.
As author of the GUI library I discover issues like this where the
library code needs to execute on the "main" thread.  Users of the
library expect the typical Haskell environment where you can't tell
the difference between threads, and you fork at will.  How can I make
sure my library works from GHC (with arbitrary user threads) and from
GHCI?

As John Lato points out in his email lots of people bump into this
without realizing it and don't understand what the problem is.  We can
try our best to educate everyone, but I have this sense that we could
also do a better job of providing primitives to make it so that code
will run on the main thread regardless of how people invoke the
library.

In my specific case (Cocoa on OSX), it is possible for me to use some
Cocoa functions to force things to run on the main thread.  From what
I've read Cocoa uses pthreads to implement this. I was hoping we could
expose something from the RTS code in Control.Concurrent so that it's
part of an "official" Haskell API that library writers can assume.

Judging by this SO question, it's easier to implement this in Haskell
on top of pthreads than to implement it in C (here I'm assuming GHC's
RTS uses pthreads, but I've never checked):
http://stackoverflow.com/questions/6130823/pthreads-perform-function-on-main-thread

In fact, the it sounds like what Gtk2hs is doing with the postGUI functions.

Jason

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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Jason Dagit]

On Wed, Jul 6, 2011 at 2:20 AM, Simon Marlow  wrote:
> On 05/07/2011 20:38, Jason Dagit wrote:
>>
>> On Tue, Jul 5, 2011 at 12:11 PM, Simon Marlow  wrote:
>>>
>>> On 04/07/11 06:02, Jason Dagit wrote:

 Hello,

 I'm trying to get some GUI code working on OSX and numerous forums
 around the internet keep reiterating that on OSX to correctly handle
 GUI events you need to use the original thread allocated to your
 process to check for events and to call the Cocoa framework
 functionality.  Specifically, using a secondary thread (even a bound
 thread) is not sufficient with the Cocoa framework.

 I looked at the threading documentation in Control.Concurrent for GHC
 and it's not clear to me if this is even possible with GHC without
 restricting to the non-threaded RTS.  This means that using the GUI
 library from GHCI is not an option and using multiple OS threads in
 the final application is also not possible.  This means that some FFI
 libraries will be unusable.
>>>
>>> In a compiled program, the main thread is a bound thread, bound to the
>>> main
>>> OS thread of the process (i.e. the GUI thread in your case).  So you can
>>> safely make Cocoa calls using the main thread of your compiled Haskell
>>> program, and from other threads if you add some way to forward operations
>>> to
>>> the main thread, like gtk2hs's postGUI.
>>
>> Is my understanding correct that this is only the case for the
>> non-threaded RTS?
>
> No - I'm talking about the threaded RTS here.  It's trivially true of the
> non-threaded RTS too, because there's only one OS thread.
>
>>  If so, what do you do when you need to use the
>> threaded RTS?  My test was to check if the main thread was bound when
>> compiling with -threaded.  I got the impression that I couldn't
>> guarantee that the code was running on the original thread.
>
> You do have that guarantee for the main thread.  Could you point out the
> docs that gave you the opposite impression - I'll see if we can improve
> them.

I did read this section:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#g:8

And I played with some of the functions there.  What I didn't take
away from this was the guarantee that main runs on the original OS
thread.  I had the impression that it was running from some bound
thread, possibly created via runInBoundThread.  I think that ghc and
ghci are quite different in this regard.  It would probably be good to
mention that distinction.

Jason

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

Re: [Haskell-cafe] Arrow instance of function type [a] -> [b]

[Brandon Allbery]

On Wed, Jul 6, 2011 at 09:43, Steffen Schuldenzucker
 wrote:
>
> Hi Markus,
>
> On 07/06/2011 03:04 PM, Markus Läll wrote:
>>
>> [...]
>>
>> import Control.Arrow
>> import Control.Category
>>
>> type X a b = [a] ->  [b]
>>
>> instance Category X where
>>    id = map Prelude.id
>>    g . f = g Prelude.. f
>>
>> instance Arrow X where
>>    arr f = map f
>>    first f = unzip>>>  first f>>>  uncurry zip
>>
>> The problem is that it's not allowed to use partially applied type
>> synonyms. It is however possible to define a type synonym which value
>> is a partially applied type, but I haven't been able to figure out if
>> I could somehow use that fact in defining the X... Is it at all
>> possible, or is a newtype the only way to do it?
>>
>
> You should really use a newtype for that. Allowing partially applied type
> synonyms would greatly increase the expressiveness of the type language.
> (too much, actually)
> In fact, you could write arbitrary type level lambdas, like that:
>
>> type Y b a = [a] -> [b]
>
> But now, given instances like this:
>
>> instance Category X where ...
>>
>> instance Category Y where ...
>> -- uh, yeah, does it make sense in this case? Whatever, we *could* have an
>> instance.
>
> , any function of type [a] -> [b] will match both instances. So which
> instance to choose? We have two solutions:
>
> a) The compiler discovers itself that we have overlaps here and complains.
>
> This seems hard to me (is it even possible in finite time?). Note that it is
> easy if type synonyms are always fully applied because the compiler just has
> to fill in the definition of all the types and can then proceed to compare
> just the instance *heads*.
>
> b) You somehow annotate which instance to choose for each specific case. But
> that's exactly what newtypes are for!
>
> The problem does indeed occur in your example: What is (id :: [a] -> [b])
> supposed to be, Prelude.id (as given by the general instance for functions)
> or map Prelude.id (given by your instance)?
>
> -- Steffen
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
brandon s allbery                                      allber...@gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

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

Re: [Haskell-cafe] Arrow instance of function type [a] -> [b]

[Steffen Schuldenzucker]

Hi Markus,

On 07/06/2011 03:04 PM, Markus Läll wrote:

[...]

import Control.Arrow
import Control.Category

type X a b = [a] ->  [b]

instance Category X where
id = map Prelude.id
g . f = g Prelude.. f

instance Arrow X where
arr f = map f
first f = unzip>>>  first f>>>  uncurry zip

The problem is that it's not allowed to use partially applied type
synonyms. It is however possible to define a type synonym which value
is a partially applied type, but I haven't been able to figure out if
I could somehow use that fact in defining the X... Is it at all
possible, or is a newtype the only way to do it?



You should really use a newtype for that. Allowing partially applied 
type synonyms would greatly increase the expressiveness of the type 
language. (too much, actually)

In fact, you could write arbitrary type level lambdas, like that:

> type Y b a = [a] -> [b]

But now, given instances like this:

> instance Category X where ...
>
> instance Category Y where ...
> -- uh, yeah, does it make sense in this case? Whatever, we *could* 
have an instance.


, any function of type [a] -> [b] will match both instances. So which 
instance to choose? We have two solutions:


a) The compiler discovers itself that we have overlaps here and complains.

This seems hard to me (is it even possible in finite time?). Note that 
it is easy if type synonyms are always fully applied because the 
compiler just has to fill in the definition of all the types and can 
then proceed to compare just the instance *heads*.


b) You somehow annotate which instance to choose for each specific case. 
But that's exactly what newtypes are for!


The problem does indeed occur in your example: What is (id :: [a] -> 
[b]) supposed to be, Prelude.id (as given by the general instance for 
functions) or map Prelude.id (given by your instance)?


-- Steffen

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

Re: [Haskell-cafe] NLP libraries and tools?

[Dmitri O.Kondratiev]

Hi,
Continuing my search of Haskell NLP tools and libs, I wonder if the
following Haskell libraries exist (googling them does not help):
1) End of Sentence (EOS) Detection. Break text into a collection of
meaningful sentences.
2) Part-of-Speech (POS) Tagging. Assign part-of-speech information to each
token.
3) Chunking. Analyze each tagged token within a sentence and assemble
compound tokens that express logical concepts. Define a custom grammar.
4) Extraction. Analyze each chunk and further tag the chunks as named
entities, such as people, organizations, locations, etc.

Any ideas where to look for similar Haskell libraries?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Arrow instance of function type [a] -> [b]

[Markus Läll]

Hi!

Is it possible to define an Arrow instance of list to list functions?
Something like

import Control.Arrow
import Control.Category

type X a b = [a] -> [b]

instance Category X where
   id = map Prelude.id
   g . f = g Prelude.. f

instance Arrow X where
   arr f = map f
   first f = unzip >>> first f >>> uncurry zip

The problem is that it's not allowed to use partially applied type
synonyms. It is however possible to define a type synonym which value
is a partially applied type, but I haven't been able to figure out if
I could somehow use that fact in defining the X... Is it at all
possible, or is a newtype the only way to do it?


-- 
Markus Läll

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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[John Lato]

Message: 23

> Date: Wed, 06 Jul 2011 10:14:56 +0100
> From: Simon Marlow 
> Subject: Re: [Haskell-cafe] How to ensure code executes in the context
>of aspecific OS thread?
> To: Jason Dagit , cvs-...@haskell.org,Haskell
> Cafe
>
> Message-ID: <4e142790.8090...@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 05/07/2011 20:33, Ian Lynagh wrote:
> > On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
> >>
> >> In GHCi it's a different matter, because the main thread is running
> >> GHCi itself, and all the expressions/statements typed at the prompt
> >> are run in forkIO'd threads (a new one for each statement, in fact).
> >> If you want a way to run command-line operations in the main thread,
> >> please submit a feature request.  I'm not sure it can be done, but
> >> I'll look into it.
> >
> > We already have a way: -fno-ghci-sandbox
>
> Aha, I'd forgotten about that!  Thanks Ian.
>
> Simon
>

IIRC a lot of people have had trouble running GUI apps from within GHCi on
OS X, whether they're GLUT, Gtk2hs, WxHaskell, or native, and several users
consider this a large obstacle.  I know that I haven't been successful with
gtk2hs.  However, at this suggestion I just tried running a gtk2hs app I'm
developing with the -fno-ghci-sandbox flag, and it worked perfectly.

Thanks very much, Ian.

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

Re: [Haskell-cafe] function terms

[oleg]

Ian Childs wrote:
> I have a function that returns a witness to 's :: Term a' and 't ::
> Term b' having the same type, if they do, but I am wondering how to
> extend this to the first argument of an arrow type.

Basically you have to write the deconstruct that takes
(TRepr a), the witness for type a, and returns either Nothing or
  Just (exists b1 b2. (EQ a (b1->b2), TRepr b1, TRepr b2))

That is, if the type a is indeed an arrow type, you return the triple:
the witnesses for the argument and the result types and the witness
for the equality of a and b1->b2.

Problems like these often occur in type-checking (or in
de-serialization of a typed term from an untyped representations). The
following page discusses two (GADT and GADT-less) solutions:
http://okmij.org/ftp/tagless-final/course/course.html#type-checking

Specifically,
http://okmij.org/ftp/tagless-final/course/Typ.hs
defines such an arrow witness, names `AsArrow'.

Both approaches are essentially equivalent -- and both are quite
complex. It really takes a couple of hours to explain either of them.
I don't believe a simple solution exists.

 


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

Re: [Haskell-cafe] function terms

[Ian Childs]

Sorry, that should be (Const "="). The GADT is defined as follows:

data Var a where
  MkVar :: (GType a) => String -> Var a

data LTerm a where
  Var :: (GType a) => Var a -> LTerm a
  Const :: (GType a) => String -> LTerm a
  (:.) :: (GType a, GType b) => LTerm (a -> b) -> LTerm a -> LTerm b
  Abs :: (GType a, GType b) => Var a -> LTerm b -> LTerm (a -> b)
infixl 6 :.

(here i have used :. instead of App so that it is easier to read). I  
had to restrict types to the class (GType) of types that I have  
instantiated for comparison.



On 6 Jul 2011, at 11:16, Henning Thielemann wrote:



On Wed, 6 Jul 2011, Ian Childs wrote:

Term a is meant to be the simply-typed lambda-calculus as a GADT.  
Then given
two terms App (App "=" l1) r1, and App (App "=" l2) r2, I want to  
form App
(App "=" (App l1 l2)) (App r1 r2), but as you can see this will  
only work if
the types of l1 and l2, and r1 and r2, match as detailed  
previously. does

that make sense?


What is App? It looks like you apply it once to a string ("=") and  
also to

terms(?) like l1, r1. How is the GADT defined?



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

Re: [Haskell-cafe] function terms

[Henning Thielemann]

On Wed, 6 Jul 2011, Ian Childs wrote:

Term a is meant to be the simply-typed lambda-calculus as a GADT. Then given 
two terms App (App "=" l1) r1, and App (App "=" l2) r2, I want to form App 
(App "=" (App l1 l2)) (App r1 r2), but as you can see this will only work if 
the types of l1 and l2, and r1 and r2, match as detailed previously. does 
that make sense?


What is App? It looks like you apply it once to a string ("=") and also to 
terms(?) like l1, r1. How is the GADT defined?


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

Re: [Haskell-cafe] function terms

[Ian Childs]

Term a is meant to be the simply-typed lambda-calculus as a GADT.  
Then given two terms App (App "=" l1) r1, and App (App "=" l2) r2, I  
want to form App (App "=" (App l1 l2)) (App r1 r2), but as you can  
see this will only work if the types of l1 and l2, and r1 and r2,  
match as detailed previously. does that make sense?


On 6 Jul 2011, at 10:48, Henning Thielemann wrote:



On Wed, 6 Jul 2011, Ian Childs wrote:

Yes they are Haskell expressions - I called them terms because  
actually they
are GADTs of type Term a and Term b. I can't use type 'b -> c' as  
they are

part of a larger pattern.

I have a function that returns a witness to 's :: Term a' and  
't :: Term b'
having the same type, if they do, but I am wondering how to extend  
this to

the first argument of an arrow type.


Can you give us a bit more (but not too much) code in order to show  
the

problem?



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

Re: [Haskell-cafe] function terms

[Henning Thielemann]

On Wed, 6 Jul 2011, Ian Childs wrote:

Yes they are Haskell expressions - I called them terms because actually they 
are GADTs of type Term a and Term b. I can't use type 'b -> c' as they are 
part of a larger pattern.


I have a function that returns a witness to 's :: Term a' and 't :: Term b' 
having the same type, if they do, but I am wondering how to extend this to 
the first argument of an arrow type.


Can you give us a bit more (but not too much) code in order to show the 
problem?


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

Re: [Haskell-cafe] function terms

[Ian Childs]

Yes they are Haskell expressions - I called them terms because  
actually they are GADTs of type Term a and Term b. I can't use type  
'b -> c' as they are part of a larger pattern.


I have a function that returns a witness to 's :: Term a' and 't ::  
Term b' having the same type, if they do, but I am wondering how to  
extend this to the first argument of an arrow type.


Thanks

On 6 Jul 2011, at 10:23, Henning Thielemann wrote:



On Wed, 6 Jul 2011, Ian Childs wrote:

Suppose I have two terms s and t of type "a" and "b" respectively,  
and I want
to write a function that returns s applied to t if "a" is an arrow  
type of
form "b -> c", and nothing otherwise. How do i convince the  
compiler to

accept the functional application only in the correct instance?


Why can't 's' simply have type 'b -> c'? With "term" do you mean a  
Haskell

expression?



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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 06/07/2011 07:37, Jason Dagit wrote:


On Jul 5, 2011 1:04 PM, "Jason Dagit" mailto:dag...@gmail.com>> wrote:
 >
 > On Tue, Jul 5, 2011 at 12:33 PM, Ian Lynagh mailto:ig...@earth.li>> wrote:
 > > On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:
 > >>
 > >> In GHCi it's a different matter, because the main thread is running
 > >> GHCi itself, and all the expressions/statements typed at the prompt
 > >> are run in forkIO'd threads (a new one for each statement, in fact).
 > >> If you want a way to run command-line operations in the main thread,
 > >> please submit a feature request.  I'm not sure it can be done, but
 > >> I'll look into it.
 > >
 > > We already have a way: -fno-ghci-sandbox
 >
 > I've removed all my explicit attempts to forkIO/forkOS and passed the
 > command line flag you mention.  I just tried this but it doesn't
 > change the behavior in my example.

I tried it again and discovered that due to an argument parsing bug in
cabal-dev that the flag was not passed correctly. I explicitly passed it
and verified that it works. Thanks for the workaround. By the way, I did
look at the user guide for options like this and didn't see it. Which
part of the manual is it in?

Can I still make a feature request for a function to make code run on
the original thread? My reasoning is that the code which needs to run on
the main thread may appear in a library in which case the developer has
no control over how ghc is invoked.


I'm not sure how that would work.  The programmer is in control of what 
the main thread does, not GHC.  So in order to implement some mechanism 
to run code on the main thread, we would need some cooperation from the 
main thread itself.  For example, in gtk2hs the main thread runs an 
event handler loop which occasionally checks a queue for requests from 
other threads (at least, I think that's how it works).


Cheers,
Simon



The alternative appears to be context specific workarounds. I think that
a general solution, if possible, will make gui libraries easier to
develop for Ghc.  I'm hooping it's as simple as exposing a pthreads call.


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

Re: [Haskell-cafe] function terms

[Henning Thielemann]

On Wed, 6 Jul 2011, Ian Childs wrote:

Suppose I have two terms s and t of type "a" and "b" respectively, and I want 
to write a function that returns s applied to t if "a" is an arrow type of 
form "b -> c", and nothing otherwise. How do i convince the compiler to 
accept the functional application only in the correct instance?


Why can't 's' simply have type 'b -> c'? With "term" do you mean a Haskell 
expression?


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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 05/07/2011 20:38, Jason Dagit wrote:

On Tue, Jul 5, 2011 at 12:11 PM, Simon Marlow  wrote:

On 04/07/11 06:02, Jason Dagit wrote:


Hello,

I'm trying to get some GUI code working on OSX and numerous forums
around the internet keep reiterating that on OSX to correctly handle
GUI events you need to use the original thread allocated to your
process to check for events and to call the Cocoa framework
functionality.  Specifically, using a secondary thread (even a bound
thread) is not sufficient with the Cocoa framework.

I looked at the threading documentation in Control.Concurrent for GHC
and it's not clear to me if this is even possible with GHC without
restricting to the non-threaded RTS.  This means that using the GUI
library from GHCI is not an option and using multiple OS threads in
the final application is also not possible.  This means that some FFI
libraries will be unusable.


In a compiled program, the main thread is a bound thread, bound to the main
OS thread of the process (i.e. the GUI thread in your case).  So you can
safely make Cocoa calls using the main thread of your compiled Haskell
program, and from other threads if you add some way to forward operations to
the main thread, like gtk2hs's postGUI.


Is my understanding correct that this is only the case for the
non-threaded RTS?


No - I'm talking about the threaded RTS here.  It's trivially true of 
the non-threaded RTS too, because there's only one OS thread.



 If so, what do you do when you need to use the
threaded RTS?  My test was to check if the main thread was bound when
compiling with -threaded.  I got the impression that I couldn't
guarantee that the code was running on the original thread.


You do have that guarantee for the main thread.  Could you point out the 
docs that gave you the opposite impression - I'll see if we can improve 
them.


Cheers,
Simon

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

Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?

[Simon Marlow]

On 05/07/2011 20:33, Ian Lynagh wrote:

On Tue, Jul 05, 2011 at 08:11:21PM +0100, Simon Marlow wrote:


In GHCi it's a different matter, because the main thread is running
GHCi itself, and all the expressions/statements typed at the prompt
are run in forkIO'd threads (a new one for each statement, in fact).
If you want a way to run command-line operations in the main thread,
please submit a feature request.  I'm not sure it can be done, but
I'll look into it.


We already have a way: -fno-ghci-sandbox


Aha, I'd forgotten about that!  Thanks Ian.

Simon

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

[Haskell-cafe] (no subject)

[Ian Childs]

Suppose I have two terms s and t of type "a" and "b" respectively,  
and I want to write a function that returns s applied to t if "a" is  
an arrow type of form "b -> c", and nothing otherwise. How do i  
convince the compiler to accept the functional application only in  
the correct instance?


Thanks,
Ian

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