- Haskell-Cafe - Haskell.org

RE: Pointers in Haskell??
by Simon Peyton-Jones 10 Dec '01

10 Dec '01

| > Simon Peyton-Jones. The implementation of functional | > programming languages. Prentice-Hall, 1987 | | is this book could be made available online ? cos on amazon | it seems out of print. I'm planning to scan it in and make the copy available online. In the next month or two. Simon

2 1

Re: instance declarations
by Ketil Z Malde 10 Dec '01

10 Dec '01

David Feuer <dfeuer(a)cs.brown.edu> writes: > 1. Why can't [instances] be hidden in module imports/exports? The way I see it, an instance declaration is an assertion that a certain data type supports a certain set of operations. Thus, if the data type and the operations on it are in scope, it makes sense for the class instance to be, too. (This leads to the question of why we need to have instance declarations at all :-) (My guesses would be: compiler implementation issues, code clarity, error detection, partially implemented classes)) Problems arise when a data type needs to be instantiated twice in the same class, but with different operator implementations. (I.e. you have a data type which prints differently according to which module you're in) This would, I think, be a problem in most languages, think of deriving a C++ class twice from the same base class while providing different overrides for the functions. I'm not entirely convinced it's an issue that needs a better resolution than the language provides today. (There's a diminishing returns effect when adding language features, and at some point, the increased complexity of the language doesn't make it worth it, IMHO.) > 2. Why can't you simultaneously declare a type to be an instance of > multiple classes? Why does it matter? > class C1 t where a::t->t > class C1 t => C2 t where b::t->t > instance C1 T, C2 T where > a=... > b=... To me, it'd make more sense to provide class C1 t where a :: t -> t class (C1 t) => C2 t where b :: t -> t instance C2 T where a = ... -- implicitly instantiating C1 b = ... and avoid long instantiation chains. But that too is IMHO a minor issue. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

Re: instance declarations
by Marcin 'Qrczak' Kowalczyk 10 Dec '01

10 Dec '01

Fri, 7 Dec 2001 11:38:14 -0800, Mark P Jones <mpj(a)cse.ogi.edu> pisze: > There's no solid technical reason for this, but Haskell doesn't allow > it at the moment because there isn't an easy way to name an instance > declaration. There is another problem: even if we created a syntax to name them, if they would not be exported by default then current programs would have to be changed. An instance is usually meant to be exported, so even not considering compatibility it would be tedious to list all those instances in the export list (unless you want to export every named thing as well and omit the export list). It's easy to overlook some and the point when somebody tries to use a particular instance might be far in the future. Each instance is often a "small" part of an interface. I agree that the ability to selectively export instances would be good. Only it's hard to combine with the current policy of exporting all instances by default. Perhaps in the future it will be possible to specify the interface of a Haskell module more formally, with types of exported values for example. Then we should remember about instances and solve both problems simultaneously. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

3 2

Re: instance declarations
by David Feuer 10 Dec '01

10 Dec '01

