Re: [Haskell] 6 Assistant professor positions in Utrecht
Ik had ook al aan Johan gemeld dat het woord talented suggereert dat er bij jullie ook non-talented personen werken. Hij zou het aan laten passen. Doaitse Op 4 jan. 2018 09:13 schreef "Swierstra, W.S. (Wouter)" : > We are currently advertising vacancies for > > > 6 talented Assistant Professors in Information and Computing Sciences > > > (Tenure Track 0.8 - 1.0 FTE) > > > # Job description > > We are searching for motivated, excellent candidates, on the > Assistant Professor level. You must have expertise in Computing > and Information Sciences, preferably in the areas of Information > Science, Games, Artificial Intelligence or Data > Science. Excellent candidates with other areas of expertise > related to our current research groups and teaching programmes > are also invited to apply. > > You have proven ambition and talent for research. As teaching is > an important and satisfying part of our work, we are searching > for people with a demonstrable motivation to teach. The > department is expanding and provides a dynamic work > environment. If you are excited to actively participate in > shaping the department, you are very welcome to apply. > > Due to our successful teaching programmes and our ambitions in > research the Department is expanding. We are therefore actively > searching for 6 talented Research and Teaching Assistant > Professors in Information and Computing Sciences. Please note > that positions offered will vary, depending on experience and > expertise. > > # Qualifications > > ## Research > > * PhD in Computer Science, Information Science or another relevant > discipline; > * track record of international publications in leading conferences and > journals; > * experience with or good prospects for acquiring external research funds; > * vision on future research directions in own area of expertise; > * experience with or readiness to supervise PhD projects; > * active role in international scientific communities. > > ## Teaching > > * experience with and enthusiasm for teaching and student supervision; > * ability to teach in departmental BSc and MSc programmes; > * well-developed didactic skills; > * excellent command of the English language; > * experience with or willingness to use innovative teaching methods > and (e-learning) technologies; > * vision on teaching and your own contribution to teaching. > > Please note that we are also interested in candidates with a focus on > teaching. > > ## Leadership: > > * play an active and cooperative role in the department and the university; > * willingness to organize scientific events, such as research seminars or > teaching seminars; > * willingness to partake in departmental committees. > > The department finds gender balance specifically and diversity in > a broader sense very important. In recent procedures we attracted > a significant number of women (three out of five positions). We > are very keen on appointing more female scientists and therefore > strongly encourage qualified women to apply. > > # Offer > > The candidate will be offered a tenure track position, depending > on experience (0.8 / 1.0 FTE). > > Salary depends on qualifications and experience, and ranges > between 3,111 and 5,405 euro (scale 10 - 12 Collective Labour > Agreement Dutch Universities) gross per month for a full-time > employment. > > The salary is supplemented with a holiday bonus of 8% and an > end-of-year bonus of 8.3% per year. We offer flexible employment > conditions, working-from-home facilities, partially paid parental > leave, a pension scheme, and collective insurance schemes. > Facilities for sports and child care are available on our campus, > which is only 15 minutes away from the historical city center of > Utrecht. > > We offer you the possibility to develop towards a Basic Teaching > Qualification, supported with educational development programs > offered by the University. We also offer candidates the > possibility to travel to conferences. > > # About the organization > > A better future for everyone. This ambition motivates our > scientists in executing their leading research and inspiring > teaching. At Utrecht University, colleagues from various > disciplines collaborate intensively towards major societal > themes. Our focus is on Dynamics of Youth, Institutions for Open > Societies, Life Sciences and Sustainability. > > The city of Utrecht is one of the oldest cities in the > Netherlands, with a charming old center and an internationally > oriented culture that is strongly influenced by its century-old > university. Utrecht city has been consistently ranked as one of > the most livable cities in the Netherlands. > > The Faculty of Science consists of six departments: Biology, > Pharmaceutical Sciences, Information and Computing Sciences, > Physics and Astronomy, Chemistry and Mathematics. The Faculty is > home to 5,900 students and nearly 1,600 staff and is > internationally renowned for the quality of its research. The > Facu
[Haskell] Summer school on Applied Functional Programming at Utrecht University; deadline for registration May 15
Again we will teach an "Applied Functional Programming Summer in Haskell" school this year at Utrecht University. In the previous four occasions students were all very happy with the school and we plan to repeat this success this year. Among the intended audience are prospective master students who gained an interest in Functional Programming, e.g. by taking a general course on programming languages, and want to learn more about Haskell and its typical programming patterns. In previous years we have taught an introductory part (advanced bachelor level), an advanced part (beginning master level) and a shared part for both groups. Topics covered are, besides some examples of domain specific languages, also monads, monad transformers, arrows, parser combinators and self-analysing programs, underlying principles, type inferencing, etc. Half of the course time is spent on a larger programming exercise; you can also come with a problem of your own if you want, and get help from the Utrecht University Software Technology group in finding the proper Haskell idioms, tools and libraries, for solving it. Important links: -- our own page where we supply information based on questions asked http://www.cs.uu.nl/wiki/USCS/ -- on this page you can find the poster you can print and hang somewhere (why not your office door): Furthermore we ask for your cooperation to bring this announcement under the attention of potential participants. Best, Doaitse Swierstra, Atze Dijkstra and Johan Jeuring ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Compositional Compiler Construction, Oberon0 examples available
On Aug 21, 2012, at 13:46 , Heinrich Apfelmus wrote:
> Doaitse Swierstra wrote:
>> Heinrich Apfelmus wrote:
>>> I have a small question: Last I remember, you've mainly been using
>>> your UUAGC preprocessor to write attribute grammars in Haskell,
>>> especially for UHC. Now that you have first-class attribute
>>> grammars in Haskell ("achievement unlocked"), what do you intend to
>>> do with the preprocessor? How do these two approaches compare at
>>> the moment and where would you like to take them?
>> On the page http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo there is
>> a link (http://www.fing.edu.uy/~mviera/papers/VSM12.pdf) to a paper
>> we presented at LDTA (one of the ETAPS events) this spring. It
>> explains how UUAGC can be used to generate first class compiler
>> modules.
>> We have also a facility for grouping attributes, so one can trade
>> flexibility for speed. The first class approach stores list of
>> attributes as nested cartesian products, access to which a clever
>> compiler might be able to optimize. This however would correspond a
>> form of specialisation, so you can hardly say that we have really
>> independent modules; as always global optimisation is never
>> compositional). From the point of view of the first class approach
>> such grouped non-termionals are seen as a single composite
>> non-terminal.
>
> Ah, I see. So the custom syntax offered by UUAGC is still appreciated, but
> you now intend to compile it to first-class attribute grammars instead of
> "bare metal Haskell". Makes sense. Thanks!
It is not much that it is our intention, but it is an easy way to make an
existing compiler extensible. The main (fixed) part of the compiler is
constructed in the "old" way from an UUAGC description, and those attributes
are grouped (and quite a bit more efficient). On top of this you can define
extra attributes and computations, which plug in to the old system.
Notice that there is a main difference between the two approaches is that the
uuagc route gives you fast compilers, because we can analyse the grammar, and
generate efficient tree walking evaluators, whereas the first-class approach
gives you great flexibility and the possibility to abstract from common
patterns for which others prefer to get lost in stacks of monads, or find out
that monads do not work at all since they cannot feed back information into a
computation easily.
Doaitse
>
>
> Best regards,
> Heinrich Apfelmus
>
> --
> http://apfelmus.nfshost.com
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Compositional Compiler Construction, Oberon0 examples available
On Aug 19, 2012, at 10:40 , Heinrich Apfelmus wrote:
> Doaitse Swierstra wrote:
>> Over the years we have been constructing a collection of Embedded
>> Domain Specific Languages for describing compilers which are
>> assembled from fragments which can be compiled individually. In this
>> way one can gradually ``grow a language'' in a large number of small
>> steps. The technique replaces things like macro extensions or
>> Template Haskell; it has become feasible to just extend the language
>> at hand by providing extra modules. The nice thing is that existing
>> code does not have to be adapted, nor has to be available nor has to
>> be recompiled.
>> Recently we have been using (and adapting) the frameworks such that
>> we could create an entry in the ldta11 (http://ldta.info/tool.html)
>> tool challenge, where one has to show how one's tools can be used to
>> create a compiler for the Oberon0 language, which is used a a running
>> example in Wirth's compiler construction book.
>> We have uploaded our implementation to hackage at:
>> http://hackage.haskell.org/package/oberon0.
>> More information can be found at the wiki:
>> http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo
>> You may take a look at the various Gram modules to see how syntax is
>> being defined, and at the various Sem modules to see how we use our
>> first class attribute grammars to implement the static semantics
>> associated with the various tasks of the challenge.
>> We hope you like it, and comments are welcome,
>
> Awesome!
>
> I have a small question: Last I remember, you've mainly been using your UUAGC
> preprocessor to write attribute grammars in Haskell, especially for UHC. Now
> that you have first-class attribute grammars in Haskell ("achievement
> unlocked"), what do you intend to do with the preprocessor? How do these two
> approaches compare at the moment and where would you like to take them?
>
>
> Best regards,
> Heinrich Apfelmus
On the page http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo there is a link
(http://www.fing.edu.uy/~mviera/papers/VSM12.pdf) to a paper we presented at
LDTA (one of the ETAPS events) this spring. It explains how UUAGC can be used
to generate first class compiler modules.
We have also a facility for grouping attributes, so one can trade flexibility
for speed. The first class approach stores list of attributes as nested
cartesian products, access to which a clever compiler might be able to
optimize. This however would correspond a form of specialisation, so you can
hardly say that we have really independent modules; as always global
optimisation is never compositional). From the point of view of the first class
approach such grouped non-termionals are seen as a single composite
non-terminal.
Doaitse
>
> --
> http://apfelmus.nfshost.com
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Compositional Compiler Construction, Oberon0 examples available
On Aug 19, 2012, at 10:40 , Heinrich Apfelmus wrote:
> Doaitse Swierstra wrote:
>> Over the years we have been constructing a collection of Embedded
>> Domain Specific Languages for describing compilers which are
>> assembled from fragments which can be compiled individually. In this
>> way one can gradually ``grow a language'' in a large number of small
>> steps. The technique replaces things like macro extensions or
>> Template Haskell; it has become feasible to just extend the language
>> at hand by providing extra modules. The nice thing is that existing
>> code does not have to be adapted, nor has to be available nor has to
>> be recompiled.
>> Recently we have been using (and adapting) the frameworks such that
>> we could create an entry in the ldta11 (http://ldta.info/tool.html)
>> tool challenge, where one has to show how one's tools can be used to
>> create a compiler for the Oberon0 language, which is used a a running
>> example in Wirth's compiler construction book.
>> We have uploaded our implementation to hackage at:
>> http://hackage.haskell.org/package/oberon0.
>> More information can be found at the wiki:
>> http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo
>> You may take a look at the various Gram modules to see how syntax is
>> being defined, and at the various Sem modules to see how we use our
>> first class attribute grammars to implement the static semantics
>> associated with the various tasks of the challenge.
>> We hope you like it, and comments are welcome,
>
> Awesome!
>
> I have a small question: Last I remember, you've mainly been using your UUAGC
> preprocessor to write attribute grammars in Haskell, especially for UHC. Now
> that you have first-class attribute grammars in Haskell ("achievement
> unlocked"), what do you intend to do with the preprocessor? How do these two
> approaches compare at the moment and where would you like to take them?
>
>
> Best regards,
> Heinrich Apfelmus
On the page http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo there is a link
(http://www.fing.edu.uy/~mviera/papers/VSM12.pdf) to a paper we presented at
LDTA (one of the ETAPS events) this spring. It explains how UUAGC can be used
to generate first class compiler modules.
We have also a facility for grouping attributes, so one can trade flexibility
for speed. The first class approach stores list of attributes as nested
cartesian products, access to which a clever compiler might be able to
optimize. This however would correspond a form of specialisation, so you can
hardly say that we have really independent modules; as always global
optimisation is never compositional). From the point of view of the first class
approach such grouped non-termionals are seen as a single composite
non-terminal.
Doaitse
>
> --
> http://apfelmus.nfshost.com
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] [Announce] Compositional Compiler Construction, Oberon0 examples available
Over the years we have been constructing a collection of Embedded Domain Specific Languages for describing compilers which are assembled from fragments which can be compiled individuallu. In this way one can gradually ``grow a langauge'' in a large number of small steps. The technique replaces things like macro extensions or Template Haskell; it has become feasable to just extend the language at hand by providing extra modules. The nice thing is that existing code does not have to be adapted, nor has to be available nor has to be recompiled. Recently we have been using (and adapting) the frameworks such that we could create an entry in the ldta11 (http://ldta.info/tool.html) tool challenge, where one has to show how one's tools can be used to create a compiler for the Oberon0 language, which is used a a running example in Wirth's compiler construction book. We have uploaded our implementation to hackage at: http://hackage.haskell.org/package/oberon0. More information can be found at the wiki: http://www.cs.uu.nl/wiki/bin/view/Center/CoCoCo You may take a look at the various Gram modules to see how syntax is being defined, and at the various Sem modules to see how we use our first class attribute grammars to implement the static semantics associated with the various tasks of the challenge. We hope you like it, and comments are welcome, Marcos Viera Doaitse Swierstra ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Summer school on Applied Functional Programming at Utrecht University; deadline for registration May 15
Again we will teach an "Applied Functional Programming Summer in Haskell" school this year at Utrecht University. In the previous two occasions students were all very happy with the school and we plan to repeat this success this year. The intended audience are prospective master students who have been in contact with Functional Programming, e.g. by taking a general course on programming languages, and want to learn more about Haskell and its typical programming patterns. In the previous two years we have taught an introductory part (advanced bachelor level), an advanced part (beginning master level) and a shared part for both groups. Topics covered are, besides some examples of domain specific languages, also monads, monad transformers, arrows, parser combinators and self-analysing programs, underlying principles, type inferencing, etc. Half of the course time is spent on a larger programming exercise; you can also come with a problem of your own if you want, and get help from the Utrecht University Software Technology group in finding the proper Haskell idioms, tools and libraries, for solving it. Important links: -- our own page where we supply information based on questions asked http://www.cs.uu.nl/wiki/bin/view/USCS2011/WebHome -- the poster you can print and hang somewhere (why not your office door): http://www.cs.uu.nl/wiki/pub/USCS2011/WebHome/USCSpos11.pdf -- the official summerschool site where you can register: http://www.utrechtsummerschool.nl/index.php?type=courses&code=H9 Furthermore we ask for your cooperation to bring this announcement under the attention of potential participants. Best, Doaitse Swierstra PS: apologies if you get this mail more than once ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] A opportunity to lern (parsing huge binary file)
The uu-parsing library support every ata type that is an instance of
Data.Listlike
(http://hackage.haskell.org/packages/archive/ListLike/3.0.1/doc/html/Data-ListLike.html#t:ListLike)
and thus input from Data.Bytestring.Lazy.
A very small starting program can be found below. Note that here we ask for the
error correction during parsin at the end of the processing; that is probably
something you do not want to do, unless you only keep a very small part of the
input in the result. The parsers are online, do not hang on to the input and
thus you essentially only access and keep the part of the result you are
interested in.
We find it a great help to have the error correction at hand since it makes it
a lot easier to debug your parser. Here we just recognise any list of Word8's.
Doaitse
{-# LANGUAGE MultiParamTypeClasses #-}
module ReadLargeBinaryFile where
import Text.ParserCombinators.UU
import Text.ParserCombinators.UU.BasicInstances
import Data.Word
import Data.ByteString.Lazy (ByteString,readFile)
import Prelude hiding (readFile)
type BS_Parser a = P (Str Word8 ByteString Integer) a
instance IsLocationUpdatedBy Integer Word8 where
advance pos _ = pos + 1
p:: BS_Parser [Word8]
p = pList (pSatisfy (const True) (Insertion "" 0 0) )
main filename = doinp <- readFile filename
let r@(a, errors) = parse ( (,) <$> p <*> pEnd)
(createStr 0 inp)
putStrLn ("-- Result: " ++ show a)
if null errors then return ()
else do putStr ("-- Correcting steps:
\n")
show_errors errors
putStrLn "-- "
where show_errors :: (Show a) => [a] -> IO ()
show_errors = sequence_ . (map (putStrLn . show))
interface and that exists for Data.
On 10 mrt 2011, at 16:36, Skeptic . wrote:
>
>
> Hi,
> I finally have an opportunity to learn Haskell (I'm a day-to-day Java
> programmer, but I'm also at ease with Scheme), parsing a huge (i.e. up to 50
> go) binary file. The encoding is very stable, but it's not a flat struct
> array (i.e. it uses flags).
> Different outputs (i.e. text files) will be needed, some unknown at this
> time.
> Sounds to me a perfect "real-world" task to see what Haskell can offer.
>
> Any suggestions at how to structure the code or on which packages to look at
> is welcome.
>
> Thanks.
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Ph.D position, Utrecht University, the Netherlands
=== Vacancy PhD student on Realizing Optimal Sharing in the Functional Language Implementations Utrecht University, The Netherlands. === Within the Software Technology group of the Information and Computing Sciences department of Utrecht University there is a vacancy for a PhD student to work on the efficient implementation of functional languages. The position is funded by NWO, the Netherlands Organization for Scientific Research. - Project summary: Lambda-calculus and term rewriting are models of computation lying at the basis of functional programming languages. Both possess syntactic meta-theories based on analyzing rewrite steps. Unfortunately, naive implementations are inefficient, since subterms are frequently copied. To overcome this problem in both theoretical systems and actual implementations, duplicate work is avoided by using graph-based term representations, in which identical subterms can be (but not always are) shared. The question arises whether graph-representations and their reductions that are optimal in a theoretical sense can also be practical from an implementer's point of view. However, so far it is unclear whether nice theoretical ideas combine well with existing implementation methods. The overall-goal of this project is to answer this question in a back-and-forth communication between theoretical concepts and practical realizations. Starting points are the recent work on the optimal Lambdascope implementation based on context sharing, and the Haskell implementation developed at Utrecht University. One of the open problems is whether the Lambdascope framework can be extended to efficiently represent sets of mutually recursive definitions. Another, whether global program analysis can discover where Lambdascope-based approaches solve problems due to insufficient sharing. If both questions can be solved, we want to combine Lambdascope-based implementations with conventional frameworks, and investigate how efficient the resulting implementations become. The unique combination of the theoretical depth from the Logic department and the implementation skills and compiler infrastructure from the Computer Science department make Utrecht University the optimal surroundings for such a project. - Project leaders are Prof.dr. Doaitse Swierstra and dr. Vincent van Oostrom (principal investigator). The project will be executed in close cooperation between * the Software Technology group (http://www.cs.uu.nl/wiki/Center) of the Information and Computing Sciences department (http://www.cs.uu.nl/ ) * and the Theoretical Philosophy group (http://www.uu.nl/EN/faculties/Humanities/research/researchinstitutes/zeno/research/theoreticalphilosophy/Pages/default.aspx ) of the Philosophy department (http://www.phil.uu.nl/), and between * the more practically oriented PhD student and * the more theory oriented postdoc. - Requirements: Master degree in Computer Science, Logic, or equivalent. Good knowledge of functional programming, and several advanced computer science techniques. Knowledge of lambda-calculus implementations, Haskell, and compiler construction will be useful. Both theory and software development based on this should appeal to you. Terms of employment: the PhD student should start as soon as possible, but no later than January 1, 2010. The position is for four years (after one year there will be an evaluation), full-time. Gross salary starts with € 2042,-- per month in the first year and increases to € 2612,-- in the fourth year of employment. The salary is supplemented with a holiday bonus of 8% and an end-of-year bonus of 3%. In addition we offer: a pension scheme, partially paid parental leave, facilities for child care, flexible employment conditions in which you may trade salary for vacation days or vice versa. Conditions are based on the Collective Employment Agreement of the Dutch Universities: http://www.vsnu.nl/Workstudy/Universities-as-employers-/Collective-Labour-Agreement.htm More information: * about the project can be found on http://www.cs.uu.nl/wiki/bin/view/Center/OptimalSharing * about the Software Technology group on http://www.cs.uu.nl/wiki/Center * about the Information and Computing Sciences department on http://www.cs.uu.nl/ * about this vacancy can be obtained from Doaitse Swierstra (doai...@cs.uu.nl , +31 6 4613 6929). Send your application in pdf (or another non-proprietary format) to mailto:sciencep...@uu.nl with a cc to mailto:doai...@cs.uu.nl. on or before Se
[Haskell] ANNOUNCE: uu-parsinglib-2.0.0
The new uu-parsinglib package is the first version of the new parsing combinator library package from Utrecht University. Features: - online result construction - much simpler internals than the combinators in the uulib package, because of the availabilty of GADT's and other extensions which have become available over the last ten years - error correction - parsing ambiguous grammars (even with online result construction), provided one is willing to label a non-terminal as ambiguous - monadic interface. We solve a problem in the "Polish parsing" monadic construct, which could lead to a black hole in combination with error correction - instead of trying to make everything a parameter we rely a bit more on the user to provide some basic functions, based on given canonical implementations - no abstract interpretation yet, as found in the original uulib package. So if you have large grammars with many alternatives the uulib package is to be preferred - extensive motivation and documentation found in a technical report available from the web page Cons: - the package is likely to change and be extended in the near future as we incorprorate more of the uulib library into the new package Pros: - suggestions are welcome Doaitse Swierstra ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: ChristmasTree 0.1 (excuses for second attempt)
We are pleased to announce the availability of the package
"ChristmasTree", which contains the code associated with our paper at
the last Haskell symposium:
@inproceedings{1411296,
author = {Marcos Viera and S. Doaitse Swierstra and Eelco Lempsink},
title = {Haskell, do you read me?: constructing and composing
efficient top-down parsers at runtime},
booktitle = {Haskell '08: Proceedings of the first ACM SIGPLAN
symposium on Haskell},
year = {2008},
isbn = {978-1-60558-064-7},
pages = {63--74},
location = {Victoria, BC, Canada},
doi = {http://doi.acm.org/10.1145/1411286.1411296},
publisher = {ACM},
address = {New York, NY, USA},
}
The name of the package stands for:
"Changing Haskell's Read Implementation Such That by Manipulating
Abstract Syntax Trees it Reads Expressions Efficiently"
which, given the time of year, seems appropriate.
Feel free to download and unpack this "present" at what for the Dutch
is called "Sinterklaasavond" (http://en.wikipedia.org/wiki/Sinterklaas),
Arthur Baars
Marcos Viera
Eelco Lempsink
Doaitse Swierstra
PS: the package uses our library supporting transformation of typed
abstract syntax, which we placed in a separate package TTTAS
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] [Announce] TTTAS (with excuse for second attempt to post)
We are pleased to announce the availability of the package "TTTAS",
which contains the code associated with our paper at the coming TLDI
workshop:
[EMAIL PROTECTED] BSV09,
author = {Arthur Baars and S. Doaitse Swierstra and Marcos Viera},
title = {Typed Transformations of Typed Abstract Syntax},
booktitle = {TLDI '09: fourth ACM SIGPLAN Workshop on Types in
Language Design and Implementation},
year = {2009},
location = {Savannah, Georgia, USA},
publisher = {ACM},
address = {New York, NY, USA},
}
For more information see: http://www.cs.uu.nl/wiki/bin/view/Center/TTTAS
Arthur Baars
Marcos Viera
Doaitse Swierstra
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announce: TTTAS
We are pleased to announce the availability of the package "TTTAS",
which contains the code associated with our paper at the coming TLDI
workshop:
[EMAIL PROTECTED] BSV09,
author = {Arthur Baars and S. Doaitse Swierstra and Marcos Viera},
title = {Typed Transformations of Typed Abstract Syntax},
booktitle = {TLDI '09: fourth ACM SIGPLAN Workshop on Types in
Language Design and Implementation},
year = {2009},
location = {Savannah, Georgia, USA},
publisher = {ACM},
address = {New York, NY, USA},
}
For more information see: http://www.cs.uu.nl/wiki/bin/view/Center/TTTAS
Arthur Baars
Marcos Viera
Doaitse Swierstra
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: ChristmasTree 0.1
We are pleased to announce the availability of the package
"ChristmasTree", which contains the code associated with our paper at
the last Haskell symposium:
@inproceedings{1411296,
author = {Marcos Viera and S. Doaitse Swierstra and Eelco Lempsink},
title = {Haskell, do you read me?: constructing and composing
efficient top-down parsers at runtime},
booktitle = {Haskell '08: Proceedings of the first ACM SIGPLAN
symposium on Haskell},
year = {2008},
isbn = {978-1-60558-064-7},
pages = {63--74},
location = {Victoria, BC, Canada},
doi = {http://doi.acm.org/10.1145/1411286.1411296},
publisher = {ACM},
address = {New York, NY, USA},
}
The name of the package stands for:
"Changing Haskell's Read Implementation Such That by
Manipulating Abstract Syntax Trees it Reads Expressions Efficiently"
which, given the time of year, seems appropriate.
Feel free to download and unpack your present at what for the Dutch is
called "Sinterklaasavond" (http://en.wikipedia.org/wiki/Sinterklaas),
Arthur Baars
Marcos Viera
Eelco Lempsink
Doaitse Swierstra
PS: the package uses our library supporting transformation of typed
abstract syntax, which we placed in a separate package TTTAS
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Software Engineering and Functional Programming (with Haskell)
There have been a series on workshop about the commercial use of functional programming. You can find the slides of presentations at: http://cufp.galois.com/ Some companies even use knowledge of FP to filter out the good applicants ;-}} What is your instructor's opinion about that? Doaitse Swierstra On Apr 3, 2007, at 11:40 PM, Paul Johnson wrote: Sukit Tretriluxana wrote: Unfortunately my instructor disagrees that the topic is relevant. In his response, he mentioned that he will accept the topic only if I can prove the following. Haskell has been around for quite a while. To convince me, you'll have to give me references that I can read about nontrivial examples of significant software systems already built exclusively with Haskell which includes the software engineering principles applied in this environment and the software measures that demonstrate the claims. I welcome the opportunity for you to provide me with such in-depth research references to support your viewpoint. For FP in general you could look at Erlang. Its an functional programming language used for telecom systems. www.erlang.org has a bunch of references, including some very significant software systems. I would suggest broadening your scope to include Erlang, and then look at some of the issues with Erlang and the way in which Haskell purity helps, like deforestation. In Erlang you can write a function as a pipeline of maps, filters and folds, but it tends to be very inefficient because all the intermediate data structures have to be created. In Haskell the compiler can strip out these structures because the order of execution does not matter. I know that Haskell has been used for chip design software. Simon Peyton-Jones' recent paper on the history of Haskell has some references. Paul. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GADT: call for proper terminology
I would prefer notation like: data Parser a | Alt (Parser a) (Parser a) | Map ( b -> a) (Parser b) | Succ a Parser (a,b) | Seq (Parser a) (Parser b) Parser String | Lit (String -> Bool) Parser [a]| Many (Parser a) This takes away the noise in the heading of the current GHC notation (which is just plain confusing), and enables e.g. grouping of common alternatives, Doaitse Swierstra On Oct 11, 2006, at 11:42 PM, Lennart Augustsson wrote: Well, Kent Petersson and I proposed them as an addition to Haskell in 1994, so they are not that new. :) -- Lennart http://web.cecs.pdx.edu/~sheard/papers/silly.pdf On Oct 11, 2006, at 09:47 , Paul Hudak wrote: Lennart Augustsson wrote: Well, I think the GADT type definition syntax is the syntax data type definitions should have had from the start. Too bad we didn't realize it 15 years ago. -- Lennart I agree! In my experience teaching Haskell, the current syntax is a bit confusing for newbies, and for years I've been telling students, "It really means this: ..." and then I write out a syntax more like GADT's. I also think that if we had adopted this syntax from the beginning, GADT's would have been "discovered" far sooner than now. -Paul ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] open assistant professorship at Utrecht University, Software Technology
We have an open 5 year position for an assistant professor. Current areas of interest are: - domain specific embedded languages (especially in the form of combinator languages) - programming language design and implementation - generic programming techniques - tools and methods for building complex systems out of a large number of artefacts in a controlled way - program verification - systems for generating informative feedback to users in the case of inconsistencies in specifications - advanced type systems and their implementation - software generation We strongly believe that the functional programming paradigm is an excellent starting point for many new developments in the above mentioned areas. In our research we try to identify real problems, to find solutions for them, to formalise these, and to build tools in order to convey the solutions to the problem holders. Thus we try to combine sound principles for solving real-life problems. Given the increased pressure on our finances cooperation with industry is of growing importance, which will also hold for this position. Further details can be found at: http://www.cs.uu.nl/vacatures/en/62612.html Doaitse Swierstra ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Lrc status
Lrc was developed in my group, and was taken home by Joao Saraiva, after finishing his Ph.D. thesis. We are not maintaining it anymore, since we have switched to our new attribute grammar system: http://www.cs.uu.nl/wiki/HUT/AttributeGrammarSystem For building editing environments we have the experimental Proxima system, with which one can build editors in a reasonably easy way, although some effort is required: http://www.cs.uu.nl/wiki/Center/Proxima My hope is to ever merge them again. Doaitse On Jul 11, 2006, at 9:55 PM, Robert Dockins wrote: Does anyone have any information about the current status of Lrc? Has it ever been released? Does it live somewhere else now? The homepage is apparently: http://www.di.uminho.pt/~jas/Research/ LRC/lrc.html It has a bunch of "coming soon" links, but the page hasn't been updated since about 2002. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Trying On Learn Haskell Web Server
You may find some useful code (that is still in need of beautification, but on the other hand: it works) at: http://www.cs.uu.nl/wiki/WebFunctions Doaitse Swierstra On 2006 mrt 03, at 20:30, Aditya Siram wrote: Hi all, I am former imperative programmer (Java/C/Python) I have recently discovered Haskell and read through "Yet Another Haskell Tutorial" (the best I have found) and "Tackling The Awkward Squad". This paper mentions a Haskell Web Server (HWS) but I am not able to find the source. Where can I find the source? Has this code been updated since the paper was written? Can it be compiled and run on a recent version of GHC?Hugs? I would like to use it as an example program to teach myself Haskell. Thanks... Deech ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Scripting language: is Haskell a good choice?
You have some way to go. It may be helpful to take a look at our course on compiler construction, in which we explain how to use the various tools we have built to build compilers and interpreters. I suggest you download the code and the tools and the lecture notes, and start to try to make some of the exercises. Our students somehow manage ;-} http://www.cs.uu.nl/wiki/Ipt/WebHome Doaitse Swierstra On 2006 jan 25, at 17:23, Bulat Ziganshin wrote: Hello Jules, Wednesday, January 25, 2006, 12:29:48 AM, you wrote: JJ> I would like to create a scripting language, similar to Ruby, Perl and JJ> Python. Pugs, written in Haskell, is a Perl6 implementation. Is Haskell a JJ> good choice for me? yes, if you ready to learn many new things. Haskell is very different from non-FP languages JJ> I have no experience with Haskell (yet), but I like the JJ> concept of functional programming. Because Haskell will probably be too slow JJ> for the final implementation, I will have to rewrite it in C or maybe D. i'm not sure that you will not change your plans. may be sometime you will prefer to rewrite existing Haskell implemetations just to make your interpreter faster ;) JJ> Haskell can be very useful as a test/prototype implementation, where speed JJ> is not very important. But will I be able to create a clean, and easy to JJ> understand implementation in Haskell? if speed is not main goal - definitely yes JJ> The scripting language will be object JJ> oriented, and imperative. Is that a problem because Haskell is functional, JJ> or is there be an obvious and nice way to implement an imperative scripting JJ> language? it's no problem at all JJ> The language is very dynamic, and the source-tree needs to be in memory JJ> because it is modifiable at run-time. JJ> Would it be good to do this in Haskell, and port it to C if I like the JJ> implementation, or start in C? Keep the parser/lexer for the source code in JJ> Haskell, but port only the interpreter to C? yes, you can use C and Haskell together. but C code can't walk Haskell data structures, so such co-working will need some manual work JJ> What would be a good place to start? I am reading Yet Another Haskell JJ> tutorial, and I've read the first 6 of two dozen lessons in Haskell. What to JJ> do next, practice/read more/start with the implementation of the scripting JJ> language? read about parsec library and start :) this lib already contains several examples of implementing small FP and imperative languages, each implemetation is just 5-10 kb in size -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Can anyone help me with partition numbers?
Or (since we started to do someone's homework anyway) generate 0 = [[]] generate n = [x:rest | x <- [1..n], rest <- generate (n-x)] Doaitse Swierstra On 2005 nov 25, at 10:29, Tomasz Zielonka wrote: On Thu, Nov 24, 2005 at 05:52:23PM +0100, Jan van Eijck wrote: Like so: generatePs :: (Int,[Int]) -> [[Int]] generatePs (n,[]) = [take n (repeat 1)] generatePs (n,(x:xs)) = (take n (repeat 1) ++ (x:xs)) : generatePs (pack (x-1) ((n +x),xs)) where pack :: Int -> (Int,[Int]) ->(Int,[Int]) pack 1 (m,xs) = (m,xs) pack k (m,xs) = if k > m then pack (k-1) (m,xs) else pack k (m-k,k:xs) parts :: Int -> [[Int]] parts n | n < 1 = error "part: argument <= 0" | n == 1= [[1]] | otherwise = generatePs (0,[n]) How about a shorter version? part :: Integer -> [[Integer]] part = gen 1 where gen m 0 = [[]] gen m n = [ x:xs | x <- [m..n], xs <- gen x (n - x) ] Best regards Tomasz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell based web server?
On: http://www.cs.uu.nl/wiki/WebFunctions/ you may find some code that could get you started. It includes a small webserver based on Simon Marlow's design, Doaitse Swierstra On 2005 nov 13, at 21:29, Tomasz Zielonka wrote: On Sat, Nov 12, 2005 at 01:10:03PM -0800, Gregory Woodhouse wrote: I've been reading the article "Tackling the Awkward Squad" by Simon Peyton Jones (and find it very readable and useful, BTW). I wonder if the HTTP/1.1 server referred to in this article is available on the web. I think you can get it from the fptools CVS repository. You will find instructions on the GHC site - http://www.haskell.org/ghc/. It's pretty old and because it uses non-standard extensions, you may have some problems with newer versions of GHC. If you do, try with hws-wp (http://www.mdstud.chalmers.se/~md9ms/hws-wp/). If not, where else can I look for examples of TCP/IP based server applications written in Haskell? HTTP client library written in Haskell: http://www.haskell.org/http/ A chat client written in Haskell: http://repetae.net/john/computer/ginsu/ Best regards Tomasz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Latex and Bibtex
At least I can provide you with a bibtex parser written using the
Utrecht Parser Combinators. As you will see from the text the bibtex
format is actually quite intricate.
Doaitse Swierstra
-- $Header:
/data/cvs-rep/uust/examples/bibtex-parser/BibtexParser.hs,v 1.8
2002/11/08 12:48:00 uust Exp $
-- $Name: $ (version name)
{- Fast, Error Correcting Parser Combinators; Version: see Version
History in same directory.
- Copyright: S. Doaitse Swierstra
Department of Computer Science
Utrecht University
P.O. Box 80.089
3508 TB UTRECHT
the Netherlands
[EMAIL PROTECTED]
-}
{- file: bibtex6.hs
A parser for BibTeX
using the UU parsing combinators
Piet van Oostrum, Atze Dijkstra, Doaitse Swierstra (April 22, 2001)
-}
module Main where
import UU.Parsing
import UU.Parsing.CharParser
import UU.Scanner.Position
import System
import Char
showMessage (Msg exp pos action) =
"\nParse error: " ++ show pos ++ "\n" ++
actionMessage ++ "\n"
where actionMessage = case action of
Insert s -> "expecting: " ++ show exp ++
"\nrepaired by inserting " ++ show s
Delete s -> "expecting: " ++ show exp ++
"\nrepaired by deleting unexpected
symbol " ++ show s
Other m -> m
parsebib filename -- e.g. parsebib "btxdoc.bib"
= do res <- parseFile showMessage pBibData filename
putStrLn ("\nResult:" ++ show (length res) ++ " bib items were
parsed")
main
= do args <- getArgs
if null args
then putStr "BibtexParser \n"
else parsebib (head args)
--
===
-- = DATA TYPES
==
--
===
type BibParser = AnaParser Input Pair Char Pos
type BibData = [ BibEntry]
data BibEntry = Entry String (String, [Field]) -- kind keyword
fieldlist
| Comment String
| Preamble [ValItem]
| StringDef Field
deriving Show
type Field= (String, [ValItem])
data ValItem = StringVal String
| IntValInt
| NameUse String
deriving Show
--
===
-- = PARSERS
=
--
===
pBibData= pChainr ((\ entry _ right -> entry:right) <$> pBibEntry)
( [] <$ pList (allChars `pExcept` "@"))
pBibEntry
= ( Entry <$ pAt <*> pName <*> pOpenClose (
pKeyName <* pSpec ','
<+>
pListSep_ng pComma pField
<* (pComma
`opt` ' '))
<|> Comment <$ pAt <* pKey "comment" <*> ( pCurly (pList
(allChars `pExcept` "}"))
<|> pParen (pList
(allChars `pExcept` ")"))
)
<|> Preamble <$ pAt <* pKey "preamble" <*> pOpenClose pValItems
<|> StringDef <$ pAt <* pKey "string" <*> pOpenClose pField
)
pField :: BibParser (String, [ValItem])
pField = pName <* pSpec '=' <+> pValItems
pValItems = pList1Sep (pSpec '#') ( StringVal <$> pString
<|> int_or_name <$> pName
)
where int_or_name s = if all isDigit s
then IntVal.(read::String->Int) $ s
else NameUse s
--
===
-- = LEXICAL STUFF
===
--
===
pLAYOUT :: BibParser String
pLAYOUT = pList (EOr [] `setfirsts` pAnySym " \t\r\n")
pSpec c = pSym c <* pLAYOUT
pParen p = pPacked (pSpec '(') (pSpec ')') p
pCurly p = pPacked (pSpec '{') (pSpec '}') p
pOpenClose p = pParen p <|> pCurly p
pComma= pCostSym 4 ',' ',' <* pLAY
Re: [Haskell] Implicit parallel functional programming
In 1989 my first Ph.D. student. matthijs kuiper, defended his thesis "Paralell Attribute Gramar Evaluation". On emight see ag's as a limited form of functional programming. The conclusions were: - in many grammars sufficient paralellism can be detected using global flow anaysis techniques - when building paralell implementations we get nice speedups based on the number of processors - unfortunately the communication overhead makes you loose speed, so in the end you are not much better off, and actually you have nice speedups on the introduced overhead, which brings you back where you started Another point to bear in mind is that the Dutch government 20 years ago funded a quite large project aiming at parallell implementation of functional programms. The main result of this project is a quite good sequential implementation of the functional language Clean. Even further back, in the sixties, Burrough's (yes, the companyy with this beautiful Algol-60 based specilaised hardware and operating system) has spent a lot of money on trying to construct paralle reduction machines (and many others later too, especially in Japan) trying to exploit all this implicitly available paralellism. All these projects failed beacuse Moore's law overtook their results. Doaitse Swierstra On 2005 jan 20, at 3:13, Ben Lippmeier wrote: I thought the "lazy functional languages are great for implicit parallelism" thing died out some time ago - at least as far as running the programs on conventional hardware is concerned. Designing an algorithm that breaks apart a "sequential" lazy program into parallel chunks of the appropriate size is **HARD** (with double asterixes). The time and space behavior of a lazy program is complex enough for the _programmer_ to reason about, let alone an automated analysis - which has no knowledge of what the program is actually trying to do. I think a more likely approach lies in the direction of the so called "parallel strategies". If you haven't already, I would strongly suggest reading: Algorithm + Strategy = Parallelism, 1998, PW Trinder, et al. You can get this paper from Simon Peyton Jones's homepage. Also, at the end of Hans Wolfgang-Loidl's thesis he develops a granularity analysis for a Haskell subset - one of the first steps in any kind of implicit parallelism. It's a pretty good effort, but at the end of it all it still relies on a pre-existing table of information about recursive functions. I think that these kind of analyses tend suffer from uncomputability problems more than most. If you've still got your heart set on implicit parallelism, then there's a (very slow) simulator you might want to poke around with. I wrote it based around Clem Baker-Finch's "Abstract machine for parallel lazy evaluation", which supports fully speculative implicit parallelism. There's a link to it on my homepage at http://cs.anu.edu.au/people/Ben.Lippmeier Keean Schupke wrote: I have to say I disagree... I feel Haskell is highly suited to implicit parallel execution... The key to "implicit" parallelisation is that it is implicit - not explicit, so the programmer should feel like they are programming a sequential language. If we can assume little memory access penalties for threads running on other CPUs (shared cache model), it seems to be a matter of putting locks on the right structures, and allowing any worker-thread to take the next function ready to run from the scheduler. Keean. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
new version of Parser Combinators and Syntax Macros's (beta)
Title: new version of Parser Combinators and Syntax Macros's At: http://www.cs.uu.nl/groups/ST/Software/UU_Parsing you will find the latest/greatest version of our combinators, that are: - faster (faster than Parsec) - correct much faster - compute results lazily, and produce error messages online in the IO monad while parsing (using unsafeInterleavedIO) - are compatible with the syntax macro mechanism we have implemented (beta): http://www.cs.uu.nl/~arthurb/index.html Doaitse -- -- __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ tel: +31 30 253 3962 fax: +31 30 251 3791 mobile: +31 6 2880 1680 __
new version of parser combinators
We have been working hard on new versions of the Parser Combinators
and AG system, with the following improvements:
even better error repairs
much faster and simpler basic parsing machine
permutation (of different types) and list combinators
extensive reporting about repairs made and what was expected
the possibility to manipulate your own state during parsing
and result construction, using classed based (like monads) interfaces
As an example of the permutation combinators we parse a permutation
of three elements:
1) a list of 'a's
2) a 'b'
3) an optional 'c'
which is described by:
permtest :: Parser Char (String, Char, Char)
permtest = permute $ (,,) ~$~ pList (pSym 'a') ~*~ pSym 'b' ~*~ pOptSym 'c'
pOptSym :: Char -> Parser Char Char
pOptSym x = pSym x <|> pSucceed '_'
which we try on several inputs resulting in:
t permtest "acb"
Result:
("a",'b','c')
t permtest "cdaa"
Errors:
Symbol 'd' before 'a' was deleted, because 'b' or ('a')* was expected.
Symbol 'b' was inserted at end of file, because 'a' or 'b' was expected.
Result:
("aa",'b','c')
t permtest "abd"
Errors:
Symbol 'd' at end of file was deleted, because 'c' or eof was expected.
Result:
("a",'b','_')
t permtest ""
Errors:
Symbol 'b' was inserted at end of file, because 'c' or 'b' or ('a')*
was expected.
Result:
("",'b','_')
The manual is still of an earlier version and will be adapted soon.
As an example of the combinators we provide a parser for bibtex
files, that returns the repairs made to the erroneous entries (as
far as we understand the bibtex format).
I hope this is useful to you,
Doaitse Swierstra
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: strictness question
Thanks for the prompt reply. Hugs apparently is more lazy and performs all the matching lazily, and that really makes a difference in my case. Doaitse At 8:11 AM -0800 3/2/01, Simon Peyton-Jones wrote: >Strange. You don't supply a complete program, so it's hard to >test. > >Nevertheless, the Haskell Report (Sect 3.12) specifies that >a let adds a single twiddle. Thus > > let (x, (y,z)) = e in b > >means > > let x = case e of (x,(y,z)) -> x >y = case e of (x,(y,z)) -> y >z = case e of (x,(y,z)) -> z > in b > >And that is what GHC implements. You get something different if you >add twiddles inside: > > let (x, ~(y,z)) = e in b > >means > let x = case e of (x,_) -> x >y = case e of (_,(y,_)) -> y > etc > >Adding more twiddles means less eager matching. I don't know whether >Hugs implements this. > >Simon > >| -Original Message- >| From: S. Doaitse Swierstra [mailto:[EMAIL PROTECTED]] >| Sent: 01 March 2001 11:26 >| To: [EMAIL PROTECTED] >| Subject: strictness question >| >| >| I ran into a difference between GHC and Hugs. The following code: >| >| f (P p) ~(P q) = P (\ k -> \inp -> let (((pv, (qv, r)), m), st) = >| p (q k) inp >|in (((pv qv , r ), m), st)) >| >| runs fine with Hugs but blows up with GHC, whereas: >| >| f (P p) ~(P q) = P (\ k -> \inp -> let ~(~(~(pv, ~(qv, r)), m), >| st) = p (q k) inp >|in (((pv qv , r ), m), st)) >| >| runs fine with GHC too. >| >| From the Haskell manual I understand that pattern matching >| in "let"'s >| should be done lazily, so the addition of a collection of ~'s should >| not make a difference. Am I right with this interpretation? >| >| A possible source of this problem may be origination from the smarter >| GHC optimiser, but in that case the optimiser is not doing its work >| well. >| >| Doaitse Swierstra >| >| >| >| >| -- >| __ >| >| S. Doaitse Swierstra, Department of Computer Science, Utrecht >| University >|P.O.Box 80.089, 3508 TB UTRECHT, the >| Netherlands >|Mail: mailto:[EMAIL PROTECTED] >|WWW: http://www.cs.uu.nl/ >|PGP Public Key: >http://www.cs.uu.nl/people/doaitse/ >tel: +31 (30) 253 3962, fax: +31 (30) 2513791 >__________ > >___ >Haskell mailing list >[EMAIL PROTECTED] >http://www.haskell.org/mailman/listinfo/haskell -- __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
strictness question
I ran into a difference between GHC and Hugs. The following code: f (P p) ~(P q) = P (\ k -> \inp -> let (((pv, (qv, r)), m), st) = p (q k) inp in (((pv qv , r ), m), st)) runs fine with Hugs but blows up with GHC, whereas: f (P p) ~(P q) = P (\ k -> \inp -> let ~(~(~(pv, ~(qv, r)), m), st) = p (q k) inp in (((pv qv , r ), m), st)) runs fine with GHC too. From the Haskell manual I understand that pattern matching in "let"'s should be done lazily, so the addition of a collection of ~'s should not make a difference. Am I right with this interpretation? A possible source of this problem may be origination from the smarter GHC optimiser, but in that case the optimiser is not doing its work well. Doaitse Swierstra -- __________ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GHC for Darwin?
At 3:59 PM -0800 12/20/00, Ashley Yakeley wrote: >Are there any plans to port GHC to Darwin? Darwin is a FreeBSD-variant >that runs on the PowerPC processor. ><http://www.opensource.apple.com/projects/darwin/>. > >I was going to compile it myself before I remembered that compilers do >platform-specific code-generation. Duh. > >-- >Ashley Yakeley, Seattle WA > > >___ >Haskell mailing list >[EMAIL PROTECTED] >http://www.haskell.org/mailman/listinfo/haskell Atze Dijkstra (mailto:[EMAIL PROTECTED]) is working on a port of the GHC to MacOS X. He has reached the state where he managed to compile some programs (e.g. our attribute grammar system and combinator libraries). Doaitse Swierstra -- __________ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Extensible data types?
It is exactly for reasons like these that we developped our small attribute grammar system: http://www.cs.uu.nl/groups/ST/Software/UU_AG/index.html Doaitse Swiesrtra At 7:21 AM -0200 10/20/00, José Romildo Malaquias wrote: >Hello. > >I am back with the issue of extensible union types. Basically >I want to extend a data type with new value constructors. >Some members of the list pointed me to the paper > >"Monad Transformers and Modular Interpreters" >Sheng Liang, Paul Hudak and Mark Jones > >The authors suggest using a type constructor to express >the disjoint union of two other types: > >data Either a b = Left a | Right b > >which indeed is part of the Haskell 98 Prelude. Then they introduce >a subtype relationship using multiparameter type classes: > >class SubType sub sup where > inj :: sub -> sup -- injection > prj :: sup -> Maybe sub -- projection > >The Either data type consructor is then used to express >the desired subtype relationshipe: > >instance SubType a (Either a b) where > inj = Left > prj (Left x) = Just x > prj _ = Nothing > >instance SubType a b => SubType a (Either c b) where > inj = Right . inj > prj (Right x) = prj x > prj _ = Nothing > >The authors implemented their system in Gofer, due to >restrictions in the type class system of Haskell. >But now that there are Haskell extensions to support >multiparametric type classes, that could be implemented >in Haskell. > >The above code fails to type check due to instances >overlapping. Hugs gives the following error message: > >ERROR "SubType.hs" (line 10): Overlapping instances for class "SubType" >*** This instance : SubType a (Either b c) >*** Overlaps with : SubType a (Either a b) >*** Common instance : SubType a (Either a b) > >(I did not check Gofer, but is there a way to solve these >overlapping of instances in it?) > >So this is scheme is not going to work with Haskell (extended >with multiparameter type classes). > >I would like hear any comments from the Haskell comunity on >this subject. Is there a workaround for the overlapping instances? > >Regards. > >Romildo >-- >Prof. José Romildo Malaquias <[EMAIL PROTECTED]> >Departamento de Computação >Universidade Federal de Ouro Preto >Brasil > >___ >Haskell mailing list >[EMAIL PROTECTED] >http://www.haskell.org/mailman/listinfo/haskell -- __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Parsing include files
At 4:03 AM -0700 8/21/00, Julian Seward (Intl Vendor) wrote: >| Since compilers are one of the areas where everyone agrees that FPLs >| are the right tool for the job, there should be a standard pattern to >| deal with include files. Am I missing something essential? > >No. Parsec is an excellent library, but I think there's a >design flaw in that you can't write your own lexer. The >"traditional" thing to do is write a lexer, which can deal >with include files, etc, as you want. Parsec would then >be presented with a list of tokens, rather than a list of >chars as at present. Doing this would also avoid the hassle >of having to remember to skip whitespace here, there and >everywhere, which cluttered up a parser I wrote recently >with parsec. > >Daan, what do you say? > >Other than that, Parsec is really good. I particularly liked >the error reporting stuff. > >J You will find a rather complete lexer at: http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/#scanner which does recursive imports etc. An example of its use can be found in the attribute grammar system and the small example compiler in the same place. You may want to adapt the scanner to your own needs. It may be tempting to try to combine the scanning and the parsing in one go, but you may wonder why there are separate tools like YACC and Lex for those different tasks. The lexer was written to be used in conjunction with the error correcting library you will find there too, but is in no way tied to it and might be used with other libraries just as well. We are about to release a new version of our combinators, with a library of scanner constructing combinators. If you are prepared to live without some documentation I can make the new files available. Doaitse Swierstra -- ______ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __
new version of: Fast, Error Correcting Parser Combinators
I have been polishing the ,,"Fast, Error Correcting Parser Combinators", and as a result they are now so much faster (for some applications more than three times) that you may consider downloading the newest version from http://www.cs.uu.nl/groups/ST/Software/Parse/ I also fixed a couple of small bugs in the scanner module and added some "Unsafe and Dirty Combinators" that allow you to interfere with the correction process. You should probably not use these if you do not understand the correction process underlying the combinators. Doaitse Swierstra __________ S. Doaitse Swierstra, Department of Computer Science, Utrecht University (Prof. Dr)P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __
propaganda 1: Fast, Error Correcting Parsing Combinators
,,Fast, Error Correcting Parsing Combinators (Updated: Aug-19-1999) I have placed a completely new set of parser combinators on the net at http://www.cs.uu.nl/groups/ST/Software/Parse/. I consider my old LL(1) combinators obsolete by now. ,,Why would you like to use these Combinators? Have you always been intrigued by Combinator Parsers because they allow you to: use the abstraction, typing and naming mechanism of Haskell create parsers dynamically keep life simple by not having to run a separate program in order to generate a parser work with (limited forms of) infinite grammars but did you not like: expensive backtracking implementations bad error reporting and error recovery properties my previous combinators because they required the grammar to be LL(1) spurious shift-reduce conflicts reported by other parser generating tools then why not use my new parsing combinators? (Provided you have access to the universal type extensions, as present in e.g. Hugs) My parser combinators perform (without the programmer having to worry) left-factorisation of the underlying grammar. The only restriction on the grammar is that it should not be (neither directly nor indirectly) left-recursive! If it is, you will soon find out by running out of stack space. A paper describing the combinators is in the works. Although the title above uses the word "deterministic", this may be a bit misleading, since it is well known fact that not all context free languages can be parsed deterministically. I hope this software is useful to you. If you have any comments do not hesitate to contact me. Doaitse Swierstra mailto:[EMAIL PROTECTED] ___ ___ S. Doaitse Swierstra, Department of Computer Science, Utrecht University (Prof. Dr)P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __
propaganda 2: Fast, Multi Layout Pretty Printing Combinators
,,Fast, Multi Layout Pretty Printing Combinators (Updated: Aug-19-1999) I have placed a completely new version of our parser combinators on the net at http://www.cs.uu.nl/groups/ST/Software/PP/ Why would you like to use these Combinators? Have you always been intrigued by Pretty Printing Combinators because they allow you to: specify pretty printers easily create pretty printers dynamically but did you not like: the fact that alternative layout were difficult to specify or expensive to compute then why not use our new pretty printing combinators? I hope this software is useful to you. If you have any comments do not hesitate to contact us. Doaitse Swierstra mailto:[EMAIL PROTECTED],[EMAIL PROTECTED] __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University (Prof. Dr)P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __
propaganda 3: Advaced Functional Programming 3 Proceedings
,,AFP3 Proceedings
You may not have noticed, but Springer has published
the proceedings of the AFP3:
,,@book{AFP3,
author= {Doaitse Swierstra and Pedro Henriques and Jos\'{e}
Oliveira},
title = {Advanced Functional Programming, Third International
School, AFP'98},
publisher = {Springer},
year = {1999},
isbn = {9 783540 662419},
series= {LNCS},
number= {1608}
}
I quote from the preface:
In this volume you will find the lecture notes corresponding to the
presentations given at the 3rd summer school on
Advanced Functional Programming, held in Braga, Portugal from
September 12--19, 1998.
This school was preceded by earlier instances in Bastad (1995, Sweden,
LNCS
925) and Portland (1996, USA, LNCS 1110). The goal of this series of
schools is
to bring recent developments in the area of functional programming to
a large group of students. The notes are published in order to enable
individuals, small study groups, and lecturers to become acquainted
with recent work in the fast developing area of functional
programming.
What makes this instance of the school particularly interesting is
that all lectures introduced useful software, that was used by the
students in the classes to get hands-on experience with the subjects
taught. We urge readers of this volume to download the latest version
of this
software from the Internet and try to do the exercises from the
text themselves; the proof of the program is in the typing.
The first lecture, on ,,Sorting
Morphisms, serves as a gentle
introduction to the things to come. If you have always been afraid of
the word ``morphism'', and you have been wondering what catamorphisms,
anamorphisms, hylomorphims and paramorphims were about, this is the
paper to read first; you will discover that they are merely names for
recursion patterns that occur over and over again when writing
functional
programs. The algorithms in the paper are all about sorting, and
since
you are likely to know those algorithms by heart already, seeing
them structured and analyzed in a novel way should serve as a
motivation to
read on with the second lecture.
The second lecture, on ,,Generic
Programming, is almost a book in a
book. The notes can be seen as the culminating point of the
STOP-project, that was sponsored by the Dutch government at the end of
the 80's and the beginning of the 90's; its overall goal was the
development of a calculational way of deriving programs. The project
has provided deeper insight into real functional programming
and into the theory behind many things commonly written by functional
programmers. One of the main achievements of the project has been
to make people aware of the fact that many algorithms can be described
in a data-independent way. The PolyP system introduced in these notes
is one of the translations to the Haskell-world of this theoretical
underpinning.
The third lecture, on ,,Generic
Program Transformation, can also
be seen as an application of the theory introduced in lecture two.
Many efficiency-improving program transformations can be
performed in a mechanical way, and these would not have been possible
without
insight into the correctness of such transformations gained in the
lecture on Generic Programming.
The fourth lecture, on ,,Designing
and Implementing Combinator
Languages, introduces an easy to write formalism for writing
down the
catamorphisms introduced in earlier chapters. It is shown how quite
complicated catamorphisms, that at first sight seem rather forbidding
by making extensive use of higher order domains, can actually be
developed in a step-wise fashion, using an attribute grammar view; it
is furthermore shown how to relate this way of programming with
concepts from the object-oriented world thus making clear what the
strengths and weaknesses of each world are.
The fifth lecture, titled ,,Using
MetaML: a Staged Programming
Language, introduces the concept of partial evaluation; it
serves as
another instance of the quest for ``the most generic of writing
programs without having to pay too much''. The staging techniques
show how costs that were introduced by adding extra levels of
abstraction, may be moved from run-time to compile-time.
It has been common knowledge to users of modern functional languages
that the type system can be a great help in shortening programs and
reducing errors. In the extreme one might see a type as a predicate
capturing the properties of any expression with that type. In the
sixth lecture on ,,Cayenne -- Spice
up your Programming with
Dependent Types it is shown in what direction functional
languages are
most likely to develop, and what may be expected of the new type
systems to
b
Re: Int vs Integer
At: http://www.cs.uu.nl/groups/ST/haskell.pdf you may find a pdf version of the current haskell 1.4 report. You may read and browse through it with the Acrobat redaer. Some of you might find this more pleasing than the html version, Doaitse Swierstra -- PLEASE NOTE THAT THE DOMAIN NAME ruu HAS BEEN CHANGED TO uu I HONESTLY APOLOGIZE FOR THE INCONVENIENCES THIS CAUSES TO YOU, BUT IT HAS BEEN ENFORCED UPON US BY THE UNIVERSITY BOARD. The old domain will remain functioning for a long time, but you cannot say that you have not been warned. __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University (Prof. Dr)P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __
Re: Call for parsers
You may have a look at my version of the parser combinators, which: - are deterministic, and thus relatively fast - correct errors in the input - have now been tuned with a scanner coming with it - have been extended with some new useful combinators. Unfortunately I am now in Bolivia (so do not reply to this address). You may find a somehat older version through my home page at Utrecht University. I intend to put them, with a small description, on the net, together with a very small attribute grammar system, and an example mini-compiler. If you are in urgent need you may contact [EMAIL PROTECTED], for a more or less complete set of files, Doaitse Swierstra
Re: Monads and Linear Logic
At 8:08 PM 9/3/97, Patrick Logan wrote:
>I am stretching my imperative brain cells to comprehend(!) monads, and
>now their relationship to linear ("unique" in Clean) objects. I have
>glanced at Philip Wadler's paper, but the semantics are impenetrable
>to me at this point, and I am looking at the issue from a more
>"practical" point of view ("practical" in the sense of "practice",
>"practitioner", not that theory is impractical!).
>
>My impression is that monads and linear objects are used in
>essentially the same way. I have explicitly read how linear objects
>allow the compiler to "garbage collect" them at compile time because
>the compiler knows exactly how they are used. I assume the same can be
>done for monads? Is this done in the good Haskell compilers?
It has gone unnoticed by many that an assignment not only assigns a new
value to a variable, but is at the same time a form of static garbage
collection. The programmer implicitely states explicitely that the old
value is no longer of interest. This is were state-monads and
uniqueness-types coincide.
Doaitse Swierstra
>
>In general laymen's terms, what are the performance and expressiveness
>issues in comparing monads with linear objects?
>
>Thanks
>--
>Patrick Logan mailto:[EMAIL PROTECTED]
>Voice 503-533-3365Fax 503-629-8556
>Gemstone Systems, Inc http://www.gemstone.com
__
S. Doaitse Swierstra, Department of Computer Science, Utrecht University
(Prof. Dr)P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands
email: [EMAIL PROTECTED]
WWW: http://www.cs.ruu.nl/
PGP Public Key: http://www.cs.ruu.nl/people/doaitse/
tel: +31 (30) 253 3962, fax: +31 (30) 2513791
__^___^___
