[Haskell] Call for papers -- FOAL: Foundations of Aspect-Oriented Languages 2007

[Ralf Lammel]

[Added a subject. Please accept my apologies! Foundations of AOP and AO 
languages have benefitted from the functional programming community for a while 
now. Haskellers, please have a look. Thanks! Ralf]

   Call For Papers
 FOAL: Foundations of Aspect-Oriented Languages 2007

A one day workshop affiliated with AOSD 2007 in Vancouver, British Columbia.

Submission Deadline: 23:00 GMT, 10 January 2007
Notification of Acceptance: 2 February 2007
Final Versions of Papers Due:   1 March 2007
Workshop:   13 March 2007

Themes and Goals

FOAL is a forum for research in foundations of aspect-oriented programming 
languages. Areas of interest include but are not limited to:

 * Semantics of aspect-oriented languages
 * Specification and verification for such languages
 * Type systems
 * Static analysis
 * Theory of testing
 * Theory of aspect composition
 * Theory of aspect translation (compilation) and rewriting

The workshop aims to foster work in foundations, including formal studies, 
promote the exchange of ideas, and encourage workers in the semantics and 
formal methods communities to do research in the area of aspect-oriented 
programming languages. All theoretical and foundational studies of this topic 
are welcome.

The goals of FOAL are to:

 * Make progress on the foundations of aspect-oriented programming
   languages.
 * Exchange ideas about semantics and formal methods for
   aspect-oriented programming languages.
 * Foster interest within the programming language theory and types
   communities in aspect-oriented programming languages.
 * Foster interest within the formal methods community in
   aspect-oriented programming and the problems of reasoning about
   aspect-oriented programs.

Workshop Format

The planned workshop format is primarily presentation of papers and group 
discussion. Talks will come in three categories: long (30 minutes plus 15 
minutes of discussion), regular (20 minutes plus 5 minutes of
discussion) and short (7 minutes plus 3 minutes of discussion). The short talks 
will allow for presentations of topics for which results are not yet available, 
perhaps for researchers who are seeking feedback on ideas or seek 
collaborations.

We also plan to ensure sufficient time for discussion of each presentation by 
limiting the overall number of talks.

Submissions

Invitation to the workshop will be based on papers selected by the program 
committee; those wishing to attend but not having a paper to submit should 
contact the organizers directly to see if there is sufficient space in the 
workshop.

FOAL solicits long, regular, and short papers on all areas of formal 
foundations of AOP languages. Submissions will be read by the program committee 
and designated reviewers. Papers will be selected for long, regular, and short 
presentation at the workshop based on their length, scientific merit, 
innovation, readability, and relevance. Papers previously published or already 
being reviewed by another conference are not eligible. Some papers may not be 
selected for presentation, and some may be selected for presentation in shorter 
talks than their paper length would otherwise command. We will limit the length 
of paper presentations and the number of papers presented to make sure that 
there is enough time for discussion.

Papers presented at the workshop will be included in a technical report (from 
Iowa State University). Authors will retain their own copyright to the papers. 
Publication of papers at other venues will thus remain possible. We will also 
investigate having a special issue of a journal for revisions of selected 
papers after the workshop.

Authors should note the following details:

 * Submissions are due no later than 23:00 GMT, 10 January 2007.
   (This is a firm deadline.)
 * Authors must indicate whether they wish to be considered for a
   long, regular, or short presentation.
 * Papers for long presentations must not exceed 10 pages in length;
   those for regular presentations must not exceed 7 pages in length,
   and those for short presentations must not exceed 3 pages in length.
 * Some papers may not be selected for presentation, and some may be
   selected for presentation in shorter talks than requested.
 * We encourage use of the ACM Conference format
    for
   submissions, as this will be required for accepted papers. You
   must add page numbers (which are not part of the standard format)
   to your submissions, to make adding comments easier.
 * Submissions are to be made to the following URL:
   http://continue.cs.brown.edu/servlets/foal07/continue.ss

