non-lambda attributes

[wisnesky]

Should allow att1 -> att2 in addition to att1 -> lambda x. att2(x)

[wisnesky]

This is in MapExpRaw. The 'x' in the lambda should be given a name that can't shadow any other name; in Aql java, we punted and just made up a name that is unlikely to appear elsewhere.

This is low priority but some Aql examples do rely on it.

[marcosh]

It's not completely clear to me what needs to be done here, especially the part about the x.

Are you referring to https://github.com/CategoricalData/fql/blob/520e24963d399ef6e04e35d60f11a1e9f91e3c85/src/main/java/catdata/aql/exp/CombinatorParser.java#L1168?

Is it the problem the fact that you need a name of the attribute to return something of the type (String, (String, RawTerm))? If so, would it be ok to create a new datatype

data MappingAttributeTerm
    = MappingAttributeTermLambda String String RawTerm
    | MappingAttributeTermPath _

so that we could treat the two cases indipendently without reverting to strange tricks?

[wisnesky]

A mapping F : S -> T takes each attribute att : s -> t to a lambda expression \x:F(s). e : F(t), where x may occur many times in e. But sometimes people like to write in ‘point free notation’, using function composition. In other words, instead of writing

grandfather -> \x:Person. father(father(x)

to write

grandfather -> father.father

Like in a path expression. Indeed, path expressions are a unary special case of lambda terms.

At the abstract syntax level, AQL uses terms whose variables have unit type to represent the lambda expressions. The type Mapping can’t change.

MappingExpRaw’ can change, but if so, evalMappingRaw’ will need to change as well. I’m fine with this.

On Oct 16, 2018, at 3:12 AM, Marco Perone notifications@github.com wrote:

It's not completely clear to me what needs to be done here, especially the part about the x.

Are you referring to https://github.com/CategoricalData/fql/blob/520e24963d399ef6e04e35d60f11a1e9f91e3c85/src/main/java/catdata/aql/exp/CombinatorParser.java#L1168?

Is it the problem the fact that you need a name of the attribute to return something of the type (String, (String, RawTerm))? If so, would it be ok to create a new datatype

data MappingAttributeTerm = MappingAttributeTermLambda String String RawTerm | MappingAttributeTermPath _

so that we could treat the two cases indipendently without reverting to strange tricks?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

[marcosh]

@wisnesky I pushed on the branch https://github.com/statebox/aql/tree/54/non-lambda-attributes the parser for point free attributes.

I am a bit stuck though with the implementation of evalMappingRaw'. Would it be possible for you to help me with it? Maybe even with some pair programming

[wisnesky]

The various ‘evalRaw’ functions are indeed messy; I’d be happy to chat about it. The basic challenge is figuring out how to interpret the strings entered by users as attributes, fks, entities, etc, which requires a lot of checking to see if a string is in a list (of e.g., attributes) and then casting the string appropriately.

For example

--g :: Typeable sym => String ->[fk']-> [att'] -> RawTerm -> Term () ty sym en' fk' att' Void Void

Takes a variable name, a list of foreign keys and a list of attributes attributes, and then translates a raw term into an actual term

g v (RawApp x []) | v == x = Var () g v fks'' atts'' (RawApp x (a:[])) | elem' x fks'' = Fk (fromJust $ cast x) $ g' v fks'' atts'' a g v fks'' atts'' (RawApp x (a:[])) | elem' x atts'' = Att (fromJust $ cast x) $ g' v fks'' atts'' a g u fks'' atts'' (RawApp v l) = let l' = Prelude.map (g u fks'' atts'') l in case cast v of Just x -> Sym x l' Nothing -> error "impossible until complex typesides”

The g’ is a similar helper method restricted to entities and foreign keys.

On Oct 18, 2018, at 2:42 AM, Marco Perone notifications@github.com wrote:

@wisnesky I pushed on the branch https://github.com/statebox/aql/tree/54/non-lambda-attributes the parser for point free attributes.

I am a bit stuck though with the implementation of evalMappingRaw'. Would it be possible for you to help me with it? Maybe even with some pair programming

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[wisnesky]

I went ahead and added this to the latest commit, but I re-did the parser stuff. I'm sorry Marco but I just can't seem to get my head around how your parsers map onto AQL syntax.

[marcosh]

don't worry. You clearly have a clearer idea around this stuff