Split `Indigo.Prelude`
Clarification and motivation
Indigo.Prelude
was intended first and foremost to define all the hiding
rules in one place (it is even in the module documentation), however it is also the only thing that we export with the idea that import Indigo
should be the only necessary import for a module implementing a contract.
This was fine at first, but considering that we are using RebindableSyntax
and similar more and more and replacing existing stuff from Prelude
(see #124 (closed) #135 (closed) #136 (closed)), this is creating a lot of conflicts to resolve.
However Indigo is now split in a Frontend
, a Backend
and an Internal
side, so we should probably split the two uses of Indigo.Prelude
as well. For example, there is no reason for the Backend
to not use standard Prelude
s if/then/else
or fromInteger
or basic operators, however we want to export the replacement of each of these from the Frontend
in Indigo
.
So we should have an Indigo.Backend.Prelude
and an Indigo.Frontend.Prelude
(or just Indigo.Prelude
) and export only the second one in Indigo
.
Acceptance criteria
Indigo.Prelude
is split in two parts:
- one with the
hiding
rules common to modules of theindigo
package and is used in most of them (especially in theBackend
) - one with the
hiding
of anything fromPrelude
that is conflicting with any of the exported modules.
Only the second one should be exported as part of the Indigo
module