We will notify the corresponding author of papers that are selected for 
presentation at the workshop by 2 February 2006. Early registration for AOSD 
(you must reg

[Haskell] (no subject)

[Ralf Lammel]

[Foundations of AOP and AO languages have benefitted from the functional 
programming community for a while now. Haskellers, please have a look. Thanks! 
Ralf]

   Call For Papers
 FOAL: Foundations of Aspect-Oriented Languages 2007

A one day workshop affiliated with AOSD 2007 in Vancouver, British Columbia.

Submission Deadline: 23:00 GMT, 10 January 2007
Notification of Acceptance: 2 February 2007
Final Versions of Papers Due:   1 March 2007
Workshop:   13 March 2007

Themes and Goals

FOAL is a forum for research in foundations of aspect-oriented programming 
languages. Areas of interest include but are not limited to:

 * Semantics of aspect-oriented languages
 * Specification and verification for such languages
 * Type systems
 * Static analysis
 * Theory of testing
 * Theory of aspect composition
 * Theory of aspect translation (compilation) and rewriting

The workshop aims to foster work in foundations, including formal studies, 
promote the exchange of ideas, and encourage workers in the semantics and 
formal methods communities to do research in the area of aspect-oriented 
programming languages. All theoretical and foundational studies of this topic 
are welcome.

The goals of FOAL are to:

 * Make progress on the foundations of aspect-oriented programming
   languages.
 * Exchange ideas about semantics and formal methods for
   aspect-oriented programming languages.
 * Foster interest within the programming language theory and types
   communities in aspect-oriented programming languages.
 * Foster interest within the formal methods community in
   aspect-oriented programming and the problems of reasoning about
   aspect-oriented programs.

Workshop Format

The planned workshop format is primarily presentation of papers and group 
discussion. Talks will come in three categories: long (30 minutes plus 15 
minutes of discussion), regular (20 minutes plus 5 minutes of
discussion) and short (7 minutes plus 3 minutes of discussion). The short talks 
will allow for presentations of topics for which results are not yet available, 
perhaps for researchers who are seeking feedback on ideas or seek 
collaborations.

We also plan to ensure sufficient time for discussion of each presentation by 
limiting the overall number of talks.

Submissions

Invitation to the workshop will be based on papers selected by the program 
committee; those wishing to attend but not having a paper to submit should 
contact the organizers directly to see if there is sufficient space in the 
workshop.

FOAL solicits long, regular, and short papers on all areas of formal 
foundations of AOP languages. Submissions will be read by the program committee 
and designated reviewers. Papers will be selected for long, regular, and short 
presentation at the workshop based on their length, scientific merit, 
innovation, readability, and relevance. Papers previously published or already 
being reviewed by another conference are not eligible. Some papers may not be 
selected for presentation, and some may be selected for presentation in shorter 
talks than their paper length would otherwise command. We will limit the length 
of paper presentations and the number of papers presented to make sure that 
there is enough time for discussion.

Papers presented at the workshop will be included in a technical report (from 
Iowa State University). Authors will retain their own copyright to the papers. 
Publication of papers at other venues will thus remain possible. We will also 
investigate having a special issue of a journal for revisions of selected 
papers after the workshop.

Authors should note the following details:

 * Submissions are due no later than 23:00 GMT, 10 January 2007.
   (This is a firm deadline.)
 * Authors must indicate whether they wish to be considered for a
   long, regular, or short presentation.
 * Papers for long presentations must not exceed 10 pages in length;
   those for regular presentations must not exceed 7 pages in length,
   and those for short presentations must not exceed 3 pages in length.
 * Some papers may not be selected for presentation, and some may be
   selected for presentation in shorter talks than requested.
 * We encourage use of the ACM Conference format
    for
   submissions, as this will be required for accepted papers. You
   must add page numbers (which are not part of the standard format)
   to your submissions, to make adding comments easier.
 * Submissions are to be made to the following URL:
   http://continue.cs.brown.edu/servlets/foal07/continue.ss

We will notify the corresponding author of papers that are selected for 
presentation at the workshop by 2 February 2006. Early registration for AOSD 
(you must register for AOSD to attend the workshop) is 9 F

RE: [Haskell] SYB Documentation is inconclusive.

[Ralf Lammel]

Arthur,

constrFields eventually returns some mangled strings from the abstract syntax 
tree; see ghc-fptools/ghc/compiler/basicTypes/DataCon.lhs; and that abstract 
syntax promises to be order-preserving.

It says (not surprisingly):

   dcFields  :: [FieldLabel],
-- Field labels for this constructor, in the
-- same order as the argument types;
-- length = 0 (if not a record) or dataConSourceArity.

gmapQ maps the children to results. Since it is a map, it is order-preserving. 
There is not even any associatively business in the case of gmapQ (as opposed 
to gmapQl and gmapQr).

So zipping together results from gmapQ and constrFields plus handling the 
special case of non-record types, should be just fine, no? What could possibly 
go wrong? Perhaps you are saying that the documentation of constrFields should 
promise explicitly that it does not mangle order?

Let me know if I don't get what you are after ... perhaps in the café.

Ralf


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Arthur van Leeuwen
> Sent: Thursday, November 23, 2006 12:09 AM
> To: haskell@haskell.org
> Subject: [Haskell] SYB Documentation is inconclusive.
>
> L.S.,
>
> lately I've been playing with Data.Generics and records. I would like
> to write a generic method to output to e.g. CSV files. Given
> MissingH.CVS
> that problem reduces to a generic method to take lists of records to
> lists of lists with shown record fields, with as first element a list
> of the
> field names. That is, something quite like:
>
>  > totable :: [RecordType] -> [[String]]
>  > totable rs = fields (head rs) ++ map showrecord rs
>  >   where fields a = constrFields . head . dataTypeConstrs .
> dataTypeOf $ a
>  >showrecord = gmapQ (show . toConstr)
>
> However, there are no guarantees whatsoever that the order of the
> fieldnames
> returned by constrFields corresponds to the order in which gmapQ returns
> the results for the children (that is the fields, in this case) of
> the records.
>
> Furthermore, I see no way of forcing such an order otherwise, other than
> writing boilerplate myself.
>
> So, is there something I just haven't seen in the lib yet, is something
> missing, or is just the documentation inconclusive and does the library
> behave as I want it to?
>
> Doei, Arthur.
>
> --
>
>/\/ |   [EMAIL PROTECTED]   | Work like you don't need
> the money
> /__\  /  | A friend is someone with whom | Love like you have never
> been hurt
> /\/__ | you can dare to be yourself   | Dance like there's nobody
> watching
>
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Paper announcement: Software Extension and Integration with Type Classes

[Ralf Lammel]

Dear Haskellers,

The following paper may still benefit from your comment.
The final version is only due per 10 August 2006.

Thanks,
Ralf Laemmel

--

http://homepages.cwi.nl/~ralf/gpce06/ 

Title: Software Extension and Integration with Type Classes

Authors: Ralf Lämmel and Klaus Ostermann 

Abstract 

The abilities to extend a software module and to integrate a software module 
into an existing software system without changing existing source code are 
fundamental challenges in software engineering and programming-language design. 
We show that these challenges can be tackled, at the level of language 
expressiveness, by using the language concept of type classes, as it is 
available in the functional programming language Haskell. A detailed comparison 
with related work shows that type classes provide a powerful framework in which 
solutions to known software extension and integration problems can be provided. 
We also pinpoint several limitations of type classes in this context. 

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

RE: [Haskell] Google SoC: Software Transactional Memory for Parrot

[Ralf Lammel]

Bulat wrote:

> it seems that Haskell continues to be a source of new technologies for
> other languages. i will wait for GADT for C# :)

No need to wait:
http://doitest.acm.org/10.1145/1094811.1094814
" We show that existing object-oriented programming languages such as
Java and C# can express GADT definitions, and a large class of
GADT-manipulating programs, through the use of generics, subclassing,
and virtual dispatch. However, ..."

Ralf

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

RE: [Haskell] Ambiguous type variable when using Data.Generic

[Ralf Lammel]

Bas,

There is a really easy (and intended) way to make this work.
See Sec. 6.4 SYB1 paper (TLDI 2003).

- You compose things as follows:
 simplify = id `extT` simplifyRhs `extT` simplifyExp `extT` ... 
- You apply everything right away to simplify.

There is no need to use a class in your case.
However, if you really want to you need to apply the pattern from the
SYB3 paper.

BTW, simplifications are often not of the kind that non-descending step
functions and recursion by everything does the right thing. Often you
need a more powerful schemes such as bottom-up innermost normalization
(some variation thereof). Please see the Stratego and Strafunski
literature for this purpose.

Best,
Ralf

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Bas van Dijk
> Sent: Saturday, May 20, 2006 7:50 AM
> To: haskell@haskell.org
> Subject: [Haskell] Ambiguous type variable when using Data.Generic
> 
> Hello,
> 
> I'm writing a function 'preProcess' that simplifies the AST that comes
out
> of
> Language.Haskell.Parser.parseModule. Simplifying means rewriting infix
> applications to normal prefix applications (in both patterns and
> expressions), removing parentheses, rewriting guards to if-then-else
> expressions, etc..
> 
> At the moment I use Data.Generic to traverse the AST and apply
> simplification
> functions to the different values. Like this:
> 
>

--
> -
> preProcess :: HsModule -> HsModule
> preProcess = em simplifyRhs . em simplifyPat . em simplifyExp
> where
>   em f = everywhere (mkT f)
> 
>   simplifyExp :: HsExp -> HsExp
>   simplifyExp (HsInfixApp e1 op e2) = HsApp (HsApp (opToExp op)
e1) e2
>   simplifyExp (HsLeftSection  e  op)= HsApp (opToExp op) e
>   simplifyExp (HsRightSection op e) = HsApp (opToExp op) e
>   simplifyExp (HsParen e) = e
>   simplifyExp e = e
> 
>   opToExp (HsQVarOp name) = HsVar name
>   opToExp (HsQConOp name) = HsCon name
> 
>   simplifyPat :: HsPat -> HsPat
>   simplifyPat (HsPInfixApp p1 consName p2) = HsPApp consName [p1,
p2]
>   simplifyPat (HsPParen p) = p
>   simplifyPat p = p
> 
>   simplifyRhs :: HsRhs -> HsRhs
>   simplifyRhs (HsGuardedRhss rhss) = HsUnGuardedRhs $ makeIf rhss
>   where
> makeIf :: [HsGuardedRhs] -> HsExp
> makeIf [] = nonExhaustivePatternError
> makeIf (HsGuardedRhs _ con exp : rhss) =
>  HsIf con exp $ makeIf rhss
> 
> nonExhaustivePatternError =
> HsApp (HsVar (UnQual (HsIdent "error")))
>   (HsLit (HsString "Non-exhaustive patterns"))
> 
>   simplifyRhs rhs = rhs
>

--
> -
> 
> This works, however I would like to have a single function 'simplify'
that
> can
> be applied to different values in the AST. This calls for a class
Simplify
> with instances for expressions, patterns, etc.:
> 
>

--
> -
> preProcess :: HsModule -> HsModule
> preProcess = everywhere (mkT simplify)
> 
> class Simplify a where
> simplify :: a -> a
> 
> instance Simplify HsExp where
> simplify (HsInfixApp e1 op e2) = HsApp (HsApp (opToExp op) e1) e2
> simplify (HsLeftSection  e  op)= HsApp (opToExp op) e
> simplify (HsRightSection op e) = HsApp (opToExp op) e
> simplify (HsParen e) = e
> simplify e = e
> 
> instance Simplify HsPat where
> simplify (HsPInfixApp p1 consName p2) = HsPApp consName [p1, p2]
> simplify (HsPParen p) = p
> simplify p = p
> 
> instance Simplify HsRhs where
>   simplify (HsGuardedRhss rhss) = HsUnGuardedRhs $ makeIf rhss
>   where
> makeIf :: [HsGuardedRhs] -> HsExp
> makeIf [] = nonExhaustivePatternError
> makeIf (HsGuardedRhs _ con exp : rhss) =
>   HsIf con exp $ makeIf rhss
> 
> nonExhaustivePatternError =
> HsApp (HsVar (UnQual (HsIdent "error")))
>   (HsLit (HsString "Non-exhaustive patterns"))
> 
>   simplify rhs = rhs
> 
> opToExp (HsQVarOp name) = HsVar name
> opToExp (HsQConOp name) = HsCon name
>

--
> -
> 
> However, compiling the above gives the following type error:
> 
> Ambiguous type variable `b' in the constraints:
>   `Typeable b' arising from use of `mkT' at Special.hs:145:25-27
>   `Simplify b' arising from use of `simplify' at
Special.hs:145:29-36
> Probable fix: add a type signature that fixes these type variable(s)
> 
> How can I make this work?
> 
> Greetings,
> 
> Bas van Dijk
> __

[Haskell] Last call for papers: RULE-BASED PROGRAMMING 2006

[Ralf Lammel]

RULE'06, 7th International Workshop on Rule-Based Programming, 11th August, 
2006, Seattle, USA, A Satellite Event of RTA 
http://www.dcs.kcl.ac.uk/events/RULE06/



IMPORTANT DATES 

- 14th May, 2006 Deadline for electronic submission of papers
- 15th June, 2006 Notification of acceptance of papers
- 30th June, 2006 Deadline for final versions of accepted papers
- 11th August, 2006 Workshop


INVITED SPEAKERS 

Joint RULE and WRS keynote speakers: 
- Dick Kieburtz, OHSU/OGI School of Science & Engineering 
- Claude Kirchner, INRIA and LORIA


RULE-BASED PROGRAMMING
 
The rule-based programming paradigm is characterized by the repeated, localized 
transformation of a data object such as a term, graph, proof, constraint store, 
etc. The transformations are described by rules which separate the description 
of the object to be replaced (the pattern) from the calculation of the 
replacement. Optionally, rules can have further conditions that restrict their 
applicability. The transformations are controlled by explicit or implicit 
strategies. 
The basic concepts of rule-based programming appear throughout computer 
science, from theoretical foundations to practical implementations. Term 
rewriting is used in semantics in order to describe the meaning of programming 
languages, as well as in the implementation of program transformation systems. 
Rules are used implicitly or explicitly to perform computations, e.g., in 
Mathematica, OBJ, ELAN, Maude or to perform deductions, e.g., by using 
inference rules to describe or implement a logic, theorem prover or constraint 
solver. Mail clients and mail servers use complex rules to help users 
organising their email and sorting out spam. Language implementations use 
bottom-up rewrite systems for code generation (as in the BURG family of tools.) 
Constraint-handling rules (CHRs) are used to specify and implement 
constraint-based algorithms and applications. Rule-based programming idioms 
also give rise to multi-paradigm languages like Claire.


TOPICS 

We solicit original papers on all topics of rule-based programming, including:
- Languages for rule-based programming 
  * Expressivity, Idioms, Design patterns 
  * Semantics, Type systems 
  * Implementation techniques 
  * System descriptions 
- Other foundations 
  * Complexity results 
  * Advances on rewriting logic 
  * Advances on rewriting calculus 
  * Static analyses of rule-based programs 
  * Transformation of rule-based programs 
- Applications of rule-based programming, e.g.: 
  * Program transformation 
  * Software analysis and generation 
  * System Control 
  * Work-flow control 
  * Knowledge engineering 
- Combination with other paradigms 
  * Functional programming 
  * Logic programming 
  * OO programming 
  * Language extensions 
  * Language embeddings 
- System descriptions 



SUBMISSIONS 

Papers (of at most 15 pages) should be submitted electronically via the 
web-based submission site. http://www.easychair.org/RULE2006/ 
Any problems with the submission procedure should be reported to one of the PC 
chairs:  Maribel Fernandez ([EMAIL PROTECTED]), Ralf Lämmel ([EMAIL PROTECTED])


 
PROCEEDINGS 

Accepted papers will be published in the preliminary proceedings volume, which 
will be available during the workshop. The final proceedings will be published 
in Electronic Notes in Theoretical Computer Science (ENTCS), Elsevier. 


PROGRAMME COMMITTEE 

- Mark van den Brand (TU Eindhoven, Netherlands)
- Horatiu Cirstea (LORIA, France) 
- Pierre Deransart (INRIA Rocquencourt, France) 
- Michael L. Collard (Kent State University, USA) 
- Martin Erwig (Oregon State University, USA) 
- Francois Fages (INRIA Rocquencourt, France) 
- Maribel Fernandez (Co-Chair, King's College London, UK) 
- Jean-Pierre Jouannaud (LIX, Ecole Polytechnique, France) 
- Oleg Kiselyov (FNMOC, USA) 
- Ralf Lämmel (Co-Chair, Microsoft, USA)
- Ugo Montanari (Universita di Pisa, Italy) 
- Pierre-Etienne Moreau (LORIA, France) 
- Tobias Nipkow (Technical University Munich, Germany) 
- Tom Schrijvers (K.U.Leuven, Belgium)
- Martin Sulzmann (National University of Singapore, Singapore)
- Victor Winter (University of Nebraska at Omaha, USA) 

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

[Haskell] RULE 2006 at FLoC --- paper deadline 14 May

[Ralf Lammel]

==
 Call for Papers

   RULE 2006 
 7th International Workshop on Rule-Based Programming
   http://www.dcs.kcl.ac.uk/events/RULE06/

  Seattle, USA
11th August 2006

 A satellite event of RTA 2006 at FLoC
===


The basic concepts of rule-based programming appear throughout Computer
Science, from theoretical foundations to practical implementations. Term
rewriting is used in semantics in order to describe the meaning of
programming languages, as well as in the implementation of program
transformation systems. Rules are used implicitly or explicitly to
perform computations, e.g., in Mathematica, OBJ, ELAN, Maude or to
perform deductions, e.g., by using inference rules to describe or
implement a logic, theorem prover or constraint solver. Mail clients and
mail servers use complex rules to help users organising their email and
sorting out spam. Language implementations use bottom-up rewrite systems
for code generation (as in the BURG family of tools.)
Constraint-handling rules (CHRs) are used to specify and implement
constraint-based algorithms and applications. Rule-based programming
idioms also give rise to multi-paradigm languages like Claire.

The purpose of this workshop is to bring together researchers from the
various communities working on rule-based programming to foster advances
in the theory of rule-based programming, cross-fertilization between
theory and practice, research on rule-based programming methods, and the
exploration of important application domains of rule-based programming.

RULE 2006 will be a one-day satellite event of RTA 2006 at FLoC.


Topics of interest
--

* Languages for rule-based programming
  - Expressive power, Idioms, Design patterns
  - Semantics, Type systems
  - Implementation techniques
  - System descriptions

* Other foundations
  - Complexity results
  - Advances on rewriting logic
  - Advances on rewriting calculus
  - Static analyses of rule-based programs
  - Transformation of rule-based programs

* Applications of rule-based programming, e.g.:
  - Program transformation
  - Software analysis and generation
  - System Control
  - Work-flow control
  - Knowledge engineering
  - System descriptions

* Combination with other paradigms
  - Functional programming
  - Logic programming
  - OO programming
  - Biocomputing
  - Language extensions
  - Language embeddings



Submissions and Publication:

Papers (of at most 15 pages) should be submitted electronically via the
submission page: http://www.easychair.org/RULE2006 Any problems with the
submission procedure should be reported to one of the PC chairs:
[EMAIL PROTECTED], [EMAIL PROTECTED] 

Accepted papers will be published in the preliminary proceedings volume,
which will be available during the workshop. The final proceedings will
be published in Electronic Notes in Theoretical Computer Science
(ENTCS), Elsevier.

IMPORTANT DATES
- 14th May 2006: Deadline for electronic submission of papers
- 15th June 2006: Notification of acceptance of papers
- 30th June 2006: Deadline for final versions of accepted papers
- 11th August 2006: Workshop

Programme Committee:

- Mark van den Brand (TU Eindhoven, Netherlands)
- Horatiu Cirstea (LORIA, France)
- Pierre Deransart (INRIA Rocquencourt, France)
- Michael L. Collard (Kent State University, USA)
- Martin Erwig (Oregon State University, USA)
- Francois Fages (INRIA Rocquencourt, France)
- Maribel Fernandez (Co-Chair, King's College London, UK)
- Jean-Pierre Jouannaud (LIX, Ecole Polytechnique, France)
- Oleg Kiselyov (FNMOC, USA)
- Ralf Laemmel (Co-Chair, Microsoft, USA )
- Ugo Montanari (Universita di Pisa, Italy)
- Pierre-Etienne Moreau (LORIA, France)
- Tobias Nipkow (Technical University Munich, Germany)
- Tom Schrijvers (K.U.Leuven, Belgium)
- Martin Sulzmann (National University of Singapore, Singapore) 
- Victor Winter (University of Nebraska at Omaha, USA)

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

[Haskell] The Haskell road ... to Google

[Ralf Lammel]

Two new papers available:

Book review
"The Haskell Road to Logic, Maths and Programming" by Kees Doets and Jan van 
Eijck
To appear in JoLLI journal; 13 pages.
http://www.cs.vu.nl/~ralf/JoLLI06
Executive summary: The "Haskell road" is an excellent book worth
considering as course material and reading anyhow. A non-Haskell
road is also discussed in the review.

Google's MapReduce Programming Model -- Revisited
Draft; To be submitted; feedback appreciated; 27 pages.
http://www.cs.vu.nl/~ralf/MapReduce
Executive summary: The seminal MapReduce paper had been briefly
discussed at LTU without really going into technical details. The
present paper discovers the concepts from a functional programming
perspective. Did you ever wonder why MapReduce is called MapReduce?

Ralf Laemmel


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

RE: [Haskell] Hlist distribution -- compiler error in TIP

[Ralf Lammel]

Dear Frank,

HList is definitely tested with 6.4. See transcript below. My guess
would be that you are perhaps not running with options as stated in the
Makefile. Anyway, if your problems persist, I am happy to take this
offline. 

Merry Christmas,
Ralf

[EMAIL PROTECTED] ~/projects/HList/src
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.4

[EMAIL PROTECTED] ~/projects/HList/src
$ make test
ghci -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances MainGhcGeneric1.hs -v0 < Main.in >
MainGhcGeneric1.out
diff -b MainGhcGeneric1.out MainGhcGeneric1.ref
ghci -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances MainGhcTTypeable.hs -v0 < Main.in >
MainGhcTTypeable.out
diff -b MainGhcTTypeable.out MainGhcTTypeable.ref
runhugs -98 +o MainHugsTTypeable.hs < Main.in > MainHugsTTypeable.out
diff -b MainHugsTTypeable.out MainHugsTTypeable.ref
ghci -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances MainPosting-040607.hs -v0 < Main.in >
MainPosting-040607.out
diff -b MainPosting-040607.out MainPosting-040607.ref
ghci -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances MainGhcGeneric2.hs -v0 < Main.in >
MainGhcGeneric2.out
diff -b MainGhcGeneric2.out MainGhcGeneric2.ref
ghci -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances MainGhcGeneric3.hs -v0 < Main.in >
MainGhcGeneric3.out
diff -b MainGhcGeneric3.out MainGhcGeneric3.ref

[EMAIL PROTECTED] ~/projects/HList/src

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Frank
> Sent: Saturday, December 24, 2005 8:46 AM
> To: haskell@haskell.org
> Subject: [Haskell] Hlist distribution -- compiler error in TIP
> 
> I just got the Hlist distribution but could not compile the example
files
> With ghc 6.4 (I use ghci - in eclipse - I did not use ghc with the
> makefile).
> 
> I got the following compile time error on module TIP:
> 
> 
> C:\gisCodev13\HeterogenousList\src/TIP.hs:247:22:
> Could not deduce (HType2HNat e l n1,
> HDeleteAtHNat n1 l l'1,
> HOccurs e (TIP l),
> HOccurs e2 (TIP l'1))
>   from the context (HOccurs e1 (TIP l),
>   HType2HNat e1 l n,
>   HDeleteAtHNat n l l',
>   HOccurs e2 (TIP l'),
>   HOccurs e2 (TIP l),
>   HType2HNat e2 l n',
>   HDeleteAtHNat n' l l'',
>   HOccurs e1 (TIP l''))
>   arising from use of `y' at
> C:\gisCodev13\HeterogenousList\src/TIP.hs:247:22
> Probable fix:
>   add (HType2HNat e l n1,
>  HDeleteAtHNat n1 l l'1,
>  HOccurs e (TIP l),
>  HOccurs e2 (TIP l'1))
>   to the type signature(s) for `tuple'
>   or add an instance declaration for (HOccurs e (TIP l), HOccurs
e2
> (TIP
> l'1))
> In the definition of `tuple':
>   tuple (TIP l)
>   = let
>   x = hOccurs (TIP l)
>   l' = hDeleteAtProxy (toProxy x) l
>   y = hOccurs (TIP l')
> in (x, y)
> 
> 
> Can anybody quickly see, what is wrong?
> 
> 
> 
> Andrew U. Frank
> Professor, Head of Department
> Geoinformation and Cartography E127   phone: +43 1 588 01 12710
> TU Vienna secr. +43 1 588 01 12700
> Gusshausstrasse 27-29 fax +43 1 588 01 12799
> A-1040 Vienna Austria cellular phone +43 676 41925
72
> http://www.geoinfo.tuwien.ac.at/persons/frank/frank.html
> skype:AndrewUFrank
> 
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Call for papers -- FOAL 2006: Foundations of Aspect-Oriented Languages

[Ralf Lammel]

FOAL: Foundations of Aspect-Oriented Languages
--- CALL FOR PAPERS ---
Submission deadline: 25 January 2006

A one day workshop affiliated with AOSD 2006 in Bonn, Germany, on March 21, 
2006.


Themes and Goals

FOAL is a forum for research in foundations of aspect-oriented programming 
languages. Areas of interest include but are not limited to: 

- Semantics of aspect-oriented languages
- Specification and verification for such languages
- Type systems
- Static analysis
- Theory of testing
- Theory of aspect composition
- Theory of aspect translation (compilation) and rewriting 

The workshop aims to foster work in foundations, including formal studies, 
promote the exchange of ideas, and encourage workers in the semantics and 
formal methods communities to do research in the area of aspect-oriented 
programming languages. All theoretical and foundational studies of this topic 
are welcome. 

The goals of FOAL are to: 
- Make progress on the foundations of aspect-oriented programming languages. 
- Exchange ideas about semantics and formal methods for aspect-oriented 
programming languages. 
- Foster interest within the programming language theory and types communities 
in aspect-oriented programming languages. 
- Foster interest within the formal methods community in aspect-oriented 
programming and the problems of reasoning about aspect-oriented programs. 


Workshop Format

The planned workshop format is primarily presentation of papers and group 
discussion. Talks will come in three categories: long (30 minutes plus 15 
minutes of discussion), short (20 minutes plus 5 minutes of discussion) and 
very short (7 minutes plus 3 minutes of discussion). The very short talks will 
allow for short presentations of topics for which results are not yet 
available, perhaps for researchers who are seeking feedback on ideas or seek 
collaborations.

We also plan to ensure sufficient time for discussion of each presentation by 
limiting the number of long talks and having only a few short talks.


Submissions

Invitation to the workshop will be based on papers selected by the program 
committee; those wishing to attend but not having a paper to submit should 
contact the organizers directly to see if there is sufficient space in the 
workshop.

FOAL solicits full-length, short, and very short papers on all areas of formal 
foundations of AOP languages. Submissions will be read by the program committee 
and designated reviewers. Papers will be selected for long, short, and very 
short presentation at the workshop based on their length, scientific merit, 
innovation, readability, and relevance. Papers previously published or already 
being reviewed by another conference are not eligible. Some papers may not be 
selected for presentation, and some may be selected for presentation in shorter 
talks than their paper length would otherwise command. We will limit the length 
of paper presentations and the number of papers presented to make sure that 
there is enough time for discussion.

Papers presented at the workshop will be included in a technical report (from 
Iowa State University). Authors will retain their own copyright to the papers. 
Publication of papers at other venues will thus remain possible. We will also 
investigate having a special issue of a journal for revisions of selected 
papers after the workshop. 


Authors should note the following details:

- Submissions are due no later than 23:00 GMT, Friday, 25 January, 2006. This 
is a firm deadline.
- Authors must indicate whether they wish to be considered for a long, short, 
or very short presentation. 
- Papers for long presentations must not exceed 10 pages in length; those for 
short presentations must not exceed 5 pages in length, and those for very short 
presentations must not exceed 3 pages in length. 
- Some papers may not be selected for presentation, and some may be selected 
for presentation in shorter talks than requested. 
- We encourage use of the ACM Conference format for submissions, as this will 
be required for accepted papers. You must add page numbers (which are not part 
of the standard format) to your submissions, to make adding comments easier. 
- Submissions are to be sent as PDF (preferred) or postscript attachments in an 
email to Curtis Clifton, clifton -at- rose-hulman -dot- edu. 

We will notify the corresponding author of papers that are selected for 
presentation at the workshop by 10 February 2006. The early registration 
deadline for AOSD will be 17 February 2006. FOAL attendees must be registered 
for AOSD. Final versions of papers for the proceedings will be due on 7 March 
2006. 


Important Dates

* Submission Deadline 23:00 GMT, 25 January 2006
* Notification of Acceptance 10 February 2006
* AOSD Early Registration Deadline 17 February 2006
* Final Versions of Papers due 7 March 2006
* Workshop 21 March 2006

Program Committee 

* Mira Mezini (PC Chair) - Darmstadt University of Technology
* Jonathan Aldrich - Carnegi

RE: [Haskell] Re: Records

[Ralf Lammel]

Good questions.

You can't have a polymorphic typecase like "`extQ` (show :: Show a => a
-> String )" because that's not really a *type*case. It is too
polymorphic.
 
You can have a polymorphic typecase like "`extQ` ( lshow :: [ a ] ->
String )" because that's covered by the SYB2 paper; you need ext1Q
(extQ1, depending on version).

With SYB3, the second case is easier; it's just an instance.
The first case ... still doesn't work ... this time for reasons of the
class system. The type system doesn't allow to write one "default"
instance for the case that a certain constraint is satisfiable (here:
Show a) and to have yet another "default" instance to kick in
*otherwise* to the SYB version. 

It would be great to have typeclass case to deal with this issue.
Questions asking for typeclass case pop every now and then.

The idea of the example is that you would need to define your own
generic show function from scratch. The limitation of SYB1/SYB2 is that
you would hit a closed-world-assumption. That's why SYB3! It allows you
to add instances to the new generic show, as you go. Because of the lack
of typeclass case, you still wouldn't be able to use the normal Prelude
show function as default. You can use it instance-per-instance, by
adopting each (attractive) show instances to be become instance of the
new generic show function. However, you need to clone code because you
probably want to re-tie the recursive knot in the new generic function.

SYB3 is shipped separately, please use the distribution you pointed to.
Simon PJ and I are still undecided regarding the modalities for adding
SYB3 to the GHC libraries. Basically, we don't like the idea of having
two libraries; SYB3 is more powerful but the combinator types are
somewhat more complicated. However, using the separate SYB3 distribution
is safe because it comes with TH support and a standalone mini SYB
library.

Regards,
Ralf

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

> On Behalf Of Johannes Waldmann
> Sent: Monday, November 28, 2005 7:33 AM
> To: haskell@haskell.org
> Subject: [Haskell] Data.Generics question
> 
> Dear all, in Data.Generics.Text
> http://cvs.haskell.org/cgi-
> bin/cvsweb.cgi/fptools/libraries/base/Data/Generics/Text.hs?rev=1.10
> I find this nice example
> 
> gshow = ( \t ->
> "("
>  ++ showConstr (toConstr t)
>  ++ concat (gmapQ ((++) " " . gshow) t)
>  ++ ")"
> ) `extQ` (show :: String -> String)
> 
> but I couldn't figure out how to use this to declare a useful show 
> instance. I would need something like
> 
>`extQ` (show :: Show a => a -> String )
> 
> i. e. use Show instance if available, or
> 
>`extQ` ( lshow :: [ a ] -> String )
> 
> i. e. use another function if argument type is a list type
> 
> 
> BTW: I guess the above is related to
> http://homepages.cwi.nl/~ralf/syb3/
> Do the current (6.4) ghc compiler/libraries correspond to what's in 
> that paper?
> --
> -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
>  http://www.imn.htwk-leipzig.de/~waldmann/ ---
> 
> 
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Instances That Ignore Type Constraints? (HList-related)

[Ralf Lammel]

Hi,

'isBoxed (Carton func)' fails because there is no way whatsoever that any 
expression context will disambiguate the x y type variables of func's type. 
That is, the type of `isBoxed (Box func)` does not expose x (and y -- the 
latter being irrelevant because of the fundep); so there is no way that the 
type system could ever figure out which x (and y) was meant; hence overloading 
will never ever get resolved (check out the hugs type error, which tells you 
exactly that).

One could argue in favor of incoherent choice of instances.
(I don't!)

Say, if you had:

{-# OPTIONS -fallow-undecidable-instances #-}
{-# OPTIONS -fallow-incoherent-instances #-}
instance Func x x -- or some other generic instance

It will work fine:

ghci> isBoxed (Carton func)
HFalse

However, why would you want to wrap such a function anyhow, if you are not 
going to use it? :-) Perhaps, this is a case of superficial, say unintended 
polymorphism.

If you *really* wanted to box (or to carton) a polymorphic type-class bounded 
function, then you may need to do something like this:

data WFunc = WFunc (forall x y. Func x y => (x -> y))
hugs-or-ghci> isBoxed (Carton (WFunc func))
HFalse

This works fine ... but this is probably *not* what you wanted in the first 
place. Also, this technique is extremely limiting because now you would need to 
fabricate wrappers like WFunc for each new polymorphic expression (when the 
constraints or the type differ). 

I am keen to hear more about your problem, and to help accordingly.
(Haskell-café?)

Regards,
Ralf


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Jared Warren
> Sent: Wednesday, October 26, 2005 7:01 PM
> To: Haskell Mailing List
> Subject: [Haskell] Instances That Ignore Type Constraints? (HList-related)
> 
> 
> > data Box x = Box x
> > data Carton x = Carton x
> > class Func x y | x -> y where func :: x -> y
> 
> > class IsBoxed f b | f -> b where isBoxed :: f -> b
> > instance IsBoxed (Box x) HTrue where isBoxed _ = hTrue
> > instance IsBoxed (Carton x) HFalse where isBoxed _ = hFalse
> 
> `isBoxed (Box func)` fails in GHC with "Ambiguous type variables
> `x', `y' in the constraint: `Func x y' arising from use of `func'...".

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

RE: [Haskell] getArgs, maxBound, float division: pure functions?

[Ralf Lammel]

Just for the record,
Cobol has a long history of specifying local rounding options.
More recently, the options for rounding are elaborated in the context of
adding standard arithmetic.

http://www.cobolportal.com/j4/files/05-0152.doc

Ralf

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Bjorn Lisper
> [...]
> He was very careful to give
> the language a good design also regarding floating-point computations.
His
> design choice, as regards rounding, was to allow the compiler to
choose
> rounding mode by default (thus allowing more freedom for
optimization),
> while providing a set of special arithmetic operators, with specified
> rounding modes, to use when more explicit control is needed.
> 
> He also proposed a special construct "letctrl ... in e", where the
"..."
> are
> a list of directives telling how to interpret and evaluate the
expression
> e. One possible directive is "RoundingMode = ..." to set the rounding
mode
> locally in e. Other directives control, for instance, whether
> optimizations
> like x*0.0 -> 0.0 are allowed in e, whether to force strict evaluation
of
> all subexpressions (so optimizations cannot affect exceptions), to set
> allowed miminum accuracy, etc.
> 
> The language has exception handling (including a "handle" construct to
> catch
> exceptions), which also takes care of floating-point exceptions.

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

RE: [Haskell] Object-Orientation and Haskell

[Ralf Lammel]

>   Define a type A such that for any type B you can define
> 
> up :: B -> A
> down :: A -> Maybe B
> 
>   such that
> 
> down . up = Just
> 
> You can do this quite easily in Java or C++, mutatis mutandis. You
can't
> do this in Haskell, I don't think. You can't actually do this in
> O'Haskell either, it seems the O' essentially amounts to syntactic
sugar.

You can't even do this in OCaml.
However, in OOHaskell you can.

>From the TOC of the OOHaskell paper
http://homepages.cwi.nl/~ralf/OOHaskell/

5.4 Casts based on dynamics 50
5.5 Casts based on unions   51

The second technique may add something to this discussion here.
We use a sort of intersection-type encoding (also reminiscent of TICs).

Thanks,
Ralf
 
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] reflection/metadata in Haskell?

[Ralf Lammel]

I would rather argue that:
- Template Haskell approx. *compile-time* reflection
- Scrap your boilerplate II (ICFP 2004) approx. *run-time* reflection
- Generic Haskell is effectively a Haskell generator
Ralf
P.S.: Another way to get *compile-time* reflection in Haskell is of course 
type-level programming as pioneered by McBride and Hallgreen ...

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Mads Lindstrøm
> Sent: Wednesday, September 21, 2005 11:40 AM
> To: haskell@haskell.org
> Subject: Re: [Haskell] reflection/metadata in Haskell?
> ...
> I do not know of any Java-like reflection capabilities in Haskell.
> However, "Scrap Your Boilerplate" (search google) and Generic Haskell
> can do a lot of the same stuff reflection can do in Java. Think of it as
> compile-time reflection.

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

[Haskell] OOHaskell -- major release of report and library

[Ralf Lammel]

An extended technical report has been released at:
TR & software: http://homepages.cwi.nl/~ralf/OOHaskell/ 
TR: http://arxiv.org/abs/cs.PL/0509027 

"Haskell's overlooked object system"
10 September 2005, 79 pages

by O. Kiselyov (FNMOC, Monterey, CA, USA)
and R. Laemmel (Microsoft Corp., WA, USA)

Some recently added topics:

- Many Haskell 98 encodings
- Safe value recursion
- Safe downcasts
- Safe co-variant method arguments
- Nominal subtyping
- Iso-recursive object types
- With and depth subtyping

The report describes and classifies all principled, to our best
knowledge, object encodings in Haskell98, with and without common
extensions.

On the one hand, this report covers many advanced topics, as to make it
interesting for programming language researchers. On the other hand, the
report is detailed and lightweight enough to be useful as an OO-FP
tutorial.

Regards,
Oleg and Ralf

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

RE: [Haskell] Dynamic binding

[Ralf Lammel]

> If we were on an OOP mailing
> list, I could ask for days how to simulate pattern matching and
> algebraic types---and get a nonsensical runaround involving the
visitor
> pattern and huge swaths of unreadable code.

In such a case, I would be happy if someone told me that there is work
like this: http://www.cs.cornell.edu/Projects/jmatch/ 
People who wrote those papers clearly have thought harder of the
problem than most subscribers to the preconceived OOP mailing list.

> Ralf, I think it's incumbent on you, having said several times "that
> isn't solving the problem", to more clearly explain what problem you
> think exists and cannot be solved gracefully 

I am sure I said it.

Also, Oleg and I should be fairly clear on all this in the OOHaskell
paper.

http://www.cwi.nl/~ralf/OOHaskell Major revision 13 June 2005

We will be grateful for additional comments and questions,
and I am happy to summarize all feedback we get,
if not on this mailing list, then in the paper's appendices,
and elsewhere.

Anyway, as it is incumbent on me to explain,
I try to be as concise as I can get at 4.00am:

[This should also cover Andreas' question.]

1. The original poster asked:

> What would be the normal way for a Haskell programmer
> to handle the typical shape example in beginner OO
> tutorials?

2. 

I take for granted that "typical shape example" is very
well abstracted in this famous benchmark:

http://onestepback.org/articles/poly/ 
http://www.angelfire.com/tx4/cus/shapes/

The essence of the typical shape example is the following:

a there are different kinds of shapes (say rectangle, circle, whatever),
b which are organized in a subtyping hierarchy, and
c each kind of shape supports a subclass-specific draw method;
d the interface of shapes allows for mutation/observation of state,
e and eventually we want to process collections of shapes

3.

Note that e) looks arbitrary at first sight,
but it is crucial because shape apps will
involve instances of the Composite pattern.

Also note that the original poster indeed said:

std::list shapes;
for(std::list::iterator it = shapes.begin();it !=
shapes.end();++it)
{ (*it)->draw(...); }

Also note that the
body of the for loop happens to be a single
statement that invokes draw, but obviously we must keep in mind
what happens if the body is a compound statement.

4. 

Where did I say "that isn't solving the problem"?

((

For the record,
I did *not* say so when Lennart posted his proposal.
I only mentioned that this proposal has the extensibility
problem and that ("minor issue") it needs extra effort to
recover the same degree of type distinction as in the normal
OO approach.

))

Indeed,
I did strongly disagree regarding the faithfulness of Bulat's
attempts. He made two proposals. The first one basically
suggested:

- do not build a list of shapes,
- do rather build a list of (lazy) applications of draw methods to shape
construction arguments
- then do not map over a list of shapes to perform functionality per
element
- do rather map over a list of expressions to sequence their effects.

If you think of it,
we can get rid of the generality of Haskell's map this way,
which is something that others have thought of:

http://lambda-the-ultimate.org/node/view/613


The second proposal by Bulat goes as follows:
(again I save band with by not showing the actual code)

- define a single *non-parameterized* datatype ShapeInterface
- construct all sorts of shapes as terms over this monomorphic type
- allow for state by IOref allocation before returning the shape terms
- do *not* cover the problem of shapes with different interfaces
- that is do really just pretend that all shapes have the same type
- do therefore simplify away the issue of different types for different
kinds of shapes
- based on this simplification, build a homogeneous list of shapes
- and do a reasonable loop with type-specific draw method invocations
indeed.

Again, if you think of it, we can adopt the same simplification
strategy to Haskell. That is, in Haskell 20??, superclass constraints
will not be allowed. We will recommend to define a single class in
the recompilable Prelude to which we add methods as we encounter them.

Ralf

P.S.: I just realized that there is no OOCobol solution in the shapes
repository. I sign for it.

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

RE: [Haskell] Dynamic binding

[Ralf Lammel]

Lennart,

from a textbook perspective I agree
that this solution should be mentioned to make it easy
for non-Haskellers to get into the subject.

However (as you of course know, but I just don't understand
why you don't dare to mention the limitations a) and b) ...)

a)

Your constructor-based approach is not extensible.
(Adding another form of shape requires touching existing code and
recompilation.) I reckon that the (normal implied OO) point of
the Shapes example, to a considerable extent, is also about the
potential addition of new shapes.

Saying we can take a snapshot of shape "types"  and burn them
into constructors of an algebraic type does not give me the
impression of Haskell being ahead in type system and programming
language arena.

b)

This "burn subtypes into constructors" leads me to a second
weakness. By doing so, we have lost the precision of the
original type dichotomy circle vs rectangle vs square since
these guys are now all represented as terms of type.

Of course, you might say that we could define dedicated
types for circle, rectangle and square so that we would use
the shape type merely as a *sum* type. (So constructors
only serve for embedding.) This way we could at least recover
the typing precision of OO.

So I am willing to give in on b) 
but I maintain a) 
and I really miss extensible datatypes :-)

Ralf
(doing too much C# these days I guess)


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Lennart Augustsson
> Sent: Thursday, June 23, 2005 7:30 AM
> To: Andrew Ward
> Cc: haskell@haskell.org
> Subject: Re: [Haskell] Dynamic binding
> 
> Andrew Ward wrote:
> > Hi All,
> > In Simon Thompson's The Craft of Functional Programming Second
Edition,
> > page 226, it is mentioned that Laufer (1996) describes a Haskell
> > extension to allow dynamic binding. I was wondering if this has been
> > implemented as an extension in any of the haskell compilers, or
> variants?
> > I am a c++ programmer by trade, only dabbling in Haskell when I was
at
> > university, so it seems a disadvantage to me to not have dynamic
binding
> > in Haskell 98.
> > What would be the normal way for a Haskell programmer to handle the
> > typical shape example in beginner OO tutorials?
> 
> 
> Unlike previous posters that have shown various ways to simulate
> object oriented programming I'm going to try and answer the
> question. :)
> 
> Here is what I would do:
> 
> --
> data Shape
>   = Circle Point Radius
>   | Square Point Size
> 
> draw :: Shape -> Pict
> draw (Circle p r) = drawCircle p r
> draw (Square p s) = drawRectangle p s s
> 
> moveTo :: Shape -> Point -> Shape
> moveTo (Circle _ r) p = Circle p r
> moveTo (Square _ s) p = Square p s
> 
> shapes :: [Shape]
> shapes = [Circle (0,0) 1, Square (1,1) 2]
> 
> shapes' :: [Shape]
> shapes' = map (moveTo (2,2)) shapes
> --
> 
> This is in rather stark contrast to the object oriented way of doing
the
> same things.  For reference, here's how you could do it :
> 
> --
> class IsShape shape where
>  draw :: shape -> Pict
>  moveTo :: Point -> shape -> shape
> 
> data Shape = forall a . (IsShape a) => Shape a
> 
> data Circle = Circle Point Radius
> instance IsShape Circle where
>  draw (Circle p r) = drawCircle p r
>  moveTo p (Circle _ r) = Circle p r
> 
> data Square = Square Point Size
> instance IsShape Square where
>  draw (Square p s) = drawRectangle p s s
>  moveTo p (Square _ s) = Square p s
> 
> shapes :: [Shape]
> shapes = [Shape (Circle (0,0) 10), Shape (Square (1,1) 2)]
> 
> shapes' :: [Shape]
> shapes' = map (moveShapeTo (2,2)) shapes
>where moveShapeTo p (Shape s) = Shape (moveTo p s)
> --
> 
> Both ways of doing it contains the same information, it's just that
> it's organized in different ways.
> 
> The "functional way" centers around the type Shape.  You can find out
> all about what shapes exist by looking at the type definition.  For
> each operation on shapes (draw & moveTo) you describe what they do for
> the different shapes.
> 
> The object oriented way centers more around the objects (surprise,
> surprise).  For each kind of object you say that it's a shape and how
> the shape operations work.
> 
> 
> So, which is better?  I don't think you can say one is better than the
> other.  They have different strengths.  With the object oriented way
it
> is easy to answer questions like "What is a Circle?", whereas with the
> functional way it is easy to answer "How do you draw a Shape"?
> Likewise, with the object oriented way it's easier to add a new kind
> of shape and with the functional way it's easier to add a new
> operation.
> 
> To me it's a matter of taste.  I like the functional taste; my brain
> has been warped over many years.
> 
>   -- Lennart
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman

RE: [Haskell] Dynamic binding

[Ralf Lammel]

Andreas Rossberg:

Andreas R. wrote:

> "dynamic binding" is just the OOO way of saying
> "calling a first-class function").

Let me presume that dynamic binding 
was meant here in the sense of late binding, in the sense of
subtyping polymorphism. At least, the given shapes example
strongly suggested that.

If so, I can't fully parse your reply in this context.
Please elaborate.

(First-class function seems to refer to currying or what?)

(Did you miss a "polymorphic" before function? That would explain it.
But then again, note, *first-class polymorphism* comes at the price
of extra types just as the ugly ex. polymorphism trick. (This is of
course just the same trick, indeed.) As we argue in Section 5.6 of
the OOHaskell draft, current version, this does really not scale!)

Andreas R. wrote:

> In typical functional programming style,
> you need the general thing only rarely.

My impression is that the reason for not wanting (some do want however)
true dynamic binding in Haskell relates more to the fact that we
willingly
make closed world assumptions about the cases to dispatch one. Where the
C++ programmer defines classes, we are often just fine to define
*one* datatype with n constructors (corresponding to n classes).
In such a case, we have an easy time (except when we want case n+1
without
recompilation).

Using this "idea", late binding degenerates to pattern matching,
which is the value-level variation on VMT dispatch. (And for the
rare cases, where we want to become polymorphic with an open world,
we seem to be willing to sacrifice type inference and we engage
into existential polymorphism / first-class polymorphism.)
 
And then of course with normal Haskell type classes we can nicely
simulate *interface* polymorphism (again modulo the lack of type 
inference for subtyping polymorphism). 

So pre-OOHaskell doesn't miss a lot ;-)

Ralf

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

RE: Re[2]: [Haskell] Dynamic binding

[Ralf Lammel]

Andrew,

you are circumventing the hard problem!

(Even though I am sure you just forgot to mention it.)

That is, the question is about drawing a *list* of shapes.

As correctly observed by Rathman ages back, one naturally
ends up with existential quantification when simulating
dynamic binding. Ex. quantification is sufficiently scary
for folks moving from C++ to Haskell. But fortunately it's
not necessary ... see earlier plug ...

Ralf



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of [EMAIL PROTECTED]
> Sent: Thursday, June 23, 2005 12:42 AM
> To: haskell@haskell.org
> Subject: Re: Re[2]: [Haskell] Dynamic binding
> 
> G'day all.
> 
> Thursday, June 23, 2005, 5:38:03 AM, you wrote:
> 
> > To handle the problem of drawing all shapes, in c++, I would have a
list
> > of shape pointers:
> 
> > struct shape{ virtual void draw(...);};
> > struct circle : public shape {...};
> > struct square : public shape {...};
> > std::list shapes;
> > for(std::list::iterator it = shapes.begin();it !=
> > shapes.end();++it)
> > { (*it)->>draw(...); }
> 
> > This general pattern of dynamic binding I use over and over again.
Could
> > you give me some example code of this type of thing handled in
Haskell's
> > way? Assuming that the number of classes deriving from shape might
get
> > quite large.
> 
> class Drawable s where
> draw :: s -> IO ()
> 
> data Circle = Circle Point Radius
> 
> instance Drawable Circle where
> draw (Circle centre radius) = ...
> 
> If you only need interface inheritance, this should do.  If you also
need
> implementation inheritance, then you can model it with an upcast
method:
> 
> data Shape = Shape Stuff
> 
> class Shape s where
> toShape :: s -> Shape
> draw :: s -> IO ()
> 
> instance Shape Shape where
> toShape s = s
> draw s = ...
> 
> data Circle = Circle Shape Point Radius
> 
> instance Shape Circle where
> toShape (Circle s _ _) = s
> draw (Circle _ centre radius) = ...
> 
> In your original example, draw() wasn't abstract virtual, so I assume
> there's a reasonable default draw() method for your "shape" class.  If
> there isn't, then it's probably better in Haskell to split the
typeclass:
> 
> class Shape s where
> toShape :: s -> Shape
> 
> class (Shape s) => DrawableShape s where
> draw :: s -> IO ()
> 
> And only define DrawableShape on types where "draw" makes sense.
> 
> Cheers,
> Andrew Bromage
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: Re[2]: [Haskell] Dynamic binding

[Ralf Lammel]

Bulat,

Bulat wrote:

> just create list of draw functions itself:
> 
> [drawCircle (10,10) 5, drawSquare (20,20) 10]

No! the exercise is about lists of shapes
not lists of results of drawing shapes.
This is clearly a major difference.


Bulat wrote:

> for more complex tasks - declare interface as a structure:
> 
> data ShapeInterface = Shape { draw :: IO (),
>   moveTo :: Point -> IO (),
>   calcArea :: Float
> }

No! You miss the point that the different shapes
differ regarding state types.
You don't have a chance when you use one datatype.

haskell-cafe?

Ralf

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Bulat Ziganshin
> Sent: Thursday, June 23, 2005 12:18 AM
> To: Andrew Ward
> Cc: Pal-Kristian Engstad; haskell@haskell.org
> Subject: Re[2]: [Haskell] Dynamic binding
> 
> Hello Andrew,
> 
> Thursday, June 23, 2005, 5:38:03 AM, you wrote:
> 
> AW> To handle the problem of drawing all shapes, in c++, I would have
a
> list
> AW> of shape pointers:
> 
> AW> struct shape{ virtual void draw(...);};
> AW> struct circle : public shape {...};
> AW> struct square : public shape {...};
> AW> std::list shapes;
> AW> for(std::list::iterator it = shapes.begin();it !=
> AW> shapes.end();++it)
> { (*it)->>draw(...); }
> 
> AW> This general pattern of dynamic binding I use over and over again.
> Could
> AW> you give me some example code of this type of thing handled in
> Haskell's
> AW> way? Assuming that the number of classes deriving from shape might
get
> AW> quite large.
> 
> just create list of draw functions itself:
> 
> [drawCircle (10,10) 5, drawSquare (20,20) 10]
> 
> you are not expected that this problem can be solved with one line of
> code? :)
> 
> 
> for more complex tasks - declare interface as a structure:
> 
> data ShapeInterface = Shape { draw :: IO (),
>   moveTo :: Point -> IO (),
>   calcArea :: Float
> }
> 
> 
> and return this structures from "constructor" functions:
> 
> circle x y r = Shape { draw = drawCircle center r,
>moveTo newCenter = ,
>calcArea = pi*r*r
>  }
>where center = Point x y
> 
> square x y size = Shape { draw = ,
>   moveTo newCenter = ,
>   calcArea = size*szie
> }
> 
> figures = [circle 1 2 3, square 4 5 6, circle 7 8 9]
> 
> 
> 
> of course, you cannot use inherited field names when using this
> technique :)
> 
> --
> Best regards,
>  Bulatmailto:[EMAIL PROTECTED]
> 
> 
> 
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Dynamic binding