(sorry to mess up mail threading, but I couldn't properly reply to the message the way I'm using email right now--broken mail clients) >Recently, however, there has been some interest in using named instance >declarations in other ways, so perhaps we will see features like this >creeping into future versions of the language. In what kinds of ways? Sounds interesting. >[Of course, there is a way of naming instance declarations with the >current Haskell syntax, although it is a little verbose, and would >require more work on the implementers part than simple matching of >strings. The syntax I'm thinking of would look something like the >following: > > module M(C(..), instance C Int, instance C a => C [a]) where ... This is the sort of thing I was thinking too. But I would probably want to extend that to classes and types. For instance module M (class Eq a=>C a (...), type A, instance C A, instance C a => C [a]) where ... If I am not mistaken, this would allow separation of the type namespace from the typeclass namespace, and would make it obvious whether the thing being exported is a type or a class. It could also potentially allow the context(s) for class and instance declarations to be more restrictive in the header or in imports than in the module body. The latter could perhaps allow resolution of overlapping instances at import time, by restricting the instances to the point of non-overlap. I'm not sure that the former would actually be useful. Hmmm.... speaking of overlapping instances... Would there be a practical way to add negation (of classes and possibly even types) to the context syntax? This would let you say instance (Integral a) => C (T a) where ... instance (not Integral a, Real a) => C (T a) where ... instance (not Num a) => C (T a) where ... .... It would also seem nice to be able to say instance (Integral a, not a Int) => C a where .... and instance C Int where ..... but this seems even more questionable.

2 1

Re: Pointers in Haskell??
by Yoann Padioleau 10 Dec '01

10 Dec '01

Jan Kort <kort(a)science.uva.nl> writes: > > Simon Peyton-Jones. The implementation of functional > programming languages. Prentice-Hall, 1987 is this book could be made available online ? cos on amazon it seems out of print. > > Jan > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Yoann Padioleau, INSA de Rennes, France, Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____**

4 3

RE: Brain Teaser
by Jay Allen 09 Dec '01

09 Dec '01

You're asking us to do your CS homework for you. Do it yourself - it's not hard if you actually think about it. Look at the Shopping Receipt exercise in Simon Thompson's HASKELL: THE CRAFT OF FUNCTIONAL PROGRAMMING if you need a template. If you get stuck, ask specific technical questions - not "Can you please code this for me?" -J- -----Original Message----- From: Faisal [mailto:cs0u919b@liverpool.ac.uk] Sent: Sun 12/9/2001 4:17 PM To: Haskell-Cafe(a)haskell.org; Haskell-Cafe(a)haskell.org Cc: Subject: Brain Teaser i got this from a tutor who thinks hes awesome and clever and thinks that i wont be able to find the solutions to this! The question is whos clever enuf out there to help me make my tutor look like a fool! Please help, i will be in ur debt for a long time!!!! Background Rhode Jams make a variety of jams and require a database to keep track of their stocks. Their jams come in three types: Ordinary Jam Extra Jam (with a higher proportion of fruit to sugar) and Luxury Conserve (with a very high fruit content). Each of these types of jam is available in the following flavours: Strawberry Raspberry Apricot Plum Peach. Rhode Jams need to store information concerning the prices of each kind of jam they produce, and the number of items they have in stock. For this assignment, you are asked to develop a datatype to represent a database record, and some functions that could be used in a prototype system to help Rhode Jams monitor their stock (you do not have to develop a fully-fledged database). Haskell source code for each of the following: 0 Define a type StockItem that can be used to represent a database record: each element of the data type should contain data for a type of jam, a flavour, a price, and the number of items currently in stock. (The type StockItem is required, you may choose to define this type by building it from other types that you define; all definitions should be documented and handed in.) 1 Define a function of type StockItem -> [Char] that gives a string representation of a database record, in a format suitable for printing to a screen. 2 Define a function of type [StockItem] -> [StockItem] that takes such a list of database records and returns the list of all records representing jams with fewer than twenty items currently in stock. 3 Define a function of type [StockItem] -> Int that calculates the total value of the current stock. 4 Define a function that takes a list of flavours and a list of jam types as arguments, and returns the list of StockItems that represents all possible combinations of types and flavours of jam from the given lists (with stock levels set to 0, and a fixed price of 87 pence for ordinary jam, 98 pence for extra jam, and 128 pence for luxury conserve). _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Brain Teaser
by Faisal 09 Dec '01

09 Dec '01

i got this from a tutor who thinks hes awesome and clever and thinks that i wont be able to find the solutions to this! The question is whos clever enuf out there to help me make my tutor look like a fool! Please help, i will be in ur debt for a long time!!!! Background Rhode Jams make a variety of jams and require a database to keep track of their stocks. Their jams come in three types: Ordinary Jam Extra Jam (with a higher proportion of fruit to sugar) and Luxury Conserve (with a very high fruit content). Each of these types of jam is available in the following flavours: Strawberry Raspberry Apricot Plum Peach. Rhode Jams need to store information concerning the prices of each kind of jam they produce, and the number of items they have in stock. For this assignment, you are asked to develop a datatype to represent a database record, and some functions that could be used in a prototype system to help Rhode Jams monitor their stock (you do not have to develop a fully-fledged database). Haskell source code for each of the following: 0 Define a type StockItem that can be used to represent a database record: each element of the data type should contain data for a type of jam, a flavour, a price, and the number of items currently in stock. (The type StockItem is required, you may choose to define this type by building it from other types that you define; all definitions should be documented and handed in.) 1 Define a function of type StockItem -> [Char] that gives a string representation of a database record, in a format suitable for printing to a screen. 2 Define a function of type [StockItem] -> [StockItem] that takes such a list of database records and returns the list of all records representing jams with fewer than twenty items currently in stock. 3 Define a function of type [StockItem] -> Int that calculates the total value of the current stock. 4 Define a function that takes a list of flavours and a list of jam types as arguments, and returns the list of StockItems that represents all possible combinations of types and flavours of jam from the given lists (with stock levels set to 0, and a fixed price of 87 pence for ordinary jam, 98 pence for extra jam, and 128 pence for luxury conserve).

1 0

Re: Pointers in Haskell??
by Jeff Dalton 07 Dec '01

07 Dec '01

> >> ... So the question of whether names are "*the* (only) way" to obtain > >> sharing isn't really a language question-- it's more of a > >> compiler question. > > > >Are they the only way that's guaranteed to result in sharing, or is > >even that not the case? > > Depends on what you mean by "guaranteed". Since in Haskell sharing vs. not > sharing is not a semantic issue, you can't very well say that if sharing > doesn't occur under such-and-such circumstances, the language specification > is violated. But the answers to the original question seemed to be saying you would get sharing if you wrote code of a certain sort. I take it that the language semantics doesn't strictly require sharing, but it sounded like it was something programmers could assume would happen in practice. If not, then shouldn't the answers to the original question have been different? What I was wondering was why the answers to the original question about pointers involved giving a name to the thing you wanted shared. Is there something less direct that would also work? For instance, could I instead name something that contained the structure I wanted shared and then use an appropriate expression to refer to the part I wanted shared - or do I have to give a name directly to that part. The main point of my Java example was to give an example where I didn't give a name to the very thing I wanted shared, but instead gave a name to something that contained it. > This is very different from languages like Java, where > > Object[] x = new Object[](...) > Object[] y = x; > > means that x and y refer to the same array (not merely equivalent arrays), > and if they don't, it's not Java. And what's crucial is that you can write > a Java program that detects whether x and y refer to the same array, by > updating the array via x and observing the effect via y. You can just use ==. Also, I'm not sure the Java language semantics really does require that x and y in your example above refer to the same locations in memory. The update test doesn't necessarily show that either. It just shows that if you change one, the "other" changes too. Of course, programmers assume that assignment to array elements is done in a fairly direct and simple way; but the language semantics might nonetheless allow something more expensive and complex. -- Jeff

1 0

Re: Pointers in Haskell??
by Jeff Dalton 07 Dec '01

07 Dec '01

In-Reply-To: Hamilton Richards's message of Fri, 7 Dec 2001 12:11:23 -0600 > In my previous example, > > > t = [0..] > > b = 3 : t > > c = 5 : t > > lists b and c share t, but in > > > x = 3 : [0..] > > y = 5 : [0..] > > lists x and y share nothing. Extensionally, they have the same values as b > and c, but each has its own copy of [0..]. That's because you're interpreting "same value" extensionally. The same sort of issue comes up in Lisp or Java. But suppose in Java I have Object x = new Whatever(); and that new object has some large substructures. I can get one of those substructures to be shared, rather than copied, without having a variable whose value is that substructure. For instance, the substructure might be shared in Object[] anArray = new Object[](x.getSubstructure(), x.getSubstructure()); provided that x.getSubstructure() returns the very same substructure (not a copy) each time. > Unless, that is, the compiler is clever enough to recognize the > subexpression [0..] which x and y have in common. I don't know whether any > Haskell compilers look for common subexpressions, but it's certainly an > option. > So the question of whether names are "*the* (only) way" to obtain > sharing isn't really a language question-- it's more of a compiler question. Are they the only way that's guaranteed to result in sharing, or is even that not the case? Cheers, Jeff

2 1

RE: Pointers in Haskell??
by ADAMS,RICHARD (Non-HP-Roseville,ex1) 07 Dec '01

07 Dec '01

I would also recommend the following book, which, in Chapter 3, discusses graph reduction, closures, and pointers: Fethi Rabhi, and Guy Lapalme. Algorithms: a functional programming approach; Second Edition. Addison-Wesley, 1999. Another useful book, but probably not for the beginner, is Chris Okasaki. Purely Functional Data Structures. Cambridge University Press, 1998, 1999. Best Regards, Richard E. Adams Softmatrix, Inc. Roseville, CA Email: richard_adams(a)non.hp.com -----Original Message----- From: Bryan Hayes (Hayes Technologies) [mailto:bryan.hayes@hayestechnologies.com] Sent: Friday, December 07, 2001 7:30 AM To: haskell-cafe(a)haskell.org Subject: Pointers in Haskell?? I am totally new to Haskell, so maybe this is a stupid question. Various languages have pointers (or references), for good reason. Haskell can at least partly do without them (they are only existing internally somehow). My question is: Does Haskell principally not need pointers (i.e. in case of 2 data structures needing to reference an other very large data structure) or is this a design flaw or have a overlooked something? -------------------------------------------------- HAYES TECHNOLOGIES Software Speed Optimization Bryan Hayes Managing Director Mannheimer Str. 8 D-67098 Bad Dürkheim Deutschland / Germany Tel. +49 / (0)6322 / 94 950 - 68 Fax +49 / (0)6322 / 94 950 - 69 Mobile Tel. +49 / (0)163 / 6111867 E-Mail: mailto:bryan.hayes@hayestechnologies.com Web-Site: http://www.hayestechnologies.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0