Page 1 of 1

Supports Qualification for Domains

Posted: 5 May 2014 15:13
by Martin Meyer
Hello Thomas,

stating that an interface A supports an interface B extends A by all predicates and properties of B. But it does not extend A by the domains of B.

Since the feature of parametrizing interfaces by scope type variables has been introduced, it can cause inconveniences, that A is not extended by B's domains. It is, when B has a list of scope type variables, which is in A's support qualification assigned to some -lengthy, nested, complicated- list of types.

This -lengthy, nested..- type assignment list must be repeated in the code, when using a domain declared in B in the context of the scope type assignments made in A. The issue turns out even worse, when its not only two interfaces but a supports-chain of interfaces, where each one contributes some scope type assignments to the next.

In my opinion it would be better, when the supports qualification also extended interfaces' types. Maybe you plan already for such change in future version?

Many regards,

Posted: 6 May 2014 8:38
by Thomas Linder Puls
I am not sure what you mean can you give a little example to illustrate the problem?

Posted: 6 May 2014 15:11
by Martin Meyer
Below is an example of a supports-chain of three interfaces:
  • - 1st interface is some generic map (myGenericMapM{@Key, @Data}),
    - 2nd one uses 1st one to construct a map of companies (companyMapM),
    - 3rd one uses 2nd and 1st to declare a map of employees per company (employeeMapM).
The issue now is, that domain tree exists in the scope of type myGenericMapM{@Key, @Data}, but not in companyMapM and employeeMapM. Thatfore it is way cumbersome for the user of type employeeMapM to refer to the functor empty.

Code: Select all

interface myGenericMapM{@Key, @Data}       % insert, delete, etc. predicates could be here         domains         tree =             empty;             node(@Key, @Data, tree LeftChild, tree RightChild).       properties         algebraicRep : tree (o).   end interface myGenericMapM   class myGenericMapM{@Key, @Data} : myGenericMapM{@Key, @Data} end class myGenericMapM   implement myGenericMapM{@Key, @Data}       facts         algebraicRep : tree := empty.   end implement myGenericMapM   %---------   interface companyMapM{@CompanyData}     supports myGenericMapM{string CompanyName, @CompanyData} end interface companyMapM   class companyMapM{@CompanyData} : companyMapM{@CompanyData} end class companyMapM   implement companyMapM{@CompanyData}     inherits myGenericMapM{string CompanyName, @CompanyData} end implement companyMapM   %---------   interface employeeMapM     supports companyMapM{myGenericMapM{unsigned EmployeeID, string EmployeeName}} end interface employeeMapM   class employeeMapM : employeeMapM end class employeeMapM   implement employeeMapM     inherits companyMapM{myGenericMapM{unsigned EmployeeID, string EmployeeName}} end implement employeeMapM   %---------   implement main   clauses     run():-         console::init(),         EmployeeMapM = employeeMapM::new(),         Tree = EmployeeMapM:algebraicRep, %  I would want to code here: %     if Tree = employeeMapM::empty then %  however that doesn't work out, instead it must be:         if Tree = myGenericMapM{string, myGenericMapM{unsigned, string}}::empty then             stdIo::write("employeeMap is empty")         end if.   end implement main   goal     mainExe::run(main::run).

Posted: 7 May 2014 9:52
by Thomas Linder Puls
OK, I see the problem.

Have you however tried writing like this instead:

Code: Select all

        if Tree = myGenericMapM{_, _}::empty then             stdIo::write("employeeMap is empty")         end if.

Posted: 7 May 2014 11:13
by Martin Meyer
I have just tried it, myGenericMapM{_, _} gives some type mismatch error. Also putting myGenericMapM{_, myGenericMapM{_, _}} there does not please the compiler.

Posted: 9 May 2014 13:46
by Thomas Linder Puls
We will address this problem, but changes will only be in a later version.

Posted: 9 May 2014 16:44
by Martin Meyer
Of course in a later version - I can imagine, that this change about the object model will be a very complex thing.

Thanx a lot for your support,