Re: [Haskell] Survey of Haskell in Higher Education
Am Montag, 28. November 2005 20:52 schrieb John Hughes: > Wolfgang Jeltsch wrote: > > "What is the first programming language students on your degree programme > > learn?" > > "What is the second programming language students on your degree programme > > learn?" > > > > This is too restrictive. What if the lecture "Computer Science I" is held > > in different years by different lecturers which teach different > > programming languages? > > > > Best wishes, > > Wolfgang > > [...] > > Mind you, I'm amazed the teachers for the rest of the curriculum can cope > without knowing what programming language their students have learned! The students have to learn one or two programming languages in their first semester so that they get to know some basic principles of programming. If during their studies they need a programming language they didn't learned so far then they just have to learn it. The students are expected to be able to and take the time to learn programming languages outside their university courses. Of course, this is more demanding for them than learning every language they need as part of their courses. But – hey – it's university, not school. :-) > John Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Survey of Haskell in Higher Education
Wolfgang Jeltsch wrote: "What is the first programming language students on your degree programme learn?" "What is the second programming language students on your degree programme learn?" This is too restrictive. What if the lecture "Computer Science I" is held in different years by different lecturers which teach different programming languages? Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell In this case enter "Varies from year to year" in both fields. Mind you, I'm amazed the teachers for the rest of the curriculum can cope without knowing what programming language their students have learned! John ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Survey of Haskell in Higher Education
Wolfgang Jeltsch wrote: Am Montag, 28. November 2005 16:39 schrieb John Hughes: I'm carrying out another survey of the Haskell community, this time to find out how Haskell is being used in university teaching. "Roughly how many students took the course last time it was taught?" What if this course was never thaught so far? "Since when, roughly, has this course been taught using Haskell?" What if this course is first thaught in spring 2006? Tricky. If you can make a reasonable estimate of student numbers, say via students already registered for the course, then go ahead and report it. Otherwise, it's maybe better just to leave the course out of the survey--too much of an unknown quantity. 2006 is not an option for "since when...", but just put 2005. I'll understand it to include the entire academic year starting in 2005. By the way, do proseminars (simpler form of seminars where 1st or 2nd year undergraduate students have to give speeches) also count? If, for example, one student out of a large class gives a talk about Haskell, then I would say no--the "Haskell content" in that case is trivial. If all the students give seminars about Haskell programs they have written, then the answer is clearly yes. You have to make a judgement here: is Haskell used as a medium of instruction to a non-trivial extent? If so, include the course. You can always add an explanatory comment. John [...] Best wishes, Wolfgang ___ 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: Records (was Re: [Haskell] Improvements to GHC)
On 11/28/05, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
>
> As I already said, this approach may lead to mixing different concepts.
> Example:
>
> data Person = Person { name :: String }
> data File = File { name :: String }
>
> A field identifier has to be seen in context of the datatype it belongs to.
> When used in conjunction with Person, name means a person's name while it
> means a filename (a notably different thing) when used in conjunction with
> File. With the typeclass approach, we would have a single function called
> "name" which deals with different things. Important details would just be
> camouflaged. This is not good. In fact, it is really bad in my opinion.
Hi Wolfgang,
I think you are right in that two similarly named fields should not be
automatically considered to be equivilent. Indeed that is why the
typeclass approach I proposed requires that one explicitly declare any
typeclasses, and explicitly declare when two similarly named fields
are part of the same typeclass -- one thus cannot have two fields been
considered equivalent without the programmer making a conscious
descision that this is correct behaviour.
> Maybe it would really be better to have functions like Person.name and
> File.name?
In the case you give, I think you are right. In this case, using
namespaces to distinguish fields is preferable to treating the same.
However I think there are also other cases in which it *is* desirable
to allow several datatypes to have the same field -- with the
programmer making a contious descision to do things this way.
[snip]
-Rob
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Survey of Haskell in Higher Education
"What is the first programming language students on your degree programme learn?" "What is the second programming language students on your degree programme learn?" This is too restrictive. What if the lecture "Computer Science I" is held in different years by different lecturers which teach different programming languages? Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Survey of Haskell in Higher Education
Am Montag, 28. November 2005 16:39 schrieb John Hughes: > I'm carrying out another survey of the Haskell community, this time to > find out how Haskell is being used in university teaching. "Roughly how many students took the course last time it was taught?" What if this course was never thaught so far? "Since when, roughly, has this course been taught using Haskell?" What if this course is first thaught in spring 2006? By the way, do proseminars (simpler form of seminars where 1st or 2nd year undergraduate students have to give speeches) also count? > [...] Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
Am Sonntag, 27. November 2005 22:34 schrieb John Lask:
> correct me if I am wrong but ...
>
> 1. Field namespaces: solved by using type classes
>
> This would imply that the type of the field is the same between all
> instances of this common field.
>
> Under this proposal two fields with same label and different type would
> not be possible
> eg { name :: String }, { name :: Int }
As I already said, this approach may lead to mixing different concepts.
Example:
data Person = Person { name :: String }
data File = File { name :: String }
A field identifier has to be seen in context of the datatype it belongs to.
When used in conjunction with Person, name means a person's name while it
means a filename (a notably different thing) when used in conjunction with
File. With the typeclass approach, we would have a single function called
"name" which deals with different things. Important details would just be
camouflaged. This is not good. In fact, it is really bad in my opinion.
Maybe it would really be better to have functions like Person.name and
File.name?
> John
Best wishes,
Wolfgang
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Re: Records
Good questions.
You can't have a polymorphic typecase like "`extQ` (show :: Show a => a
-> String )" because that's not really a *type*case. It is too
polymorphic.
You can have a polymorphic typecase like "`extQ` ( lshow :: [ a ] ->
String )" because that's covered by the SYB2 paper; you need ext1Q
(extQ1, depending on version).
With SYB3, the second case is easier; it's just an instance.
The first case ... still doesn't work ... this time for reasons of the
class system. The type system doesn't allow to write one "default"
instance for the case that a certain constraint is satisfiable (here:
Show a) and to have yet another "default" instance to kick in
*otherwise* to the SYB version.
It would be great to have typeclass case to deal with this issue.
Questions asking for typeclass case pop every now and then.
The idea of the example is that you would need to define your own
generic show function from scratch. The limitation of SYB1/SYB2 is that
you would hit a closed-world-assumption. That's why SYB3! It allows you
to add instances to the new generic show, as you go. Because of the lack
of typeclass case, you still wouldn't be able to use the normal Prelude
show function as default. You can use it instance-per-instance, by
adopting each (attractive) show instances to be become instance of the
new generic show function. However, you need to clone code because you
probably want to re-tie the recursive knot in the new generic function.
SYB3 is shipped separately, please use the distribution you pointed to.
Simon PJ and I are still undecided regarding the modalities for adding
SYB3 to the GHC libraries. Basically, we don't like the idea of having
two libraries; SYB3 is more powerful but the combinator types are
somewhat more complicated. However, using the separate SYB3 distribution
is safe because it comes with TH support and a standalone mini SYB
library.
Regards,
Ralf
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Johannes Waldmann
> Sent: Monday, November 28, 2005 7:33 AM
> To: haskell@haskell.org
> Subject: [Haskell] Data.Generics question
>
> Dear all, in Data.Generics.Text
> http://cvs.haskell.org/cgi-
> bin/cvsweb.cgi/fptools/libraries/base/Data/Generics/Text.hs?rev=1.10
> I find this nice example
>
> gshow = ( \t ->
> "("
> ++ showConstr (toConstr t)
> ++ concat (gmapQ ((++) " " . gshow) t)
> ++ ")"
> ) `extQ` (show :: String -> String)
>
> but I couldn't figure out how to use this to declare a useful show
> instance. I would need something like
>
>`extQ` (show :: Show a => a -> String )
>
> i. e. use Show instance if available, or
>
>`extQ` ( lshow :: [ a ] -> String )
>
> i. e. use another function if argument type is a list type
>
>
> BTW: I guess the above is related to
> http://homepages.cwi.nl/~ralf/syb3/
> Do the current (6.4) ghc compiler/libraries correspond to what's in
> that paper?
> --
> -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
> http://www.imn.htwk-leipzig.de/~waldmann/ ---
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Records
Ketil Malde wrote:
>> Perhaps data Foo = Foo { foo :: Int, bar :: Int ; bar = 2 * foo self }
>> with a reserved word "self" is better. - Are there semantic problems?
>
> Can't you solve this by writing a fiunction to construct Foo with the
> desired properties?
Sure but by the same argument I wouldn't need records at all
because I could use tuples :-) I'd say it makes the intention
of the programmer more explicit, and this is what pragmatics
of programming languages is all about, isn't it ...
Also, for updates ( like x { foo = 3 } )
I'd expect that a new record is built
and the initializer is called again - this would be
inconvenient to write with functions because of the unwrapping
and wrapping (you would need to name all components even if they don't
change so you don't want to mention them).
I think it would be even more convenient if it were possible
to have initializers in separate modules (a la orphan instances)
because often I have one module that just defines the data type,
and then several modules that define operations.
I would need to know all the default-initialized fields
already when writing the type definition,
which is wrong design (it forces me to make decisions too early
and write them down in the wrong place).
I realize that my above idea looks something like introducing
objects through the back door. Because one might say that I want
something like a "Foo" with an additional component (bar)
that is ignored by those who don't know them.
This is indeed a severe criticism - normally I tend to avoid
implementation inheritance and now it looks like I'm advocating it...
best regards,
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
http://www.imn.htwk-leipzig.de/~waldmann/ ---
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Records
Johannes Waldmann <[EMAIL PROTECTED]> writes:
> Again, the concrete syntax problem is whether to hide the argument.
> Perhaps data Foo = Foo { foo :: Int, bar :: Int ; bar = 2 * foo self }
> with a reserved word "self" is better. - Are there semantic problems?
Can't you solve this by writing a fiunction to construct Foo with the
desired properties? I.e. something like
mkStdFoo f = Foo f (2*f)
Or is there other functionality you would get by using records in this
way?
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Survey of Haskell in Higher Education
I'm carrying out another survey of the Haskell community, this time to find out how Haskell is being used in university teaching. If you're teaching a course and using Haskell in any way, then this survey is aimed at you! You can find the survey form at http://www.cs.chalmers.se/~rjmh/Wash/Survey/TeachingSurvey.cgi Once again, as a reward for completing the form, you will see the results so far! I'm only surveying courses being taught this academic year, but I would like to gather as complete information as possible. I know that not all teachers using Haskell read this list, so I would appreciate it if you could help me by informing colleagues who are using Haskell about the existence of the survey. The information gathered will be used in the "History of Haskell" paper that I, Simon PJ, Phil Wadler and Paul Hudak are working on. Thanks very much for you help! John Hughes PS I now have over 500 responses to my earlier survey on use of Haskell--thank you very much! The results are interesting, and can be obtained from http://www.cs.chalmers.se/~rjmh/Wash/Survey/Survey.cgi. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Data.Generics question
Dear all, in Data.Generics.Text
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Data/Generics/Text.hs?rev=1.10
I find this nice example
gshow = ( \t ->
"("
++ showConstr (toConstr t)
++ concat (gmapQ ((++) " " . gshow) t)
++ ")"
) `extQ` (show :: String -> String)
but I couldn't figure out how to use this
to declare a useful show instance. I would need something like
`extQ` (show :: Show a => a -> String )
i. e. use Show instance if available, or
`extQ` ( lshow :: [ a ] -> String )
i. e. use another function if argument type is a list type
BTW: I guess the above is related to
http://homepages.cwi.nl/~ralf/syb3/
Do the current (6.4) ghc compiler/libraries
correspond to what's in that paper?
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
http://www.imn.htwk-leipzig.de/~waldmann/ ---
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
> It actually sounds a lot like pattern guards, since you're suggesting this
> sugar could be applied to any sort of object? So your desugarer would
> allow a function like
>
> islong :: [a] -> Bool
> islong {length = l} = l > 10
this looks like a hack that only works for one-argument functions,
and its only purpose seems to hide the argument.
I don't like the (local) looks of "length = 1" anyway.
Compare to "length [] = 0". You'd think the first one
is a typing error until you spot the surrounding "{ .. }"
While we're at it, I'd like to mention a feature that
I'd love to have in a record system (for a long time):
defaults, resp. initializer functions.
E. g. data Foo = Foo { foo :: Int, bar :: Int ; bar x = 2 * foo x }
Something like that (imagine that (*) is some expensive computation).
Note that default declarations in classes are vaguely similar.
Again, the concrete syntax problem is whether to hide the argument.
Perhaps data Foo = Foo { foo :: Int, bar :: Int ; bar = 2 * foo self }
with a reserved word "self" is better. - Are there semantic problems?
It might even be desirable to hide the "computed" component,
i. e. Foo { foo = 5, bar = 7 } could be forbidden.
And still better: if we could say later (i. e. outside the
definition of Foo) that the values of bar
should be "memorized" in the Foo records.
Of course this might be hard for separate compilation
(if type definition and memorized functions are in different modules.
Again, this is vaguely similar to orphan instances.)
Best regards,
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
http://www.imn.htwk-leipzig.de/~waldmann/ ---
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On Sun, Nov 27, 2005 at 08:47:54PM +, Rob Ennals wrote:
> On 11/23/05, David Roundy <[EMAIL PROTECTED]> wrote:
> > > 3. "Safe" getters for multi-constructor data types: ditto
> >
> > I think either you misunderstood my meaning by "safe", or I misunderstood
> > your paper. I meant that if I write
> >
> > data FooBar = Foo { foo :: String } | Bar { bar :: String }
> >
> > there shouldn't be accessors of type
> >
> > foo :: FooBar -> String
> > bar :: FooBar -> String
>
> I did indeed misunderstand what you meant by "safe". Bottom is indeed
> a nasty thing.
>
> Perhaps such definitions should generate a warning? (banning them
> outright would cause compatability issues)
Yeah, issuing a warning (which can become an error with -Werr) is a nice
option. The other option would be some sort of syntax to declare that a
particular record is unordered. Or I suppose to just give up on backward
compatibility. Any of these three alternatives would be fine with me.
> > > 7. Unordered records: yep (if I understand the problem correctly)
> >
> > I don't think you understood correctly.
>
> I was thinking along the same lines as Wolfgang : don't export the
> internal representation of the type, but do expose the field
> manipulator functions.
>
> This needn't prevent the use of pattern matching, provided the
> desugaring of patterns is consistent with the rest of the system.
>
> E.g. I was assuming that
>
> case e of { x = 3, y = 4} -> ...
>
> would desugar to
>
> case e of _ | x z = 3 && y z = 4 -> ...
>
> Note that this pattern matching syntax will continue to work, even if
> 'x' and 'y' are reimplemented as normal functions, rather than fields.
Indeed, it hadn't occurred to me to make pattern matching work this way.
It actually sounds a lot like pattern guards, since you're suggesting this
sugar could be applied to any sort of object? So your desugarer would
allow a function like
islong :: [a] -> Bool
islong {length = l} = l > 10
--
David Roundy
http://www.darcs.net
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Can anyone help...
I apologize for the posting in which I mention the inadequacy of Doaitse Swierstra partition program, it has been commented by others, and the thread is obsolete. But my posting (issued immediately then) got delayed by the moderator because of the schizoidal nature of my e-mail address... Sorry. Jerzy Karczmarczuk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Coordination 2006: Second call for papers
[ Our apologies for multiple copies. ] == Second Call for Papers COORDINATION 2006 8th International Conference on Coordination Models and Languages http://www.cs.unibo.it/discotec06/Coordination06 as part of DisCoTec'06 - Distributed Computing Techniques co-located with DAIS'06 & FMOODS'06 http://www.cs.unibo.it/discotec06 Bologna, Italy 14-16 June 2006 == IMPORTANT DATES * Submission of abstract: 10 January 2006 * Submission of papers: 17 January 2006 * Notification of acceptance: 7 March 2006 * Final version: 28 March 2006 * Conference: 14-16 June 2006 == CONFERENCE GOALS Modern information systems rely increasingly on combining concurrent, distributed, mobile, reconfigurable and heterogenous components. New models, architectures, languages, verification techniques are necessary to cope with the complexity induced by the demands of today's software development. Coordination languages have emerged as a successful approach, in that they provide abstractions that cleanly separate behavior from communication, therefore increasing modularity, simplifying reasoning, and ultimately enhancing software development. Building on the success of the previous editions, this conference provides a well-established forum for the growing community of researchers interested in models, languages, architectures, and implementation techniques for coordination. PREVIOUS EDITIONS The previous editions of COORDINATION took place in Cesena (Italy), Berlin (Germany), Amsterdam (Netherlands), Limassol (Cyprus), York (UK), Pisa (Italy) and Namur (Belgium). More details are available at http://www.coordination2005.org. TOPICS OF INTEREST They include but are not limited to: * Theoretical models and foundations for coordination: component composition, concurrency, mobility, dynamic aspects of coordination, emergent behavior. * Specification, refinement, and analysis of software architectures: patterns and styles, verification of functional and non-functional properties. * Coordination, architectural, and interface definition languages: implementation, interoperability, heterogeneity. * Multiagentsystems andcoordination:models, languages, infrastructures. * Dynamic software architectures:mobile code and agents, configuration, reconfiguration, self-organization. * Coordination and modern distributed computing: Web services, peer-to-peer networks, grid computing, context-awareness, ubiquitous computing. * Programming languages, middleware, tools, and environments for the development of coordinated applications * Industrial relevance of coordination and software architectures: programming in the large, domain-specific software architectures and coordination models, case studies. * Interdisciplinary aspects of coordination PROCEEDINGS Proceedings of previous editions of this conference were published by Springer, in the Lecture Notes in Computer Science (LNCS) series and are available as LNCS volumes 1061, 1282, 1594, 1906, 2315, 2949 and 3454. The intention is to continue this series. SUBMISSION INSTRUCTIONS Authors are invited to submit full papers electronically in PostScript or PDF using a two-phase online submission process. Registration of the paper information and abstract (max. 250 words) must be completed before 10 January 2006. Submission of the full paper is due no later than 17 January 2006. Further instructions on the submission procedure will be published at http://www.cs.unibo.it/discotec06/Coordination06. Submissions must be formatted according to the LNCS guidelines (see http://www.springer.de/comp/lncs/authors.html) and must not exceed 15 pages in length. Papers that are not in the requested format or significantly exceed the mandated length may be rejected without going through the review phase. Submissions should explicitly state their contribution and their relevance to the theme of the conference. Other criteria for selection will be originality, significance, correctness, and clarity. Simultaneous or similar submissions to other conferences or journals are not allowed. CONFERENCE LOCATION The conference will be hosted by the Department of Co
[Haskell] Call For Papers: ISMM 2006 (International Symposium on Memory Management)
* Call For Papers The 2006 International Symposium on Memory Management (ISMM'06) Co-located with PLDI 2006 Ottawa, Canada June 10-11 2006 http://www.cs.technion.ac.il/~erez/ismm06 * IMPORTANT DATES: Submission: January 23, 2006, 11PM PST Notification: March 6, 2006 Camera-ready: Monday, April 3, 2006 ISMM is a forum for research in management of dynamically allocated memory. ISMM solicits full-length papers on all areas of memory management. Survey papers that present an aspect of memory management with a new clarity and insight are also welcome. Papers are solicited on, but not limited to, these topics, - Explicit storage allocation and de-allocation - Garbage collection algorithms and implementations - Compiler analyses to aid memory management - Interaction with languages, operating systems, and hardware, especially the memory system - Memory system interaction with programming languages, operating systems, and hardware. The ISMM 2006 paper reviewing process adds two features new to ISMM: double blind reviewing, and an opportunity for rebuttal; see the ISMM webpage for more details. Full submissions should be at most 12 pages excluding bibliography and well-marked appendices but including all figures and tables, using at least 11-point font and reasonable margins for US Letter paper. Papers that violate these guidelines will be rejected by the program chair. Program committee members are not required to read appendices, and so a paper should be intelligible without them. Submitted papers must be in English and formatted to print on US Letter (8.5 x 11 inches) paper. Submissions must contain an abstract and postal and electronic mailing addresses for at least one author. Instructions for on-line submission of papers will become available on the ISMM webpage at http://www.cs.technion.ac.il/~erez/ismm06. Submissions will be read by the program committee and designated reviewers and judged on scientific merit, innovation, readability, and relevance. Papers previously published or already being reviewed by another conference are not eligible; if a closely related paper has been submitted to a journal, the authors must notify the program chair. The proceedings will be published by ACM. Authors should read the ACM Author Guidelines and related information. Authors of accepted papers must guarantee that their paper will be presented at the conference. For additional information please feel free to contact the Program Chair, Eliot Moss ([EMAIL PROTECTED]). General Chair: Erez Petrank (Technion, Israel) Program Chair: J. Eliot B. Moss (Univ. of Mass. at Amherst) Program Committee: Vikram Adve(Univ. of Illinois at Urbana-Champaign) Richard Jones (Univ. of Kent) Hillel Kolodner(IBM Haifa Research Lab) Chandra Krintz (Univ. of California at Santa Barbara) Kathryn S McKinley (Univ. of Texas at Austin) GregMorrisett (Harvard University) RaviRajwar (Intel) Yannis Smaragdakis (Georgia Tech) Guy Steele (Sun Microsystems) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Can anyone help me with partition numbers?
Doaitse Swierstra wrote: Or (since we started to do someone's homework anyway) generate 0 = [[]] generate n = [x:rest | x <- [1..n], rest <- generate (n-x)] Unless I am misled, this will generate the *unordered* partitions, e.g., for n=7, 64 of them, not 15. Jerzy Karczmarczuk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
