[Haskell-cafe] how to change a process name

2011-07-07 Thread 山本和彦
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


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

2011-07-07 Thread Simon Marlow

On 06/07/2011 21:11, David Barbour wrote:

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlow marlo...@gmail.com
mailto:marlo...@gmail.com 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.


That's a fair point.


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.


Interruption is not affected, as far as I'm aware.

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?

2011-07-07 Thread Simon Marlow

On 06/07/2011 21:19, Jason Dagit wrote:

On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlowmarlo...@gmail.com  wrote:

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



On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlowmarlo...@gmail.com
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.


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


Now that I think about it, the original reason may have been that if the 
computation grows a large stack, having it in a separate thread means 
GHCi can recover the memory.  However we have been able to recover stack 
memory for some time now, so that is no longer an issue.


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?

2011-07-07 Thread Aleksandar Dimitrov
It's actually a shame we're discussing this on -cafe and not on -nlp. Then
again, maybe it's going to prompt somebody to join -nlp, and I'm gonna CC it
there, because some folks over there might be interested, but not read -cafe.

On Wed, Jul 06, 2011 at 07:22:41PM -0700, wren ng thornton wrote:
 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.

That is indeed one of the best ways to do it (for Indo-European languages,
anyway.) When you mentioned Arabic for producing sentences that go on for ages —
you don't really need to go that far. I have had the doubtful pleasure of
reading Kant and Hegel in their original versions. In German, it is sometimes
still considered good style to write huge sentences. I once made it a point,
just to stick it to a Kant-loving-person, to produce a sentence that spanned 2
whole pages (A4.) It wasn't even difficult.

I sometimes think that we should just adopt a similar notion of span, like
rhetorical structure theorists do. In that case, you're not segmenting
sentences, but discourse atoms — those are even more ill-defined, however.

 But the problem is that what constitutes an appropriate solution for
 computational needs is still very ill-defined. 

Well, yes, and, well, no. Tokens are ill-defined. There's no good consensus on
how you should parse tokens (i.e., is in spite of one token or three?) either,
and so you just pick one that works for you. Same for sentence boundaries:
they're sometimes also ill-defined, but who says you need to define it well?

Maybe there's just a purpose-driven definition? — that people can agree on,
anyways. My purpose is either tagging, or parsing, or NE-detection, or
computational semantics… In all cases, I'm choosing the definition my tools can
use. Not because that's correct, but I don't really need it to be, no?

I'm very much a works for me person in these matters. Mostly because I'm tired
of linguists fighting each other over trivial matters. Give me something I can
work with already!

Regards,
Aleks


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


[Haskell-cafe] Web Framework to Show Experimental Data

2011-07-07 Thread Dmitri O.Kondratiev
Hi!
I am looking for the Haskell libraries to quickly create some Web Framework
to Show Experimental Data.
Please share your experience and ideas. What tools would you chose for such
a framework:

== Architecture
There are several unsynchronized processes:
1) Finder - demon that periodically searches and collects JSON data from the
Web and stores this data in some sort of Archive (DB).
2) Processor - demon that periodically process new data from Archive
collected by Finder and stores results of its work in the same Archive.
3) Web application that shows processed data in a browser.

== General Requirements
*** Main requirement - simplicity and high speed of development ***
- Max Data storage capacity - 10 Mb
- Max number of Web users - 50
- Web UI shows what Archive has at the moment of user request.

== Web UI Requirements
- Multi-page view of long data sets (some sort of scrolling)
- Simple graphs and charts (desirable)

== Questions
1) What to use for the Archive? Though input data is in JSON format, data
generated from it is binary vectors. Not sure that CouchDB is a good choice
in this case.
What simple (Haskell lib + DB) combination one may advise that support
concurrent read / write access with simple locking (don't need full
transactional support)?
2) Web framework? Don't need AJAX, just basic stuff but simple and easy to
code forms?

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


Re: [Haskell-cafe] Web Framework to Show Experimental Data

2011-07-07 Thread Chris Smith
On Thu, 2011-07-07 at 13:21 +0400, Dmitri O.Kondratiev wrote:
 1) What to use for the Archive? Though input data is in JSON format,
 data generated from it is binary vectors. Not sure that CouchDB is a
 good choice in this case. 
 What simple (Haskell lib + DB) combination one may advise that support
 concurrent read / write access with simple locking (don't need full
 transactional support)?

I think this might be an excellent place to use Lemmih's acid-state
package.  If I read you correctly, you basically want to store a small
enough amount of data that it's not a concern that it will need to
reside in memory, and it's fairly regular so there won't be a lot of
value in ad hoc queries?  If this is the case, then acid-state will let
you store it in Haskell data types, and with a bit of Template Haskell,
you can access it in a persistent way.

 2) Web framework? Don't need AJAX, just basic stuff but simple and
 easy to code forms?

