[Haskell] Call for Remote Hackathon Participation at SoTeSoLa
Time to show off with Haskell again in the areas of software mining, software reverse/re-engineering. Please have a look and join. Ralf Lämmel Call for Remote Hackathon Participation at SoTeSoLa http://planet-sl.org/sotesola2012-hackathon On 20 and 22 Aug, starting 5:55pm, CEST, SoTeSoLa will run an open Hackathon on software mining and reverse/re-engineering, for which remote participation is endorsed. Context Reverse and Re-engineering are established areas in software engineering and computer science. Reverse engineering is meant in a broad sense to include software mining, fact extraction, software visualization, vocabulary mining, analysis of language usage, architecture recovery, etc. Re-engineering is also meant in a broad sense to include, for example, program refactoring, wrapping, dead-code elimination, language migration, database re-engineering, and other forms of software evolution. There exist numerous methods and tools out there. There have been various efforts to integrate the related body of knowledge in textbooks, online resources, and otherwise. At SoTeSoLa, such integration will be continued in the form of a hackathon with on-site and remote participation. Objective During the hackathon, the participants exercise methods and tools of interest in reverse/re-engineering/software mining experiments. In order to focus efforts, to enable diverse experiments, and to stimulate synergies, the experiments target the software chrestomathy of the 101companies project, which is available as a git repository 101repo of source code and as dumps and resources 101data of extracted facts. The participants will typically target specific 101implementations or sets thereof, specific technologies (such as EF, JAXB, Hibernate, Ant, or Make), and specific languages (such as Java, Haskell, or C#). Such selection should help in demonstrating efficiently the methods and tools of interest. The expectation is that the hackathon produces a corpus of samples, which may be useful, for example, in teaching software mining, reverse and re-engineering, or as a benchmark or a point of reference in these areas of research. Some ilustrations and various helpful pointers are available (see the resource section of the website). Logistics On Monday, 20 Aug, the focus is on reverse engineering and specifically software mining; on Wedneday, 22 Aug, the focus is on re-engineering, hackathonists are welcome to reverse/re-engineer/mine software at all times, though. At the beginning of the hackathon, Vadim Zaytsev gives a presentation to explain the hackathon concept. This presentation will be recorded and broadcasted for remote participants. Remote participants can connect with on-site participants via Google Hangout and Skype. Hackathon teams with interesting results can give a short presentation in a designated session on the next day of the SoTeSoLa program. Checklist 1. Register through Hackathon web site. http://planet-sl.org/sotesola2012-hackathon 2. Receive Hackathon latest instructions before hackathon onsite, via Google Hangout, or YouTube. 3. Join in over Google Hangout or Skype during the hackathon. 4. Submit code and documentation, e.g., via GitHub. 5. Optionally, present during a designated SoTeSoLa session next day. Award All registered teams compete for the SoTeSoLa Hackathon award funded by Google. The winner will be selected by a committee that is formed at the school drawing from speakers and other senior community members present at the school. The presentation at the beginning of the hackathon provides advice on how to compete for the award. SoTeSoLa is a fun-oriented research event. Regards, Jean-Marie Favre (Research 2.0 Chair) Ralf Laemmel (General Chair, SoTeSoLa) Vadim Zaytsev (Hackathon Coordination) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Call for Participation: SoTeSoLa, 19-23 Aug, Koblenz
Dear Haskell-ers, SoTeSoLa is not a Haskell- or FP-centric event, but Haskell-ers are very much encouraged to represent their technological space at the school. In fact, I know for a reason that some Haskell-ers will be there, but the more the better. I expect that Haskell will play a role in one of the two hackathons and perhaps in some working group. (For instance, we are thinking about a working group on the spreadsheet-centric technological space, where Haskell plays a role as a modeling language and otherwise.) Regards, Ralf The summer school SoTeSoLa 2012 is a highly discussion- and result-oriented Research 2.0 event on software technologies and software languages. http://planet-sl.org/sotesola2012 SoTeSoLa 2012 takes place in Koblenz 19-23 August 2012. SoTeSoLa brings together senior and junior researchers and technologists interested in software science, specifically the foundations of software technologies and the notion of technological spaces as linking together software languages, technologies, and various resources adding up to a technological and community context. SoTeSoLa also hosts this time the SATToSE 2012 seminar on Advanced Techniques Tools for Software Evolution. Key topics at the school are these: - Generic language technology - Co-evolution of software artifacts - Multi-language, multi-technology problems - Research 2.0 applied to software engineering - Technological spaces: past, present, and future - eLearning for language engineers technologists - Models of knowledge resources for software developers - Model-driven engineering beyond software development - Software re/reverse/engineering in the Semantic Web Era SoTeSoLa aims at exercising a new format for a software language/technology forum, i.e., a more Research 2.0-based approach so that much focus is on understanding each others context, integrating knowledge, automation thereof, and organizing future research and work of the participants. To this end, regular lectures are de-emphasized, but a more discussion- and result-oriented format will be exercised. The event maxes out at 42 participants. SoTeSoLa 2012 is supported by the ADAPT research focus at the University of Koblenz-Landau as part of Rhineland Palatinate's Research Initiative 2008--2013. SoTeSoLa 2012 is also supported by RainCode. SoTeSoLa is hosted by the Software Languages Team in Koblenz. Deadlines: - Registration deadline: 4 August 2012 - Hotel reservation deadline: 1 August 2012 - Deadline for SATToSE presentation proposals: 25 July 2012 - Deadline for student grant applications: 25 July 2012 - Deadline for hackathon and working-group proposals: none and ASAP - Notification for SATToSE presentation proposals: 29 July 2012 - Summer school: 19 August (afternoon) - 23 August 2012 (noon) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] PhD/PostDoc opening in programming techniques and technologies
PhD/PostDoc opening in programming techniques and technologies in the Software Languages Team [1] in Koblenz. Applicants can safely assume that functional programming plays a huge role in this. The application deadline is 31 Aug. A German description of formalities is available [2]. One essential component of the position is research, teaching as well as development efforts on 101companies [3]. Regards, Ralf [4] [1] http://softlang.wikidot.com/ [2] http://softlang.uni-koblenz.de/docs/Ausschreibungstext_WiMi_HPII-Laemmel.pdf [3] http://101companies.org/ [4] http://softlang.wikidot.com/rlaemmel:home ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] CfP ADAPT Summer School
Dear Haskellers, this summer school contains bits of formal methods and language design that typically intersect very well with interests on this list. Looking forward to meet some of you in Koblenz. Ralf 8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CALL FOR PARTICIPATION : ADAPT 2010 1st ADAPT Summer School September 26 - October 2, 2010, Koblenz, Germany http://adapt.uni-koblenz.de/summerschool2010 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Software adaptation is a topic that crosscuts much of software engineering, programming languages, information systems, formal methods, and other major areas of computer science. The CS department at the University of Koblenz-Landau engages in a research focus on software adaptation, and thereby connects scientists and teams in classical areas of computer science as much as application areas such as web-based systems, SOA, mobile systems, and robotics. ADAPT 2010 is the first edition in a series of summer schools on software adaptation. The program of ADAPT 2010 appeals to PhD students and possibly specialized Master's students in computer science. 8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Haskell in image processing
Disclaimer: this is an Xmas gift as opposed to serious stuff. http://professor-fish.blogspot.com/2009/12/major-breakthrough-in-image-processing.html Greetings, Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Data.Generics.gzip3 anyone?
On Mon, Jun 1, 2009 at 8:20 PM, David Fox da...@seereason.com wrote: Is there a Scrap Your Boilerplate guru out there who could whip up a three argument version of gzip for me? This can be done of course (untested but type-checked code follows). Left wondering what the scenario might be :-) Ralf import Prelude hiding (GT) import Data.Generics -- As originally defined: Twin map for transformation gzipWithT2 :: GenericQ (GenericT) - GenericQ (GenericT) gzipWithT2 f x y = case gmapAccumT perkid funs y of ([], c) - c _ - error gzipWithT2 where perkid a d = (tail a, unGT (head a) d) funs = gmapQ (\k - GT (f k)) x -- For three args now gzipWithT3 :: GenericQ (GenericQ (GenericT)) - GenericQ (GenericQ (GenericT)) gzipWithT3 f x y z = case gmapAccumT perkid funs' z of ([], c) - c _ - error gzipWithT3 where perkid a d = (tail a, unGT (head a) d) funs' = case gmapAccumQ perkid' funs y of ([], q) - q _ - error gzipWithT3 where perkid' a d = (tail a, unGQ (head a) d) funs = gmapQ (\k - (GQ (\k' - GT (f k k' x ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Data.Generics.gzip3 anyone?
Thank you! What I have in mind is three way merging - you have two
revisions based on the same original value, and you need to decide whether
they can be merged automatically or they need to be merged by a user. You
only have a real conflict when both revisions differ from the original and
from each other.
Here is the completed exercise.
For comparison, the two args versions are shown up-front.
There is gzipWithM3 needed for gzip3, and gzip3 itself.
I also made it so that the top-level gzip functions have the
appropriate polymorphism.
Say same type for the args rather than independent polymorphism.
{-# LANGUAGE RankNTypes #-}
import Prelude hiding (GT)
import Data.Generics
-- As originally defined: Twin map for transformation
gzipWithT2 :: GenericQ (GenericT) - GenericQ (GenericT)
gzipWithT2 f x y = case gmapAccumT perkid funs y of
([], c) - c
_ - error gzipWithT2
where
perkid a d = (tail a, unGT (head a) d)
funs = gmapQ (\k - GT (f k)) x
-- As originally defined: Twin map for transformation
gzipWithM2 :: Monad m = GenericQ (GenericM m) - GenericQ (GenericM m)
gzipWithM2 f x y = case gmapAccumM perkid funs y of
([], c) - c
_ - error gzipWithM
where
perkid a d = (tail a, unGM (head a) d)
funs = gmapQ (\k - GM (f k)) x
-- As originally defined: generic zip
gzip2 ::
(forall x. Data x = x - x - Maybe x)
- (forall x. Data x = x - x - Maybe x)
gzip2 f = gzip2' f'
where
f' :: GenericQ (GenericM Maybe)
f' x y = cast x = \x' - f x' y
gzip2' :: GenericQ (GenericM Maybe) - GenericQ (GenericM Maybe)
gzip2' f x y =
f x y
`orElse`
if toConstr x == toConstr y
then gzipWithM2 (gzip2' f) x y
else Nothing
-- For three args now
gzipWithT3 ::
GenericQ (GenericQ (GenericT))
- GenericQ (GenericQ (GenericT))
gzipWithT3 f x y z =
case gmapAccumT perkid funs z of
([], c) - c
_ - error gzipWithT3
where
perkid a d = (tail a, unGT (head a) d)
funs = case gmapAccumQ perkid' funs' y of
([], q) - q
_ - error gzipWithT3
where
perkid' a d = (tail a, unGQ (head a) d)
funs' = gmapQ (\k - (GQ (\k' - GT (f k k' x
gzipWithM3 :: Monad m
= GenericQ (GenericQ (GenericM m))
- GenericQ (GenericQ (GenericM m))
gzipWithM3 f x y z =
case gmapAccumM perkid funs z of
([], c) - c
_ - error gzipWithM3
where
perkid a d = (tail a, unGM (head a) d)
funs = case gmapAccumQ perkid' funs' y of
([], q) - q
_ - error gzipWithM3
where
perkid' a d = (tail a, unGQ (head a) d)
funs' = gmapQ (\k - (GQ (\k' - GM (f k k' x
gzip3 ::
(forall x. Data x = x - x - x - Maybe x)
- (forall x. Data x = x - x - x - Maybe x)
gzip3 f = gzip3' f'
where
f' :: GenericQ (GenericQ (GenericM Maybe))
f' x y z = cast x = \x' - cast y = \y' - f x' y' z
gzip3' ::
GenericQ (GenericQ (GenericM Maybe))
- GenericQ (GenericQ (GenericM Maybe))
gzip3' f x y z =
f x y z
`orElse`
if and [toConstr x == toConstr y, toConstr y == toConstr z]
then gzipWithM3 (gzip3' f) x y z
else Nothing
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: indirectly recursive dictionaries
Re: Tom: Thanks. This was an excellent analysis.
Re: Oleg: Obviously, I don't want to add instance C1 int. Rather C1
Int should be implied by the existing scheme for recursive dictionary
construction and bar should typecheck fine. (foo already relies on
this scheme.) However, as Tom pointed out, we would need FD
improvement to happen more intermittently.
... and that's the Gretchen-Frage I guess whether there is a
reasonable (enough) scheme of doing so? The *intention* sounds
reasonable. In fact, to me it sounds less reasonable to defer FD
improvement and go on with an unnecessarily general goal C1 (y, Bool),
i.e., without taking advantage of the fact that y is functionally
determined by a constant type Int.
That's a slippery slope - I know.
Ralf
PS:
Is this a topic that should relocate to haskell-cafe, if there is
further interest?
I don't know ...
On Tue, Mar 17, 2009 at 2:52 AM, Ralf Laemmel rlaem...@gmail.com wrote:
{-
Recursive instance heads as in ...
instance C0 (x,Bool) = C0 x
... are Ok if we allow for typechecking scheme as described in SYB with
class.
The main idea is to assume C0 x in proving the preconditions of the
body of the clause.
This is also works for mutual recursion among type classes and
instances to the extent exercised in ditto paper.
What about the below example though?
Here recursion detours through an extra class in a way that leads to
nonterminating typechecking with GHC 6.10.1.
Does anyone agree that a constraint resolution scheme like the one
mentioned could be reasonably expected to cover this case?
Regards,
Ralf
-}
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-overlapping-instances #-}
{-# OPTIONS -fallow-undecidable-instances #-}
-- Direct recursion terminates (typechecking-wise)
class C0 x
where
m0 :: x - ()
m0 = const undefined
instance (C0 x, C0 y) = C0 (x,y)
instance C0 Bool
instance C0 (x,Bool) = C0 x
foo :: ()
foo = m0 (1::Int)
-- Indirect recursion does not terminate (typechecking-wise)
class C1 x
where
m1 :: x - ()
m1 = const undefined
instance (C1 x, C1 y) = C1 (x,y)
instance C1 Bool
instance (C2 x y, C1 (y,Bool)) = C1 x
class C2 x y | x - y
instance C2 Int Int
-- It is this declaration that causes nontermination of typechecking.
bar :: ()
bar = m1 (1::Int)
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] indirectly recursive dictionaries
{-
Recursive instance heads as in ...
instance C0 (x,Bool) = C0 x
... are Ok if we allow for typechecking scheme as described in SYB with class.
The main idea is to assume C0 x in proving the preconditions of the
body of the clause.
This is also works for mutual recursion among type classes and
instances to the extent exercised in ditto paper.
What about the below example though?
Here recursion detours through an extra class in a way that leads to
nonterminating typechecking with GHC 6.10.1.
Does anyone agree that a constraint resolution scheme like the one
mentioned could be reasonably expected to cover this case?
Regards,
Ralf
-}
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-overlapping-instances #-}
{-# OPTIONS -fallow-undecidable-instances #-}
-- Direct recursion terminates (typechecking-wise)
class C0 x
where
m0 :: x - ()
m0 = const undefined
instance (C0 x, C0 y) = C0 (x,y)
instance C0 Bool
instance C0 (x,Bool) = C0 x
foo :: ()
foo = m0 (1::Int)
-- Indirect recursion does not terminate (typechecking-wise)
class C1 x
where
m1 :: x - ()
m1 = const undefined
instance (C1 x, C1 y) = C1 (x,y)
instance C1 Bool
instance (C2 x y, C1 (y,Bool)) = C1 x
class C2 x y | x - y
instance C2 Int Int
-- It is this declaration that causes nontermination of typechecking.
bar :: ()
bar = m1 (1::Int)
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell goes GPCE/OOPSLA 2008
[One-liner version: please submit workshop/tutorial proposals for GPCE 2008.] The conference on Generative Programming and Component Engineering (GPCE) had some functional programming input over the last few years. It is a good idea to continue this trend. For instance, Haskell-hosted ideas of meta programming and more general (FP-based) ideas of staged programming are at the heart of GPCE. Likewise, aggressive optimization and advanced modularization concepts are in the intersection of the Haskell crowd and the GPCE scope. This year's GPCE conference again co-locates with OOPSLA. We are looking for strong proposals for workshops and tutorials that complement the GPCE technical programme, and thereby also contribute to the combined GPCE/OOPSLA programme. It will be great to get a submission or two from the Haskell community. Please have a look at the call for proposals, at the list of topics, and at the history of the GPCE conference series. For instance, it would be appropriate to see a workshop or a tutorial on type functions, general type-level programming, hygienic templates or macros, advanced partial evaluation, FP refactorings, component programming in FP, ..., something like that. I specifically encourage you to reach out for the crowd at GPCE/OOPSLA so that we extend our impact. http://www.hope.cs.rice.edu/twiki/bin/view/GPCE08/ http://www.hope.cs.rice.edu/twiki/bin/view/GPCE08/CallForWorkshops http://www.hope.cs.rice.edu/twiki/bin/view/GPCE08/CallForTutorials [Deadline: 20th March] Regards, Ralf Laemmel Satellite Chair GPCE 2008 PS: The paper deadline for GPCE is in May. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] detecting existing instances
Given two type classes A t and B t, I'd like the typechecker to derive
different A t instances depending exactly on whether t is an instance of
B. In other words, is it possible to define a class (actually a type-level
function) IsB t f such that:
A GHC-like type system is in principle powerful enough to do just
that. We exploit such capability in HList and OOHaskell. That is, the
class whose instance availability should be observed must be first set
up to carry an extra functionally dependent type parameter that
specifically is meant to report back on instance availability. Then,
we sacrifice the capability of a generic default instance for that
class to indeed report back the lack of an instance through a
type-level False on the new type-parameter position, whereas all
normal instances report back type-level True. The usual problem of
functional-dependency violation occurs, that is, the generic default
instance is not entirely standard because if it says to return False
for all types, then the other instances can't claim the opposite
unless we had special fundep rules for generic default instances.
However, we can recover from that by making the generic default
instance vacuously generic in the type-level Boolean result position
so that it becomes strictly more general than any specific instance,
while we still assign type-level False to the position but by a
type-level cast (instead of a verbatim False).
Type-level type cast is the type-level programmer's swiss army knife.
See the illustration below.
HTH,
Ralf
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-overlapping-instances #-}
{-# OPTIONS -fallow-undecidable-instances #-}
module M2 where
import M1
instance TypeCast x x where typeCast = id
main =
do
print $ b $ hasInstance ST1
print $ b $ hasInstance ST2
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-overlapping-instances #-}
{-# OPTIONS -fallow-undecidable-instances #-}
module M1 where
-- Type-level Booleans
data T -- True
data F -- False
class B x where b :: x - Bool
instance B T where b = const True
instance B F where b = const False
-- Sample types
data ST1 = ST1
data ST2 = ST2
-- A class that reports on instance availability
class B b = R x b | x - b
instance R ST1 T
instance (B b, TypeCast F b) = R x b -- generically missing instance
-- Observe instance availability
hasInstance :: R x b = x - b
hasInstance _ = undefined
-- The key weapon
class TypeCast x y | x - y, y - x
where
typeCast :: x - y
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Empty instance declaration
Isaac wrote: I wonder whether it would be safe for the compiler to infer simply by the default methods mentioning each other in a cycle. It might miss some cases when (probably involving laziness) the default methods actually terminate and form an intended set of implemention, and warn when it shouldn't... which is bad, but does that ever happen? mentioning each other in a cycle is too imprecise unfortunately at least for two reasons: a) we could face a well-designed mutual recursion. b) we could face co-induction. The ultimate solution is to extend type signatures by termination requirements and to have a termination checker enforcing them. For instance, Andreas Abel has done groundbreaking work on termination checking. Cheers, Ralf ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Empty instance declaration
You did not say anything that's imprecise about mentioning each other in a cycle, just the well-known fact that it's not equivalent to total termination checking (in fact, it's neither fully an overestimate nor underestimate of termination -- it's just an estimate that's likely to be right when used in the context of default method definitions). It's imprecise also in so far that you would need to define what you mean by it. Does it mean that we focus on the pattern f ... = g ... g ... = f ... ... or does it include the case f ... = h g ... g ... = f ... ... and that's still very imprecise because the dots don't mean anything proper. Are you willing to look at the pattern *after* overloading resolution. Let's have a proper termination checker! Btw, obviously a class by itself would not be checked (in terms of the default methods), but only an instance (with the defaults pulled in). Cheers, Ralf ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CFP --- FOAL: Foundations of Aspect-Oriented Languages
[You can actually check that indeed Haskell folks have contributed to this workshop in the past. -- Ralf] Call for papers: FOAL: *F*oundations *o*f *A*spect-Oriented *L*anguages A one day workshop affiliated with AOSD 2008 in Brussels, Belgium, on 31 March or 1 April 2008. Themes and Goals *FOAL* is a forum for research in foundations of aspect-oriented programminglanguages. 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 the ACM Digital Library, hence authors of accepted papers will be asked to transfer copyright to the ACM. However, as FOAL is a workshop, publication of extended versions of the papers in other venues will 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, 11 January 2008 (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. - 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. We will notify the corresponding author of papers that are selected for presentation at the workshop by 8 February 2008. Early registration for AOSD (you must register for AOSD to attend the workshop) will end on 25 February 2008. Final versions of papers for the proceedings will be due on 1 March 2008. For more information, visit the FOAL Workshop home page (at http://www.eecs.ucf.edu/FOAL). Important Dates Submission Deadline 23:00 GMT, 11 January 2008 Notification of Acceptance 8 February 2008 Final Versions of Papers Due 1 March 2008 Workshop 31 March 2008 or 1 April 2008 Program Committee We are pleased to have assembled another exceptional program committee for FOAL this year: - Curtis Clifton (Program Committee Chair)— Rose-Hulman Institute of Technology - Jonathan Aldrich — Carnegie Mellon
Re: Restricted Types and Infinite Loops
Hi Simon (PJ),
cc Simon (DF),
I rather reckon we are facing a bug here.
The attached minimalised Foo.hs shows the offending code pattern.
With GHC 6.2 we get *** Exception: loop
With GHC 6.4 we get(still waiting for the rest of the string)
The scenario is about class/instance-head-level recursion
through superclassing and instance constraints.
Nothing too weird.
There are no _explicit_ recursive dictionaries.
An observations though.
The relevant class head does not just mention a recursive superclass,
but also an innocent superclass ClassB. If we move this innocent
superclass constraint to the instance level (see Bar.hs), then
we get termination with both 6,2 and 6.4.
Another issue.
This feature seems to need multi-parameter classes really!
Ralf
Simon Peyton-Jones wrote:
Simon
You've found an interesting case.
First, you are skating on thin ice here. GHC's ability to build
recursive dictionaries is quite experimental, and you are relying on it
completely.
But you're right: it should work. I can see why it isn't but I have
not got it clear enough in my head to know the best way to fix it.
Still less do I have a formal story about what should type-check
(without loops) and what should not.
So this is going to continue to fail in 6.4, but it's on my list to look
at.
Simon
--
Ralf Lammel
[EMAIL PROTECTED]
Microsoft Corp., Redmond, Webdata/XML
http://www.cs.vu.nl/~ralf/
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
{-
Try:
(sat::Int - String - String) undefined hello
-}
module Foo where
class (Sat (a - b - String), ClassB b) = ClassA a b
class ClassB a
where
fun :: a - String
class Sat x
where
sat :: x
instance ClassA a b = Sat (a - b - String)
where
sat = const fun
instance ClassA a String
instance ClassB String
where
fun = id
{-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
{-
Try:
(sat::Int - String - String) undefined hello
-}
module Foo where
class Sat (a - b - String) = ClassA a b
class ClassB a
where
fun :: a - String
class Sat x
where
sat :: x
instance (ClassA a b, ClassB b) = Sat (a - b - String)
where
sat = const fun
instance ClassA a String
instance ClassB String
where
fun = id
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: gunfoldl
It is called gunfold rather than gunfoldl
as you will see when you browse the Data.Generics.Basics.
Also, your gunfold code looks like it will not work.
Here is a simple example for Maybe:
gunfold k z con =
case constrIndex con of
1 - z Nothing -- no children
2 - k (z Just) -- one child, hence one k
Bottom line:
- apply z to the Constructor
- apply k as many times as the number of children.
No warranty that this is easy for your type Item.
Good luck,
Ralf
Akos Korosmezey wrote:
I wrote a little data structure with quantified constructors:
module MyModule where
import Data.Generics
import Data.HashTable
data Item = forall a. (Data a) = Leaf Bool a
| forall a. (Data a) = Branch Bool a Int Int
deriving (Typeable)
I want it to make an instance of Data:
instance Data Item where
gfoldl k z (Leaf b v) = z (Leaf b) `k` v
gfoldl k z (Branch b v a1 a2) = z (\x - Branch b x a1 a2) `k` v
--gunfoldl k z c = case constrIndex c of
--1 - k z (Leaf undefined
undefined)
toConstr (Leaf _ _) = leafConstr
toConstr (Branch _ _ _ _) = branchConstr
dataTypeOf _ = itemDataType
itemDataType = mkDataType Subliminal.Item [leafConstr, branchConstr]
leafConstr = mkConstr itemDataType Leaf [] Prefix
branchConstr = mkConstr itemDataType Branch [] Prefix
But, when I try to compile it with ghc-6.4-20050217:
ghc -fglasgow-exts -i. -c kicsi.hs
kicsi.hs:13:4:
Warning: No explicit method nor default method for `gunfold'
In the instance declaration for `Data Item'
ghc-6.4.20050217: panic! (the `impossible' happened, GHC version
6.4.20050217):
cgPanic
k{v a1vu}
static binds for:
local binds for:
gunfold{v r22q}
SRT labelghc-6.4.20050217: panic! (the `impossible' happened, GHC
version 6.4.20050217):
initC: srt
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
If I uncomment the gunfoldl lines:
ghc -fglasgow-exts -i. -c kicsi.hs
kicsi.hs:12:8: `gunfoldl' is not a (visible) method of class `Data'
Compilation exited abnormally with code 1 at Fri Feb 18 20:55:32
Could you please help me?
Thanks
Akos
--
Ralf Lammel
[EMAIL PROTECTED]
Microsoft Corp., Redmond, Webdata/XML
http://www.cs.vu.nl/~ralf/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Restricted Types and Infinite Loops
Hi Simon SD,
cc Simon PJ,
(Since the _evaluation_ does not terminate (rather than type checking),
this seems to imply that evaluation-time dictionary construction does
not terminate. Right?)
Anyhow, do this change, and your code works.
diff SDF.save SDF.hs
10c10
class (Data (DictClassA a) b, ClassB b) = ClassA a b where
---
class (Data (DictClassA a) b) = ClassA a b where
*Test func2D (classBD (dict::DictClassA Int String)) hello
bye
*Test Leaving GHCi.
(BTW, this even works with GHC 6.2 as opposed to the examples from the
SYB3 paper.)
Here I assume that you don't _really_ depend on ClassB to be a
superclass of ClassA. (Why would you?)
This is a simpler recursion scheme in terrms of class/instance constraints.
Regards,
Ralf
Simon David Foster wrote:
Hi,
(I've attached the full code for this problem)
First I'll explain the problem description, I have two class ClassA and
ClassB, the former has two parameters and the latter has one. The second
parameter of ClassA is constrained by ClassB.
class ClassB a where
class ClassB b = ClassA a b where
Because I wish to effectively pass the context of ClassA around, I need
to create a pair of dictionary types (as in Restricted Data Types in
Haskell, Hughes 99), one to represent ClassA (DictClassA) and one to
represent ClassB (DictClassB). DictClassA also contains a term of type
DictClassB since ClassA is a subclass of ClassB. I should then be able
to call all the functions of ClassB via the appropriate term of
DictClassA, like so (assuming we want to use func2);
*Test func2D (classBD (dict::DictClassA Int String)) hello
bye
So far so good, but now suppose I want Class A to have the further
constraint
class (Data (DictClassA a) b, ClassB b) = ClassA a b where
(so as to make ClassA a subclass of Data)
If we now try and do
*Test func2D (classBD (dict::DictClassA Int String)) hello
We go into an infinite loop. Why? The expression still type-checks ok
and I can't see what it is trying to do. All the functions of ClassA can
be accessed ok, but not ClassB.
*Test funcD ((dict::DictClassA Int String)) hello 5
hello
Is it something to do with ClassB only having one parameter?
I'm running GHC 20041231.
-Si.
{-# OPTIONS -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances #-}
module Test where
import Data.Typeable
-- Skeleton of the Data class
class (Typeable a, Sat (ctx a)) = Data ctx a
-- Our main class with 2 parameters
class (Data (DictClassA a) b, ClassB b) = ClassA a b where
func :: b - a - String
-- The class which contrains ClassA
class ClassB a where
func2 :: a - String
data DictClassA a b = DictClassA { funcD :: b - a - String, classBD ::
DictClassB b }
data DictClassB b = DictClassB { func2D :: b - String }
class Sat a where
dict :: a
instance Sat (ctx String) = Data ctx String
-- Trying to access any of functions in ClassA works fine, but trying to get at
anything in ClassB causes and infinite loop.
instance (Data (DictClassA a) b, ClassA a b, ClassB b) = Sat (DictClassA a b)
where
dict = DictClassA { funcD = func, classBD = dict }
instance ClassB b = Sat (DictClassB b) where
dict = DictClassB { func2D = func2 }
instance ClassA a String where
func _ _ = hello
instance ClassB String where
func2 _ = bye
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
Ralf Lammel
[EMAIL PROTECTED]
Microsoft Corp., Redmond, Webdata/XML
http://www.cs.vu.nl/~ralf/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] sugar for extensible types (was: class associated types, via GADTs.)
Assoc types and GADTs are great but I am still too fond of encoding extensible datatypes with (open) classes. I contributed to some related discussion at comp.compilers a while ago [1]. The Haskell code samples are worth sharing (because they are so simple): http://homepages.cwi.nl/~ralf/OOHaskell/src/interpreter/nonextensible.hs http://homepages.cwi.nl/~ralf/OOHaskell/src/interpreter/extensible.hs (Note: *no* OOHaskell idioms used.) My conclusion at that time was: 1. Style/verbosity-wise, this is close to mainstream OOP. 2. It would be great (and rather trivial) to provide syntactic sugar for data to replace the class/instances needed per extensible datatype. Reifying closed datatypes as open classes is folk-lore. 3. I am not too much concerned to write equations of extensible functions as instances of a dedicated class. One reason to complain is of course that the programmer had to provide instance constraints for each equation (in fact, instance) of an extensible function. (In particular, I mean the instance constraints for recursive occurrences of the extensible function under definition.) So type inference would fall short for extensible datatypes. 4. But this is not difficult to resolve either. The existing compiler/type system does all the hard work already. That is, each equation of an extensible function is hiddenly given to the type checker as a normal function using a fresh function symbol on the LHS. The class constraints of the thereby inferrable type can now be turned into instance constraints for the equation-encoding instance of the class for the extensible function. (Thanks to Oleg for enlightening me.) Add some syntactic sugar to that, and you are done. 5. One remaining problem is about type signatures, in particular, the inferred type signatures such as those obtained by t:. The problem is that they blow up whenever a concrete value of an extensible datatype is involved. We would see the entire term structure in the type! How difficult could it be to inform the type-checker, or (I am kidding) just the pretty printer for type signatures such that types for extensible types are generalised to the corresponding class before printing. A bit more cheating: the class is not reported as a constraint on the LHS of = but as (extensible) type on the RHS of =. Not difficult. This should also work the other way around, say, we would also be allowed to enter type signatures where we use the names of extensible datatypes in types without exposing the underlying nature of these extensible datatypes to correspond to classes. 6. There is one _real_ problem, which is about the size of the resulting dictionaries, and the complexity of the operations on that. There is a good chance that our extensible datatypes won't scale in current Haskell implementations. I am sure that some sort of memoisation for dictionary types/constraint checking should provide sufficient help here. However I don't hold my breath --- this might be difficult. Ralf [1] http://compilers.iecc.com/comparch/article/04-12-111 -- Ralf Lammel [EMAIL PROTECTED] Microsoft Corp., Redmond, Webdata/XML http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: gfindtype type
Typeable is a superclass of Data. So you would indeed imply Typeable by requiring Data. However, you don't _need_ Data but only Typeable. You need Data x to find Typeable y; once you find y you don't need to _traverse_ any further into y. To summarise, requiring Typeable is simply more precise as to what's needed. Ralf Stefan Holdermans wrote: Jim, Why is gfindtype :: (Data x, Data y) = x - Maybe y and not gfindtype :: (Data x, Typeable y) = x - Maybe y ? Because you're not always interested in a subterm of the same type as the parent node. Ouch, answered your question before I really read it, i.e., before a first cup of coffee. Sorry. Regards, Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: What are the MonadPlus laws?
Jules Bean wrote: Are there any interesting programming uses of MonadPlus apart from 'calculations returning multiple values'.. i.e. lists/sets/multisets/maybe? Just a minor point ... You mention Maybe in the list above but I would like to wonder whether it is fully appropriate to associate it with calculations returning multiple values. Depending on what you find interesting, I would like to mention *biased binary choice*. Try the left operand first, if it fails, try the second operand. For instance, this is a key idiom in strategic programming with Strafunski (and has been adopted from Stratego). All in all, this more like try and catch or exception handling rather than calculations returning multiple values. Ralf -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Typeable and Data instances for Double, FiniteMap, ...
Georg Martius wrote: I was playing around with Scap you Boilerplate and realised some missing instances of Typeable and Data. Is there a particular reason why there is no Data Double instance? There has been a Double instance under CVS (GHC HEAD) since March 2004. It will be included in GHC 6.4. (BTW, this email should go to glasgow-haskell-users perhaps?) Furthermore I was wondering why no instance for the collection types such as FiniteMap, Set and HashTable is provided. Yes, once you start to use the SYB library you end up wanting it to cover almost all your types. I will make an effort *now* hoping that all the instance can still make it into GHC 6,4. (There are indeed a few more unsupported types that make obviously sense.) I looked at the library source-code (GHC) and reallised that there is really much documenting comments in, but which are not Haddock comments. Again I don't understand that. Is the programmer supposed to look at the source-code rather the API documentation? I wonder how other Haskellers think of that. I tend to use non-Haddock comments whenever I want to document *implementation details*. Is there an idiom for that; so that people get not confused? Regards, Ralf ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] SCP special issue on Foundations of AOP --- Last CFC + Deadline extension
Special Issue on Foundations of Aspect-Oriented Programming Science of Computer Programming Last Call For Contributions [ Please note the new deadline: 1 March 2005. This deadline caters for synchronisation with the FOAL 2005 workshop. See text below. ] Guest Editors: Pascal Fradet and Ralf Lämmel http://www.cs.vu.nl/faop-scp/ Call for contributions Modularity concepts support the separation of concerns, and hence they are crucial for mastering the complexity of software. In recent years, the modularity concept of aspects has been introduced. Aspects facilitate the modularisation of crosscutting concerns. The corresponding paradigm, aspect-oriented programming (AOP), is part of a larger effort -- Aspect-Oriented Software Development (AOSD). Clearly, AOP and AOSD have attracted a great deal of interest: various AOP tools are being developed and AOP is now successfully used in real-world applications. However, a widely shared criticism of AOP is that it still lacks firm foundations. For instance, the untamed form of AOP that we see today is often criticised for defeating encapsulation and preventing local reasoning. Likewise, the interference of multiple aspects is considered a serious risk of current AOP techniques. This special issue is dedicated to the foundations of aspect-oriented programming including formal methods, tools, languages and calculi. The special issue goes along with the successful series of FOAL workshops (Foundations of Aspect Oriented Languages). Extended versions of FOAL 2002--2005 papers are particularly welcome. However, submission to the special issue is completely open. The special issue will be published in the journal Science of Computer Programming, which implies excellent visibility and high quality standards. The guest editors solicit high-quality contributions that address the foundations of AOP, and that improve the state of the art of developing, understanding, controlling and reasoning about aspect-oriented programs. Work on modularity concepts other than aspects is also solicited provided that such work is clearly related to AOP. For instance, fundamental contributions to reflection are likely to be relevant for the foundations of AOP. Specific topics of interest include, but are not limited to: * Reasoning about aspect-oriented programs. * Semantics of aspects and weaving. * Formal aspect languages or calculi. * Formal properties of aspects, advice, and join-point models. * Type systems for aspect-oriented languages. * Verification and static analysis of aspect-oriented programs. * Theory of aspect composition and aspect interactions. * Aspect-oriented programming pearls. Deadline for submissions: *1 March 2005* Author's notification: 1 July 2005 Special issue's publication:Winter 2005/2006 Special issue's web site: http://www.cs.vu.nl/faop-scp/ The submissions should be sent in PDF or Postscript to the guest editors via email: [EMAIL PROTECTED], [EMAIL PROTECTED] Authors who want to discuss potential submissions are encouraged to contact the guest editors. For details about the policy of the Science of Computer Programming journal, and the requirements for prospective authors see a recent issue of the journal and check the journal's web site http://www.elsevier.com/locate/scico/. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Problem with type signature in local function
Timely question. :-)
GHC supports lexically scoped type variables.
And this support has just been _extended_ to be readily useful for you
(see discussion on the ghc list just a few days back).
With GHC CVS HEAD the following program works fine.
(Note that I removed the inner Num constraint.)
{-# OPTIONS -fglasgow-exts #-}
add :: Num a = a - a - a
add n1 n2 = addToN1 n2
where addToN1 :: a - a
addToN1 number = n1 + number
... even though I would not claim that this is a really strong example
of lexically scoped variables, but you probably just simplied a real
code example.
And most of my recent code I use lexically scoped type variables
extensively. They are great.
(In principle, one does not need them at the cost of encoding. Using
asTypeOf and friends ...)
Merry Xmas,
Ralf
Christian Hofer wrote:
Hi,
in order to understand the reason for strange compiler error messages,
I often find it convenient to add type signatures to every function.
But sometimes this seems to be impossible when using type variables.
I try to give a very easy example:
add :: Num a = a - a - a
add n1 n2 = addToN1 n2
where addToN1 :: Num a = a - a
addToN1 number = n1 + number
ghc says Inferred type is less polymorphic than expected, and justly
so, because the type variable a in addToN1 must of course be the
same as in add. Is there a way to specify this?
Regards,
Chris
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Named function fields vs. type classes
Major apologies for this repeated plug for HList. Anyway, HLists [1] are *exactly* designed for this sort of problem. Well, one can also use existential quantification + bounded polymorphism; with the shapes benchmark providing a good example [2]. The trade-offs are explored a little bit on the OOHaskell slides and in the corresponding code base [3]. Cheers, Ralf [1] http://homepages.cwi.nl/~ralf/HList/ [2] http://www.angelfire.com/tx4/cus/shapes/haskell.html [3] http://homepages.cwi.nl/~ralf/OOHaskell/ John Goerzen wrote: Hi, I often have a situation where I'm designing specialized components to do a more general task. Examples could include mail folder code (maildir, mbox, etc), configuration file parsing, protocol handlers for URL accesses, logging backends, etc. For some of these, I've used a data object with named fields, each one of them being a function that performs various tasks (open connection to the URL, read data, whatever.) So, I get a standard interface. The advantage of this approach is that I can build a list containing all sorts of different data objects in it. For others, I've used typeclasses, and made the different specialized components a member of the typeclass. This seems to provide a cleaner interface, and one that is more readily extended (maybe I want to support IMAP folders, and support all its searching capabilities too). On the other hand, it's difficult or impossible to make a list of a bunch of different types of things that have nothing in common save being members of the class. Is there any advice on the best way to do these things? Thanks, John ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] controlling the scope of instances
Hi, I refer to Section 5.3 (title see subject line) in Type classes: exploring the design space by Simon Peyton Jones, Mark P. Jones and Erik Meijer HW 1997. There it is argued very briefly that a type system with controlled scope of instances risks coherence. Likewise, in Wadler's and Blotts original paper on ad-hoc polymorphism, Appendix A.7 sheds light on the related problem of principal typings. Global scope is suggested while wondering about less restrictive conditions that retain principal typing. The interaction with the module system is not really considered. I also know of /Functional Pearl: Implicit Configuration -- or, Type Classes Reflect the Value of Types/ Oleg Kiselyov, Chung-chieh Shan, Haskell Workshop 2004, which sheds some fancy light on the subject. The paper deals with local instances, but not so much with scoping via the module system. Does anyone know of a published, somewhat deeper analysis regarding the possibility to scope instances via the normal module system? For instance, why can't we have as many distinguished incarnations of a class in the type system as there are different sets of instances created in various scopes. That is, references to methods are to be *implicitly qualified* by the corresponding class incarnation (i.e., sets of instances). Methods of different incarnations are not to be confused by the type system. This would solve all coherence issues that I can think of. Or is this just getting too complicated? Any pointers greatly appreciated. Regards, Ralf ** ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CFP: FOAL 2005, Foundations Of Aspect-Oriented Languages
FOAL: Foundations of Aspect-Oriented Languages A one day workshop affiliated with AOSD 2005 in Chicago, USA, on Monday, 14 March 2005. 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, Sunday, 16 January 2005. 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, cclifton -at- cs -dot- iastate -dot- edu. We will notify the corresponding author of papers that are selected for presentation at the workshop by 3 February 2005. The early registration deadline for AOSD will be 10 February 2005. FOAL attendees must be registered for AOSD. Final versions of papers for the proceedings will be due on 1 March 2005. For more information, visit the FOAL Workshop home page at http://www.cs.iastate.edu/FOAL. Important
Interesting non-terminating behaviour for recursive classes
Hi Simon and others,
this is an interesting feature.
The three attached files are largely the same.
They don't do too weird stuff except a little bit
instance-constraint-level recursion among classes.
(and some use of undecidable instances ...)
(There are embedded comments in the files.)
(I used GHC HEAD as of now.)
LoopOfTheDay1.hs really works great.
I was surprised that this works (because hugs' type checker
encounters cut-off limit, likewise for GHC 6.2).
But GHC HEAD seems to try harder in the area of termination checking for
instance compilation and instance selection.
LoopOfTheDay2.hs does a very minor variation,
but type checking does not terminate anymore.
To me this looks like a real bug.
(Yes, I have enabled undecidable instances but the variation
point does not introduce any challenge whatsoever as far as I can see.)
LoopOfTheDay3.hs again does a minor variation.
Type checking the set of classes and instances works again,
but trying to use the classes leads to non-terminating instance selection.
I have a truly cool application for this in case it can be made work
more generally.
Thanks for looking into it!
Regards,
Ralf
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
-- Compiles fine.
-- Instance selection works fine.
-- try: :t foo (T1b T1a)
-- Notice: T1 is a recursive type.
-- Notice: the classes are recursive, too.
-- Why does this work when almost the same thing doesn't?
-- Say: adding an Int component to T1a makes things loop.
-- See LoopOfTheDay2.hs and LoopOfTheDay3.hs.
data T1 = T1a | T1b T1
class C0 x where foo :: x - (); foo = undefined
class C1 x y
class C1 x y = C2 x y
instance C0 T1 = C1 () T1
instance (C1 x T1) = C2 x T1
instance C2 () T1 = C0 T1
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
-- Compilation loops!
-- While LoopOfTheDay1.hs did compile and work,
-- this one loops during compilation, even though
-- there is only an innocent difference regarding T1,
-- i.e., an additional, non-recursive constructor component.
data T1 = T1a Int | T1b T1
class C0 x where foo :: x - (); foo = undefined
class C1 x y
class C1 x y = C2 x y
instance C0 Int = C1 () Int
instance C0 T1 = C1 () T1
instance (C1 x T1, C1 x Int) = C2 x T1
instance C1 x Int= C2 x Int
instance C2 () T1= C0 T1
instance C2 () Int = C0 Int
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
{-# OPTIONS -fallow-overlapping-instances #-}
-- Compiles fine but instance selection loops.
-- try: :t foo (T1a 1)
-- This is essentially the same as LoopOfTheDay2.hs
-- but with the innocent (?) use of overlapping instances.
data T1 = T1a Int | T1b T1
class C0 x where foo :: x - (); foo = undefined
class C1 x y
class C1 x y = C2 x y
instance C0 a= C1 () a
instance (C1 x T1, C1 x Int) = C2 x T1
instance C1 x Int= C2 x Int
instance C2 () a = C0 a
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Rank-2 types and class constraints
Hi, foo _ = undefined works fine. Otherwise the poor little a has no chance to get disambiguated. ... Ambiguous type variable `a' in the top-level constraint ... Ralf Stefan Holdermans wrote: Hi, Just out of curiosity (I cannot come up with a practical example): Why doesn't the following piece of code type check in GHC (with extensions)? foo :: (forall a . (Eq a) = a) - Integer foo = undefined It seems like the type-class constraint is playing a decisive rôle here, since the following does check. bar :: (forall a . a) - Integer bar = undefined TIA, Stefan ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-caf e ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: -fallow-incoherent-instances
Hi,
you do realise that -fallow-incoherent-instances is enabling a hell.
What mostly happens is that the most general instance is chosen.
Which explains the error here: Say the confusing instance is chosen
(because it is generic) and hence the type checker tries to establish the
Confuse constraint, which it can't because the addGeneralFallOut function
does not promise it.
I am just finishing up a draft on such class issues
having to do with Scrap your boilerplate,
which I would be keen to share somewhere later this week.
General conclusion:
I still have to see a good reason to use -fallow-incoherent-instances.
It's mostly good to shot yourself in the head.
Ralf
Christian Maeder wrote:
The attached module does not compile and yields the following error:
InCoherentInst.hs:17:
Could not deduce (Confuse a) from the context (Typeable a)
arising from use of `breakFn' at InCoherentInst.hs:17
Probable fix:
Add (Confuse a) to the type signature(s) for `addGeneralFallOut'
In the first argument of `GeneralBreakFn', namely `breakFn'
In the definition of `addGeneralFallOut':
addGeneralFallOut = let
breakFn a = throwDyn
(GeneralFallOutExcep a)
in GeneralBreakFn breakFn
The same source compiles ok without -fallow-incoherent-instances (or
with -fno-allow-incoherent-instances).
If, furthermore, the confusing instance is commented out, the source
even compiles without extensions.
I don't know if this is a bug, possibly related to the import of
Typeable stuff. I don't need a fix. I only want to point out that
globally switching on the option -fallow-incoherent-instances is
likely to break existing code, currently (ghc 6.2.2).
Cheers Christian
{-# OPTIONS -fglasgow-exts -fallow-overlapping-instances
-fallow-undecidable-instances -fallow-incoherent-instances #-}
module InCoherentInst where
import Control.Exception(throwDyn)
import Data.Typeable(Typeable)
class Confuse a where
confuse :: a - String
instance Confuse a = Typeable a
data GeneralBreakFn a = GeneralBreakFn (forall b . a - b)
addGeneralFallOut :: Typeable a = GeneralBreakFn a
addGeneralFallOut =
let breakFn a = throwDyn (GeneralFallOutExcep a)
in GeneralBreakFn breakFn
data GeneralFallOutExcep a = GeneralFallOutExcep a deriving (Typeable)
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Equality of functions
Adam Zachary Wyner wrote: Question -- is this all there is to the issue, or is there something more? Apologies in advance for not understanding the math better here. You can compare functions in a pointwise fashion, which does not work (other than approximatively) for infinite domains. This is the black box approach. You can also compare functions in a proof-theoretic fashion. Try to proof a derivation that f can be transformed into g. This is the white-box approach. This requires reasoning at the level of program text. Question -- though Haskell, as a lazy language, does not otherwise have problems with infinite lists, why does it here? Because lazyness only helps in cases where we don't want to see the full infinite data structure. Equality is a universal property; we would need to iterate over all elements of the domain. Question -- is there some way around this problem? It is very handy to be able to have a variable over functions and then compare the value to a designated function. This would let me say things like: when variableFunctionX == functionA then otherwise etc... Don't understand. One possible (dirty?) solution I thought up is to use the record types of Hugs to correlate the function with a name of type String: type FunctionNameFunction = Rec (functionName :: String, functionFunction :: WhateverFunction) Then, whenever one needs to use the function, one uses the value of functionFunction, but whenever one needs to evaluate for identity, one uses the value of functionName, using just string identity. Of course, this makes lots of things less 'pretty' (to apply a function to an argument, one has to first 'pull out' the function from the record), but it addresses a general problem. One would also have to keep careful track of which functionNames correlate with with functionFunctions. Yes, one can represent functions by type codes. These type codes would be interpreted by an Apply class (as in the HList library). Type codes could be compared for equality (again demonstrated in the HList paper). Modulo some extra tweaking, we can compute type equality for such *fixed* functions. In fact, one can build a little functional language in the type system this way. Expressions in this language would distinguished terms. One could even implement the abovementioned white-box approach in the type system. (For any given system of proof/transformation rules.) I am sure this is too complicated and too restricted than to be truly useful. Cheers, Ralf ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with overlapping class instances
Instance selection and thereby overlapping resolution is *independent* of constraints. It is defined to be purely syntactical in terms of instance heads. See the HList paper for some weird examples. Ralf Graham Klyne wrote: The reported overlapping instance is [Char], which I take to be derived from the type constructor [] applied to type Char, this yielding a form that matches (cw c). But the instance ConceptExpr (cw c) is declared to be dependent on the context ConceptWrapper cw c, which has *not* been declared for the type constructor []. GHCi with -fglasgow-exts is no more informative. What am I missing here? ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic Type Contruction
Vitor, That's amazing!!! Your question is very timely! :-) You know ... someone just challenged me with this question, and I added the corresponding function to the boilerplate testsuite. However, it is much more typeful than you propose. I call it the typeful reflection benchmark. http://www.cs.vu.nl/boilerplate/#suite http://www.cs.vu.nl/boilerplate/testsuite/getC.hs So you actually can write isC Circle some term. No string encoding! No possible confusion of different term types. Ralf Oops: I leave it as an exercise to implement this boilerplate pearl in Strafunski :-) Vitor Rodrigues wrote: I'm trying to create a library to querying XML data using Strafunski. I'm also using DrIFT to generate the instances of Typeable and Term of my Datatypes to be used inside Strafunski. Supose i've this datatypes: data Shape = Circle Float (Float,Float) | Triangle (Float, Float) (Float, Float) (Float, Float) then DrIFT, among other things, creates the functions: isCircle (Circle _ _ ) = True isCircle _ = False isTriangle (Triangle _ _ _) = True isTriangle _ = False what i'd like to have is as a generic isFoo function, with the type: is :: String - DataType - Bool that when running will act like this: is Circle (Circle 3.4 (3.0,3.1)) = True is Triangle (Circle 3.4 (3.0,3.1)) = False is Circle 2 = False I was looking on TyCon constructor and mkTyCon function, but i didn't understood it well. Can anyone tell me how can i create this is Foo function? I was thinking about create a dynamic type with mkTyCon and then see if it matches with the DataType receiveid as function parameter. Regards, Vitor Rodrigues ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] functional programming school
Matthew Roberts wrote: I am looking for a functional programming summer school in the next 12 months. I realise there was one August this year, does anyone know of any others coming up? July 4-8 2005 will be an international summer school on generative and transformational techniques in software engineering, in Portugal. As it turns out there will be several talks with an FP background. However, this summer school is going to be more about software engineering than about teaching advanced functional programming. Still interesting I hope! Details will be posted in a week or two, also on the main Haskell list. So stay tuned. Ralf ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
Graham Klyne wrote: At 22:17 13/10/04 +0200, Ralf Laemmel wrote: ... We reconstruct OCaml's tutorial in Haskell ,,, I think that's interesting as a theoretical exercise, but I don't currently see myself using that framework in practice, in the form presented. As you say Simply syntactic sugar would make OOP more convenient in Haskell. Just for clarity ... As Oleg said, we would like to refrain from judgements regarding - OO in general - the urgency of combining all of OO with FP - the urgency of the combination in the case of Haskell. We have (varying) opinions about that ... but the OOHaskell effort is about showing that Haskell readily comes with an object system, or the ability to express it. That's it! At a more arbitrary level, we opted for an OCamlish object system because OCaml's system is definitely a good benchmark in terms of the many idioms covered. It is also a rewarding approach because OCaml's relies on non-trivial language extension, where our OOHaskell approach uses Haskell's existing type system to bring OO to Haskell. This is very, very rewarding for Haskell aficionados, indeed. We are also looking at OHaskell, Haskell++ and others, whose publicaly available examples should eventually become available for OOHaskell as well. When we think of syntactic sugar then this is merely about keywords such as class, interface, begin, end, method, ..., which some people might ask for anyway. With an OO hat one, people might want to really see the different forms of absractions methods, mutable fields, classes, mixins, while from an FP point of view functions and records are totally sufficient. Anyway, some of these keywords can be provided quite conveniently just as combinators. These combinators would then perform additional type-level checks or they are just NO-OPs. Personally, I wouldn't want any syntax extension. To summarise, what's very important in our view is that OOHaskell shows that no language extension is needed to bring OO to Haskell. And even in the case where we end up providing syntactic sugar then this is about surface syntax whose reduction to normal Haskell syntax is a *local structural mapping* as it could be peformed by the most trivial preprocessor or macro system. So the type system of Haskell is fit for OO. That's cool. From a practical perspective, the foundation of OOHaskell to depend on HList implies that type errors are potentially inconvenient depending in turn on encoding details of the type-level code. For example, it takes some coding effort to teach the type-level implementation such that you see type errors that are anywhere close class a found but class b required or class a is not a subclass of class b. The HList paper discusses some idiom for better type error messages in type-level code. A mail by Oleg on keyword arguments discusses another idiom, a CPS-like trick, but there is more work to be done. It is encouraging to see that the OO structures can be constructed within the Haskell type system. Absolutely. Would it simplify your approach significantly to focus on non-mutable objects? (In recent discussions with a colleague who implements complex systems in Java, he has observed that their systems are easier to understand and maintain when they elect to use non-mutable objects.) Again, we leave it to others to make choices. If we wouldn't present the details of mutable projects, Haskell object system will be claimed to be incomplete, which it is not :-) Ralf http://homepages.cwi.nl/~ralf/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
John Goerzen wrote:
One of the best features of OO programming is that of inheritance.
...
Oleg, Keean and me have lying around a draft that adds to this
discussion. We reconstruct OCaml's tutorial in Haskell
The short paper version is online and under consideration for FOOL:
http://homepages.cwi.nl/~ralf/OOHaskell/
This work takes advantage of the HList library.
I'll attach some code related to inheritance.
So Haskell is an OOPL.
Ralf
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
-- In the following, we refer to the tutorial Objects in Caml
-- http://caml.inria.fr/ocaml/htmlman/manual005.html
-- 3.2 Reference to self
module SelfObj where
import CommonMain hiding (HDeleteMany, hDeleteMany, TypeCast,typeCast)
import GhcSyntax
import GhcExperiments
import TypeEqBoolGeneric
import TypeEqGeneric1
import TypeCastGeneric2
import Label2
import Data.STRef
import Data.IORef
import Control.Monad.ST
import Control.Monad.Fix
infixr 9 #
m # field = (m .!. field)
-- A name space for record labels
data MyNS = MyNS
l_get_x = firstLabel MyNS get-x
l_move= nextLabel l_get_x move
l_field_x = nextLabel l_move field x
l_print = nextLabel l_field_x print
{-
Ocaml Tutorial:
3.2 Reference to self
A method or an initializer can send messages to self (that is, the
current object). For that, self must be explicitly bound, here to the
variable s (s could be any identifier, even though we will often
choose the name self.
class printable_point x_init =
object (s)
val mutable x = x_init
method get_x = x
method move d = x - x + d
method print = print_int s#get_x
end;;
let p = new printable_point 7;;
val p : printable_point = obj
p#print;;
7- : unit = ()
-}
class_printable_point x_init self
= do
x - newIORef x_init
return $
l_field_x .=. x
.*. l_get_x .=. readIORef x
.*. l_move.=. (\d - do{v-readIORef x; writeIORef x (d + v)})
.*. l_print .=. ( (self # l_get_x ) = print )
.*. emptyRecord
testp1 = do
print testp1
-- Note that 'mfix' plays the role of 'new' in the OCaml code...
p - mfix (class_printable_point 7)
p # l_get_x = print
p # l_move $ 2
p # l_get_x = print
p # l_print -- Note, the latter prints the state of the mutated obj!
print OK
{-
Ocaml Tutorial:
3.7 Inheritance
We illustrate inheritance by defining a class of colored points that
inherits from the class of points. This class has all instance
variables and all methods of class point, plus a new instance variable
c and a new method color.
class colored_point x (c : string) =
object
inherit point x
val c = c
method color = c
end;;
let p' = new colored_point 5 red;;
val p' : colored_point = obj
p'#get_x, p'#color;;
- : int * string = (5, red)
-}
-- Inheritance is simple: just adding methods...
l_color = nextLabel l_print color
class_colored_point x_init color self
= do
p - class_printable_point x_init self
return $ l_color .=. (return color) .*. p
testp2 = do
print testp2
-- Note that 'mfix' plays the role of 'new' in the OCaml code...
p - mfix (class_printable_point 7)
p' - mfix (class_colored_point 5 red)
do{ x - p' # l_get_x; c - p' # l_color; print (x,c) }
print OK
{-
Ocaml Tutorial:
3.4 Virtual methods
It is possible to declare a method without actually defining it, using
the keyword virtual. ...
class virtual abstract_point x_init =
object (self)
val mutable x = x_init
method virtual get_x : int
method get_offset = self#get_x - x_init
method virtual move : int - unit
end;;
class point x_init =
object
inherit abstract_point x_init
method get_x = x
method move d = x - x + d
end;;
-}
l_offset = nextLabel l_color offset
-- Note, compared with printable_point, the we just removed the field l_get_x
-- That made the class uninstantiatable!
-- No need for any a language extension for virtual, abstract.
class_abstract_printable_point x_init self
= do
x - newIORef x_init
return $
l_field_x .=. x
.*. l_offset .=. ((self # l_get_x ) = (\v - return$ v - x_init))
.*. l_print .=. ( (self # l_get_x ) = print )
.*. emptyRecord
class_concrete_printable_point x_init self
= do
p - class_abstract_printable_point x_init self -- inherit...
return $
-- add the missing (pure virtual) methods
l_get_x .=. (readIORef (self # l_field_x))
.*. l_move.=. (\d - do{v-readIORef (self # l_field_x);
writeIORef (self # l_field_x) (d + v)})
.*. p
testp3 = do
print testp3
-- Note, if the latter is uncommented; we get the
-- desired instantiation error.
p - mfix (class_concrete_printable_point 7)
p # l_get_x = print
p #
Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
[EMAIL PROTECTED] wrote:
Some people say that ocaml's object system is kinda useless. The best
support I hear so far was:it does not hurt
Why do you (or do these people) think having all the OO idioms of OCaml
(see OCamls OO tutorial) is useless? Or do you mean too baroque? If not,
what's
missing?
implementation inheritance, the strange # syntax, virtual method, why do
I need them?
Fine with me.
OOHaskell doesn't need them, indeed.
In Java, people are doing programming-against-interface, implementation
injection etc. All these show that we don't need implementation inheritance
to be OO, and implementation inheritance is in many cases bad practice
anyway.
Well having no implementation inheritance in Java would be a pretty
brave limitation.
Anyhow, OOHaskell (and OCaml) has programming-against-interface as well.
Some related snippet from the OCaml tutorial.
{-
A point and a colored point have incompatible types, since a point has no
method color. However, the function get_x below is a generic function
applying
method get_x to any object p that has this method (and possibly some others,
which are represented by an ellipsis in the type). Thus, it applies to both
points and colored points.
let get_succ_x p = p#get_x + 1;;
val get_succ_x : get_x : int; .. - int = fun
get_succ_x p + get_succ_x p';;
- : int = 8
-}
The corresponding OOHaskell snippet
testp2 = do
print testp2
-- Note that 'mfix' plays the role of 'new' in the OCaml code...
p - mfix (class_printable_point 7)
p' - mfix (class_colored_point 5 red)
do{ x - p' # l_get_x; c - p' # l_color; print (x,c) }
let get_succ_x obj = obj # l_get_x = (return . (+ 1))
get_succ_x p = print
get_succ_x p' = print
print OK
As somebody pointed out, we could do interface in Haskell with record. The
only problem is names. If we could, as we can in OO languages, provide a
separate namespace for the fields of each record. We are pretty much done.
Have you seen HList?
There are 4 different solutions for first-class labels in the distribution.
The rest is some kind of record coersion+row polymorphism mechanism.
Yes, good point.
That's what we meant: the object system in Haskell has been overlooked.
If haskell can do what Simon P. Jones and Mark Jones described in the paper
Lightweight Extensible Records for Haskell, I'd say it is a already a
nice functional OO language.
It can readily do more than that:
http://www.cwi.nl/~ralf/HList
Compared to Ocaml, 'OO' support is seamlessly integrated with the
functional part. It leaves no redundancy, no overlapping in the language.
What are you referring to?
I mean: where is OO support seamlessly integrated with the functional part?
Do you refer to OOHaskell?
In short, what if we don't create an object piece that competes with the
functional part, but fix and enhance the record system that we currently
have?
... or just exploit heterogeneous collections.
Ralf
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Extensible Serialization class with type classes
[redirected to Haskell-cafe from ghc...] I think the point is not to define your class Seriliazer, but to define it as a generic function instead. After all, it is kind of show (because it is serialisation). Reading your earlier emails, it seems a remaining problem is to keep this function somewhat open as to allow to special cases afterwards. This is a nice topic. Here we go. The normal serialisation function with a serialisation result Q is of such a type serialise :: Data a = a - Q Internally such a function would be probably defined by recursion such as serialise = ... gmapQ serialise ... In fact, some types would already be subject to special cases. So we have serialise = generic_case `extQ` specific_case1 `extQ` specific_case2 ... where generic_case = ... gmapQ serialise ... specific_case1 = ... % do something for my favourite type This is exactly the code skeleton of show. Now the question is how to make the whole business extensible. I normally do this with a type as follows: extensible_serialise :: Data a = (forall b. Data b = b - Maybe Q) - a - Q That is, there is an extra parameter for the type specific cases to be ruled from the outside. Note the Maybe. Here, Nothing means that a specific type is not handled by the parameter, so the normal serialise has to be applied. Regarding your other problem, optional types, this seems to be solvable as well. Again, *don't* define this class class XSDType a with where xsdType :: a - String xsdNS :: a - String ...but rather define a generic function, this time is nothing but a type case of type forall x. Typeable x = x - Maybe (String, String) Hope it helps. Conclusion: don't use classes, rather use generic functions. Ralf Simon David Foster wrote: On Thu, 2004-08-26 at 20:52, Ralf Laemmel wrote: Hi Simon, I think you should be able to succeed with Scrap your boilerplate. (I am not sure that you need existentials.) For the overall XmlIsh style of type erasue and type validation see the XmlIsh example at: http://www.cs.vu.nl/boilerplate/ The main requirements for the XML serializer are; 1) It should be scalable; so users should be able to import a compile module with the basic XML infrastructure and add serializers for new Complex and Simple (i.e. leaf node) types. 2) It should be optionally typeable; there exists several systems for typing an XML document, the most prominent of which is XSD. The main requirement is that if the XML tree is to be typed, clearly each node in the tree must be associated with mapping to an XSD name and name-space (2 Strings) or some other data items if typing by another system. The way I was planning on doing this was using a class; XSDType a with functions xsdType :: a - String and xsdNS :: a - String. Then at serialisation if a particular type and all it's constituent types were XSD Typeable, extra data (i.e. an extra attribute type=nsp:name) can (again optionally) be inserted into the tree. The XmlIsh example uses a number of functions for serialising different data-types down the tree. I'm not sure how scalable doing it this way would be; can you integrate a type-class system with it? The other problem is dealing with Schematic extensions, such as SOAP Arrays which have the requirement that the elements are always typeable but should not be part of the core serialiser. My other question is, section 7 only mentions polymorphic types which hold constraints Data, Typeable and Typeable1; can the new Generics deal with other polymorphic constraints? This is the main problem; the type-class system can deal fine with just serialisation of data-type content, it just doesn't seem to be able to handle an optional type-system. Ideally I need to produce a system where one XML namespace maps to one module and that module provides data-types, serialisers and typers for the given XML types, such that other modules which use those data-types themselves should be able to import that module and its serialisers to (heuristically) build serialisers for itself. -Si. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] SCP Special Issue on Foundations of Aspect-Oriented Programming
[ Functional programming has contributed to the foundations of AOP over the last few years. For instance, see Walker's and Wand's contributions at ICFP 2003. ] Special Issue on Foundations of Aspect-Oriented Programming Science of Computer Programming Guest Editors: Pascal Fradet and Ralf Lämmel Call for contributions Modularity concepts support the separation of concerns, and hence they are crucial for mastering the complexity of software. In recent years, the modularity concept of aspects has been introduced. Aspects facilitate the modularisation of crosscutting concerns. The corresponding paradigm, aspect-oriented programming (AOP), is part of a larger effort -- Aspect-Oriented Software Development (AOSD). Clearly, AOP and AOSD have attracted a great deal of interest: various AOP tools are being developed and AOP is now successfully used in real-world applications. However, a widely shared criticism of AOP is that it still lacks firm foundations. For instance, the untamed form of AOP that we see today is often criticised for defeating encapsulation and preventing local reasoning. Likewise, the interference of multiple aspects is considered an unacceptable risk of current AOP techniques. This special issue is dedicated to the foundations of aspect-oriented programming including formal methods, tools, languages and calculi. The special issue goes along with the successful series of FOAL workshops (Foundations of Aspect Oriented Languages), but submission to the special issue is completely open. The special issue will be published in the journal Science of Computer Programming, which implies excellent visibility and high quality standards. The guest editors solicit high-quality contributions that address the foundations of AOP, and that improve the state of the art of developing, understanding, controlling and reasoning about aspect-oriented programs. Work on modularity concepts other than aspects is also solicited provided that such work is clearly related to AOP. For instance, fundamental contributions to reflection are likely to be relevant for the foundations of AOP. Specific topics of interest include, but are not limited to: * Reasoning about aspect-oriented programs. * Semantics of aspects and weaving. * Formal aspect languages or calculi. * Formal properties of aspects, advice, and join-point models. * Type systems for aspect-oriented languages. * Verification and static analysis of aspect-oriented programs. * Theory of aspect composition and aspect interactions. * Aspect-oriented programming pearls. Deadline for submissions: *1 February 2005* Author's notification: 1 June 2005 Special issue's publication:Winter 2005/2006 Special issue's web site: http://www.cs.vu.nl/faop-scp/ The submissions should be sent in PDF or Postscript to the guest editors via email: [EMAIL PROTECTED], [EMAIL PROTECTED] Authors who want to discuss potential submissions are encouraged to contact the guest editors. For details about the policy of the Science of Computer Programming journal, and the requirements for prospective authors see a recent issue of the journal and check the journal's web site http://www.elsevier.com/locate/scico/. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Data instances in ghc 6.2.1?
Claus Reinke wrote: For context: I wanted to show people in the haskell tools thread - how easy it is these days to write a Haskell program transformation for instrumenting source code with asserts, e.g. to get location info for heads of empty lists :-) Yes, it is easy! - why these lovely new tools won't be used because even without transformations they don't reproduce the source :-( Yes, but then, we should really work on reproducability of code! After all, you have gathered relevant experiences in the HaRe project. So the requirements are clear. How much work is it to incorporate comments and layout in a systematic manner? In GDK, we don't have any problems doing this for C-based combinator parsing. We use a simple wrapper pattern. Whenever, we fetch a token from the lexer, then we build a sandwich token that also comprises the comment/layout (identation) from before the token. Ok, since we go for an abstract syntax, we also need to catch keywords and all this. Also, we must switch off all normalisation in the parse tree construction. (Are there any normalisations going on in Language/Haskell? Probably, not In, gcc, for example, there is, which is problem.) But as they can't use this in the current release anyway, I'll leave it at that. I have committed the extended Language/Haskell/Syntax.hs. Why not demonstrate, what you said, anyway, using CVS built from head? I would love to help with both: - this showcase - and improving Language/Haskell Cheers, Ralf ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Data instances in ghc 6.2.1?
Hi Claus, the tuple instances did not make it into GHC 6.2 because of CVS branching policy. GHC CVS HEAD compiles the example. And yes, SPJ approved recently that Language.Haskell.Syntax should derive Data and Typeable. But, I can't access cvs.haskell.org. Already for a while, it asks for my password, which I never got handed out. Ralf Claus Reinke wrote: Shouldn't there be more instances of Data and friends? I thought that tuples beyond size 2 were mentioned here before ghc 6.2, but this silly example doesn't work because of missing Data instance (it does work with d instead of d3): import Data.Generics -- file = Tst.hs d = ([hi,head],(ho,(True,head))) d3 = ([hi,head],ho,(True,head)) main = print $ everywhere (id `extT` worker) d3 where worker head = tail worker s = s Since these instances claim to be derivable: shouldn't that be done for the stuff in Language.Haskell.Syntax? cheers, claus ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] Polymorphic algebraic type constructors
Graham Klyne wrote:
If I have a polymorphic algebraic type (T a) with several type
constructors, only one of which actually references the type
parameter, is there any way to express type conversion for the
type-parameter-independent constructors without actually mentioning
all the constructors?
Just for the record, using gunfold (from boilerplate paper II)
and cast (from boilerplate paper I), one can do this in a weird
way. The default equation becomes:
f g s = just (shallow_rebuild s)
-- instead of f g s = s
The shallow_rebuild function rebuilds the top-layer of a term.
Polymorphism is no problem here because the constructor is built from
scratch.
The dirty bit is just which goes from Maybe to Certainly.
Code attached for fun. This particular solution is perhaps too untyped,
but some bits of this solution were surprising for me.
Ralf
{-# OPTIONS -fglasgow-exts #-}
import Data.Typeable
import Data.Generics
-- Representation of kids
kids x = gmapQ Kid x -- get all kids
type Kids = [Kid]
data Kid = forall k. Typeable k = Kid k
-- Build term from a list of kids and the constructor
fromConstrL :: Data a = Kids - Constr - Maybe a
fromConstrL l = unIDL . gunfold k z
where
z c = IDL (Just c) l
k (IDL Nothing _) = IDL Nothing undefined
k (IDL (Just f) (Kid x:l)) = IDL f' l
where
f' = case cast x of
(Just x') - Just (f x')
_ - Nothing
-- Helper datatype
data IDL x = IDL (Maybe x) Kids
unIDL (IDL mx _) = mx
-- Two sample datatypes
data A = A String deriving (Read, Show, Eq, Data, Typeable)
data B = B String deriving (Read, Show, Eq, Data, Typeable)
-- Mediate between two left-equal Either types
f :: (Data a, Data b, Show a, Read b)
= (a-b) - Either String a - Either String b
f g (Right a)= Right $ g a -- conversion really needed
-- f g (Left s) = Left s-- unappreciated conversion
-- f g s = s -- doesn't typecheck
-- f g s = deep_rebuild s-- too expensive
f g s= just (shallow_rebuild s) -- perhaps this is Ok?
-- Get rid of maybies
just = maybe (error tried, but failed.) id
-- Just mentioned for completeness' sake
deep_rebuild :: (Show a, Read b) = a - b
deep_rebuild = read . show
-- For the record: it's possible.
shallow_rebuild :: (Data a, Data b) = a - Maybe b
shallow_rebuild a = b
where
b = fromConstrL (kids a) constr
constr = indexConstr (dataTypeOf b) (constrIndex (toConstr a))
-- Test cases
a2b (A s) = B s-- silly conversion
t1 = f a2b (Left x) -- prints Left x
t2 = f a2b (Right (A y)) -- prints Right (B y)
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Modelling Java Interfaces with Existential data types
Mike Aizatsky wrote: It's quite good. It reminds me the quirks Alexandrescu does in his Modern C++ Design or here http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html . Since type system allows implementation of natural arithmetic, do you know, is it Turing-complete? Yes, C. McBride and T. Hallgren and others have done earlier examples of what they or we call faked dependently programming or type-level programming. It is not just Turing complete, it is phantastic. By using type equality and other goodies, we got pretty far. But I still would like to write type signatures for methods, operating with HLists. Or should I make all my list processing functions to be classes (like hfold) and to add type constraints in class definition? This sounds like a serious development overhead for me. Yes, we favour a dedicated class per method. Everything beyond that is future work / current research. Agreed: faking is faking. We want better support for this style. (i) I like comparing Haskell datatypes with Java classes. But Java classes also contain t methods. What would you call methods in Haskell? Functions on datatypes? Java's methods end up in Haskell as methods in the type classes. Clearly, the data part can still comprise higher-order functions. BTW: if you like, think of Java methods as AspectJ introductions. Java classes are empty (with regard to methods) when you begin. One way to think of it. So with AspectJ you can modularise in ways that Haskell suggests anyhow :-) You end up with creating quite a complicate and non-trivial library for just implementing something like ListInterface. Heterogeneous lists are perhaps an overkill for polymorphic lists modulo subtyping. But there are *many* tradeoffs. For instance, the perhaps easier to comprehend version with existentials and type-safe cast has these problems: - the \exists makes the data opaque; so one better anticipates all operations that are eventually needed in constraints. - polymorphic recursion and existstentials don't quite nicely go together. - you need the wrapper constructor to point out existential quantification. I don't see a way to store functions in a file. That's the task Clean Dynamics solve. I guess others know better than I. Storing functions isn't possible AFAIK, with Haskell's Dynamics/Read/Show, what else? Similar problems for existentially quantified data. For the rest, read/show and variations are Ok. Yes, Clean's Dynamics are cool. -- Yet another heterogeneous equality yaHEq :: (Typeable a, Typeable b, Eq a) = a - b - Bool yaHEq a b = case cast b of Just a' - a == a' Nothing - False Cool! Do you know anything about cast performance? It is implemented rather efficiently in Data.Dynamics, say one Int per type. So it is basically the cost of Int comparison, but I don't have performance figures at hand. There is certainly a kind of startup overhead. Say all the Ints have to be produced and registered somewhere, but once all types are around it should be like Int comparison. The only issue is to get rid of AnyMyInterface around the code. Can you explain me why type MyList = forall a. (MyInterface a) = [a] list1 :: MyList list1 = [MyImplementation1 10, MyImplementation2 20] doesn't work? Ghc gives pretty obscure (for me) error message: Cannot unify the type-signature variable `a' with the type `MyImplementation1' Expected type: a Inferred type: MyImplementation1 In the application `MyImplementation1 10' In the list element: MyImplementation1 10 I guess you want the forall to be an existential quantifier. Anyway, the way the forall is placed, it is really a universal one. So you are saying that you want to get a list of polymorphic implementations, but your actual list comprises actual implementations. So the error message is right. Perhaps enjoy some of this discussion: http://www.haskell.org/pipermail/haskell/2004-February/013600.html PS The sample in your previous post doesn't run due to lack of hMapOut Do you mean that I did not include the hMapOut code? -- Map a heterogeneous list to a homogeneous one class HMapOut f r e where hMapOut :: f - r - [e] instance HMapOut f HNil e where hMapOut _ _ = [] instance ( HMapOut f l e' , HApply f e e' ) = HMapOut f (HCons e l) e' where hMapOut f (HCons e l) = hApply f e : hMapOut f l I double-checked that the downloadable sources run: ghci gh-users-040607.hs works. BTW, yesterday, I really forgot to include this interesting Eq instance: instance Eq AnyMyInterface where (AnyMyInterface x) == (AnyMyInterface y) = x `yaHEq` y Cheers, Ralf ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Modelling Java Interfaces with Existential data types
Hi Mike, Let's redirect to Haskell cafe. http://www.mail-archive.com/glasgow-haskell-users%40haskell.org/msg06288.html http://www.mail-archive.com/glasgow-haskell-users%40haskell.org/msg06289.html thanks for your time to look into the HList paper. 1. It looks like your HList is basically a sugarized version of data AnyMyInterface = Impl1 MyImplementation1 | Impl2 MyImplementation2 with the same drawback: you require me to explicitly list all the possible implementations of my interface I don't think that anything was required to be explicit: If you mean this here: type MyList = MyImplementation1 :*: MyImplementation2 :*: HNil ... then note that this type is inferred! So with HLists, there is nothing like your Impl1 and Impl2, and no new datatype like your AnyMyInterface. Just for clarity: (i) I like comparing Haskell datatypes with Java classes. (ii) In Haskell, when you want to say that you have different implementations for the same interface, or when you want to say that different datatypes provide implementations of a certain interface, then you use Haskell's type class system. (iii) When you define an interface in Java, you rather define a type class in Haskell. Type class are of course more powerful, but we don't mind. (iv) When you say implements in Java, you rather say instance in Haskell. (v) When you define the methods of the interface to be implemented in Java, you define the methods of the instance. I would claim the Haskell code ends up being more modular :-) You immediately get a simple form of Java-like interface polymorphism in Haskell, say when you got a constraint, then you are polymorphic over implementations (instances) of that constraint. The crux of your concern seems to be that you want to package values of different types (Java: classes). Indeed you want to have heterogeneous containers modulo subtyping. And our lovely HLists are just good for that, but they come with the added value that they don't make the elements opaque as it is the case with the sometimes troublesome existentials. It might be possible to load them via hs-plugins or to obtain using something similar to Clean Dynamics (btw, is there anything similar available for Haskell?). Data.Dynamics Not needed here. 2. There will also be problems in gluing the utility/legacy code. E. g. if I want to call any list function on HLists (e.g. reverse). The idea of having heterogeneous FiniteMap can be implemented by storing the single-element lists, but it will complicate the code, which will work with the map. I concur. Using HList for everything is perhaps too invasive. The HList paper makes clear that there are certain cases where HLists are really needed, and they are complementary what generics provide you with in Java. I was just able to use them for something were a Generic Java programmer uses Generics and subtyping for. So existentials are perhaps Ok. However, directly comparing the opaque values is untypeable, I'm completely confident with applying (==) to different type. It's quite a common operation in OO-world. Yes, what you need is type-safe cast. See paper 1 here: http://www.cs.vu.nl/boilerplate/ I would like to have the following behaviour: instance Eq AnyMyInterface where (==) (AnyMyInterface a1) (AnyMyInterface a2) = if (typeOf a1) == (typeOf a2) then false else a1 == a2 Java is just a weakly typed subset of Haskell :-) Here we go ... -- Yet another heterogeneous equality yaHEq :: (Typeable a, Typeable b, Eq a) = a - b - Bool yaHEq a b = case cast b of Just a' - a == a' Nothing - False *Main yaHEq True True True *Main yaHEq True True False *Main As you said yesterday that the equality issue is your main problem, let's wipe this out for existentials as well. I revise your existential wrapper type to include all goodies that are needed, say Eq and Typeable: data AnyMyInterface = forall a. ( Eq a , Typeable a , MyInterface a ) = AnyMyInterface a This is just your list type: type MyList' = [AnyMyInterface] Here are two lists: list4 = [ AnyMyInterface $ MyImplementation1 10 , AnyMyInterface $ MyImplementation1 10 ] list5 = [ AnyMyInterface $ MyImplementation1 10 , AnyMyInterface $ MyImplementation2 10 ] Here is a demo: *Main list4!!0 == list4!!1 True *Main list5!!0 == list5!!1 False Cheers, Ralf PS1: All code is here: http://homepages.cwi.nl/~ralf/HList/code.html PS2: I guess Sheard's work on parameterised modules might also interest you. http://portal.acm.org/citation.cfm?id=507648dl=ACMcoll=portal And John Huges Restricted Data types as it shows how to reify dictionaries: ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Modelling Java Interfaces with Existential data types
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-overlapping-instances #-}
{-
Hi Mike,
You might heterogeneous lists useful.
http://www.cwi.nl/~ralf/HList/
See the treatment of your example below.
Cheers,
Ralf
-}
import HList
import HTypeDriven
-- These are your two implementations.
data MyImplementation1 = MyImplementation1 Int deriving (Show,Eq)
data MyImplementation2 = MyImplementation2 Int deriving (Show,Eq)
-- This is your interface class and the two instances.
class MyInterface a
where
foo :: a - Int
instance MyInterface MyImplementation1
where
foo (MyImplementation1 i) = i
instance MyInterface MyImplementation2
where
foo (MyImplementation2 i) = i
-- Here is your list,
-- without the noise you don't like.
list1 = MyImplementation1 10
.*. MyImplementation2 20
.*. HNil
-- If you like, this is the type, but it is not needed.
-- This list is not opaque. Less trouble in our experience.
-- (When compared to using existentials.)
type MyList = MyImplementation1
:*: MyImplementation2
:*: HNil
-- Perhaps you want to make sure that you have a list of implementations
-- of MyInterface. Here is *one* way to do it. But you don't need to this
-- because this will be automatically checked (statically) whenever you
-- try to use the fooISH interface.
class ListOfMyInterface l
where
listOfMyInterface :: l - l
listOfMyInterface = id
instance ListOfMyInterface HNil
instance ( MyInterface e
, ListOfMyInterface l
)
= ListOfMyInterface (HCons e l)
-- So you apply the id function with the side effect of statically
-- ensuring that you are given a list of implementations of MyInterface.
list2 :: MyList
list2 = listOfMyInterface list1
-- Here is another way to do it.
-- You apply a heterogenous fold to the list.
-- This second solution is just for fun.
data ImplementsMyInterface = ImplementsMyInterface
instance HApply ImplementsMyInterface (e,l) (HCons e l)
where
hApply _ (e,l) = HCons e l
myKindOfList l = hFoldr ImplementsMyInterface HNil l
-- Basically again you apply the identity function; a deep one this time.
list3 :: MyList
list3 = myKindOfList list1
-- Your quality can indeed not work because the existentially quantified
-- implementations are of course opaque. You can just compare apples and
-- oranges. Equality of heterogeneous lists is trivial; it is just derived.
-- To make it a little bit more interesting, we can consider heterogeneous
-- or stanamic equality. So you will always get a Boolean even for lists
-- of different types. See below.
-- Here is your bar function
-- It uses one sort of maps on heterogeneous lists.
bar :: MyList - Int
bar = sum . hMapOut Foo
data Foo = Foo -- type driver for class-level application
instance MyInterface e = HApply Foo e Int
where
hApply _ e = foo e
{-
Demo follows.
*Main :l gh-users-040607.hs
Compiling FakePrelude ( ./FakePrelude.hs, interpreted )
Compiling HType( HType.hs, interpreted )
Compiling HList( ./HList.hs, interpreted )
Compiling HArray ( ./HArray.hs, interpreted )
Compiling HTypeDriven ( ./HTypeDriven.hs, interpreted )
Compiling Main ( gh-users-040607.hs, interpreted )
Ok, modules loaded: Main, HTypeDriven, HArray, HList, HType, FakePrelude.
*Main list1
HCons (MyImplementation1 10) (HCons (MyImplementation2 20) HNil)
*Main bar list1
30
*Main list1 == list1
True
*Main list1 `hEqList` hReverse list1
False
*Main
-}
{-
Mike Aizatsky wrote:
Hello,
I'm in process of rewriting the old Java application. While this is for sure
lots of fun, there're some problems in modeling the java interfaces.
Here's the common Java scenario (it's actually the pattern, common for all
OO-languages, so there should be no problems in understanding it):
interface MyInterface {
int foo();
}
class MyImplementation1 implements MyInterface { int foo() {...} }
class MyImplementation2 implements MyInterface { int foo() {...} }
And, somewhere in the code:
int bar(ListMyInterface list) { sum up all foos return }
I've found quite an obvious translation of it to Haskell:
module Ex where
class MyInterface a where
foo :: a - Int
data AnyMyInterface = forall a. (MyInterface a) = AnyMyInterface a
instance MyInterface AnyMyInterface where
foo (AnyMyInterface a) = foo a
data MyImplementation1 = MyImplementation1 Int
instance MyInterface MyImplementation1 where
foo(MyImplementation1 i) = i
data MyImplementation2 = MyImplementation2 Int
instance MyInterface MyImplementation2 where
foo(MyImplementation2 i) = i
type MyList = [AnyMyInterface]
list1 :: MyList
list1 = [AnyMyInterface (MyImplementation1 10), AnyMyInterface
(MyImplementation2 20)]
bar :: MyList - Int
bar l = sum (map foo l)
However there're some problems with this way to go:
1. It's quite verbose. I already have a dozen of such interfaces, and I'm a
bit tired of writing all this AnyInterface
Re: What happened to constrFields?
The problem is that constrFields is not included with 6.2.1. You would need to build GHC from CVS. It will be in 6.4 for sure. And yes, you are right, there is no other way to get the names of all fields of a constructor. Ralf Stefan Reich wrote: In recent versions of the GHC libraries, constrFields (as defined here http://www.cs.vu.nl/boilerplate/library/Data.Generics.Basics.html) has disappeared. I failed to figure out another way to get the names of all fields of a constructor. Have I overlooked anything? Do I have to use Template Haskell? -Stefan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Polymorphic lists...
MR K P SCHUPKE wrote: Hi Oleg, I like the polymorphic list indexed by Ints... there do seem to be a couple of differences between this and the list indexed by natural numbers. ... Agreed with these differences. Another difference: it is initially a heterogeneous set rather than list! (Because the instance TH a (a, x) is for found, and the overlapping instance TH a (b,c) is for proceeding with the rest of the set if a and b are not the same.) Of course, you could readily store lists of a's rather than a's, and always use [a] as access type rather than a. This deviation looks as follows: instance (Show a) = TH a ([a],x) where ... alter x (xs,y) = (x:xs,y) So a heteregeneous list would be modelled as a type-indexed set of homogeneous lists. That's pretty close. Still cool and simple. Ralf ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Polymorphic lists...
Hi Kean,
looks cool.
I get your point about static typing.
I guess that adding a fold operator would make your implementation more
complete.
Oleg has also encountered some of your operations (as you probably know):
http://www.haskell.org/pipermail/haskell/2003-August/012355.html
(Oleg also prefers the term polymorphic lists --- sigh, and he considers
indexing
by types rather than naturals. In fact, he mentions that values can be
retrieved by either type or index, while only the former is discussed
in detail, if I am right. To me it seems, he would also need to end up
using dependant-type encoding of naturals, say data Zero ... and data Succ
..., for look-up. If I am still right, then his operator type_index is
underspecified
because it returns a plain Int, but Int could be replaced by dependant-type
Naturals. Really just guessing. Oleg?)
Minor point: the code I posted combines existential types and type-safe
cast. It does *not* employ the type Dynamic. (You might say that dynamics
and this combination are somewhat equivalent.)
Ralf
MR K P SCHUPKE wrote:
Didn't know If I should post it straight away... its quite long and I dont do
attachments (well not If I can help it. I am aware Dynamic can model heterogenious
lists
(thanks for correct terminology) - but I need static typing. Thats the clever thing
about
this code - the list is heterogenious but statically typed.
So... for your perusal - and If its not up to being included in the libraries I would
value any comments/code review for my own edification.
The module is called Relation as I am modelling Relational Algebra... but if anyone
can
think of a better name...
First some examples:
putStrLn $ show (rIndex two rel1) -- show the third item in rel1
putStrLn $ show (rHead r)
putStrLn $ show (rTail r)
putStrLn $ show (rLast r)
putStrLn $ show (rInit r)
putStrLn $ show (r `rEnqueue` TEST3) -- insert the string into the last (not head)
position
putStrLn $ show ((3 :: Int) `RCons` r) -- insert the Int into the head of the list
r = toTuple (( 1.1 :: Double) `RCons` (fromTuple (hello,1,World)))
And the code:
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-undecidable-instances #-}
{-# OPTIONS -fallow-overlapping-instances #-}
module Lib.DBC.Relation where
--
-- (c) 2004 Keean Schupke, All Rights Reserved.
--
data Zero = Zero deriving Show
data Suc n = Suc n deriving Show
class Nat n
instance Nat Zero
instance Nat n = Nat (Suc n)
zero :: Zero
zero = Zero
one :: Suc Zero
one = Suc zero
two :: Suc (Suc Zero)
two = Suc one
three :: Suc (Suc (Suc Zero))
three = Suc two
four :: Suc (Suc (Suc (Suc Zero)))
four = Suc three
five :: Suc (Suc (Suc (Suc (Suc Zero
five = Suc four
--
infixr 1 `RCons`
data RNil = RNil deriving Show
data RCons a r = a `RCons` r deriving Show
--
class Relation r where
rHead :: a `RCons` r - a
rTail :: a `RCons` r - r
rIsEmpty :: r - Bool
instance Relation RNil where
rHead (x `RCons` _) = x
rTail (_ `RCons` _) = RNil
rIsEmpty RNil = True
instance Relation r = Relation (a `RCons` r) where
rHead (x `RCons` _) = x
rTail (_ `RCons` xs) = xs
rIsEmpty (_ `RCons` _) = False
class RLast r a | r - a where
rLast :: r - a
instance RLast (a `RCons` RNil) a where
rLast (x `RCons` RNil) = x
instance RLast r b = RLast (a `RCons` r) b where
rLast (_ `RCons` xs) = rLast xs
class RInit r1 r2 | r1 - r2 where
rInit :: r1 - r2
instance RInit (a `RCons` RNil) RNil where
rInit (_ `RCons` RNil) = RNil
instance RInit (b `RCons` r1) r2 = RInit (a `RCons` b `RCons` r1) (a `RCons` r2) where
rInit (x `RCons` xs) = x `RCons` rInit xs
class REnqueue r1 r2 a | r1 a - r2 where
rEnqueue :: r1 - a - r2
instance REnqueue RNil (a `RCons` RNil) a where
rEnqueue RNil y = y `RCons` RNil
instance REnqueue r1 r2 b = REnqueue (a `RCons` r1) (a `RCons` r2) b where
rEnqueue (x `RCons` xs) y = x `RCons` rEnqueue xs y
class (Nat n,Relation r) = RIndex n r a | n r - a where
rIndex :: n - r - a
instance Relation r = RIndex Zero (a `RCons` r) a where
rIndex Zero (x `RCons` _) = x
instance RIndex n r b = RIndex (Suc n) (a `RCons` r) b where
rIndex (Suc n) (_ `RCons` xs) = rIndex n xs
infixl 2 `rProduct`
class (Relation r1,Relation r2,Relation r3) = RProduct r1 r2 r3 | r1 r2 - r3 where
rProduct :: r1 - r2 - r3
instance RProduct RNil RNil RNil where
rProduct RNil RNil = RNil
instance Relation r = RProduct RNil r r where
rProduct RNil r = r
instance RProduct r1 r2 r3 = RProduct (a `RCons` r1) r2 (a `RCons` r3) where
rProduct (x `RCons` xs) y = x `RCons` (xs `rProduct` y)
--
class Relation r = RTuple t r | t - r , r - t where
fromTuple :: t - r
Re: Polymorphic lists...
I would like to see your code indeed ... it seems the attachment was missing. Anyway, I am not sure if it obvious or not, but heterogenously typed lists can be nicely modelled with Data.Typeable (!!!) I guess we should add something like this to the module? See http://www.cs.vu.nl/boilerplate/testsuite/hlist.hs or the inlined code below Regards, Ralf -- Heterogeneously typed lists data HList = HNil | forall a. Typeable a = HCons a HList -- The empty list initHList :: HList initHList = HNil -- Add an entry addHList :: Typeable a = a - HList - HList addHList a l = HCons a l -- Test for an empty list nullHList :: HList - Bool nullHList HNil = True nullHList (HCons _ _) = False -- Retrieve head by type case headHList :: Typeable a = HList - Maybe a headHList HNil = Nothing headHList (HCons a _) = cast a -- Retrieve head by type case tailHList :: HList - HList tailHList HNil = error tailHList tailHList (HCons _ l) = l -- Access per index; starts at 1 nth1HList :: Typeable a = Int - HList - Maybe a nth1HList i l | i 1 || i == 0 nullHList l = error nth1HList nth1HList 1 l = headHList l nth1HList i l = nth1HList (i-1) (tailHList l) -- A demo list mylist = addHList (1::Int) $ addHList (True::Bool) $ addHList (42::String) $ initHList -- Main function for testing main = print ( show (nth1HList 1 mylist :: Maybe Int)-- shows Maybe 1 , ( show (nth1HList 1 mylist :: Maybe Bool) -- shows Nothing , ( show (nth1HList 2 mylist :: Maybe Bool) -- shows Maybe True , ( show (nth1HList 3 mylist :: Maybe String) -- shows Maybe 42 MR K P SCHUPKE wrote: I needed a list which could handle items of different types for the database code I am writing. I have written a module implementing such a list based on dependant types (from Conor McBride: Faking It; Simulating Depandant Types in Haskell). Although McBride does not mention lists/vectors with items of differing types, the solution to implementing them came from his 'nthFront' function for re-arranging the order of arguments to a function. Any type can be inserted into the list, which supports head/tail/init/last, as well as indexed lookup, and a cartesian-product (concatenating two lists together). I have included fromTuple/toTuple as well. This seems quite a useful construct, and if there is nothing similar in the standard libraries at the moment, do you think this is worth including? Regards, Keean Schupke. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Parsing Typed Data from a String
Hi,
with the boilerplate style one can build terms while exploring permutations.
This can accommodated as a generic program.
An illustrative code snippet follows.
Let's define a function that builds a datum a while reading constructor
strings via a monad. Hence the function is of the following type:
buildT :: forall a. Data a = ReadT a
The corresponding monad is easily defined for the following type:
newtype ReadT a = ReadT { unReadT :: [String] - Maybe ([String],a) }
The function buildT goes essentially like this:
buildT =
do str - readT -- 1
con - string2constr str -- 2
ske - return $ fromConstr con -- 3
fs - return $ gmapQ buildT' ske -- 4
perm [] fs ske --5
In step 1, we read a constructor string from the input.
In step 2, we turn the string into a proper constructor.
In step 3, we compute a skeleton term (with bottoms).
In step 4, we compute a list of specialisations of buildT,
that only attempt to build subterms of the given type of kid.
In step 5, we repeatedly map the list of functions over the
skeleton until all functions have been applied once.
For more details, see [1,2]
There are other kinds of type reflection that come handy
in such a context; we really plan to release [3] very soon :-)
Ralf
[1] The boilerplate site: http://www.cs.vu.nl/boilerplate
[2] The code for this example:
http://www.cs.vu.nl/boilerplate/testsuite/perm.hs
[3] Scrap more boilerplate by SPJ and Ralf Laemmel, forthcoming.
Simon D. Foster wrote:
I am currently trying to implement a method of allowing arbitrary record
syntax data-types to be converted to and from an XML representation of
them using the Read and Show class;
i.e. simply derive either Show and then parse the given String to
extract the name/value pairs which can then be converted to XML, or
using the XML generate a representation of the data entity (e.g.
Person{name=\Fred Smith\, age=47}) and read this back into an actual
value.
However I have one small problem; the order of the incoming parameters
of the XML data-type representations is not guaranteed, but according to
Haskell 98 report;
If the constructor is defined using record syntax...the fields must be
given in the same order as the original declaration.
So my question is, is there any method in GHC which allows you to
extract the order of the constructors in a type or to parse a
type-representation in such a way that the order of the records doesn't
matter (I am looking for ease/simplicity of use)?
Or do I just tell them to put the records in alphabetical order?
-Si.
(Please CC replies to me).
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] new primitive instances of Data?
I'm in the process of trying to write generic binary serialization code using the Scrap Your Boilerplate method. One bump I've run into is that there are no instances of Data provided for the extended set of numeric types (the stuff in Data.Word, etc.) and it seems to be impossible to hand-write an instance that behaves similarly to the instances for other primitive types. Any ideas for ways around this? Hi, as a basis for disucssion I propose bit serialisation as in: http://www.cs.vu.nl/boilerplate/testsuite/bits/Main.hs alternatively, the inner workings of normal read and show are inspiring too: http://www.cs.vu.nl/boilerplate/library/Text.hs Your problem seems to refer to instances like the following: (Data.Generics.Basic) -- Another basic datatype instance instance Data Integer where toConstr x = IntegerConstr x fromConstr (IntegerConstr x) = x dataTypeOf _ = IntegerType This GHC 6.2 library instance indeed relies on a CWA as far as basic datatypes are conveniently supported. This is your problem, isn't it. Let me also show the CWA datatype here for convenience: -- | Representation of constructors data Constr = -- The prime case for proper datatype constructors DataConstr ConIndex String Fixity -- Provision for built-in types | IntConstr Int | IntegerConstr Integer | FloatConstr Float | CharConstrChar -- Provision for any type that can be read/shown as string | StringConstr String -- Provision for function types | FunConstr deriving (Show, Typeable) This CWA is there because it allows us to map types to constructors and to go back without inefficient or imprecise conversion. It is basically there for an optimisation. It can be bypassed without problems. That is, there seem to be two ways to handle the problem you have: a) Go via read and show for all the various types such as in: (from Data.Generics.Basics again) -- A basic datatype without a specific branch in Constr instance Data Rational where toConstr x = StringConstr (show x) fromConstr (StringConstr x) = read x dataTypeOf _ = StringType (You can also use other functions that show and read of course.) b) Use type extension via mk? and ext? combinators as in generic read: (from Data.Generics.Text again) gread = readP_to_S gread' where gread' :: Data a = ReadP a gread' = gdefault `extR` scase where -- A specific case for strings scase :: ReadP String scase = readS_to_P reads -- The generic default for gread -- gdefault :: Data a = ReadP a gdefault = ... Please let me know if you need further help. Simon PJ and I have a draft which explains all this but it is too clumsy to release yet :-) All the best, Ralf -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: pattern-matching extension?
As Bernie and Derek already pointed out, in principle, the rich work on intensional polymorphism and dynamic typing comes to mind. In particular, dynamics are readily supported in Haskell. Let me add the following. Type-safe cast is now clearly localised in the module Data.Typeable. (Due to a refactoring from last summer, which will be effective in GHC 6.2) Here I recall the type of type-safe cast as used in scrap your boilerplate: cast :: (Typeable a, Typeable b) = a - Maybe b No detouring to Dynamics needed. Having *type-safe cast* means that you can also perform *type case*. So here we go. import Data.Typeable We now define a function along the lines of what you asked for. (I will discuss below the limitations of this.) f :: (Show a, Typeable a) = a - String f a = (maybe (maybe others float (cast a) ) int (cast a) ) where -- do something with ints int :: Int - String int a = got an int, incremented: ++ show (a + 1) -- do something with floats float :: Float - String float a = got a float, multiplied by .42: ++ show (a * 0.42) -- do something with all other typeables others = got something else: ++ show a Full examples and relevant Data.* modules at http://www.cs.vu.nl/boilerplate/#suite (see Type-case demo) Discussion: -- - So type case works fine. I agree with you that having syntax for type case (instead of folding over maybies as I do above) would be great. -- - Your example asks for more. It asks for what I would call type-class case. You want to cast values whose type possibly instantiates this or that class, for example, the Show class. I agree that this would be cool to have. Especially when programming with generics, one sometimes wants to do what you just demonstrated: show things. It is not clear to me how many users such a language extension would have however. It is a major extension. Just look at the type of your f. It pretends to be parametrically polymorphic. So an argument would not carry any class dictionaries. When doing the type-class case, these dictionaries had to be invented. Nice research topic!!! -- - Your particular syntax is problematic in two respects. 1. The type of f looks too innocent. There is some preference (not a dogma) in Haskell that unconstrained type variables stand for parametric polymorphism. 2. One would maybe want to use another symbol than :: because otherwise one could get accidentally well-typed patterns. -- - The specific type-class case for Show is of course not necessary if all relevant values are known to be showable. So we can go for the Data rather than the Typeable class. Then my example becomes as follows: f :: Data a = a - String f a = -- as before where -- do something with all other data -- NOTE the gshow as opposed to show others = got something else: ++ gshow a Ralf Abraham Egnor wrote: I've occasionally wanted some sort of equivalent of an instanceOf function in haskell, i.e. one that would let me define a function that could dispatch on the type of its argument as well as the value. One option I've seen for this is http://okmij.org/ftp/Haskell/class-based-dispatch.lhs;, but that unfortunately has the downside of requiring you to write both a constructor for PACK and an instance of Packable for each type you'd like to dispatch on. The thought occurred to me that it is (intuitively) natural to do this via extending the pattern-matching facility to include types as well as literal values, i.e. something like: f :: a - String f (a :: Int) = got an int, incremented: ++(show (a+1)) f (a :: Show q = q) = got a showable: ++(show a) f _ = got something else This has a couple of nice features - it's a simple extension of the syntax, and acts as a sort of type-safe typecast. However, I have zero knowledge of how hard it would be to implement this, and there may be theoretical difficulties I haven't seen. Thoughts? Abe ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
FOAL 2004 -- deadline 19.01.2004
(* This field has meanwhile seen a number of contributions from the functional programming community. So it is fair to assume that the present announcement is of interest for some subscribers of this list. *) FOAL: Foundations of Aspect-Oriented Languages A one day workshop affiliated with AOSD 2004 in Lancaster, UK, on March 23, 2003. 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 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. 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, Monday, 19 January 2004. (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, cclifton -at- cs -dot- iastate -dot- edu. We will notify the corresponding author of papers that are selected for presentation at the workshop by 9 February 2004. The early registration deadline for AOSD is 13 February 2004. FOAL attendees must be registered for AOSD. Final versions of papers for the proceedings will be due on 1 March 2004. For more information, visit the FOAL Workshop home page at http://www.cs.iastate.edu/FOAL. Important Dates Submission Deadline 23:00 GMT, 19 January 2004
FOAL 2004 -- deadline 19.01.2004
(* This field has meanwhile seen a number of contributions from the functional programming community. So it is fair to assume that the present announcement is of interest for some subscribers of this list. *) FOAL: Foundations of Aspect-Oriented Languages A one day workshop affiliated with AOSD 2004 in Lancaster, UK, on March 23, 2003. 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 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. 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, Monday, 19 January 2004. (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, cclifton -at- cs -dot- iastate -dot- edu. We will notify the corresponding author of papers that are selected for presentation at the workshop by 9 February 2004. The early registration deadline for AOSD is 13 February 2004. FOAL attendees must be registered for AOSD. Final versions of papers for the proceedings will be due on 1 March 2004. For more information, visit the FOAL Workshop home page at http://www.cs.iastate.edu/FOAL. Important
CFP --- FOAL 2004: Foundations of Aspect-Oriented Languages
(* This field has meanwhile seen a number of contributions from the functional programming community. So it is fair to assume that the present announcement is of interest for subscribers of this list. *) FOAL: Foundations of Aspect-Oriented Languages A one day workshop affiliated with AOSD 2004 in Lancaster, UK, on March 23, 2003. 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 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. 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, Monday, 19 January 2004. (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, cclifton -at- cs -dot- iastate -dot- edu. We will notify the corresponding author of papers that are selected for presentation at the workshop by 9 February 2004. The early registration deadline for AOSD is 13 February 2004. FOAL attendees must be registered for AOSD. Final versions of papers for the proceedings will be due on 1 March 2004. For more information, visit the FOAL Workshop home page at http://www.cs.iastate.edu/FOAL. Important Dates Submission Deadline 23:00 GMT, 19 January 2004 Notification of Acceptance
Re: Generic Haskell Diffs?
[EMAIL PROTECTED] wrote: According to the communities report there are different generic haskell projects (Jeuring/Hinze and PJ/Lämmel) out there. But I don't understand their relation. Can you use both at the same time? Is one building on the other? Are there adressing different issues? A clarifying sentence or two would be heartily welcome. There is just one Generic Haskell project even though the actual language extension is a moving target of course because this is an active project. The boilerplate approach is about lightweight generic programming IN Haskell. The fact that the boilerplate approach is supported by GHC is very, very convenient, but in a sense optional: in principle, you could write Typeable and Data instances yourself, and you could still leverage generic programming in Haskell. Anyway, some more information can be found on the boilerplate page. Using both approaches together would be quite cool!?! There is no technical reason why this would be impossible. But it is certainly not the case that the two approaches are complementary. They overlap quite a bit. The boilerplate approach tries to be easy in the traversal arena. In the literature, there are some comments on how these and other approaches relate. I would still find it interesting to see a survey that works through some examples and compares the two approaches and others. Ralf ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Another fold question
Continuing Keith's self-reply ... the Music type involves types other than Music; so it is fair to say that ultimately you would need generalised folds extended to the case of *systems* of datatypes (cf. Dealing with large bananas). Imagine for example getPitches :: Music - [Pitch]. Even if a function, be it getNotes or otherwise, investigates patterns in addition to just looking at arguments obtained by recursive folding, then this function can be generally turned into a simple fold. This is the step of going from paramorphisms to catamorphisms using the infamous tupling technique that goes back to L. Meertens I think :-). (I am not sure that this the obvious way to think of these things.) Finally, the getNotes function only recurses into Music but not into the structure of Notes, and so I would actually prefer to have a return type [(Pitch,Octave,Duration)] rather than [Music] just to be sure that I am extracting notes and not whatever kind of Music. Need a banana, now :-) Ralf Keith Wansbrough wrote: [replying to self, oops] Oops, I didn't look closely enough at this line. As written, this *isn't* a fold because it examines the item (Note _ _ _ :: Music) directly rather than just looking at its arguments. But (a) it's academic in this case - since none of the arguments are recursive, you can just write getNotes (Note p o d) = [Note p o d] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Type tree traversals [Re: Modeling multiple inheritance]
Brandon Michael Moore wrote: Great. But I can't build from the source: I'm getting errors about a missing config.h.in in mk. I'm just trying autoconf, comfigure. I'll look closer over the weekend. Use the following (more specifically autoREconf). The GHC build guide is behind. cvs -d cvs.haskell.org:/home/cvs/root checkout fpconfig or use anonymous access. cd fptools cvs checkout ghc hslibs libraries testsuite testsuite is optional and many other nice things are around. find . -name configure.ac -print to find all dirs that need autoreconf (not autoconf anymore) autoreconf (cd ghc; autoreconf) (cd libraries; autoreconf) ./configure allmost done cp mk/build.mk.sample mk/build.mk Better this sample than no mk/build.mk at all. gmake Builds a nice stage2 compiler if you have ghc for bootstrap, alex, happy, ..., but otherwise configure would have told you. Ralf ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
strange difference between old and hierachical module names
Hi, I am trying to compile some modules with old imports such import MonadFix. These modules compile fine with GHC 6.0 latest RPM, and also on CVS source tree 6.1 somewhere from july. However, the file below does NOT get through with GHC HEAD. I get ... Compiling Foo ( Foo.hs, interpreted ) Foo.hs:13: `mfix' is not a (visible) method of class `MonadFix' Failed, modules loaded: none. If I use the new import Control.Monad.Fix instead of MonadFix, everything works fine. This is a bit strange because for most old imports there is no such problem. Seems to be something special going on with MonadFix. Thanks, Ralf module Foo where -- Does not work 6.3 as 2 Nov 2003 import MonadFix -- Works with 6.3 -- import Control.Monad.Fix data Foo a = Foo a instance Monad Foo instance MonadFix Foo where mfix = undefined ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Data representation, maybe reflection, laziness
Hi Mark, The boilerplate style of generic programming [1] should be of help here. For example, here you can see how to do a normal read and show: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Data/Generics/Text.hs?only_with_tag=MAIN We are also using this style to do decode and encode (think of bit streams), or to read and show XML (just working on this as we speak). Data.Generics allows you to obtain access to constructors and type information, which is crucial for versatile read/show functionality. The rather inductive style underlying derivable type classes, which you mentioned, does not provide such access, but could probably be extended to do so. You will also find a preliminary module Data.Generics.Reify at [1] that illustrates indeed that there is some link to reflection if you like this view. One of the applications that really requires getting a handle on type information is test-set generation. Regards, Ralf [1] http://www.cs.vu.nl/boilerplate/ (The code base shown here is as of GHC 6.2, but a simple version of Data.Generics was shipped with GHC 6.0.) Mark Carroll wrote: People have been talking about transmitting Haskell values on the GHC users' list, and I wanted to ask some more general stuff, partly out of mild ignorance. Ralf Hinze and Simon Peyton-Jones wrote an interesting paper on generic programming and derivable type classes. It looked like maybe programmers would be able to write their own deriving xml stuff and whatever, which looked great because, if there's not already one out there, I'd love to derive some read/show analogue automatically for data in some encoding that's very efficient to write and parse (i.e. not XML (-:). I was also wondering how the ability to write deriving stuff related to what one might think of as being reflection - that is, for example, could a definition of deepSeq be derived that automatically knows how to recurse into and traverse data structures and make sure everything's evaluated? This leads me to the point that little of the code I write needs laziness, but many of my unpleasant performance surprises come from laziness. I do find it hard to figure out where to put strictness annotations to actually make things work - for instance, I think it's laziness things that are causing my uses of Control.Exception.evaluate to actually work more by trial and error. No doubt it'll all grow clearer in time. Maybe I need laziness annotations instead. (-: Still, I was wondering what current thinking and directions were with regard to any of the above! -- Mark ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
command-line options become extensional imports
Regarding M. P. Jones proposal to move command-line options to the module space, I would like to reiterate something from an earlier email: What if you want to express that overlapping instances are fine for a certain class C but not for the rest? Recasted to the module speak of MPJ, would that require some parameterisation? I am sure this question makes sense for several extensions. (A humble solution: One could dedicate a module to the class C, and then rely on scope rules for modules regarding the propagation of the import Extension.OverlappingInstances.) Another issue is of course that this modulish approach, which I like very much, requires sometimes that an imported extension X is *reexported* from hacker module H so that some other module A will also be compiled with the corresponding extensions enabled. Such invasive, implicit reexport is quite non-standard. In general, this raises the issue of scopes for such extensions. For some extensions, they might be *invasive* that they really require special code for all modules. For some other extension, there might be a *choice* for applying the extension to the given module or also all clients transitively or non-transitively. Aligning these options with the module system, or more precisely with the existing scope/import/export rules of the module system seems to be non-convincing to me at this stage. In fact, finding the ultimate solution would go beyond the scope of Haskell, it would be an achievement for programming languages but also software configuration in general. Regards, Ralf ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: *safe* coerce: four methods compared
[EMAIL PROTECTED] wrote: This is a Related Work section of the previous message. ... again cunning stuff omitted ... I buy most of this but IMHO you should make very clear that there is not just a single safeCoerce, but the TI/init_typeseq argument has to be constructed and supplied by the programmer in a way that (s)he decides what array of types can be handled. So if you wanted to use your approach to scrap boilerplate [1], say deal with many datatypes, this becomes quite a burden. Think of actually building initial type sequences. Think of how combinators need to be parameterised to take type sequences. (That's what I called a CWA yesterday.) On the other hand, you mention this duality between type classes vs. type heaps. Yes, I would say that type classes and type case are somewhat dual. You provide a type case. What I like about your type case vs. the approach taken in [1] is that your type case will be very precise. That is, you don't say one can just try anything what is Typeable but you rather restrict questions to the types in the supplied initial type sequence. This is certainly beneficial for applications other than scraping boilerplate. Ralf [1} Scrap your boilerplate: a practical design pattern for generic programming by Ralf Lämmel and Simon Peyton-Jones, appeared in Proceedings of TLDI 2003, ACM Press http://www.cs.vu.nl/boilerplate/#paper -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ http://www.cwi.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: *safe* coerce, for regular and existential types
[EMAIL PROTECTED] wrote: ... loads of cunning stuff omitted Software-engineering-wise your approach suffers from an important weakness: a closed world assumption. The programmer has to maintain your TI and pass it on in all kinds of contexts for the array of types to be handled. I also had a type-safe and efficient cast in [1] with a CWA. (I guess it works fine for extensials.) My CWA was even more serious however. I use a class for casting whose declaration even depends on the array of types to be handled. On the positive side, I didn't need undecidable not even overlapping instances. Also, the programmer is not concerned with passing on any type seq like your TI. I really admire your use of polymorphic lists (which are in fact kind of products) to get the problem of type sequences to the value level. Cool! Do you see any way to effectively remove this CWA? (Only then it could serve as a replacement of the current cast function.) If yes, would you expect that your approach is more efficient then the one taken in Data.Typeable? (We recently split up Data.Dynamics into Data.Dynamics and a more primitive module Data.Typeable which contains cast; see CVS) Is it obvious to see that fetching stuff from the type sequences would be indeed efficient for long PLists? Well, I guess the hard problem is the CWA anyway. Ralf [1] The Sketch of a Polymorphic Symphony http://homepages.cwi.nl/~ralf/polymorphic-symphony/ See the Larghetto movement It is trivial; it makes Stephanie Weirich's type-safe cast fit for nominal type analysis. -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ http://www.cwi.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: StrategyLib - need help
(Let's go to haskell-cafe if we want to continue.) Hi Dmitry, Sigh. Indeed, the distributed instance Show TermRep is not fit. The default TermRep in the Strafunski distribution is not even willing to disclose constructor names. So there is no way unless you tweak TermRep (and DrIFT). TermRep should hold a string component for the constructor (or the string representation in the case of primitive types). I will provide a StrategyLib on top of Data.Generics very soon. Then your trouble is gone. (The Scrap Your Boilerplate approach is really much more convenient.) As a quick fix, I advise you to code a monster switch as follows. (Tested in StrategyLib/examples/little-lambda) testShow:: [String] testShow = runIdentity (applyTU (full_tdTU myShowTU) expr4) where myShowTU = constTU [] `adhocTU` (\(x::Expr)- return [show x]) `adhocTU` (\(x::Type)- return [show x]) `adhocTU` (\(x::Identifier)- return [show x]) So this is one line per type. Not that bad. And it is nice because you can comment out types easily during debugging. Greetings, Ralf RL a) Add a class constraint for Show to the Term class. RL(Would that work? It's a bit invasive anyway.) Yes, that a bit invasive to say at least. With equal ease I can hack DrIFT to produce instances of Show the way I want them. RL b) Alternatively, imoort TermRep and use explode and then show on RLTermRep. (This show maybe does not look so nice, RL but this should be good enough for debugging.) I dont quite follow you here. If I (show . explode) the topmost Term, I got just the name of the type of that term. If I try to build a traversal which explode-s everything on the way, I got the same error as before (which is expected, I believe). RL c) Be more specific about what terms to print, RLsay have type-specific cases for types of terms of interest. (This RLwould be reasonable if you only care about a few types, RL or there are even just a few types anyway.) Thing is that there is a lot of types and I'd like to print all of them. -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ http://www.cwi.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: StrategyLib - need help
Very good point!
adhoc and friends support TYPE case.
What's needed here is a so-far unsupported type-CLASS case
which is actually at least non-trivial.
I can only offer semi-solutions:
a) Add a class constraint for Show to the Term class.
(Would that work? It's a bit invasive anyway.)
b) Alternatively, imoort TermRep and use explode and then show on TermRep.
(This show maybe does not look so nice,
but this should be good enough for debugging.)
c) Be more specific about what terms to print,
say have type-specific cases for types of terms of interest.
(This would be reasonable if you only care about a few types,
or there are even just a few types anyway.)
On the long term:
the boilerplate approach as supported in GHC 6.0 will
help with this. (In fact, the GHC 6.0 release comes with a
simple gshow defined on Data.) StrategyLib will soon be
reconstructed on top of scrap your boilerplate (say, Data.Generics).
The issue of type-class case is identified, but I don't know if we will
succeed with this very soon.
Hope this helps.
Ralf
Dmitry Astapov wrote:
I want to write generic traversal which prints everything on the way:
uglyPrint :: (Term t, Show t) = t - [(String)]
uglyPrint = (map snd) . runIdentity . applyTU (full_tdTU uglyPrintStep)
uglyPrintStep :: (Show t, Term t) = TU [(t, String)] Identity
uglyPrintStep = constTU [] `adhocTU` (return . uglyPrintAny)
uglyPrintAny x = [(x,show x)]
ugliestPrintEver :: (Term t, Show t) = t - IO ()
ugliestPrintEver x = do { putStrLn $ show x }
Compiler (GHC 6.0) gives me:
Ambiguous type variable `t' in these top-level constraints:
`Term t'
arising from use of `uglyPrintStep' at ...
`Show t'
arising from use of `uglyPrintStep' at ...
All data types which are instances of Term are instances of Show as well -
I know it. Question is - how to persuade GHC?
I there any want to use typeclass restrictions with traversal, or there is
no luck for me?
--
Dmitry Astapov //ADEpt
GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
--
Ralf Laemmel
VU CWI, Amsterdam, The Netherlands
http://www.cs.vu.nl/~ralf/
http://www.cwi.nl/~ralf/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Language extension proposal
Ashley Yakeley wrote: Oh I do this all the time in HBase. I simply do this: data Type a = MkType getType :: a - Type a getType _ = MkType class (Bounded a) = FloatTraits a where epsilon :: a mantissaDigits :: Type a - Int Suffering from persecution mania, I prefer to know for sure that nobody never ever will pattern match on those a's. So I prefer to write: -- Values serving as type arguments type TypeArg a = a - () -- Constant function as type argument typeArg :: TypeArg a typeArg = const () -- Extract type argument from value getTypeArg :: a - TypeArg a getTypeArg _ = typeArg I start to use this style more agressively in Strafunski and the boilerplate gmaps. A side remark: Data.Dynamic does NOT use this style but rather Ashley's: ... typeOf :: a - TypeRep ... which is a pitty because there is nothing in the type which prevents you from looking at a; its only in the comments. Every now and then I get this wrong. The only annoyance is that you frequently have to write (MkType :: Type MyFloat). Syntactic sugar for _that_ would be useful. On the other hand, supporting the above style with TypeArg's by an ADT, would make the whole thing entirely safe and transparent. -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ http://www.cwi.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Language extension proposal
Ashley Yakeley wrote: At 2003-06-28 02:51, Ralf Laemmel wrote: Suffering from persecution mania, I prefer to know for sure that nobody never ever will pattern match on those a's. So I prefer to write: I don't understand. Did you mean pattern-match on MkType? I could stop that by hiding it but exposing mkType = MkType. You are right. My comments attack the Data.Dynamic.typeOf style. Your use of a designated phantom datatype Type and my use of - for this purpose seem to be equivalent. Ralf ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Collecting values from Functors?
Ralf Hinze wrote: What happens if the tree contains additional integers to record, say, balancing information. The information a functor provides is vital here. Take as the simplest example newtype Weighted a = WithWeight (Int, a) Without the functor definition there is no way to distinguish the two Ints in Weighted Int. You are right in that gmapping is not generally aware of term components that relate to the parameter of a parameterised datatype. This has to do with the restricted structural induction and with the bias towards nominal type case. One can still recover `type distinctions' by pattern matching however. I elaborated the example like this: http://www.cs.vu.nl/boilerplate/testsuite/foldTree.hs (More generally, it is certainly debatable if the gmap combinators are in place for more fancy datatypes, e.g., nested datatypes. I mean that the design and use of these datatypes is normally an ingenious process as opposed to boilerplate programming in the sense of AST or document traversal.) Ralf L. -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ http://www.cwi.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ovelapping instances under control
Hi, I think that there is consensus regarding the usefulness of overlapping instances. But it is a pitty that the -fallow-overlapping-instances declaration is so pervasive. I mean: - If I deal with several classes, only few of them require overlapping instances, then I would like to restrict -fallow to the relevant classes. - If I compile a module A with overlapping instances allowed, and I import A into B, then I don't want to be forced to allow overlapping instances in B unless B by itself wants to produce overlaps. Did I miss anything? If not, would that be difficult (formally, technically)? Ralf -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ http://www.cwi.nl/~ralf/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Last Call: SCP Special Issue on Program Transformation; Deadline 1.4.2003
Program Transformation Special Issue in the Science of Computer Programming Deadline is 1.4.2003 Find CFC attached or at http://www.cwi.nl/~ralf/pt-scp/ (Program transformation is of interest for many subscribers of this list because program transformation is crucial for the implementation of functional languages, and it is also a typical application domain of functional programming. Other keywords: Meta-programming, XML processing, refactoring.) -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ http://www.cwi.nl/~ralf/ Special Issue on Program Transformation Science of Computer Programming Guest Editor Ralf Lämmel Call for contributions The special issue is devoted to `program transformation' in the sense of automated program adaptation by executable transformations. Such transformations are used in software development and especially in software maintenance in various ways, e.g., for refactoring, software migration, mass maintenance, change logging, schema evolution, program specialisation, software configuration, aspect weaving, and others. The special issue seeks high-quality contributions studying the following dimensions of transformations: * formal aspects such as operator suites for transformations and their properties; * language design issues such as suitable language setups and meta-programming frameworks; * infra-structural issues such as the relation to front-ends, program analysis, interfaces; * software engineering aspects such as scaling, testing and maintaining transformations; * emerging fields such as unanticipated software evolution; * case studies such as lessons learned in large-scale transformation projects. Deadline for paper submissions: 1 April 2003 Author's notification: 1 July 2003 Special issue's publication:End of 2003 The submissions should be sent in PS or PDF to the guest editor via email. If you are not sure about the suitability of a given subject, or if you want to know more details about the special issue's intent, do not hesitate to contact the guest editor. The guest editor's email address is [EMAIL PROTECTED];or see the URL http://www.cwi.nl/~ralf/. For details about the policy of the Science of Computer Programming journal and the requirements for prospective authors, see a recent issue of the journal and check the journal's web site http://www.elsevier.com/locate/issn/01676423.
Re: Design patterns in Haskell
I shamelessly copy from the abstract of [1]:
We contend that design patterns can be an effective means of
consolidating and communicating program construction expertise for
functional programming just as they have proven to be in
object-oriented programming. One might suppose that the powerful
abstraction mechanisms of functional programming obviate the need for
design patterns, since many pieces of program construction knowledge
can be captured by reusable functions. This confusion of design
patterns with reusable components misses the point: patterns start
where components end, in the sense that the former describe how the
latter can be constructed and used. Thus, additional abstraction
\emph{creates} the need for new design patterns.
[1] Design Patterns for Functional Strategic Programming
http://www.cs.vu.nl/Strafunski/dp-sf/
Ralf
P.S.: Should we move to haskell-cafe@... ?
--
Ralf Laemmel
VU CWI, Amsterdam, The Netherlands
http://www.cs.vu.nl/~ralf/
http://www.cwi.nl/~ralf/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
New Strafunski packages released
New Strafunski packages released Strafunski is a Haskell-centred bundle that provides support for generic programming and language processing. Strafunski is based on the notion of a functional strategy --- first-class generic functions that can traverse into terms while mixing uniform and type-specific behaviour. This is the 3rd release of Strafunski with the following improvements: - StrategyLib extended by several themes, e.g., for metrics. - Added Sdf2Haskell package for mapping syntaxes to datatypes. - Cobol, Java, and Haskell meta-programming examples included. - Haskell ATermLib integrated. - Sample code from the following papers integrated: - PADL 2003: A Strafunski application letter - RULE 2002: Towards Generic Refactoring - WRS 2002: The Sketch of a Polymorphic Symphony - DrIFT-Strafunski supports a number of additional models. Documentation, papers, and downloads are now available from: http://www.cs.vu.nl/Strafunski A good entry point for contemporary Strafunski is: A Strafunski Application Letter (PADL 2003) See http://www.cwi.nl/~ralf/padl03/ It demonstrate that typed functional programming in Haskell, augmented with Strafunski's support for generic traversal and external components, is very appropriate for the development of practical language processors. In particular, Strafunski is used for Cobol reverse engineering, Java code metrics, and Haskell re-engineering. Feedback is very much appreciated, and can be directed to the authors: * Ralf Laemmel([EMAIL PROTECTED]) * Joost Visser([EMAIL PROTECTED]) Have fun! ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
CFC: SCP Special Issue on Program Transformation
Not just a few haskell@... subscribers do transformation for/with functional programming. Thanks for passing on to interested authors. -- Ralf Laemmel VU CWI, Amsterdam, The Netherlands http://www.cs.vu.nl/~ralf/ http://www.cwi.nl/~ralf/ Special Issue on Program Transformation Science of Computer Programming Guest Editor Ralf Lämmel Call for contributions The special issue is devoted to `program transformation' in the broader context of software maintenance. That is, program transformation is meant here in the sense of automated program adaptation by executable transformations. Such transformations are used in software maintenance but also in software development in various ways, e.g., for refactoring, software migration, mass maintenance, change logging, schema evolution, aspect weaving, and others. The special issue seeks high-quality contributions studying the following dimensions of transformations: * formal aspects such as operator suites for transformations and their properties; * language design issues such as suitable language setups and meta-programming frameworks; * infra-structural issues such as the relation to front-ends, program analysis, interfaces; * software engineering aspects such as scaling, testing and maintaining transformations; * emerging fields such as unanticipated software evolution; * case studies such as lessons learned in large-scale transformation projects. Deadline for paper submissions: 1 April 2003 Author's notification: 1 July 2003 Special issue's publication:End of 2003 The submissions should be sent in PS or PDF to the guest editor via email. If you are not sure about the suitability of a given subject, or if you want to know more details about the special issue's intent, do not hesitate to contact the guest editor. The guest editor's email address is [EMAIL PROTECTED];or see the URL http://www.cwi.nl/~ralf/. For details about the policy of the Science of Computer Programming journal and the requirements for prospective authors, see a recent issue of the journal and check the journal's web site http://www.elsevier.com/locate/issn/01676423.
Functional design patterns (was: How to get functional software engineering experience?)
Andrew J Bromage wrote: On the other hand, it's an exciting time to do engineering in declarative languages, because we can invent the design patterns and discover what the good habits are as we go along. BTW, FP is older than OOP. So why are we so late :-) ? Joost Visser and I, we worked out a few maybe not so obvious functional programming patterns such as Success By Failure, Role Play, Rewrite Step, Keyhole Operation just to mention a few. By not so obvious I mean that they deal with generic programming rather than functional programming in general. http://www.cs.vu.nl/Strafunski/dp-sf/ We use a certain FORMAT for design patterns, and there is some modest analysis why this format is appropriate. Also, there is some discussion why design patterns would do good for functional programming. This might be interesting in the further process of accumulating design patterns for functional programming. I am in complete agreement with Jeffrey Palmer who wrote: From the research I've done to date, functional programming provides enough of a paradigm shift that there are significant new patterns/idioms I have the feeling that the FP community has a hard time getting started with design patterns. Part of the problem is that design patterns are inherently vague and this is maybe something the authors in our field do not like to consider. That is, if something is being written that is meant to document design experience for functional programming, it ends up being complex (say, Stop programming this or that; you will definitely fall in love with Haskell if you can parse this article.). Another more technical part of the problem is that it is not obvious what format would be appropriate, especially because the driving ingredient of an OO design pattern is the class hierarchy or an object structure, and this does not make sense in a functional setting. Yet another problem is that design patterns are all about design and less about coding. Many challenges in functional programming are about coding, and just about coding. We might need a different understanding of what design patterns are because we would like to cover the rich set of programming idioms in functional programming. I feel tempted to say there aren't that many in OOP. I guess there are more reasons why there is no GoF book out yet for FP. But at least Jeffrey, Joost, and I, we are working on that :-) Jeffrey Palmer wrote, too: To avoid any pattern debates: I personally believe that patterns are especially useful for getting novices up to speed on concepts that might not be readily apparent at first glance. Rather than treating patterns as anything special in their own right, for me they're simply a really convenient way of teaching people new and interesting concepts. Why do you say this if you want to AVOID a debate ;-) ? Design patterns are maybe convenient for teaching ... But they are ESSENTIAL to gather design experience, and to regulate the terminology in a field. They are also CRUCIAL for the interaction of design and programming in the implementation phase, AND for the idea of refactoring. Also, the idea of a design pattern catalogue is just a kind of SELF-CHECKING notion to address all concerns a programmer could possibly have. By self-checking I mean that the firm adherence to a well-designed format for a catalogue is the key. Ralf -- Dr.-Ing. Ralf Laemmel CWI VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: first-class polymorphism beats rank-2 polymorphism
Simon Peyton-Jones wrote: Indeed the foralls are at the top, but I claim that wherever you could use the composition function you were expecting, you can also use the one GHC gives you. The two types are isomorphic. ... Let me know if you find a situation where this isn't true. ... No I believe it is not a bug. I would be interested to see why you needed to change your code. It is all not that simple. Let me try to explain. For some deeper background I refer to my draft. One more week to finish. http://www.cwi.nl/~ralf/rank2/ Maybe, we should do that offline. But maybe it is interesting for people how like rank-2 stuff. Let's consult the following code with the ghc 5.03 snapshot. It is basically the same kind of example as in my last posting but I point out a few things more clearly, and the example is simpler. - type Generic i o = forall x. i x - o x type Id x = x comb :: (Generic Id Id) - (Generic Id Id) - (Generic Id Id) comb = undefined comb' :: forall x1 x11 x. (Id x1 - Id x1) - (Id x11 - Id x11) - Id x - Id x comb' = undefined yacomb :: (forall x. x - x) - (forall x. x - x) - (forall x. x - x) yacomb = (.) yacomb' :: forall x y z. (x - x) - (y - y) - (z - z) yacomb' = undefined - I explain the code per def./decl.: 1. The type synonym Generic captures a parameterized function type where we can still plug in type constructors of kind *-* to derive domain and codomain from the explicitly quantified x. The type Generic suggests that we deal parametric polymorphism but in my real code I have class constraints on x. This immediately resolves Simon's concern about the usefulness of defining sequential composition in some new way. I had chosen seq. comp. as an example to play with types. If we go beyond parametric polymorphism, several binary combinators using Generic for arguments and result make sense (see my draft; feedback appreciated). 2. The type constructor Id of kind * - * is the identity type constructor. That is, given a type, it returns the very same type. There are plenty of useful type constructors like Id but let's restrict our discussion to Id for simplicity. As an aside, I like it very much that ghc allows me to compose type synoyms like I do with Generic and Id. hugs doesn't allow me that, and this implies that I have to use datatypes instead for things like Id, and this in turn implies that I have quite some wrapping / unwrapping going on in my hugs expression code. 3. Let's suppose we want to define SOME binary function combinator comb. It takes two polymorphic functions of a certain type as for i and o and returns another polymorphic function with potentially some other i and o for the domain and codomain. In fact, I have chosen Id for all i and o parameters for the above comb for simplicity. Let's us ignore parametricity for a moment and pretend we know how to define many combinators like this. In the example above, I left comb undefined since I only want to play with the ghc type system. As I said, in my true code I define interesting combinators with such type schemes but with extra class constraints. This is the reason that I can do more things than parametricity allows me. So let us really not think of ordinary (say, parametric polymorphic) sequential composition as my last email maybe suggested. 4. So now let's ask for the type of comb in ghc. It turns out to be the rank-1 (!!!) type I captured as explicit type annotation for comb'. I would have expected a rank-2 type because the forall is scoped by the type synonym Generic. So why should I like to see the forall going to the top? I still would say that THIS IS A BUG. Here is why the types are different: The rank-1 type allows me to combine functions on say integers (by using Int for x x1 and x11). The rank-2 type that I am asking for rules out monomorphic functions to be composed. So the type with the foralls at the top, and the foralls scoped in a rank-2 discipline are NOT isomorphic. Also, keep the possibility of class constraints in mind. Simon, is it maybe possible that you confused the type of (.), that is, forall b c a. (b - c) - (a - b) - a - c with the type forall z y x. (x - x) - (y - y) - z - z. The b c a in (.) types deal with the possibly different result types. The z y x in my rank-1 comb (messed up by ghc) deal were originally meant to display insistance on polymorphic function arguments. So the the foralls should not be at the top. 5. The type that I wrote down for yacomb is precisely the rank-2 type I would have favoured to see for comb instead of the actual type suggested by ghci. It is a rank-2 type. A minor issue: I expanded the occurrences of Id for readability (ghc keeps them at all costs because it seems to assume that I like to get reminded of them which is not the case BTW). So everything (the two arguments
RE: first-class polymorphism beats rank-2 polymorphism
Simon Peyton-Jones wrote: In fact GHC does forall-lifting on type signatures to bring the foralls to the front. But there's a bug in 5.02's forall-lifting... ... Perhaps you can try the 5.03 snapshot release? Certain things work there. In fact, it is fascinating. But now I did a new experiment ... It seems that forall-lifting does not work as expected for type synonyms in 5.03. Here is an example from my upcoming ICFP submission :-) Here is an innocent type synonym for generic functions with three parameters of kind * - *: type Generic i o m = forall x. i x - m (o x) This is a good candidate for all the parameters: type Id x = x Now I tried to define sequential composition. In fact, the following type deals with a very restricted case for simplicity: sequ :: forall t. (Generic t t Id) - (Generic t t Id) - (Generic t t Id) sequ f g = undefined Looking at the type of sequ, the foralls for t end up at the top. Hence, I have no chance to define sequential composition. Main :t sequ forall t x1 x11 x. (t x1 - Id (t x1)) - (t x11 - Id (t x11)) - t x - Id (t x) Main Please let me know if this is a bug. Please don't fix it too soon :-) because otherwise I had to rewrite some material which is now based on first-class polymorphism and datatypes for i, o, and m. Such code will probably look better in proper rank-2 style with type synonyms for type constructor parameters. I just realized that type synonyms in GHC seem to be valid arguments even when not completely instantiated? This is wonderful. It is not supported in hugs. How difficult is it to cope with this? Does it make a real difference for the type system? Ralf ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
class hierarchies inmature in hugs
I just saw someone misusing [EMAIL PROTECTED] for bug reports. I am going to join especially - it is a funny one, - the bug hasn't been fixed since Sep. 2001, - it is not even put in the list of known bugs since then. --- The following code works with ghc but not with hugs (incl. Dec. 2001 release) import Monad class Monad m = C1 m x -- Monad m is implied by C1 but test diverges if constraint not present class (C1 m x) = C2 m x where c2 :: x - m x instance Monad m = C1 m Bool instance C2 Maybe Bool where c2 = return test :: Maybe Bool test = c2 True --- So you see, C1 is a kind of derived from Monad. C2 is derived from C1 and hence implicitly from Monad. This is a kind of minimal example. Just attempt to evaluate test. hugs will loop. There is a way to help hugs. Add Monad m as a further class constraint to C2. Then it will work. Please note both programs do type check, and this is in fact fine. More generally, I get these looping programs whenever I have non-trivial class hierarchies with three or more layers. I guess more people should have suffered from that? Ralf -- Dr.-Ing. Ralf Laemmel CWI VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
first-class polymorphism beats rank-2 polymorphism
Suppose you want to define a combinator like this: combinator :: (forall y. Class y = y - y) - (forall x. Class x = x - x) This is a function combinator which turns a polymorphic function into another polymorphic function. As you can see, there is Class constraint. So in fact we would like to define the combinator by class overloading on the x in the result type. So how do we get our hands on the x while it is explicitly quantified by forall. Well, we try with implicit quantification: class Class x where combinator' :: (forall y. Class y = y - y) - x - x So far so, good: We still need to define combinator in terms of combinator'. What is the trick to do this? Sounds like a homework question? Well, I know how to do it for first-class polymorphism. So let's restart the example. We define a function type to capture the kind of functions from above: data Bar = Foo (forall x. Class x = x - x) Hence, the rank-2 type of combinator looks a bit different: combinator :: Bar - Bar The class looks as follows: class Class x where combinator' :: Bar - x - x And here is how to define combinator in terms of combinator'. combinator f = Foo (combinator' f) This works both with GHC and hugs. In the pure rank-2 setting above, one would like to define combinator accordingly: combinator f = combinator' f But GHC 5.02.2 tells me: rank2.hs:11: Could not deduce (Class x) from the context () Probable fix: Add (Class x) to the type signature(s) for combinator arising from use of `combinator'' at rank2.hs:11 In the definition of `combinator': combinator' f This is not a bug, I guess although the probable fix proposal sends you in the wrong direction I claim. I tried a few other tricks but I can't get it done although my first-class polymorphic experience makes me think that it should be possible. Anyway, can this problem be solved? Any hint appreciated. Ralf -- Dr.-Ing. Ralf Laemmel CWI VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: multiparameter generic classes
Hal Daume III wrote: are there any papers/webpages/implementations/etc. of using multiparameter classes in a generic framework, with or without dependencies? Maybe this is something for you. It uses 7 parameters and many functional dependencies. But it is a kind of trivial :-) And yes, it is about a generic framework, that is, a framework for generic refactoring. http://www.cwi.nl/~ralf/tgr/ The multi-parameter class is used to encode a form of signature morphism, namely the interface for language abstractions I deal with in the refactoring framework. Ralf thanks! - hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell -- Dr.-Ing. Ralf Laemmel CWI VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Generic programming bundle released
Folks, As a result of our work on functional transformation systems, large bananas, and traversal technology, we have come up with a new generic programming bundle, that is, Strafunski: http://www.cs.vu.nl/Strafunski/ The above web page lists papers (including a new draft on typed combinators for generic traversal) and download information for Strafunski. Strafunski should be useful for anyone in the Haskell community who needs to traverse syntaxes, or other representations. Strafunski is also just interesting as another incarnation of the general idea of generic programming. We appreciate your feedback. Regards, Joost Visser and Ralf Laemmel -- Dr.-Ing. Ralf Laemmel CWI VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
