Class op rules

Christiaan Baaij christiaan.baaij at gmail.com
Sat Mar 7 09:19:39 UTC 2020


That workaround is fragile for me:
When I put everything into one file, the "fromList/toList" rule fires.
However, when I put the test1 and main definitions into a separate file,
the "fromList/toList" rule no longer fires.
The reason for that seems to be that " fromList' = fromList " is rewritten
to " fromList' = fromList' ", and then the strictness/demand analysis flags
it up as always bottoming.
Then in the file where we write `test1 x = fromList (toList x)`, it gets
rewritten to `test1 x = fromList' (toList x)`, after which (because of the
always bottoming) it gets rewritten to `test1 _ = case fromList' of {}`


On Sat, 7 Mar 2020 at 02:56, Dr. ÉRDI Gergő <gergo at erdi.hu> wrote:

> As a workaround, can you try this?
> https://stackoverflow.com/a/32133083/477476
>
> On Fri, Mar 6, 2020, 23:23 Christiaan Baaij <christiaan.baaij at gmail.com>
> wrote:
>
>> Hello,
>>
>> The other day I was experimenting with RULES and got this warning:
>>
>> src/Clash/Sized/Vector.hs:2159:11: warning: [-Winline-rule-shadowing]
>>     Rule "map Pack" may never fire
>>       because rule "Class op pack" for ‘pack’ might fire first
>>     Probable fix: add phase [n] or [~n] to the competing rule
>>      |
>> 2159 | {-# RULES "map Pack" map pack = id #-}
>>
>> The warning seems to suggests two things:
>> 1. "Class op" -> "dictionary projection" are implemented as rewrite rules
>> and executed the same way as other user-defined RULES
>> 2. These rules run first, and you cannot run anything before them
>>
>> Now my question is, is 1. actually true? or is that warning just a
>> (white) lie?
>> If 1. is actually true, would there be any objections to adding a "-1"
>> phase: where RULES specified to start from phase "-1" onward fire before
>> any of the Class op rules.
>> I'm quite willing to implement the above if A) Class op rules are
>> actually implemented as builtin RULES; B) there a no objections to this
>> "-1" phase.
>>
>> Thanks,
>> Christiaan
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200307/f613e4b7/attachment-0001.html>


More information about the ghc-devs mailing list