[Ralf Lammel]

At the risk of being excluded from this list
(because of an unmoral number of plugs about OOHaskell),
here we go: http://homepages.cwi.nl/~ralf/OOHaskell/

You might start with the appendices of the paper and also read Section 2
which finally implements the Shapes example with ease. The C++ encoding 
is a bit verbose in so far that C++ doesn't quite have type inference,
Haskell does and so OOHaskell does too :-)

Apologies,
Ralf


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
> Behalf Of Andrew Ward
> Sent: Wednesday, June 22, 2005 6:38 PM
> To: Pal-Kristian Engstad
> Cc: haskell@haskell.org
> Subject: Re: [Haskell] Dynamic binding
> 
> Pal-Kristian Engstad wrote:
> 
> >On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote:
> >
> >
> >>What would be the normal way for a Haskell programmer to handle the
> >>typical shape example in beginner OO tutorials?
> >>
> >>
> >
> >By not doing OO. You have to ask yourself, what is the purpose and/or
> benefit
> >of using OO? In C++, OO is _useful_ because you restrict the problems
of
> >mutable data (by enclosing it in C++ classes).
> >
> >ML type languages have other methods of doing things, and guess what,
OO
> is
> >not that needed for these languages. Sum-types, pattern-matching and
data
> >constructors make half of the need for OO go away. Higher order
functions
> and
> >make it even less needed. For the rest, there's always work-arounds.
> >
> >PKE.
> >
> >
> To handle the problem of drawing all shapes, in c++, I would have a
list
> of shape pointers:
> 
> struct shape{ virtual void draw(...);};
> struct circle : public shape {...};
> struct square : public shape {...};
> std::list shapes;
> for(std::list::iterator it = shapes.begin();it !=
> shapes.end();++it)
> { (*it)->draw(...); }
> 
> This general pattern of dynamic binding I use over and over again.
Could
> you give me some example code of this type of thing handled in
Haskell's
> way? Assuming that the number of classes deriving from shape might get
> quite large.
> 
> Andrew Ward.
> 
> 
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Call for participation: Summerschool on Gen. and Transf. Techn. in SE, 4-8 July 2005, Braga

