git.iko.soy/project-m36
on master help sign in
add convenience structure to AttributeExpr
commit31bb6a00004db47877101bb5ca453a9ff454b69e authorAgentM <agentm@themactionfaction.com> dateSun 3 Apr 2016, 16:46 (11 years ago) parentf5339a4
2 files changed+4−1
compare with master
unifiedsplit
ProjectM36/Base.hs+2−1 ProjectM36/RelationalExpression.hs+2
ProjectM36/Base.hs+2−1
@@ -464,7 +464,8 @@ data PersistenceStrategy = NoPersistence | -- ^ no filesystem persistence/memory
464464 CrashSafePersistence FilePath -- ^ full fsync to disk (flushes kernel and physical drive buffers to ensure that the transaction is on non-volatile storage)
465465 deriving (Show, Read)
466466
467−data AttributeExpr = AttributeAndTypeNameExpr AttributeName TypeConstructor
467+data AttributeExpr = AttributeAndTypeNameExpr AttributeName TypeConstructor |
468+ NakedAttributeExpr Attribute
468469 deriving (Eq, Show, Generic, Binary)
469470
470471data TupleExpr = TupleExpr (M.Map AttributeName AtomExpr)
ProjectM36/RelationalExpression.hs+2
@@ -511,6 +511,8 @@ evalAttrExpr aTypes (AttributeAndTypeNameExpr attrName tCons) = do
511511 aType <- atomTypeForTypeConstructor tCons aTypes
512512 Right (Attribute attrName aType)
513513
514+evalAttrExpr _ (NakedAttributeExpr attr) = Right attr
515+
514516evalTupleExpr :: DatabaseContext -> Maybe Attributes -> TupleExpr -> Either RelationalError RelationTuple
515517evalTupleExpr context attrs (TupleExpr tupMap) = do
516518 -- it's not possible for AtomExprs in tuple constructors to reference other Attributes' atoms due to the necessary order-of-operations (need a tuple to pass to evalAtomExpr)- it may be possible with some refactoring of type usage or delayed evaluation- needs more thought, but not a priority