Well, I like Snap enough that I became a core developer for the project,
but this seems like a place it's particularly well suited.  If you just
want something really simple and clean and easy to use, Snap is that
thing.  Snap itself is very lightweight, but if you want some kind of
automated form support, then there is a snap backend for
digestive-functors.  That's a little complex for my taste, but it is one
way to do composing of forms by sticking together form handlers,
validators, and the like.  Personally, I'm a fan of just using getParam
to retrieve the data and writing Haskell code to do what you want.

-- 
Chris


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


[Haskell-cafe] CFP: PADL'12 - Practical Aspects of Declarative Languages 2012

2011-07-07 Thread Claudio Russo
   [Apologies if you receive multiple copies.]

Call for Papers
  ===

  14th International Symposium on 
  Practical Aspects of Declarative Languages (PADL 2012)

http://research.microsoft.com/~crusso/padl12

 Philadelphia, Pennsylvania, USA, January 23-24, 2012
Co-located with ACM POPL'12

Abstract/Paper submission deadline: September 10th/17th, 2011


   Conference Description
  ==

   Declarative languages build on sound theoretical bases to provide attractive 
frameworks for application development. These languages have been successfully 
applied to many different real-world situations, ranging from data base 
management to active networks to software engineering to decision support 
systems.

   New developments in theory and implementation have opened up new application 
areas. At the same time, applications of declarative languages to novel 
problems raise numerous interesting research issues. Well-known questions 
include designing for scalability, language extensions for application 
deployment, and programming environments. Thus, applications drive the progress 
in the theory and implementation of declarative systems, and benefit from this 
progress as well.

   PADL is a forum for researchers and practitioners to present original work 
emphasizing novel applications and implementation techniques for all forms of 
declarative concepts, including, functional, logic, constraints, etc. Topics of 
interest include, but are not limited to:

   * Innovative applications of declarative languages
   * Declarative domain-specific languages and applications
   * Practical applications of theoretical results
   * New language developments and their impact on applications
   * Declarative languages and Software Engineering
   * Evaluation of implementation techniques on practical applications
   * Practical experiences and industrial applications
   * Novel uses of declarative languages in the classroom
   * Practical extensions such as constraint-based, probabilistic, and 
 reactive languages.

   PADL'12 welcomes new ideas and approaches pertaining to applications and 
implementation of declarative languages. In this occasion PADL is co-located, 
as traditionally, with ACM POPL, which will be held immediately following PADL, 
January 25-27. The symposium will be held in Philadelphia, Pennsylvania, USA.



  Important Dates and Submission Guidelines
  =

  Abstract Submission:September 10, 2011
  Paper Submission: September 17, 2011
  Notification: October 22, 2011
  Camera-ready:   November 5, 2011
  Symposium:January 23-24, 2012

   Authors should submit an electronic copy of the full paper in PDF using the 
Springer LNCS format. The submission will be done through EasyChair conference 
system. If electronic submission is impossible, please contact the program 
chairs for information on how to submit hard copies. All submissions must be 
original work written in English. Submissions must be unpublished and not 
submitted for publication elsewhere. Work that already appeared in unpublished 
or informally published workshops proceedings may be submitted. PADL'12 will 
accept both technical and application papers:

   * Technical papers must describe original, previously unpublished
 research results. Technical papers must not exceed 15 pages in
 Springer LNCS format.
   * Application papers are a mechanism to present important practical
 applications of declarative languages that occur in industry or
 in areas of research other than Computer Science. Application
 papers will be published in the Springer-Verlag conference
 proceedings, and will be presented in a separate session.
 Application papers are expected to describe complex and/or
 real-world applications that rely on an innovative use of
 declarative languages. Application descriptions, engineering
 solutions and real-world experiences (both positive and negative)
 are solicited. The limit for application papers is 6 pages in
 Springer LNCS format.


 Program Committee
 =

Marcello Balduccini, Intelligent Systems Department, Kodak Research Labs 
Edwin Brady, University of St Andrews, Scotland 
Henning Christiansen, Roskilde University, Denmark 
Agostino Dovier, University of Udine, Italy 
Matthew Flatt, University of Utah, USA 
Gopal Gupta, University of Texas at Dallas, USA 
John Hughes, Chalmers University of Technology, Sweden; Quviq AB 
Gabriele Keller, University of New South Wales, Australia 
Lunjin Lu, 

Re: [Haskell-cafe] Web Framework to Show Experimental Data

2011-07-07 Thread Dmitri O.Kondratiev
Chris, thank you so much for pointing me into the right direction!
From acid-state package description:
Use regular Haskell data structures as your database... - exactly what I
need!
Snap looks very lively too, simple and you can code view in Haskell, which
means concentrate on  the problem, not on the boilerplate code!