[Ralf Lammel]

Please find attached the call for participation for the Summer School on
Generative and Transformational Techniques in Software Engineering
4 - 8 July, 2005, Braga, Portugal
http://www.di.uminho.pt/GTTSE2005
Registration is open.
There are 17 confirmed tutorials and other presentations.

--
Ralf Lammel
http://homepages.cwi.nl/~ralf/


Summer School on
Generative and Transformational Techniques
in Software Engineering
4 - 8 July, 2005, Braga, Portugal
http://www.di.uminho.pt/GTTSE2005

SCOPE AND FORMAT

The summer school brings together PhD students, lecturers, technology
presenters, as well as other researchers and practitioners who are
interested in the generation and the transformation of programs, data,
models, meta-models, and documentation. This concerns many areas of
software engineering: software reverse and re-engineering,
model-driven approaches, automated software engineering, generic
language technology, to name a few. These areas differ with regard to
the specific sorts of meta-models (or grammars, schemas, formats etc.)
that underly the involved artifacts, and with regard to the specific
techniques that are employed for the generation and the transformation
of the artifacts. The tutorials are given by renowned representatives
of complementary approaches and problem domains. Each tutorial
combines foundations, methods, examples, and tool support. The program
of the summer school also features invited technology presentations,
which present setups for generative and transformational
techniques. These presentations complement each other in terms of the
chosen application domains, case studies, and the underlying
concepts. Furthermore, the program of the school also features a
participants workshop. All students of the summer school will be
invited to give a presentation about their ongoing work. They will be
asked to submit a title and an abstract beforehand. The senior
researchers present at the summer school will provide the students
with feedback on their presentations. All summer school material will
be collected in proceedings that are handed out to the
participants. Formal proceedings will be compiled after the summer
school, where all contributions are subjected to additional
reviewing. The formal proceedings will be published in the Lecture
Notes in Computer Science series of Springer.


