Hey,
> OK. I see the "referent" concept is broader than I had thought. They are
> not just pointers, but (paraphrasing) expressions awaiting evaluation. The
> "referent pattern" is more or less the type of the expression, i.e. the
> type of whatever the expression evaluates to.
Yes. As I see it.
OK. I see the "referent" concept is broader than I had thought. They are
not just pointers, but (paraphrasing) expressions awaiting evaluation. The
"referent pattern" is more or less the type of the expression, i.e. the
type of whatever the expression evaluates to. For example, in Haskell
notation:
Hello,
>> [db][get,’people’] // *{name:@string, age:!gt(20)&!lt(33)}
>>
>> We have lost information about the “schema.” This is not good as
>> compile-time write validation is not possible.
>>
>
> So far, I am thinking: yeah, dealing with schema changes can be tricky.
This is not a “schema cha
Hello,
>> [db][get,’people’] // *{name:@string, age:!gt(20)&!lt(33)}
>>
>> We have lost information about the “schema.” This is not good as
>> compile-time write validation is not possible.
>>
>
> So far, I am thinking: yeah, dealing with schema changes can be tricky.
This is not a “schema cha
Hi Marko,
Ryan Wisnesky, Jan Hidders, and I have been jamming on the Algebraic
Property Graphs paper, which formalizes that type system. It's at 17 pages;
I hope to have it in a sharable state tomorrow after I add an intro
section. Looking forward to your feedback. We have delved into the TP4
virt
Hi,
*** This email is primarily for Josh (and Kuppitz).
I think we need Josh's type system core to mm-ADT. I’m facing the problem of
having to model both a “range” (legal schema) and a “codomain” (current schema)
of the referents of a reference. Let me explain with an example.
Suppose that the