Capital advice, thanks!

Chris Smith cdsmith at gmail.com  wrote:
Thu Jul 7 15:11:10 CEST 2011

Previous message: [Haskell-cafe] Web Framework to Show Experimental Data
Next message: [Haskell-cafe] Installation failure crypto-api on MAC
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, 2011-07-07 at 13:21 +0400, Dmitri O.Kondratiev wrote:
 1) What to use for the Archive? Though input data is in JSON format,
 data generated from it is binary vectors. Not sure that CouchDB is a
 good choice in this case.
 What simple (Haskell lib + DB) combination one may advise that support
 concurrent read / write access with simple locking (don't need full
 transactional support)?

I think this might be an excellent place to use Lemmih's acid-state
package. If I read you correctly, you basically want to store a small
enough amount of data that it's not a concern that it will need to
reside in memory, and it's fairly regular so there won't be a lot of
value in ad hoc queries? If this is the case, then acid-state will let
you store it in Haskell data types, and with a bit of Template Haskell,
you can access it in a persistent way.

 2) Web framework? Don't need AJAX, just basic stuff but simple and
 easy to code forms?

Well, I like Snap enough that I became a core developer for the project,
but this seems like a place it's particularly well suited. If you just
want something really simple and clean and easy to use, Snap is that
thing. Snap itself is very lightweight, but if you want some kind of
automated form support, then there is a snap backend for
digestive-functors. That's a little complex for my taste, but it is one
way to do composing of forms by sticking together form handlers,
validators, and the like. Personally, I'm a fan of just using getParam
to retrieve the data and writing Haskell code to do what you want.

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


Re: [Haskell-cafe] Web Framework to Show Experimental Data

2011-07-07 Thread Dmitri O.Kondratiev
According to acid-state package description:
Use regular Haskell data structures as your database... - exactly what I
need!
Snap looks very lively too, simple and you can code view in Haskell, which
means concentrate on  the problem, not on the boilerplate code!

Capital advice, thanks Chris!

Chris Smith cdsmith at gmail.com  wrote:
Thu Jul 7 15:11:10 CEST 2011

Previous message: [Haskell-cafe] Web Framework to Show Experimental Data
Next message: [Haskell-cafe] Installation failure crypto-api on MAC
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, 2011-07-07 at 13:21 +0400, Dmitri O.Kondratiev wrote:
 1) What to use for the Archive? Though input data is in JSON format,
 data generated from it is binary vectors. Not sure that CouchDB is a
 good choice in this case.
 What simple (Haskell lib + DB) combination one may advise that support
 concurrent read / write access with simple locking (don't need full
 transactional support)?

I think this might be an excellent place to use Lemmih's acid-state
package. If I read you correctly, you basically want to store a small
enough amount of data that it's not a concern that it will need to
reside in memory, and it's fairly regular so there won't be a lot of
value in ad hoc queries? If this is the case, then acid-state will let
you store it in Haskell data types, and with a bit of Template Haskell,
you can access it in a persistent way.


 2) Web framework? Don't need AJAX, just basic stuff but simple and
 easy to code forms?

Well, I like Snap enough that I became a core developer for the project,
but this seems like a place it's particularly well suited. If you just
want something really simple and clean and easy to use, Snap is that
thing. Snap itself is very lightweight, but if you want some kind of
automated form support, then there is a snap backend for
digestive-functors. That's a little complex for my taste, but it is one
way to do composing of forms by sticking together form handlers,
validators, and the like. Personally, I'm a fan of just using getParam
to retrieve the data and writing Haskell code to do what you want.

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


Re: [Haskell-cafe] how to change a process name

2011-07-07 Thread Donn Cave
Quoth Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) k...@iij.ad.jp,

 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.

If you mean, while the program is running - I don't agree that we can
change it by overriding argv on UNIX.  This might work on some specific
operating systems, but not on all of them.  I believe POSIX does not
specify any way to do this, and in fact there is no reasonably portable
way to do it.  That's probably why Haskell doesn't support it.

Now, if you mean argv[0] in execve(2), through which the caller
determines the name for the new process ... I can't explain why
Haskell's System.Posix.Process.executeFile doesn't support that,
it looks like gratuitous breakage to me.

Donn

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


[Haskell-cafe] Jenkins/Hudson support for GHC warnings?

2011-07-07 Thread Bryan O'Sullivan
Hi, folks -

I know there are quite a few Haskell projects using the Jenkins (formerly
Hudson) continuous build system, and I wonder if anyone has figured out how
to get it reliably collecting errors and warnings from GHC. The standard
warnings pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Warnings+Plugindoes
a bad job - it tends to identify random (sometimes even empty) bits of
build output as warnings. If you've configured it to behave better with GHC
/ hpc / QuickCheck / cabal-install, you'd be doing us a great service by
sharing your tricks!

