DAMP 2009 CFP reminder & revised full paper deadline

[Note the revised full paper submission date.]

                           CALL FOR PAPERS

                         DAMP 2009: Workshop on
              Declarative Aspects of Multicore Programming
                         Savannah, GA, USA
                      (co-located with POPL 2009)
                           January 20, 2009

                ABSTRACT SUBMISSION DEADLINE: OCTOBER 10

                 http://www.cse.unsw.edu.au/~pls/damp09/

Important Dates:

      Deadline for abstract submission: October 10, 2008
    Deadline for full paper submission: October 14, 2008
            Notification of acceptance: November 10, 2008
                      Final papers due: November 17, 2008
                             DAMP 2009: January 20, 2009

DAMP 2009 is the fourth in a series of one-day workshops seeking to
explore ideas in programming language design that will greatly
simplify programming for multicore architectures, and more generally
for tightly coupled parallel architectures. DAMP 2009 is co-located
with the ACM SIGPLAN - SIGACT Symposium on Principles of Programming
Languages (POPL 2009).

                             Scope

ANNOUNCE: SourceGraph-0.1 and Graphalyze-0.3

I've now uploaded my SourceGraph program to Hackage [1].  It's rather
simple at the moment, but if you pass in the .cabal file as a
parameter (e.g. run it as "SourceGraph Foo.cabal"), it will create in
the same directory as the .cabal file a Directory called "SourceGraph"
that contains an html report of some basic graph-theoretic analysis of
your code.

The output format isn't ideal, but it should serve it's purpose for
now (I'll fix it up and actually make it usable once my Thesis has
been handed in).  What I'd appreciate if people could try it out and
tell me if there's any code, etc. that it can't parse.  At the moment,
it ignores all Data-based functions (e.g. class and instance
declarations as well as record functions) and only looks at
"stand-alone" functions (i.e. normal functions).

SourceGraph requires version 0.3 of my Graphalyze library (version 0.2
added the reports in, but had some bugs that 0.3 fixes).

[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph

--

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
IvanMiljenovic.wordpress.com

PEPM 2009 - final call for papers

                                F I N A L

                      C A L L   F O R   P A P E R S

                          === P E P M  2009 ===

                         ACM SIGPLAN Workshop on
              Partial Evaluation and Program Manipulation

            http://www.clip.dia.fi.upm.es/Conferences/PEPM09

                           January 19-20, 2009
                         Savannah, Georgia, USA
                       (Affiliated with POPL 2009)

IMPORTANT DATES

           Abstract due:  October 12, 2008
             Submission:  October 17, 2008
    Author Notification: November 10, 2008
     Camera-Ready Paper: November 17, 2008

SCOPE

The   PEPM  Symposium/Workshop  series   aims  at   bringing  together
researchers  and  practitioners  working   in  the  areas  of  program
manipulation, partial evaluation, and program generation. PEPM focuses
on  techniques,  theory,  tools,  and  applications  of  analysis  and
manipulation of programs. PEPM is classified as category A in the CORE

TLDI 2009: call for papers

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

ANN: Haskell-Embedded System Design: ForSyDe 3.0 and Tutorial

Hi everyone,

I am glad to announce the 3.0 release of ForSyDe's implementation, now
available from HackageDB.

The ForSyDe (Formal System Design) methodology has been developed with
the objective to move system design (e.g. System on Chip, Hardware and
Software systems) to a higher level of abstraction.

ForSyDe is implemented as a Haskell-embedded behavioral DSL (Domain
Specific Language).

>From this release, ForSyDe includes a new deep-embedded DSL and
embedded compiler. We have also published tutorial which should be
much more user-friendly than the Haddock documentation and the ForSyDe
research papers.

ForSyDe includes two DSL flavours  which offer different features:

  1) Deep-embedded DSL (ForSyDe.Signal)

    Deep-embedded signals, based on the same concepts as Lava, are
    aware of the system structure. Based on that structural information
    ForSyDe's embedded compiler, can perform different analysis and
    transformations.
        o Thanks to Template Haskell, computations are expressed in
           Haskell, not needing to specifically design a DSL for that
           purpose.
        o Embedded compiler backends:
              + Simulation
              + VHDL (with support for Modelsim and Quartus II)
              + GraphML (with yFiles graphical markup support.)
        o Synchronous model of computation.
        o Support for components.
        o Support for fixed-sized vectors à la VHDL.

  2) Shallow-embedded DSL (ForSyDe.Shallow.Signal)

    Shallow-embedded signals are modeled as streams of data
    isomorphic to lists. Systems built with them are unfortunately
    restricted to simulation, however, shallow-embedded signals
    provide a rapid-prototyping framework with which to experiment
    with Models of Computation (MoCs).
        o Synchronous MoC.
        o Untimed MoC.
        o Continuous Time MoC.
        o Domain Interfaces allow connecting various subsystems
           with different timing (domains) regardless of their MoC.
        o Deep-embedded models can be integrated through
           simulation.

