#2110: Rules to eliminate casted id's
---------------------------------+------------------------------------------
Reporter: igloo | Owner:
Type: feature request | Status: new
Priority: lowest | Milestone: 7.6.2
Component: Compiler | Version: 6.8.2
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by nomeata):
Hi,
Replying to [comment:26 simonpj]:
> Your previous comment ("I find I disagree").
it seems that this sentence was truncated...
> But I don't see a good solution at the moment:
> * I really do not want anything relying on `unsafeCorece`. There is
nothing ill-typed going on here, and it would be horrible to subert the
type system to do something the (FC) type system can express perfectly
well.
The problems seems to me that FC is able to express it nicely, but Haskell
is not. But RULES are being written by Haskell programmers. Now there are
two alternatives:
* expose FC features (```cast```, coercions) to the Haskell programer,
even if only when specifying RULES, or
* find a reasonable and – for the Haskell programmer – intuitive
approximation to what should be there that is still Haskell.
I was currently exploring the second path. For that, there needs to be a
way to match newtype constructors and deconstructors, without having to
talk about type casts. A LHS ```map unsafeCoerce``` would fit somewhat,
but maybe this placeholder is misleading. One could introduce a new name
for this purpose, say ```map (casted id)``` or ```map
thisIsANewtypeConstructorOrDeconstructor``` or any other new name. This is
probably the easier part.
But what to put on the RHS? You want that in the FC cast that will be
there, the equality is constructed from the equality on the LHS. I feel
that this is not possible without exposing FC features to the Haskell
level – hence my suggestion to use unsafeCoerce on the RHS. One could also
try a different name there, but it would not gain much.
I am uncomfortable with the other approach of exposing FC casts and stuff
to the Haskell user. Where else has this been done before? One may argue
that people who write RULES already have to know how to read core,
otherwise they will never know why their rules work or not... but I don’t
believe this is wanted.
> * I really do not want to magically infer that a function is map-like.
That seems terribly fragile to me (what about mutual recursion, types with
multiple parameters, non-uniform recursion etc). At most one could make
a special case for lists.
I agree that this wasn’t a very good idea, and anyways such an automatic
RULE generation would be independent of the issue at hand.
> Generally the GHC story has been, lacking a good way forward, to wait
until someone has a neat idea, rather than to implement a hack that we
later regret. That's where I am on this one at the moment.
I agree. I will try to come up with ideas until I run out of them or a
neat one appears, if you don’t mind :-)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2110#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