Thanks,
Bryan.
___
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?

2011-07-07 Thread Jason Dagit
On Thu, Jul 7, 2011 at 12:41 AM, Simon Marlow marlo...@gmail.com wrote:
 On 06/07/2011 21:19, Jason Dagit wrote:

 On Wed, Jul 6, 2011 at 12:52 PM, Simon Marlowmarlo...@gmail.com  wrote:

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


 On Wed, Jul 6, 2011 at 8:09 AM, Simon Marlowmarlo...@gmail.com
 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.

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

 Now that I think about it, the original reason may have been that if the
 computation grows a large stack, having it in a separate thread means GHCi
 can recover the memory.  However we have been able to recover stack memory
 for some time now, so that is no longer an issue.

Then by all means, please make -fno-ghci-sandbox the default! :)

Thanks
Jason

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


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

2011-07-07 Thread Trevor L. McDonell

On 07/07/2011, at 1:36 AM, Johannes Waldmann wrote:

 actually libcuda is in /usr/lib/nvidia-current ...

 It still feels strange that I can build the examples from
 NVIDIA_GPU_Computing_SDK/C/src/  without modifying LDFLAGS.  

Okay. I've modified to configure script to fix the extra space issue, and to
push LDFLAGS and CFLAGS onto the environment before cabal attempts the build. It
should also correctly handle the --extra-[lib,include]-dirs flags now. Hopefully
that goes smoother in future...

I had a look though the makefiles used by the NVIDIA examples on my ubuntu test
machine, but found no mention of searching /usr/lib/nvidia-current, so I'm not
sure where that came from. Maybe that's part of the examples installer script,
but I'll have to look into that later.

 Anyway, when running accelerate-examples --cuda I get mixed results,
 
 Is there a way to find out the expected results/failures 
 for a recent accelerate package install?
 (So I can avoid reporting them.)

That is a good point. Some of the tests are expected to fail but that's not
written down anywhere yet; I'll add a README.

The stack overflow errors come from the reference implementations, not the
accelerate code; give the RTS more space to play in with +RTS -K32M or
similar. Off the top of my head permute-hist, radixsort, one of the slice tests,
and scanseg-sum fail.


Thanks for the bug reports so far!

-Trev


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


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

2011-07-07 Thread wren ng thornton
On 7/7/11 3:38 AM, Aleksandar Dimitrov wrote:
 On Wed, Jul 06, 2011 at 07:27:10PM -0700, wren ng thornton wrote:
 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.

 The issue is this: strict ByteStrings retain pointers to the original
chunk. The
 chunk is probably bigger than you'd want to keep in memory, if you, say,
wanted
 to just keep one or two words. In my case, the chunk was some 65K (that
was my
 Iteratee chunk size.)

Oh, that issue. Yeah, I maintain an intern table and make sure that the
copy in the table is a trimmed copy instead of keeping the whole string
alive. I guess I should factor that part of my tagger out into a separate
package :)

I didn't know if you meant there was a technical issue, e.g. something
about the fact that ByteStrings uses pinned memory (whereas Text doesn't
IIRC).

-- 
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?

2011-07-07 Thread wren ng thornton
On 7/7/11 3:50 AM, Aleksandar Dimitrov wrote:
 It's actually a shame we're discussing this on -cafe and not on -nlp. Then
 again, maybe it's going to prompt somebody to join -nlp, and I'm gonna
CC it
 there, because some folks over there might be interested, but not read
-cafe.

Quite :)

 When you mentioned Arabic for producing sentences that go on for ages —
 you don't really need to go that far. I have had the doubtful pleasure of
 reading Kant and Hegel in their original versions. In German, it is
sometimes
 still considered good style to write huge sentences. I once made it a
point,
 just to stick it to a Kant-loving-person, to produce a sentence that
spanned 2
 whole pages (A4.) It wasn't even difficult.

The Romans were big fans of that too (though there's only a small group of
folks interested in doing NLP on Latin these days). I've only read Hegel
et al. in translation, but the Latin I've read falls nicely into the
notion of span. It doesn't, however, always fall nicely into a
clause-based approach like Japanese does. Then again, that could be due to
the poetic/rhetorical nature of the texts in question.

I wonder if there's been any computational attempt to make the notion of
span or discourse atoms rigorous enough for pragmatic use...


 I'm very much a works for me person in these matters. Mostly because
I'm tired
 of linguists fighting each other over trivial matters. Give me something
I can
 work with already!

I can't help but be a (meta)theorist. But then, I'm of the firm opinion
that theory must be grounded in actual practice, else it belongs more to
the realm of theology than science.

-- 
Live well,
~wren



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