Links
====
ForSyDe website:
http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/
ForSyDe tutorial:
http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/files/tutorial/tutorial.html
HackageDB package page:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe
Darcs repository: darcs get
http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/darcs/ForSyDe/

ANNOUNCE: Graphalyze-0.1

I'd like to announce the initial release of my graph-theoretic
analysis library, Graphalyze [1], the darcs repo for which is also
available [2].

This is a pre-release of the library that I'm writing for my
mathematics honours thesis, "Graph-Theoretic Analysis of the
Relationships in Discrete Data".  I'll also be releasing a tool that
uses this library to analyse the structure of Haskell code, that I'm
tentatively calling SourceGraph.  As it stands, the library has a
number of algorithms included, some of which I've developed from
scratch (e.g. clique finder), and others are implementations of
published algorithms (mainly the two clustering algorithms).  The code
is meant to be more readable than efficient, and I wanted to explore
ways of developing algorithms that match more closely the way graphs
work (which makes FGL a much nicer fit than matrix-based or list-based
graph data structures).

This library is only a pre-release, as whilst everything in there
works (at least it does for me), I'd like to get some feedback from
the community, especially since this is my first ever released solo
piece of code (I've coded assignments, and worked on projects with
others, but have never released anything that I've been solely
responsible for before).  In particular, have I written the .cabal
file correctly?

Also, I'd like advice on something else: the part of the library that
I'd like to develop still is the reporting framework.  The end goal of
the library is for the user to specify which algorithms they want
applied to their data, and then the library produces a document with
the results.  This document is _not_ meant to be machine readable.  As
such, I can think of three options:

1) Plain text, with graphs either in seperate image files (using
graphviz) or else as plaintext (FGL's show function).
2) Generate LaTeX code.
3) Generate Pandoc [3] compatible Markdown, and let the user convert
it into whatever format they prefer.

I'm not a big fan of option 1), as it is probably the most unreadable
in general.  I'd like to use Pandoc, as it is theoretically possible
to convert it to numerous other filetypes, however with inline linking
there's still no way (at least I can find) to have images scaled to
the correct size automatically.  So unless I pre-scale the images,
using option 3) and then converting to PDF via LaTex generation of the
Markdown sources is probably out.   As such, what would you all prefer
to read as a documentation-style report of your software?

1) A PDF via LaTeX, which has the advantage of being printable and all
in one file
2) HTML via Pandoc, which lets you have the images linked separately
from the document, and thus no need to shrink them down (they can stay
at the natively generated size, and thus easier to zoom in, etc.).

Finally, I'll be giving my honours talk on this next Monday.  So if
you're in Brisbane on 6 October and interested, it'll be on at 2PM at
the University of Queensland (where as part of it I'll be explaining
to mathematicians why Haskell is a great language to use for
mathematics... or at least trying to!).