TUTORIALS

* Don Batory (The University of Texas at Austin):
  Feature Oriented Programming

* Ira Baxter (Semantic Designs Inc.):
  Compiling Fast XML reader/writers from DTDs using Program Transformations

* Jean Bezivin (INRIA, LINA, University of Nantes):
  Metamodelling and Model Driven Software Development

* Shigeru Chiba (Tokyo Institute of Technology):
  Program Transformation With Reflective and Aspect-Oriented Programming

* Jean-Luc Hainaut (University of Namur):
  The Transformational Approach to Database Engineering

* Zhenjiang Hu (University of Tokyo):
  Program Optimization and Transformation in Calculational Forms

* Erik Meijer (Microsoft, Redmond):
  Object, relational, and XML mapping

* Tom Mens (University of Mons-Hainaut):
  On the Use of Graph Transformations for Model Refactoring


TECHNOLOGY PRESENTATIONS

The purpose of the technology presentations is to supplement the
theoretical knowledge acquired in the tutorials with practical
knowledge of how generative and transformational tool support can be
instrumental in solving software engineering problems. Technology
presentations can include, but are not limited to demonstration of the
features of a single tool. Rather, they include:

* Reference to the concepts behind the technology
* Application of the technology to a case study of non-trivial scale
* Clear statement of benefits and limitations of the technology

The participants will have ample opportunity to interact in informal
manner with the technology presenters.

Confirmed technology presentations:
(Note: titles and authors abbreviated)

* Mark van den Brand (CWI & HvA, The Netherlands) et al.:
  Applications of the ASF+SDF Meta-Environment 

* Martin Bravenboer (Utrecht University, The Netherlands) et al.:
  Domain-specific Language Embedding using Stratego/XT and MetaBorg 

* Thomas R. Dean (Queen's University, Canada):
  Applications of Agile Parsing To Web Services 

* Helena Galhardas (IST Tagus Park, Portugal):
  Data cleaning and transformation using te AJAX framework 

* Dirk Heuzeroth (sd&m AG, Germany) et al.:
  A Tool Suite for Invasive Software Composition 

* Frederic Jouault (Université de Nantes, France):
  Model Transformation and Weaving Tools in the AMMA Platform

* Günter Kniesel (University of Bonn):
  Refactoring based on Composable Conditional Program Transformations 

* Victor Winter (University of Nebraska at Omaha, USA):
  Software transformation with HATS' Higher-Order Transformation 

* Albert Zündorf (University of Kassel, Germany):
  Model Driven Software Development with Fujaba 


VENUE

The summer school will be held in t