[Fwd: handling embedded spaces in output from ghc -M]
Hi,
I never heard a reply to this.
Is there any hope of getting this fixed?
If not, I'll have to ship my own private binary release of greencard
under windows, just so that it doesn't install in a directory with an
embedded space(!) :-(
Thanks,
-antony
--
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
[EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony
---BeginMessage---
I'm running in to a problem using ghc -M to generate dependencies when
there are embedded spaces in the path name to a dependency.
If I run ghc -M using something like:
$ ghc -M -optdep-f -optdep.hs_dependences
-iC:/Program Files/GreenCard/lib/ghc JNI.hs
it correctly computes the dependencies, but generates the following output:
--
# DO NOT DELETE: Beginning of Haskell dependencies
JNI.o : JNI.hs
JNI.o : ./GCJNI.hi
JNI.o : C:/Program Files/GreenCard/lib/ghc/StdDIS.hi
--
note that the space character in the path name on the last line is not
escaped, so make will interpret this as two seperate paths.
I believe a fix for this is to simply escape any space characters in
path names emitted by ghc -M by prefixing them with a backslash ('\').
I have tested this by hand editing my generated dependencies and it
seems to work.
As far as I know, this bug will also occur on Unix systems, which may
also have embedded spaces in path names.
I would be extremely grateful if you could fix this, as I can't ship a
version of my libraries that works with the binary distribution of
GreenCard on Windows until this is solved.
Thanks!
-antony
--
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
[EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony
---End Message---
RE: Typing RULES
Actually, the two 'b's aren't the same, as you will see if you
use -dppr-debug, or if you look at the .hi file. So the typing
for the rule looks right to me. If it isn't matching when you think
it should, it must be for some other reason. (Do you agree?)
Perhaps -ddump-rules should 'tidy' the rule so that it doesn't
print variables that look the same but arent.
Simon
| -Original Message-
| From: Josef Svenningsson [mailto:[EMAIL PROTECTED]]
| Sent: 20 February 2002 17:01
| To: [EMAIL PROTECTED]
| Subject: Typing RULES
|
|
| Hi!
|
| Ghc seems to have some problems in inferring the most general
| types of RULES pragmas. The bug was not present in 5.02.1 but
| shows up in a cvs version checked out yesterday.
|
| Here's the problem:
| Consider the following example from the user's guide:
|
| {-# RULES
| map/map forall f g xs. map f (map g xs) = map (f.g) xs #-}
|
| When I compile with -ddump-rules I get the following rule:
|
| map/map __forall {@ b
| @ b
| @ a
| f :: (b - b)
| g :: (a - b)
| xs :: [a]}
| GHC.Base.map @ b @ b f (GHC.Base.map @ a @ b g xs)
| = GHC.Base.map @ a @ b (GHC.Base.. @ b @ b @ a f g) xs ;
|
| (And it also turns out this rule is listed among the imported
| rules, not the local ones, which is a bit confusing.)
|
| The rule says that f must have type b - b for some b. This
| is clearly Bad as the matching algorithm also matches types
| and the rule will not be fired in all the cases it should.
|
| When I add a type signature for f then g get type b - b. In
| order to get the desired behaviour I have to add type
| signatures to both f and g.
|
| I hope this is easy to fix.
|
| Cheers,
|
| /Josef
|
| PS. Would it be possible to add a -fwarn-pragma which warns
| when a pragma is ignored? It is quite frustrating when some
| rules are silently ignored and you keep wonder why the rules
| don't fire. I guess I've learnt to use -ddump-rule the hard way...
|
| ___
| Glasgow-haskell-bugs mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-bugs
|
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: handling embedded spaces in output from ghc -M]
Hi, you're making a mountain out of a molehill; couple of workarounds spring to mind: * transform the -i path you feed to GHC -M, i.e., something like ghc -M -i`cygpath -w -s c:\Program Files\GreenCard`/lib/ghc * post-process the generated dependencies file to insert the double quotes and/or escape the spaces yourself. --sigbjorn - Original Message - From: Antony Courtney [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 25, 2002 00:14 Subject: [Fwd: handling embedded spaces in output from ghc -M] Hi, I never heard a reply to this. Is there any hope of getting this fixed? If not, I'll have to ship my own private binary release of greencard under windows, just so that it doesn't install in a directory with an embedded space(!) :-( Thanks, -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
(no subject)
Hi, I typed: ghc Main.hs and then GHC said: GHC.EXE: panic! (the `impossible' happened, GHC version 5.02.2): Maybe.fromJust: Nothing Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. -- Maarten ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc-5.02.2 panic (was: (no subject))
Hi, looks like a bona fide bug; thanks for reporting it. In order to be able to fix it, any chance of you sending us that Main.hs? thanks, --sigbjorn - Original Message - From: Loffler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 25, 2002 12:47 Subject: (no subject) Hi, I typed: ghc Main.hs and then GHC said: GHC.EXE: panic! (the `impossible' happened, GHC version 5.02.2): Maybe.fromJust: Nothing Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. -- Maarten ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Does GHC simplify RULES?
| Suppose I have the following RULES pragma:
|
| {-# RULES
| foo forall a . foo a = (\x - bar x) a
| #-}
|
| Ok, it's stupid but I have examples where this is motivated, trust me.
|
| Now, it seems that GHC simplifies the rule because what I get
| when compiling it with -ddump-rules is the following rule:
|
| foo __forall {@ t_a2UD a :: t_a2UD}
| Test.foo @ t_a2UD a
| = Test.bar @ t_a2UD a ;
|
| It's \beta-reduced! Argh! Why is that?
Because if it's left unsimplified, the first thing that will happen
after
the rule fires is that the beta reduction will be done. So why not
do it first? (The desugarer can leave quite a lot of crud around,
so a gentle simplification is indeed run.)
You'll need to explain your motivation a bit more. Perhaps give
the rules you'd like along with a sample simplification sequence.
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: core language external representation
Not yet. But Jeff Lewis is (I believe) planning to work actively on this. Simon | -Original Message- | From: Hal Daume III [mailto:[EMAIL PROTECTED]] | Sent: 24 February 2002 16:55 | To: GHC Users Mailing List | Cc: [EMAIL PROTECTED] | Subject: core language external representation | | | I know it's possible to get ghc to emit core at multiple | points, but is it possible to get it to read in core? For | instance, if a file is named blah.hco, perhaps parse it and | interpret it in the Core language format? If this isn't | currently possible, is there a plan to make it so? | | - Hal | | -- | Hal Daume III | | Computer science is no more about computers| [EMAIL PROTECTED] | than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: IArray
After reading your email i went to the discussion of IArray on the haskell doc page (http://www.haskell.org/ghc/docs/latest/set/sec-iarray.html) and am somewhat disturbed by it. There is the introduction of the following class: class HasBounds a where bounds :: Ix ix = a ix e - (ix,ix) which is then used in: class HasBounds a = IArray a e where array :: Ix ix = (ix,ix) - [(ix,e)] - a ix e (!) :: ... (//) :: ... It was factored this way because for certain array types we define a separate IArray instance for each element type (ie. for the unboxed UArray types), where for these types the definition of 'bounds' doesn't depend on the element type so it would be wasteful to include it in the IArray class. class Ix ix = HasBounds a ix | a - ix where bounds :: a - (ix,ix) Surely you mean class Ix ix = HasBounds a ix | a - ix where bounds :: a e - (ix,ix) ^^ don't forget the 'e'! that way, we would efine things like: instance Ix ix = HasBounds (Array.Array ix) ix where ... instance Ix ix = HasBounds (UArray ix) ix where ... Yes, this looks reasonable. Then of course Ix becomes a superclass of HasBounds and hence also of IArray, which will change quite a few types. I do remember trying various renderings of these two classes before I settled on these though: in particular I think making Ix a superclass caused problems (but I can't remember what exactly). Perhaps you could try it and let me know? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Does GHC simplify RULES?
On Mon, 25 Feb 2002, Simon Peyton-Jones wrote:
| Suppose I have the following RULES pragma:
|
| {-# RULES
| foo forall a . foo a = (\x - bar x) a
| #-}
|
| Ok, it's stupid but I have examples where this is motivated, trust me.
|
| Now, it seems that GHC simplifies the rule because what I get
| when compiling it with -ddump-rules is the following rule:
|
| foo __forall {@ t_a2UD a :: t_a2UD}
| Test.foo @ t_a2UD a
| = Test.bar @ t_a2UD a ;
|
| It's \beta-reduced! Argh! Why is that?
Because if it's left unsimplified, the first thing that will happen
after
the rule fires is that the beta reduction will be done. So why not
do it first? (The desugarer can leave quite a lot of crud around,
so a gentle simplification is indeed run.)
You'll need to explain your motivation a bit more. Perhaps give
the rules you'd like along with a sample simplification sequence.
Alright. Some more motivation is probarbly justified here. This message is
a bit lengthy. If you're not very interested in this I suggest you stop
reading now.
What I am really trying to do is trying to express the foldr/build rule
without build. Intuitively this should be possible since build just sits a
a tag on a function saying that it has the right type.
Expressing the foldr/build-build (read: foldr build minus build) rule is
easy:
{-# RULES
foldr fuse forall c n (g :: forall b . (a - b - b) - b - b).
foldr c n (g (:) []) = g c n
#-}
Now, the problem is writing list producing functions so that they get the
right type. Let's look at an example, our favourite function map. Suppose
we have the following code snippet:
foldr p z (map f xs)
How do we write map so that the intermediate list is not built? We can
define map in the following way:
map f xs = mapFB f xs (:) []
mapFB is a function where all the conses and nils are abstracted out. Now,
we can arrange so that map gets inlined in the above example. So for the
rule foldr fuse to apply mapFB must have the right type. Note that mapFB
takes four arguments and g in the rule takes two. BUT, g takes a type
argument before these two arguments because it is polymorphic. Therefore
mapFB must also take a type argument in that position in order for the
rule to apply. With this in mind we might try to give mapFB the following
type:
mapaux :: (a - b) - [a] - (forall c. (b - c - c) - c - c)
But GHC completely ignores our explicit forall quantifier and moves the
quantification to the top level. Bummer!
OK, so we want to force GHC to put a type lambda where we want to. My idea
was then to have a rule that generates a piece of polymorphic code and
insert some redundancy so that GHC would not understand that it could
remove the type lambda. Here's what I tried:
{-# RULES
map forall (f :: a - b) xs .
map f xs =
((\c n - mapaux f xs c n) :: forall c . (a - c - c) - c - c) (:) []
#-}
The idea is to fool GHC to insert a lambda before my explicit lambdas in
the rhs of the rule. Then the foldr fuse rule whould fire on the
example above. Or will it? It depends on how GHC does things and I'm not
100% sure. If GHC start simplifying something which just came out of an
application of a rule then I guess this trick is really wasted. What I
hoped for was this:
foldr p z (map f xs) ={ Rule map }=
foldr p z ((\c n - mapaux f xs c n) (:) []) ={ Rule foldr fuse }=
(\c n - mapaux f xs c n) p z ={ \beta reduction }=
mapaux f xs p z
In actual GHC the \beta reduction will probarbly happen before the second
rule application. But I suppose I would have found that out if the rule
was not simplified, now there was no way to tell.
Ok, so maybe you guys have already though about removing build and decided
against it. It might not be the most important problem in the world. But
intuitively build is completely redundant and that really bugs me. That's
why I've been playing around with this.
Cheers,
/Josef
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Does GHC simplify RULES?
Josef,
Ah, I see. I think you are trying to do something quite hard,
akin to higher-order matching, which is the kind of thing Oege's
MAG system does. I'm copying him so he can confirm or deny.
In general, it is true that
(\x. ...x...) E
might match (f E), for some expression E, where
(...E...)
does not match. But since the two are beta-convertible, it's hard
to ensure that the expression has the right form. Higher-order
matching is simply matching modulo beta, which means that it
wouldn't matter which form it's in.
GHC does not do HO matching; it is tricky and expensive, and
I think not suitable for a compiler. You are trying to help GHC with
cunning crafting of your program, but as you observe it's all terribly
fragile. That's not GHC's fault --- it's just that hand-driving HO
matching
is a fragile process.
I have to say that I'm not very optimistic. I doubt that moving
in the direction of switching off beta here and there would be a robust
solution.
Simon
| -Original Message-
| From: Josef Svenningsson [mailto:[EMAIL PROTECTED]]
| Sent: 25 February 2002 14:30
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: RE: Does GHC simplify RULES?
|
|
| On Mon, 25 Feb 2002, Simon Peyton-Jones wrote:
|
|
| | Suppose I have the following RULES pragma:
| |
| | {-# RULES
| | foo forall a . foo a = (\x - bar x) a
| | #-}
| |
| | Ok, it's stupid but I have examples where this is
| motivated, trust
| | me.
| |
| | Now, it seems that GHC simplifies the rule because what I
| get when
| | compiling it with -ddump-rules is the following rule:
| |
| | foo __forall {@ t_a2UD a :: t_a2UD}
| | Test.foo @ t_a2UD a
| | = Test.bar @ t_a2UD a ;
| |
| | It's \beta-reduced! Argh! Why is that?
|
| Because if it's left unsimplified, the first thing that will happen
| after the rule fires is that the beta reduction will be
| done. So why
| not do it first? (The desugarer can leave quite a lot of
| crud around,
| so a gentle simplification is indeed run.)
|
| You'll need to explain your motivation a bit more. Perhaps
| give the
| rules you'd like along with a sample simplification sequence.
|
| Alright. Some more motivation is probarbly justified here.
| This message is a bit lengthy. If you're not very interested
| in this I suggest you stop reading now.
|
| What I am really trying to do is trying to express the
| foldr/build rule without build. Intuitively this should be
| possible since build just sits a a tag on a function saying
| that it has the right type.
|
| Expressing the foldr/build-build (read: foldr build minus
| build) rule is
| easy:
|
| {-# RULES
| foldr fuse forall c n (g :: forall b . (a - b - b) - b - b).
|foldr c n (g (:) []) = g c n
| #-}
|
| Now, the problem is writing list producing functions so that
| they get the right type. Let's look at an example, our
| favourite function map. Suppose we have the following code snippet:
|
| foldr p z (map f xs)
|
| How do we write map so that the intermediate list is not
| built? We can define map in the following way:
|
| map f xs = mapFB f xs (:) []
|
| mapFB is a function where all the conses and nils are
| abstracted out. Now, we can arrange so that map gets inlined
| in the above example. So for the rule foldr fuse to apply
| mapFB must have the right type. Note that mapFB takes four
| arguments and g in the rule takes two. BUT, g takes a type
| argument before these two arguments because it is
| polymorphic. Therefore mapFB must also take a type argument
| in that position in order for the rule to apply. With this in
| mind we might try to give mapFB the following
| type:
|
| mapaux :: (a - b) - [a] - (forall c. (b - c - c) - c - c)
|
| But GHC completely ignores our explicit forall quantifier and
| moves the quantification to the top level. Bummer!
|
| OK, so we want to force GHC to put a type lambda where we
| want to. My idea was then to have a rule that generates a
| piece of polymorphic code and insert some redundancy so that
| GHC would not understand that it could remove the type
| lambda. Here's what I tried:
|
| {-# RULES
| map forall (f :: a - b) xs .
| map f xs =
| ((\c n - mapaux f xs c n) :: forall c . (a - c - c) -
| c - c) (:) [] #-}
|
| The idea is to fool GHC to insert a lambda before my explicit
| lambdas in the rhs of the rule. Then the foldr fuse rule
| whould fire on the example above. Or will it? It depends on
| how GHC does things and I'm not 100% sure. If GHC start
| simplifying something which just came out of an application
| of a rule then I guess this trick is really wasted. What I
| hoped for was this:
|
| foldr p z (map f xs) ={ Rule map }=
| foldr p z ((\c n - mapaux f xs c n) (:) []) ={ Rule foldr
| fuse }= (\c n - mapaux f xs c n) p z ={ \beta reduction
| }= mapaux f xs p z
|
| In actual GHC the \beta reduction will probarbly happen
| before the second rule application. But I
Re: core language external representation
On Monday 25 February 2002 02:55 am, Simon Peyton-Jones wrote: Not yet. But Jeff Lewis is (I believe) planning to work actively on this. Well put. I plan on working on this, but no sooner than mid-march. --Jeff ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
multiple processes and threads
I have an application that uses multiple processes and multiple threads together. What's the best way to detect child process terminations? The initial thread in the inital process serves as driver of the application. It creates child processes and threads to carry out portions of the computation. A natural way to have the driver detect termination of these child processes and threads would be to have the driver listen on a single MVar to which termination notices are posted. Child threads would simply post their termination notices directly. For child processes, I'd like to have a single thread in the initial process execute (getAnyProcessStatus True False) repeatedly, posting a termination notice each time such a call returns. However, with the current implementation of Concurrent Haskell, when the thread pends on the getAnyProcessStatus call, the entire initial process pends. The best solution I've come up with so far, which is unsatisfying, is to have this thread poll periodically (that is, loop over (getAnyProcessStatus False False) and (threadDelay)). Is there a better way? Dean Herington ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Doubts in GHC
Hello, I´m new in this list and I think that it´s a very good idea, because we can show our doubts. I have a doubt in GHC: How can we include a folder in the compiling process? Example: If one file called main.hs requires some others modules that are in one folder, how can compile it in GHC and include this folder? Thanks, Fernando _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
FW: Survival of generic-classes in ghc
I had meant to send this message to the Haskell list, because I think
there may be some readers who have good ideas about it.
Simon
-Original Message-
From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]]
Sent: 20 February 2002 21:16
To: Patrik Jansson; Haskell Cafe List
Cc: Ralf Hinze; Johan Jeuring
Subject: RE: Survival of generic-classes in ghc
| and I know from testing earlier versions that the
| generic-classes support was pretty buggy. Is there any hope
| of a revival? Does it already work in CVS? I suspect it will
| rot away if nobody works on it.
|
| Any comments from the implementors - does the idea fit well
| with ghc? Is it a lot of work to make it more stable?
No, it should not be a lot of work to revive, and I will do it. Keep
bugging me until I do.
One thing that is slowing me down is a design uncertainty: how to deal
cleanly with constructors. To write read, show, etc, one needs access
to the constructor name, fixity etc. We dance around that a little in
the paper. I'm thinking of this design:
-- An example data type
data List a = Nil | Cons a (List a)
-- The ring type derived from it
-- Note the Con wrapped around the constructors
data ListO a = Con NilT 1 :+: Con ConsT (a :*: List a)
-- Con is part of the Generics library, like 1, :*:, :+: newtype Con c a
= Con a
class ConCls c where
name :: c - String
arity :: c - Arity
..etc..
data NilT -- Phantom types
data ConsT -- one per constructor
instance ConCls NilT where
name _ = Nil
...etc...
instance ConCls ConsT wher
name _ = Cons
...etc...
Now you can write
class Show a where
show :: a - String
show {| Con c t |} (Con x) = (name (undefined::c)) ++ show x
...etc..
Note the undefined::c; it is really just a type argument to name, so
that we get the string for the right constructor. It's a bit clunky,
though. Another possiblity would be to make the ConCls class look like
this
class ConCls c where
name :: String
arity :: Int
...etc...
Now we'd have to give an explicit type argument at the call site:
show {| Constr c t |} (Con x) = (name {| c |}) ++ show x
I quite like the thought of being able to supply explicit type
arguments but I don't konw how to speak about the order of type
parameters. What order does map takes its two type parameters in?
Another question is whether we need an indication that we have reached
a field of the constructor. Should we have:
data ListO a = Con NilT (Field 1) :+: Con ConsT (Field a :*: (Field List
a))
newtype Field a = Field a
Without this, it's hard to write a generic function to count the number
of fields of the data type. But in general, one might want to know when
making the transition from this type to the argument types of the
constructors.
I think that the main reason I'm not making much progress is that I
don't know what design choices to make. I'd be glad to discuss it with
interested parties.
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Is there a more-robust FiniteMap?
Using FiniteMap, I often run into robustness problems. same (?) here! a student of mine recently came across a similar problem (with a hand-made search tree): he expected to run listToFM $ [(0, ()) | i - [0..10]] in constant space, but instead it took all the stack and/or heap. we made the data constructors strict, and used strict fold for insertion. this helped with ghc (but not wih hugs). are there cases where non-strict behaviour of a finite-map implementation is useful? I can't think of any (analogy: there is no lazy sorting either) - so perhaps the above suggestions should be take as defaults? perhaps ghc already does this (by specializing) when it uses FiniteMap.lhs. regards - -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Verba Volant
The following email address, [EMAIL PROTECTED] has been removed from the Verba Volant Newsletter list. If you did not cancel your email address or you wish to continue receiving Verba Volant, please send an e-mail to [EMAIL PROTECTED] Thank you and best regards, Verba Volant ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: H98 Report: expression syntax glitch
On Mon, Feb 25, 2002 at 03:38:39PM +, Malcolm Wallace wrote: nhc98 manages to parse and compile both expressions with ease, no doubt because it uses parser combinators rather than a table-driven mechanism. Yes, but it reports type errors for the variants f x = (\x - x*x .) g x = (if x then 1 else 2 +) and it accepts h = (let op x y = y in 3 `op`) so I suspect it's misparsing these as f x = (\x - (x*x .)) g x = (if x then 1 else (2 +)) h = (let op x y = y in (3 `op`)) and in the earlier example it didn't make any difference. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: H98 Report: expression syntax glitch
In the table of precedence in the original Report (now deleted in the revised Report), it makes it clear that a rightward-extending let, if, or lambda has a lower precedence than an infix operator, so for instance the parse h = (let op x y = y in (3 `op`)) is correct and h = ((let op x y = y in 3) `op`) is not. Actually the table claims that 'let' has a higher precedence than infix operators, so your second example above would be the correct parse according to the table. This may be one of the reasons it was removed, I can't remember now. Also, the table wasn't supposed to contain any extra information that isn't already in the grammar (Section 3: As an aid to undertanding the grammar, Table 1 shows the relative precedences...), so if the table is required to understand a particular parse, it would indicate a deficiency or ambiguity in the grammar. On the other hand, one way to fix this problem *is* to specify the relative precedence of 'let' co. as compared to infix operators (namely that 'let' should have a lower precedence). That would be a reasonable fix for the H98 report, IMO. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Help
Hi, I'm writting a small parser in Haskell and, when it is all done, I get the following problem: Type Binding. The thing is, I have 3 main functions: 1) Read the file, its type is: [Char] -IO [Char] (see InputOutput.hs) 2) Parse a string (using words and readDec), its type is: Integral a = [Char] - [a] (see Parse.hs) 3) Parse a list of integer, its type is: [Float] - [[Float]] (Functions.hs) Now the problem is that I cannot run the first function, then use its results as an input of the second function and, finally, its results as the input of the third function. How can I fix this without modifing all my functions because they, independly, works fine. Juan From [EMAIL PROTECTED] Thu Feb 14 16:53:00 2002 Date: 08 Feb 2002 15:21:41 -0300 From: Maxi Combina [EMAIL PROTECTED] To: Juan M. Duran [EMAIL PROTECTED] Subject: Re: Problems ya deberiamos cambiar el subject, no? pero asi esta bueno! El jue, 07-02-2002 a las 09:37, Juan M. Duran escribió: Antes que me olvide, necesito: - La cancion que hicimos (quiero que la lea la Cari) bueno, te la adjunto (es un .doc). fijate que la acabo de abrir con soffice (si, porque el modem desde win no quiere andar mas... te acordar que ya el año pasado te habia preguntado por el asunto? resulta que cuando uno reinstala win, no quiere andar. tenes que renegar un monton hasta que de algun modo empieza a andar) Bueno, el punto que el soffice no me muestra el ultimo renglon de la cancion. No se si él lo ve mal o si realemente no esta. Por las dudas te mando la ultima estrofa (que incluye --obviamente-- el último renglon: Un consejo muy piola queremos darte no vengas a este lugar a congelarte - El temita ese del mp3 en linux, recuerda?, bueno, me diste un executable que no se que hacia (algo con la dma), bueno, ese ejecutable no existe, por lo menos en mi computador. ops, entonces no sera eso. de todos modos, ese ejecutable esta muy bueno para modificar el comportamiento del duro. es parte de un paquete que se llama hdparm (asi tambien se llama el ejecutable). en tu cd de mdk 8.0 seguro que esta, sino, en la red. - Me estan ensenhando a tocar la guitarra, estoy realmente practicando y me gusta, ya se algunos acordes, los basicos vio (Do, Re, Mi, Sol, La) y ni siquiera son todos, je je. En fin, te acordas cuando me dabas clases, habias dicho que existia algo (no se, creo que era #) que era indempotente, si te acordas decimelo porque estoy meta y meta discutir con cari sobre eso, solo que no recuerdo lo que era. AH, si tenes los acordes de alguna cancion conocida por mi y que sea facil, mandalo. no, idempotente no era, ya que un operador idempotene (llamemosle E) tiene la propiedad de que EoE=E (lease E compuesto con E igual a E). Ese bicho que decis (#) es el sostenido. Provoca que la nota a la cual se le aplique se eleve en 1/2 tono. A ver: la nota Do es la nota Do y punto. La nota #do es do + 1/2 tono. Si se trata de un acorde (conjunto de notas), entonces el # provoca que todas sus notas se eleven 1/2 tono. Por ejemplo: el acorde DO mayor esta compuesto por 3 notas: do, mi y sol por lo tanto, #DO sera: do#, fa y sol# (notar que no puse #mi, ya que #mi=fa) (notar que en minusculas estan las notas y en mayusculas los acordes) El complemento de # es el bemol (no me da el teclado para dibujarlo). Lo que hace el bemol es restar 1/2 tono en vez de sumar. El # y el bemol son aditivos, i.e., ##do=#(#do)=do + 1/2 tono + 1/2 tono=re. por ejemplo: #(bemol)do=do - 1/2 tono + 1/2 tono=do bemol(fa)=fa - 1/2 tono = mi ah, ésta es la tabla de notas (se indica en terminos de #): do #do re #re mi fa #fa sol #sol la #la si do notar que todos tienen # salvo mi (ya que #mi=fa) y si (pues #si=do) Antes de mandarte una cancion, te mando la notacion usual (se llama notacion americana, creo). La idea es no escribir tanto (DO mayor, RE menor, etc son demasiadas letras). Primero, una tabla de equivalencia: (by heart, man) DO = C RE = D MI = E FA = F SOL = G LA = A SI = B Si ponemos C sin ningun aditivo, entonces es un DO mayor,. para indica el menor (DO menor), ponemos Cm. La septima: C7 Cambiar el bajo: D/F# (esto es, RE con bajo #FA) etc Una cancion facil: acabo de sacar losing my religion: Intro: F - Am - F - AM - G (no sé la letra) estrofa: Am - Em un par de veces (no se cuantas exactamente) Dm - G - Am bueno, escuchala. una mas facil: Mujer amante: = NOTACION= entre parentesis el acorde adecuado en el momento adecuado ;-) Intro: la obviamos, no calienta. Empezar en Bm Siento el calor de toda tu (G) piel en mi cu(A)erpo otra vez Est(Bm)rella fugaz enci(D)ende mi (A) sed, misteriosa mujer por tu am(G)or sensual cuanto me (Bm)das? Haz que mi (A) sueño (Em) sea un(D)a verdad dame tu (G) alma hoy hacia el ri(Bm)tual Llévame al (A) mundo (Em) donde (F#) pueda sonñar (Bm)U (D)debo saber si es (A)verdad
Re: H98 Report: expression syntax glitch
On Mon, Feb 25, 2002 at 05:07:35PM -, Simon Marlow wrote: On the other hand, one way to fix this problem *is* to specify the relative precedence of 'let' co. as compared to infix operators (namely that 'let' should have a lower precedence). That would be a reasonable fix for the H98 report, IMO. Except that it would break programs containing expressions like 1 + let x = 2 in e or (if you do the same for lambda) f $ \x - e The old table had let (and if and lambda) in two places, which is more less what GHC/Hugs do, but not a mere clarification. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Survival of generic-classes in ghc
| Another possiblity would be to make the ConCls class look like this
| class ConCls c where
|name :: String
|arity :: Int
|...etc...
|
| Now we'd have to give an explicit type argument at the call site:
|
|show {| Constr c t |} (Con x) = (name {| c |}) ++ show x
|
| I quite like the thought of being able to supply explicit type
| arguments but I don't konw how to speak about the order of type
| parameters. What order does map takes its two type parameters in?
|
| Sorry, this seems like a non-sequitur to me?
|
| 'map' has type '(a-b) - [a] - [b]'; supplying explicit
| type parameters would mean giving values to 'a' and 'b'. If
| I wanted to propose notation for this, I would suggest, e.g.,
| (map :: (String - Int) - [String] - [Int]) length
| [Hello, World]
|
| 'name' (above) has type 'String'; the '{| c |}' is not
| providing a type parameter in the same sense.
Yes it is. 'name' would have type
forall c. ConCls c = String
It requires a type argument, just like map.
Simon
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Help
You probably want to do something like this:
main =
do {
contents - input twoboxes.dat
return (control (parser contents))
}
At 11:53 25-02-02 -0300, Juan M. Duran wrote:
Hi, I'm writting a small parser in Haskell and, when it is all done, I get
the following problem: Type Binding.
The thing is, I have 3 main functions:
1) Read the file, its type is: [Char] -IO [Char] (see InputOutput.hs)
2) Parse a string (using words and readDec), its type is: Integral a =
[Char] - [a] (see Parse.hs)
3) Parse a list of integer, its type is: [Float] - [[Float]]
(Functions.hs)
Now the problem is that I cannot run the first function, then use its
results as an input of the second function and, finally, its results as
the input of the third function.
How can I fix this without modifing all my functions because they,
independly, works fine.
Juan
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Help
I thing that wont works, look:
contents :: IO [Char]
parser :: Integral a = [Char] - [a]
control :: [Float] - [[Float]]
The two problems are:
1) The input of parser. Doesnt match with the type of input
2) The input of control (or the output of parser). Doesn match
with the type of the next function.
On Mon, 25 Feb 2002, Rijk J. C. van Haaften wrote:
You probably want to do something like this:
main =
do {
contents - input twoboxes.dat
return (control (parser contents))
}
At 11:53 25-02-02 -0300, Juan M. Duran wrote:
Hi, I'm writting a small parser in Haskell and, when it is all done, I get
the following problem: Type Binding.
The thing is, I have 3 main functions:
1) Read the file, its type is: [Char] -IO [Char] (see InputOutput.hs)
2) Parse a string (using words and readDec), its type is: Integral a =
[Char] - [a] (see Parse.hs)
3) Parse a list of integer, its type is: [Float] - [[Float]]
(Functions.hs)
Now the problem is that I cannot run the first function, then use its
results as an input of the second function and, finally, its results as
the input of the third function.
How can I fix this without modifing all my functions because they,
independly, works fine.
Juan
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
a more practical version of getLine???
Hi, I'm writing a program for my final project at uni and I've come across the following annoying bug in my program. Basically, I have an interactive text prompt and I wish to be able to write commands into the prompt. I am currently using the function 'getLine', which as it's name suggests reads a line of text from the prompt. Unfortunately, when the delete key is used while writing to the prompt, the output differs (so typing loaf then 'delete' and then d does not seem to produce the same output as typing load). Also, the left and right arrow keys don't work, as they do in any normal text prompt. Any suggestins as to an alternative method to read the input??? (I'm by no means a Haskell expert btw, so I may have to be spoon fed!) thanks for your help, Rich. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