[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze
[2] http://code.haskell.org/Graphalyze/
[3] http://johnmacfarlane.net/pandoc

--

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
IvanMiljenovic.wordpress.com

Symposium videos

Guerilla videos of the Haskell Symposium 2008 presentations.  Enjoy.

Regards,
     Malcolm

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

ICFP programming contest results

The ICFP programming contest results presentation:
http://video.google.com/videoplay?docid=-4697764813432201693

Feel free to pass on this link to any other appropriate forum.

Regards,
Malcolm

DAMP 2009: Call for Papers

			C a l l   f o r   P a p e r s

      DAMP 2009: Workshop on Declarative Aspects of Multicore  
Programming

		 Savannah, Georgia, USA --- January 20, 2009
			 (co-located with POPL 2009)

   DAMP 2009 is the fourth in a series of one-day workshops seeking to  
explore
   ideas in programming language design that will greatly simplify  
programming
   for multicore architectures, and more generally for tightly coupled  
parallel
   architectures.  DAMP 2009 is co-located with the ACM SIGPLAN - SIGACT
   Symposium on Principles of Programming Languages (POPL 2009).

   The emphasis will be on functional and (constraint-)logic  
programming, but
   any programming language ideas that aim to raise the level of  
abstraction
   are welcome.  DAMP seeks to gather together researchers in  
declarative
   approaches to parallel programming and to foster cross  
fertilization across
   different approaches.

   For further information, a CFP flyer, and details on paper  
submissions, see

		   http://www.cse.unsw.edu.au/~pls/damp09/

	       Paper submission deadline is 10th October 2008!

ANNOUNCE: qtHaskell 1.1.2, the second preview version of qtHaskell

For all interested in Haskell GUIs, there is now a second preview release  
of qtHaskell - a set of Haskell bindings for Trolltech's Qt available at

http://qthaskell.berlios.de

There are a number of important changes from the previous version.

1. All FFI pointers are now Foreign Pointers. Those of a type derived from  
QObject are wrapped as QPointer types and only this wrapper is deleted  
when their finalizer runs. All other types are automatically deleted by  
their finalizer when they go out of Haskell scope - or more precisely when  
the finalizer acutally runs. To make the actual deletion time more easily  
controlable, most example code uses the function "returnGC" instead of  
just "return" in callback functions. Also non QObject derived types can be  
constructed with an alternative constructor qSomeObject_nf which has no  
finalizer. In this case it's the programmers job to delete the object when  
required.

2. All Qt enumerated types are implemented as equivalent Haskell types  
instead of just being of type Int as before. In fact I'v used separate  
types for enumerated types and their corresponding "flags" types in Qt.  
For example

enum Qt::AlignmentFlag
flags Qt::Alignment

have equivalent qHaskell types:

data CQt__AlignmentFlag a = CQt__AlignmentFlag a
type Qt__AlignmentFlag = QEnum(CQt__AlignmentFlag Int)

data CQt__Alignment a = CQt__Alignment a
type Qt__Alignment = QFlags(CQt__Alignment Int)

and a corresponding set of value functions i.e.

qt__AlignLeft and qtf__AlignLeft
qt__AlignRight and qtf__AlignRight
...

The correct value function must be used depending on the parameter type of  
the api function being called e.g.

     buttonBox <- qDialogButtonBox1 (qDialogButtonBoxf__Ok +  
qDialogButtonBoxf__Cancel)

for a "flags" type in "widgets.hs", or

     slider <- qSlider1 qt__Vertical

for an "enum" type in "hellogl.hs"

3. All qtHaskell functions which correspond to some overloaded Qt api  
function use a final numeral in their name which corresponds to the number  
of parameters in the function. For example:

QRect ()
QRect ( const QPoint & topLeft, const QPoint & bottomRight )
QRect ( const QPoint & topLeft, const QSize & size )
QRect ( int x, int y, int width, int height )

becomes

qRect
qRect2
qRect4

where qRect2 is a class of functions that can take either QPoint or QSize  
for their second parameter. This nomeclature has the advantage of being  
compatible beteen different Qt versions and of making it possible for the  
qtHaskell programmer to tell what the name of the corresponding qtHaskell  
function is just by looking at the Qt documentation.

N.B. although qtHaskell 1.1.1 programs are not therefore forwards  
compatible with qtHaskell 1.1.2, only minimal editing is required to  
upgrade them.

4. The Haskell api code is now split into separate modules for each Qt  
class. All these modules are exposed in the qtc package, hence by  
explicitly importing only the required modules for an application, the  
size of the corresponding executable can be kept to a reasonable size.
All example qtHaskell programs have a corresponding program prefixed with  
"cs", which has only this explicit importing, e.g. "widgets" and  
"cswidgets". Some example programs have also a corresponding "as" prefixed  
program which uses explicit module importing and also uses Arthur Widgets,  
about which see below.

5. There are two new detailed examples, csterrainsim and csPathDeform.  
csterrainim, is an eventloop based realtime terrain simulator based on  
OpenGL and has a frame rate almost the same as its C++ original.  
csPathDeform, is a vector graphic demo program based on a timer interrupt,  
which uses Qt's Arthur Widgets. Arthur Widgets demos are implemented by Qt  
as a derived style class ArthurStyle and a generic frame class  
ArthurFrame, from which the actual demo program frames are derived. Both  
ArthurStyle and ArthurFrame are replicated in Haskell in the qtHaskell  
library and used by csPathDeform in an entirely analagous manner to that  
of the original Qt C++ "deform" demo program. This
demonstrates that qtHaskell can be used to build generic  
objects/interfaces etc, derived from the basic Qt classes just as in C++.  
Also, use of the ArthurStyle class means that the callback functions are  
more resource intensive. The implementation of handlers in qtHaskell has  
been
revised for this release, and the csPathDeform has a smoothness and  
responsiveness that is virtually indistinguishable from the C++ original.

Enjoy!

David Harley

--

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

job advert: senior role at Credit Suisse

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell