-
Notifications
You must be signed in to change notification settings - Fork 26
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
7 changed files
with
96 additions
and
52 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,59 @@ | ||
{-# LANGUAGE TemplateHaskell, Rank2Types, ScopedTypeVariables, PostfixOperators #-} | ||
|
||
module Theory.Drasil.Realms (Realm, RealmVariant, | ||
mkRealm, mkRealmForQuant, mkRealmVariant) where | ||
|
||
import Control.Lens ((^.), view, makeLenses, makeLensesFor) | ||
import Data.List (union) | ||
import qualified Data.List.NonEmpty as NE | ||
|
||
import Language.Drasil | ||
|
||
-- TODO: Need a system for instantiating Realms into QDefs via "selecting" variants | ||
|
||
-- | 'RealmVariant's are partial components of QDefinitions, containing only | ||
-- the defining expressions and descriptions. | ||
-- Any 'RealmVariant' paired with a 'QuantityDict' will form a "whole" 'QDefinition'. | ||
data RealmVariant = RV { | ||
_cd :: [UID], -- ^ Concept domain | ||
_rvDesc :: Sentence, -- ^ Defining description/statement | ||
_expr :: Expr -- ^ Defining expression | ||
} | ||
makeLensesFor [("_expr", "expr")] ''RealmVariant | ||
|
||
-- | 'Realm's are QDefinition factories, used for showing one or more ways we | ||
-- can define a QDefinition | ||
data Realm = Realm { | ||
_rUid :: UID, -- ^ UID | ||
_qd :: QuantityDict, -- ^ Underlying quantity it defines | ||
_rDesc :: Sentence, -- ^ Defining description/statement | ||
_rvs :: NE.NonEmpty RealmVariant -- ^ All possible/omitted ways we can define the related quantity | ||
} | ||
makeLenses ''Realm | ||
|
||
|
||
instance HasUID Realm where uid = rUid | ||
instance HasSymbol Realm where symbol = symbol . (^. qd) | ||
instance NamedIdea Realm where term = qd . term | ||
instance Idea Realm where getA = getA . (^. qd) | ||
instance HasSpace Realm where typ = qd . typ | ||
instance Quantity Realm where | ||
instance MayHaveUnit Realm where getUnit = getUnit . view qd | ||
-- | The concept domain of a Realm is the union of the concept domains of the underlying variants. | ||
instance ConceptDomain Realm where cdom = foldr1 union . NE.toList . NE.map _cd . (^. rvs) | ||
instance Definition Realm where defn = rDesc | ||
-- | The related Relation of a Realm is defined as the quantity and the related expressions being equal | ||
-- e.g., `q $= a $= b $= ... $= z` | ||
instance ExprRelat Realm where relat q = sy q $= foldr1 ($=) (NE.map (^. expr) (q ^. rvs)) | ||
|
||
-- | Smart constructor for Realms, does nothing special at the moment | ||
mkRealm :: UID -> QuantityDict -> Sentence -> NE.NonEmpty RealmVariant -> Realm | ||
mkRealm = Realm | ||
|
||
-- | Smart constructor for Realms defining UIDs using that of the QuantityDict | ||
mkRealmForQuant :: QuantityDict -> Sentence -> NE.NonEmpty RealmVariant -> Realm | ||
mkRealmForQuant q = mkRealm (q ^. uid) q | ||
|
||
-- | Smart constructor for RealmVariants | ||
mkRealmVariant :: [UID] -> Sentence -> Expr -> RealmVariant | ||
mkRealmVariant = RV |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
e45bc85
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, what is in
Theory.Drasil.Realms
is super-useful - but incorrectly named. I like the "QDefinition factory" description.The Realm paper and idea is that it is a collection of theories that end up being equivalent, so give different interfaces to the same underlying abstract component. So a
Realm
, in that sense, ought to fit 'above' theory, not inside.What is true is that, indeed, the very same idea is present here, internally to a theory. One could externalize it, make a part of a "QDefinition factory" into its own theory and then use a 'Realm' to put them together -- but that would be wasteful and imprecise.
In other words, I think what's really needed is different vocabulary, with the implementation staying essentially as is. Brainstorming:
e45bc85
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, I definitely don't like leaving it named as a
Realm
.Influenced by ADTs/"enumeration types"/disjoint unions, perhaps we could have "Quantity Definition Enumeration" (QDefEnum/QDefnEnum)? The name signals that there are many ways we can define this quantity, but that an instance of the quantity should be defined using a single constructor (in this case, a "constructor" would be the actual expression definitions).
What do you think?
e45bc85
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that's still too implementation-oriented. I think I've warmed to "Multi-definition", with
MultiDefn
as a decent short form.e45bc85
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. That sounds good. Would we want "DefnVar" for "Multi-Definition Variants"?
e45bc85
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would tend to try to be more descriptive and go with
DefiningExpr
. It's a tiny bit misleading (it's not just anExpr
), but theDefining
part should help with that, as a qualifier.