headers
Ian-Woo Kim | 1 Aug 2011 02:24
Picon
Gravatar

ANNOUNCE: HROOT-0.5.0.1 - haskell binding to ROOT

Hi, everyone,

I am pleased to announce a haskell binding to the ROOT analysis package, HROOT:

    http://hackage.haskell.org/package/HROOT

From wikipedia:
ROOT (http://root.cern.ch) is an object-oriented program and library
developed by CERN. It was originally designed for particle physics
data analysis and contains several features specific to this field,
but it is also used in other applications such as astronomy and data
mining.

ROOT includes
   * histogramming and graphing to view and analyze distributions and functions,
   * curve fitting (regression analysis) and minimization of functionals,
   * statistics tools used for data analysis,
   * matrix algebra,
   * four-vector computations, as used in high energy physics,
   * standard mathematical functions,
   * multivariate data analysis, e.g. using neural networks,
   * image manipulation, used, for instance, to analyze astronomical pictures,
   * access to distributed data (in the context of the Grid),
   * distributed computing, to parallelize data analyses,
   * persistence and serialization of objects, which can cope with
changes in class definitions of persistent data, access to databases,
   * 3D visualizations (geometry)
   * creating files in various graphics formats, like PostScript, PNG, SVG,
   * interfacing Python and Ruby code in both directions,
   * interfacing Monte Carlo event generators.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ben Lippmeier | 1 Aug 2011 03:45
Gravatar

Re: logic and types


On 01/09/2011, at 8:48 , Patrick Browne wrote:

> Hi,
> Below are some questions about the logical interpretation of types and
> type classes.
> 
> Thanks,
> Pat
> 
> module J where
> type Id = String
> type Position = Integer
> data Person = Person Id Position deriving Show
> 
> -- Is this an axiom at type level?
> class Pos a  where
>   getPos :: a -> Position

One way to think of a type class is that it defines a set of types. For example, Eq is the set of types that
support equality, and Pos is the set of types that have a position. By giving the class definition you've
defined what it means to be a member of that set, namely that members must support the 'getPos' method, but
without instances that set is empty. Whether you treat this bare class definition as an axiom depends on
what you want from your logical system. 

> -- The :type command says
> -- forall a. (Pos a) => a -> Position
> -- How do I write this in logic? (e.g. implies, and, or, etc)

Type systems are logical systems, there is no difference. Granted, some systems correspond to parts of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel M T Chakravarty | 1 Aug 2011 04:22
Picon
Picon
Favicon
Gravatar

Re: XCode Dependency for HP on Mac

In addition to the excellent reasons that Mark outlined, there is another important reason to *not*
include gcc and friends in the HP.  Every software developer (as opposed to friend of a friend who just
wanted to try to learn programming with Haskell on a road trip) will already have Xcode installed on their Mac.

Having two versions of gcc, make, lots of other tools, library headers, library objects, etc is going to
lead to subtle bugs and headaches; at the latest, when you compile your first multi-language project. 
(This is where this is not comparable to the situation on Windows with mingw.  A software developer on
Windows, will have Visual Studio installed, but usually not some flavour of the GNU tools.)

Manuel

PS: I am sure there is demand for a self-contained, lightweight beginners/teaching Haskell environment,
but let's not confuse that with the main distribution.

Mark Lentczner:
> Hiho - I'm the maintainer of the Mac installer for HP. I thought I'd
> chime in a bit:
> 
> On Mac OS X, "developer tools" is essentially synonymous with "Xcode".
> That is, to get the set of standard utilities needed for development
> on compiled executables (notably the "binutils"), you install Xcode.
> True, it also includes the IDE called Xcode, but the vast bulk of that
> installation are things like headers, link libraries, command line
> tools, and other utilities for development of compiled executables in
> general.
> 
> As several have pointed out, you can download Xcode for free. If you
> have Lion, you can get Xcode 4 for free from the Mac Store. Xcode 3
> for 10.6 and 10.5. Traditionally, Apple has included Xcode on one of
> the CD-ROMs that came with a new computer, and/or as an installer
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Snoyman | 1 Aug 2011 05:08
Favicon
Gravatar

Re: A language that runs on the JVM or .NET has the advantage of Oracle & Microsoft making those layers more parallelizable.

On Sun, Jul 31, 2011 at 11:33 PM, Niklas Larsson <metaniklas <at> gmail.com> wrote:
>>
>> I m not GHC developer but wouldn't JVM LLVM backend be sufficient? Since
>> new GHC AFAIK uses LLVM then it would allow compiling Haskell to LLVM
>> and LLVM to JVM.
>>
>
> The hard part wouldn't be the code generation, but the interop with
> the class libraries, finding a workable way to use Java classes from
> Haskell and exporting Haskell code masquerading as Java classes.

I personally would be very happy to just get Haskell code to run in
the JVM, forgetting entirely about interop. It would greatly reduce
barrier-to-entry when trying to send Haskell code to clients.

Michael
Permalink | Reply | 0 comments |
headers
Donn Cave | 1 Aug 2011 08:08
Favicon

Re: State of play with Haskell-Cocoa (Objective-C)bindings?

Quoth Luke Evans <luke <at> eversosoft.com>,
> I'm planning to start an Objective-C/Cocoa project and would like to
> write it in Haskell as much as possible.
>
> Of course, I can contrive to split the project into app logic (Haskell)
> and UI (Objective-C) with some sort of minimal interface between them;
> possibly just plain old C FFI.
>
> However, I would like an interface that's as 'automatic' as possible -
> one that preferably means that I don't have to spend a lot of time
> maintaining a somewhat heavy-weight special interface layer as I grow
> my code on both sides of the divide.
> Preferably the suture line is as far over on the Objective-C side as
> possible, so that I can write pretty much everything in Haskell.
>
> Now, I see a couple of references to some options:
> - HOC seems very close to what I'm looking for, but the project looks
> pretty 'dormant'.
> - I see some mention of an Objective-C FFI, but am uncertain if this
> is in any current build of GHC.
>
> Are there any other options up anyone's sleeves?  Anybody working on
> something interesting I could play with?

You've probably seen this already and it didn't qualify as
"something interesting", but http://www.haskell.org/haskellwiki/Using_Haskell_in_an_Xcode_Cocoa_project
still works as of MacOS 10.6 and GHC 7.0.3.  No extra libraries or
tools needed - you just wrangle your Haskell .o files and all the
attendant Haskell libraries into the Xcode project, give Interface
Builder Objective C stubs to work with, and call out to Haskell
(Continue reading)

Permalink | Reply | 0 comments |
headers
wren ng thornton | 1 Aug 2011 08:57

Re: logic and types

On 8/31/11 6:48 PM, Patrick Browne wrote:
> Hi,
> Below are some questions about the logical interpretation of types and
> type classes.
>[...]
>
> -- Is this an axiom at type level?

It depends how exactly you mean "axiom". Under some interpretations, 
Haskell has no way to specify axioms, since all specifications are 
accompanied by their definitions (e.g., types are defined by their 
constructors, classes are defined by their members, functions are 
defined by their expressions). In other words, there is nothing which 
lacks computational content. In contrast, systems like Coq and Agda do 
have mechanisms for asserting axioms.

> -- forall a. (Pos a) =>  a ->  Position
> -- How do I write this in logic? (e.g. implies, and, or, etc)
> -- What exactly is being asserted about the type variable and/or about
> the class?
> -- I am not sure of the respective roles of =>  and ->  in a logical context

Loosely speaking,

     * forall translates to universal quantification,
     * classes and type constructors translate to predicates,
     * type/data families translate to functions in the logic,
     * the arrows translate to implications,
     * products/tuples translate to conjunction,
     * coproducts/unions translate to disjunction,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2011 12:05
Picon

Re: Unbelievable parallel speedup

On 03/06/2011 13:10, John D. Ramsdell wrote:
> I've enjoyed reading Simon Marlow's new tutorial on parallel and
> concurrent programming, and learned some surprisingly basic tricks.  I
> didn't know about the '-s' runtime option for printing statistics.  I
> decided to compute speedups for a program I wrote just as Simon did,
> after running the program on an unloaded machine with four processors.
>   When I did, I found the speedup on two processors was 2.4, on three
> it was 3.2, and on four it was 4.4!  Am I living in a dream world?
>
> I ran the test nine more times, and here is a table of the speedups.
>
> 2.35975	3.42595	4.39351
> 1.57458	2.18623	2.94045
> 1.83232	2.77858	3.41629
> 1.58011	2.37084	2.94913
> 2.36678	3.63694	4.42066
> 1.58199	2.29053	2.95165
> 1.57656	2.34844	2.94683
> 1.58143	2.3242	2.95098
> 2.36703	3.36802	4.41918
> 1.58341	2.30123	2.93933
>
> That last line looks pretty reasonable to me, and is what I expected.
> Let's look at a table of the elapse times.
>
> 415.67	176.15	121.33	94.61
> 277.52	176.25	126.94	94.38
> 321.37	175.39	115.66	94.07
> 277.72	175.76	117.14	94.17
> 415.63	175.61	114.28	94.02
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edward Amsden | 1 Aug 2011 17:34
Picon

Re: State of play with Haskell-Cocoa (Objective-C) bindings?

On Sun, Jul 31, 2011, Luke Evans <luke <at> eversosoft.com> wrote:
> - HOC seems very close to what I'm looking for, but the project looks pretty 'dormant'.

My last go-round with HOC it failed at parsing Apple's Objective-C
headers. I've been thinking of digging into it and fixing it, but I'm
a student with very little time so I've not started yet.
--

-- 
Edward Amsden
Student
Computer Science
Rochester Institute of Technology
www.edwardamsden.com
Permalink | Reply | 0 comments |
headers
Alex Clemmer | 1 Aug 2011 17:51
Picon
Gravatar

Regular Expression Parsing via derivatives

Hi Haskell people,

I've been snooping through various mailing lists and the current Haskell implementation of regular expressions and I was wondering if there has been a discussion about implementing regex parsing with derivatives. If so, I haven't seen it. If not, I'd like to have a discussion about it -- if for no other reason than to decide whether I should implement it as a library, or (to attempt to implement it) as a core feature.

For those of you who don't know, recent work by Might and Darais indicates that parsing CFGs can be done better (i.e., significantly faster) than more "traditional" approaches. Might's presenting at ICFP later in September about it.

I guess the first thing I should ask is, which mailing list is actually the right place to field this inquiry. I considered dropping it in the main haskell list, but wasn't sure how people would respond.

--
Alex

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Permalink | Reply | 5 comments |
headers
Antoine Latter | 1 Aug 2011 18:26
Picon
Gravatar

Re: Regular Expression Parsing via derivatives

On Mon, Aug 1, 2011 at 10:51 AM, Alex Clemmer
<clemmer.alexander <at> gmail.com> wrote:
> Hi Haskell people,
>
> I've been snooping through various mailing lists and the current Haskell
> implementation of regular expressions and I was wondering if there has been
> a discussion about implementing regex parsing with derivatives. If so, I
> haven't seen it. If not, I'd like to have a discussion about it -- if for no
> other reason than to decide whether I should implement it as a library, or
> (to attempt to implement it) as a core feature.
>
> For those of you who don't know, recent work by Might and Darais indicates
> that parsing CFGs can be done better (i.e., significantly faster) than more
> "traditional" approaches. Might's presenting at ICFP later in September
> about it.
>
> I guess the first thing I should ask is, which mailing list is actually the
> right place to field this inquiry. I considered dropping it in the main
> haskell list, but wasn't sure how people would respond.
>

This is probably the right list to ask.

I don't know much about the topic, a a quick Google search turned up:

http://hackage.haskell.org/package/regex-pderiv

which has the right keywords.

More discussion on related (or not!) here:

http://www.google.com/search?q=Regular+Expression+derivative+haskell&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:unofficial&client=firefox-a

Antoine

> --
> Alex
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
Permalink | Reply | 3 comments |

Gmane