Re: Please help me
At 2001-02-08 13:49, FAIZAN RAZA wrote: write a Haskell function cartesianProduct which when given three lists (to represent three sets) of integers returns a list of lists of ordered triples. That's easy. Just define 'product' as a function that finds the cartesian product of any number of lists, and then once you've done that you can apply it to make the special case of three items like this: cartesianProduct a b c = product [a,b,c] At least, that's how I would do it. -- Ashley Yakeley, Seattle WA ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Revamping the numeric classes
On Thu, 8 Feb 2001, Tom Pledger wrote: nice answer: give the numeric literal 10 the range type 10..10, which is defined implicitly and is a subtype of both -128..127 (Int8) and 0..255 (Word8). What are the inferred types for f = map (\x - x+10) g l = l ++ f l ? I hope I can use them as [Int] - [Int]. x + y + z -- as above -- (x + y) + z -- left-associativity of (+) -- realToFrac (x + y) + z-- injection (or treating up) done -- conservatively, i.e. only where needed What does it mean "where needed"? Type inference does not proceed inside-out. What about this? h f = f (1::Int) == (2::Int) Can I apply f to a function of type Int-Double? If no, then it's a pity, because I could inline it (the comparison would be done on Doubles). If yes, then what is the inferred type for h? Note that Int-Double is not a subtype of Int-Int, so if h :: (Int-Int)-Bool, then I can't imagine how h can be applied to something :: Int-Double. -- Marcin 'Qrczak' Kowalczyk ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Please help me
At 2001-02-08 02:04, Ashley Yakeley wrote: That's easy. Just define 'product' as a function that finds the cartesian product of any number of lists, and then once you've done that you can apply it to make the special case of three items like this: cartesianProduct a b c = product [a,b,c] At least, that's how I would do it. eesh, 'product' is something else in the Prelude. Better call it 'cartprod' or something. -- Ashley Yakeley, Seattle WA ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Revamping the numeric classes
First, a general remark which has nothing to do with Num. PLEASE WATCH YOUR DESTINATION ADDRESSES People send regularly their postings to haskell-cafe with several private receiver addresses, which is a bit annoying when you click "reply all"... Brian Boutel after Dylan Thurston: Why doesn't your argument show that all types should by instances of Eq and Show? Why are numeric types special? Why do you think it does? I certainly don't think so. The point about Eq was that a objection was raised to Num being a subclass of Eq because, for some numeric types, equality is undecidable. I suggested that Haskell equality could be undecidable, so (==) on those types could reflect the real situation. One would expect that it could do so in a natural way, producing a value of True or False when possible, and diverging otherwise. Thus no convincing argument has been given for removing Eq as a superclass of Num. In general, if you fine-grain the Class heirarchy too much, the picture gets very complicated. If you need to define separate subclases of Num for those types which have both Eq and Show, those that only Have Eq, those than only have Show and those that have neither, not to mention those that have Ord as well as Eq and those that don't, and then for all the other distinctions that will be suggested, my guess is that Haskell will become the preserve of a few mathematicians and everyone else will give up in disgust. Then the likely result is that no-one will be interested in maintaining and developing Haskell and it will die. Strange, but from the objectives mentioned in the last part of this posting (even if a little demagogic [insert smiley here if you wish]) I draw opposite conclusions. The fact that the number of cases is quite large suggests that Eq, Show and arithmetic should be treated as *orthogonal* issues, and treated independently. If somebody needs Show for his favourite data type, he is free to arrange this himself. I repeat what I have already said: I work with functional objects as mathematical entities. I want to add parametric surfaces, to rotate trajectories. Also, to handle gracefully and legibly for those simpletons who call themselves 'theoretical physicists', the arithmetic of un-truncated lazy streams representing power series, or infinitely dimensional differential algebra elements. Perhaps those are not convincing arguments for Brian Boutel. They are certainly so for me. Num, with this forced marriage of (+) and (*) violates the principle of orthogonality. Eq and Show constraints make it worse. === And, last, but very high on my check-list: The implicit coercion of numeric constants: 3.14 -=- (fromDouble 3.14) etc. is sick. (Or was; I still didn't install the last version of GHC, and with Hugs it is bad). The decision is taken by the compiler internally, and it doesn't care at all about the fact that in my prelude I have eliminated the Num class and redefined fromDouble, fromInt, etc. + Dylan Thurston terminates his previous posting about Num with: Footnotes: [1] Except for the lack of abs and signum, which should be in some other class. I have to think about their semantics before I can say where they belong. Now, signum and abs seem to be quite distincts beasts. Signum seem to require Ord (and a generic zero...). Abs from the mathematical point of view constitutes a *norm*. Now, frankly, I haven't the slightest idea how to cast this concept into Haskell class hierarchy in a sufficiently general way... I'll tell you anyway that if you try to "sanitize" the numeric classes, if you separate additive structures and the multiplication, if you finally define abstract Vectors over some field of scalars, and if you demand the existence of a generic normalization for your vectors, than *most probably* you will need multiparametric classes with dependencies. Jerzy Karczmarczuk Caen, France ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Please help me
Faizan,
A clue is to use list comprehensions (which are very like ZF set notation)
First think how you would define a cartesian product in set notation
X x Y x Z = {(x,y,z) | ...}
and then think how this is written in list comprehension notation
Chris
-Original Message-
From: FAIZAN RAZA [mailto:[EMAIL PROTECTED]]
Sent: 08 February 2001 13:49
To: [EMAIL PROTECTED]
Subject: Please help me
Hello
Please help me to solve this questions
Question
Cartesian Product of three sets, written as X x Y x Z is
defined as the set
of all ordered triples such that the first element is a
member of X, the
second is member of Y, and the thrid member of set Z. write a Haskell
function cartesianProduct which when given three lists (to
represent three
sets) of integers returns a list of lists of ordered triples.
For examples, cartesianProduct [1,3][2,4][5,6] returns
[[1,2,5],[1,2,6],[1,4,5],[1,4,6],[3,2,5],[3,2,6],[3,4,5],[3,4,6]]
Please send me reply as soon as possible
Ok
I wish you all the best of luck
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Show, Eq not necessary for Num [Was: Revamping the numeric c
On 07-Feb-2001 Patrik Jansson wrote: (interesting stuff deleted) As far as I remember from the earlier discussion, the only really visible reason for Show, Eq to be superclasses of Num is that class contexts are simpler when (as is often the case) numeric operations, equality and show are used in some context. f :: Num a = a - String -- currently f a = show (a+a==2*a) If Show, Eq, Num were uncoupled this would be f :: (Show a, Eq a, Num a) = a - String But I think I could live with that. (In fact, I rather like it.) Basically I'm too. However, what is missing for me is something like: type Comfortable a = (Show a, Eq a, Num a) = a or class (Show a, Read a, Eq a) = Comfortable a instance (Show a, Read a, Eq a) = Comfortable a I think here is a point where a general flaw of class hierachies as a mean of software design becomes obvious, which consists of forcing the programmer to arbitrarily prefer few generalizations to all others in a global, context-independent design decision. The oo community (being the source of all the evil...) usually relies on the rather problematic ontological assumption that, at least from a certain point of view (problem domain, design, implemention), the relevant concepts form in a natural way a kind a generalization hierarchy, and that this generalization provides a natural way to design the software (in our case, determine the type system in some a-priory fashion). Considering the fact that a concept, for which (given a certain point of view) n elementary predicates hold a-priory, n! possible generalizations exist a-priory, this assumption can be questioned. In contrary to the given assumption, I have made the experience that, when trying to classify concepts, even a light shift in the situation being under consideration can lead to a severe change in what appears to be the "natural" classification. Besides this, as is apparent in Show a = Num a, it is not always a priory generalizations that are really needed. Instead, the things must be fit into the current point of view with a bit force, thus changing concepts or even inventing new ones. (For example, in the oo community, which likes (or is forced?) to "ontologize" relationships into "objects", has invented "factories" for different things, ranging from GUI border frames to database connection handles. Behind such an at first glance totally arbitary conceptualization might stand a more rational concept, for example applying a certain library design principle called "factory" to different types of things. However one can't always wait until the rationale behind a certain solution is clearly recognized.) In my experience, both class membership and generalization relationships are often needed locally and post hoc, and they sometimes even express empirical (a-posteriory) relations between concepts instead of true analytical (a-priory) generalization relationships. As a consequence, for my opinion, programming languages should make it possible and easy to employ post-hoc and local class membership declarations and post-hoc and local class hierarchy declarations (or even re-organizations). There will of course be situations where a global a-priory declaration of generalization nevertheless still make completely sense. For Haskell, I could imagine (without having having much thought about) in addition to the things mentioned in the beginning, several things making supporting the "locally, fast and easy", including a mean to define classes with implied memberships, for example declarations saying that "Foo is the class of all types in scope for which somefoo :: ... is defined", or declarations saying that "class Num is locally restricted to all instances of global Num which also belong to Eq". Elke. --- Elke Kasimir Skalitzer Str. 79 10997 Berlin (Germany) fon: +49 (030) 612 852 16 mail: [EMAIL PROTECTED] see: http://www.catmint.de/elke for pgp public key see: http://www.catmint.de/elke/pgp_signature.html ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Revamping the numeric classes
On Thu, Feb 08, 2001 at 11:24:49AM +, Jerzy Karczmarczuk wrote: First, a general remark which has nothing to do with Num. PLEASE WATCH YOUR DESTINATION ADDRESSES People send regularly their postings to haskell-cafe with several private receiver addresses, which is a bit annoying when you click "reply all"... Yes, apologies. The way the lists do the headers make it very easy to reply to individuals, and hard to reply to the list. And, last, but very high on my check-list: The implicit coercion of numeric constants: 3.14 -=- (fromDouble 3.14) etc. is sick. (Or was; I still didn't install the last version of GHC, and with Hugs it is bad). The decision is taken by the compiler internally, and it doesn't care at all about the fact that in my prelude I have eliminated the Num class and redefined fromDouble, fromInt, etc. Can't you just put "default ()" at the top of each module? I suppose you still have the problem that a numeric literal "5" means "Prelude.fromInteger 5". Can't you define your types to be instances of Prelude.Num, with no operations defined except Prelude.fromInteger? Dylan Thurston terminates his previous posting about Num with: Footnotes: [1] Except for the lack of abs and signum, which should be in some other class. I have to think about their semantics before I can say where they belong. Now, signum and abs seem to be quite distincts beasts. Signum seem to require Ord (and a generic zero...). Abs from the mathematical point of view constitutes a *norm*. Now, frankly, I haven't the slightest idea how to cast this concept into Haskell class hierarchy in a sufficiently general way... This was one thing I liked with the Haskell hierarchy: the observation that "signum" of real numbers is very much like "argument" of complex numbers. abs and signum in Haskell satisfy an implicit law: abs x * signum x = x [1] So signum can be defined anywhere you can define abs (except that it's not a continuous function, so is not terribly well-defined). A default definition for signum x might read signum x = let a = abs x in if (a == 0) then 0 else x / abs x (Possibly signum is the wrong name. What is the standard name for this operation for, e.g., matrices?) [Er, on second thoughts, it's not as well-defined as I thought. Abs x needs to be in a field for the definition above to work.] I'll tell you anyway that if you try to "sanitize" the numeric classes, if you separate additive structures and the multiplication, if you finally define abstract Vectors over some field of scalars, and if you demand the existence of a generic normalization for your vectors, than *most probably* you will need multiparametric classes with dependencies. Multiparametric classes, certainly (for Vectors, at least). Fortunately, they will be in Haskell 2 with high probability. I'm not convinced about dependencies yet. Jerzy Karczmarczuk Caen, France Best, Dylan Thurston Footnotes: [1] I'm not sure what I mean by "=" there, since I do not believe these should be forced to be instances of Eq. For clearer cases, consider the various Monad laws, e.g., join . join = join . map join (Hope I got that right.) What does "=" mean there? Some sort of denotational equality, I suppose. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Instances of multiple classes at once
(Superficially irrelevant digression:) Simon Peyton-Jones came here today and talked about his combinator library for financial applications, as in his paper "Composing Contracts". One of the points he made was that a well-designed combinator library for financial traders should have combinators that work on a high level; then, when they want to start writing their own contracts, they can learn about a somewhat smaller set of building blocks inside that; then eventually they might learn about the fundamental building blocks. (Examples of different levels from the paper: "european"; "zcb"; "give"; "anytime".) One theory is that a well-designed class library has the same property. But standard Haskell doesn't allow this; that is why I like the proposal to allow a single instances to simultaneously declare instances of superclasses. One problem is how to present the information on the type hierarchy to users. (This is a problem in Haskell anyway; I find myself referring to the source of the Prelude while writing programs, which seems like a Bad Thing when extrapolated to larger modules.) On Thu, Feb 08, 2001 at 09:41:56PM +1100, Fergus Henderson wrote: One point that needs to be resolved is the interaction with default methods. Consider class foo a where f :: ... f = ... f2 :: ... f2 = ... class (foo a) = bar a where b :: ... instance bar T where -- no definitions for f or f2 b = 42 Should this define an instance for `foo T'? (I think not.) Whyever not? Because there is no textual mention of class Foo in the instance for Bar? Think about the case of a superclass with no methods; wouldn't you want to allow automatic instances in this case? One might even go further and allow a class to declare default methods for a superclass: class Foo a where f :: ... class (Foo a) = Bar a where b :: ... b = ... f = ... Best, Dylan Thurston ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Show, Eq not necessary for Num [Was: Revamping the numeric c
Thu, 08 Feb 2001 15:11:21 +0100 (CET), Elke Kasimir [EMAIL PROTECTED] pisze:
However, what is missing for me is something like:
type Comfortable a = (Show a, Eq a, Num a) = a
or
class (Show a, Read a, Eq a) = Comfortable a
instance (Show a, Read a, Eq a) = Comfortable a
I agree and think it should be easy to add.
The latter syntax is nice: obvious what it means, not legal today.
This instance of course conflicts with any other instance of that
class, so it can be recognized and treated specially as a "class
synonym".
For Haskell, I could imagine (without having having much thought
about) in addition to the things mentioned in the beginning,
several things making supporting the "locally, fast and easy",
including a mean to define classes with implied memberships, for
example declarations saying that "Foo is the class of all types in
scope for which somefoo :: ... is defined", or declarations saying
that "class Num is locally restricted to all instances of global
Num which also belong to Eq".
Here I would be more careful. Don't know if local instances or local
classes can be defined to make sense, nor if they could be useful
enough...
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Revamping the numeric classes
Thu, 8 Feb 2001 10:51:58 -0500, Peter Douglass [EMAIL PROTECTED] pisze:
The first part of my question (not contained in your reply) is
whether it is feasible to disable a developer's access to the
"unsafe" numerical operations.
import Prelude hiding (quot, rem, (/) {- etc. -})
import YourPrelude -- which defines substitutes
You can "disable" it now. You cannot disable them entirely - anyone can
define present functions in terms of your functions if he really wants.
Whether or not an individual developer chooses to do so is another
matter.
Why only quot? There are many other ways to write bottom:
head []
(\(x:xs) - (x,xs)) []
let x = x in x
log (-1)
asin 2
error "foo"
If you "know" the value is non-zero before run-time, then that is
statically determined.
I know but the compiler does not know, and I have no way to convince it.
It is possible that the developer writes a function which returns a
nonZeroNumeric value which actually has a value of zero. However,
the value of requiring division to have a nonZeroNumeric denominator
is to catch at compile time the "error" of failing to scrutinize
(correctly or incorrectly) for zero.
IMHO it would be more painful than useful.
For most commercial software, the quality of run-time error messages
is far less important than their absence.
It would not avoid them if the interface does not give a place to
report the error:
average xs = sum xs / case checkZero (length xs) of
Just notZero - notZero
Nothing - error "This should never happen"
is not any more safe than
average xs = sum xs / length xs
and I can report bad input without trouble now:
average xs = case length xs of
0 - Nothing
l - Just (sum xs / l)
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Revamping the numeric classes
Thu, 8 Feb 2001 21:41:56 +1100, Fergus Henderson [EMAIL PROTECTED] pisze:
Should this define an instance for `foo T'?
(I think not.)
How about if the instance declaration is changed to
instance bar T where
f = 41
-- no definition for f2
b = 42
?
(In that case, I think it should.)
I don't like the idea of treating the case "no explicit definitions
were given because all have default definitions which are OK"
differently than "some explicit definitions were given".
When there is a superclass, it must have an instance defined, so if
we permit such thing at all, I would let it implicitly define all
superclass instances not defined explicitly, or something like that.
At least when all methods have default definitions. Yes, I know that
they can be mutually recursive and thus all will be bottoms...
So maybe there should be a way to specify that default definitions
are cyclic and some of them must be defined? It is usually written
in comments anyway, because it is not immediately visible in the
definitions. If not formally in the language (now any method definition
can be omitted even if it has no default!), then perhaps the compiler
could detect most cases when methods are defined in terms of one
another and give a warning.
Generally the compiler could warn if the programmer has written bottom
in an unusual way. For example
f x = g some_expression
g x = f some_expression
is almost certainly a programmer error.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Revamping the numeric classes
Thu, 08 Feb 2001 11:24:49 +, Jerzy Karczmarczuk [EMAIL PROTECTED] pisze:
The implicit coercion of numeric constants: 3.14 -=- (fromDouble
3.14) etc. is sick.
What do you propose instead?
(BTW, it's fromRational, to keep arbitrarily large precision.)
Now, signum and abs seem to be quite distincts beasts. Signum seem
to require Ord (and a generic zero...).
Signum doesn't require Ord.
signum z = z / abs z
for complex numbers.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Revamping the numeric classes
On Thu, Feb 08, 2001 at 08:30:31PM +, Marcin 'Qrczak' Kowalczyk wrote:
Signum doesn't require Ord.
signum z = z / abs z
for complex numbers.
I'd be careful here.
\begin{code}
signum 0 = 0
signum z = z / abs z
\end{code}
This is, perhaps, neither precise nor general enough.
The signum/abs pair seem to represent direction and magnitude.
According to the line of reasoning in some of the earlier posts in this
flamewar, the following constraints:
(1) z = signum z * abs z where * is appropriately defined
(2) abs $ signum z = 1
should be enforced, if possible, by the type system. This suggests
that for any type having a vector space structure over Fractional
(or whatever the hierarchy you're brewing up uses for rings with
a division partial function on them) that the result type of signum
lives in a more restricted universe, perhaps even one with a different
structure (operations defined on it, set of elements) than the argument
type, and it seems more than possible to parametrize it on the argument
type. The abs is in fact a norm, and the signum projects V^n - V^n / V.
Attempts to define these things on Gaussian integers, p-adic numbers,
polynomial rings, and rational points on elliptic curves will quickly
reveal limitations of the stock class hierarchy.
Now, whether it's actually desirable to scare newcomers to the language
into math phobia, wetting their pants, and running screaming with
subtleties like this suggests perhaps that one or more "alternative
Preludes" may be desirable to have. There is a standard Prelude, why not
a nonstandard one or two? We have the source. The needs of the geek do
not outweigh the needs of the many. Hence, we can cook up a few Preludes
or so on our own, and certainly if we can tinker enough to spam the list
with counterexamples and suggestions of what we'd like the Prelude to
have, we can compile up a Prelude for ourselves with our "suggested
changes" included and perhaps one day knock together something which can
actually be used and has been tested, no?
The Standard Prelude serves its purpose well and accommodates the
largest cross-section of users. Perhaps a Geek Prelude could
accommodate the few of us who do need these sorts of schenanigans.
Cheers,
Bill
--
j0][nD33R:#math Excel/Spreadsheet Q: What is the formula for finding
out the time passed between two dates and or two times in the same day?
MatroiDN:#math excel/spreadsheet? Hmm, this is math? Is there a GTM on
excel or maybe an article in annals about spreadsheets or maybe
there's a link from wolfram to doing your own computer work, eh?
danprime:#math jeeem, haven't you seen "Introduction to Algebraic Excel"?
danprime:#math or "Spreadsheet Space Embeddings in 2-Manifolds"
brouwer:#math i got my phd in spreadsheet theory
brouwer:#math i did my thesis on the spreadsheet conjecture
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC Core output
I would *really* love to see GHC componetized (TM); it would even be better if it would become easier to use the pieces. I would like to do experiments on smaller bits of the compiler using Hugs (ideally the whole thing!). When I was working on the Java/.NET backend I had to rebuild the whole compiler just to test a few hundred lines of code that translated Core to Java which is a major pain in the butt; I don't get a kick out of dealing with installing Cygnus, recursive multi-staged makefiles, cpp, etc. Erik "do you get a kick out of runnning the marathon with a ball and chain at your feet?" Meijer - Original Message - From: "Andrew Tolmach" [EMAIL PROTECTED] To: "'Timothy Docker'" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, February 06, 2001 2:53 AM Subject: RE: GHC Core output Timothy Docker [mailto:[EMAIL PROTECTED]] writes: We agreed that it would be a Jolly Good Thing if GHC could be persuaded to produce GHC-independent Core output, ready to feed into some other compiler. For example, Karl-Filip might be able to use it. ANDREW will write a specification, and implement it. A quick question. What is meant by "Core output"? Subsequent posts seem to suggest this is some "reduced Haskell", in which full Haskell 98 can be expressed. Am I completely off beam here? Not at all. "Core" is an intermediate language used internally by the GHC compiler. It does indeed resemble a reduced Haskell (but with explicit higher-order polymorphic types) and GHC translates full Haskell 98 into it. Currently Core has no rigorously defined external representation, although by setting certain compiler flags, one can get a (rather ad-hoc) textual representation to be printed at various points in the compilation process. (This is usually done to help debug the compiler). What we hope to do is: - provide a formal definition of Core's external syntax; - give a precise definition of its semantics (both static and dynamic); - modify GHC to produce external Core files, if so requested, at one or more useful points in the compilation sequence -- e.g., just before optimization, or just after. - modify GHC to accept external Core files in place of Haskell source files, again at one or more useful points. The first three facilities will let one couple GHC's front-end (parser, type-checker, etc.), and optionally its optimizer, with new back-end tools. Adding the last facility will let one implement new Core-to-Core transformations in an external tool and integrate them into GHC. It will also allow new front-ends to generate Core that can be fed into GHC's optimizer or back end; however, because there are many (undocumented) idiosynracies in the way GHC produces Core from source Haskell, it will be hard for an external tool to produce Core that can be integrated with GHC-produced core (e.g., for the Prelude), and we don't aim to support this. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Revamping the numeric classes
Marcin 'Qrczak' Kowalczyk writes:
| On Thu, 8 Feb 2001, Tom Pledger wrote:
|
| nice answer: give the numeric literal 10 the range type 10..10, which
| is defined implicitly and is a subtype of both -128..127 (Int8) and
| 0..255 (Word8).
|
| What are the inferred types for
| f = map (\x - x+10)
| g l = l ++ f l
| ? I hope I can use them as [Int] - [Int].
f, g :: (Subtype a b, Subtype 10..10 b, Num b) = [a] - [b]
Yes, because of the substitution {Int/a, Int/b}.
| x + y + z -- as above
|
| -- (x + y) + z -- left-associativity of (+)
|
| -- realToFrac (x + y) + z-- injection (or treating up) done
|-- conservatively, i.e. only where needed
|
| What does it mean "where needed"? Type inference does not proceed
| inside-out.
In the expression
(x + y) + z
we know from the explicit type signature (in your question that I was
responding to) that x,y::Int and z::Double. Type inference does not
need to treat x or y up, because it can take the first (+) to be Int
addition. However, it must treat the result (x + y) up to the most
specific supertype which can be added to a Double.
| What about this?
| h f = f (1::Int) == (2::Int)
| Can I apply f
h?
| to a function of type Int-Double?
Yes.
| If no, then it's a pity, because I could inline it (the comparison
| would be done on Doubles). If yes, then what is the inferred type
| for h? Note that Int-Double is not a subtype of Int-Int, so if h
| :: (Int-Int)-Bool, then I can't imagine how h can be applied to
| something :: Int-Double.
There's no explicit type signature for the result of applying f to
(1::Int), so...
h :: (Subtype a b, Subtype Int b, Eq b) = (Int - a) - Bool
That can be inferred by following the structure of the term. Function
terms do seem prone to an accumulation of deferred subtype
constraints.
Regards,
Tom
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: GHC Core Language
[moving to haskell-cafe] From: matt hellige [mailto:[EMAIL PROTECTED]] a quick question re: ghc's Core language... is it still very similar to the abstract syntax given in, for example, santos' "compilation by transformation..." (i think it was his dissertation?) and elsewhere, or has it changed significantly in the last couple of years? i only ask because i know the language used in that paper is somewhat different from the Core language given in peyton jones and lester's "implementing functional languages" from 92, and includes type annotations and so on. m The current Core language is still quite similar to what is described in Santos' work; see SL Peyton Jones and A Santos, "A transformation-based optimiser for Haskell," Science of Computer Programming 32(1-3), pp3-47, September 1998. http://research.microsoft.com/Users/simonpj/papers/comp-by-trans-scp.ps.gz But there have been some noticeable changes; for example, function arguments are no longer required to be atomic. A more recent version of Core is partially described (omitting types) in SL Peyton Jones S Marlowe, "Secrets of the Glasgow Haskell Compiler Inliner," IDL'99. http://research.microsoft.com/Users/simonpj/papers/inline.ps.gz ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Revamping the numeric classes
William Lee Irwin III wrote: The Standard Prelude serves its purpose well and accommodates the largest cross-section of users. Perhaps a Geek Prelude could accommodate the few of us who do need these sorts of schenanigans. Amen. --brian ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Haskell Implemetors Meeting
GHC transforms Haskell into "Core", which is roughly the second-order lambda calculus, augmented with let(rec), case, and constructors. This is an a small explicitly-typed intermediate language, in contrast to Haskell which is a very large, implicitly typed language. Getting from Haskell to Core is a lot of work, and it might be useful to be able to re-use that work. Andrew's proposal (which he'll post to the Haskell list) will define exactly what "Core" is. Simon | -Original Message- | From: Timothy Docker [mailto:[EMAIL PROTECTED]] | Sent: 05 February 2001 22:16 | To: [EMAIL PROTECTED] | Subject: Haskell Implemetors Meeting | | | | We agreed that it would be a Jolly Good Thing if GHC could | be persuaded to produce GHC-independent Core output, | ready to feed into some other compiler. For example, | Karl-Filip might be able to use it. | ANDREW will write a specification, and implement it. | | A quick question. What is meant by "Core output"? Subsequent posts | seem to suggest this is some "reduced Haskell", in which full Haskell | 98 can be expressed. Am I completely off beam here? | | Tim Docker | | ___ | Haskell-Cafe mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell-cafe | ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
