New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setting references with a union #49

Closed
mantkiew opened this Issue Jun 26, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@mantkiew
Member

mantkiew commented Jun 26, 2014

The following model works as expected:

abstract X

A : X 
B : X 
C : X

xs ->> X * 
[ xs = A, B, C ] 

However, making X a reference

abstract X -> integer

A : X = 1
B : X = 2
C : X = 3

xs ->> X * 
[ xs = A, B, C ] 

causes the following error in Alloy:

This name is ambiguous due to multiple matches:
field this/c0_X <: ref
field this/c0_xs <: ref

The generated Alloy code is incorrect and irregular:

fact { (c0_xs.@ref) = (((c0_A.@ref) + (c0_B.@ref)) + c0_C) }

The A and B should not have @refs, so only for C is the code generated correctly.

Currently, the only way to fix it is by adding .ref as follows

[ xs = A.ref, B.ref, C.ref ] 

However, the instance produced is incorrect!

=== Instance 1 Begin ===

A = 1
B = 2
C = 3
xs$1 = C
xs$2 = B
xs$3 = A

--- Instance 1 End ---

Changing the xs to

xs ->> integer *

results in the correct instance

=== Instance 2 Begin ===

A = 1
B = 2
C = 3
xs$1 = 3
xs$2 = 2
xs$3 = 1

--- Instance 2 End ---

I suppose this has something to do with the type system.

@mantkiew mantkiew added this to the 0.3.7 milestone Jun 26, 2014

@mantkiew mantkiew modified the milestones: 0.3.9, 0.3.7, 0.4.0 Mar 5, 2015

@mantkiew mantkiew assigned mantkiew and unassigned JLiangWaterloo Jul 23, 2015

@mantkiew mantkiew modified the milestones: 0.4.1, 0.4.0 Jul 23, 2015

@mantkiew mantkiew modified the milestones: 0.4.2, 0.4.1 Sep 8, 2015

@mantkiew

This comment has been minimized.

Show comment
Hide comment
@mantkiew

mantkiew Sep 29, 2015

Member

Another way of getting correct output:

abstract X -> integer

A : X = 1
B : X = 2
C : X = 3

xs ->> X *
[ xs.dref.dref = A, B, C ]

desugars correctly to

[c0_xs . dref . dref = c0_A . dref ++ c0_B . dref ++ c0_C . dref]

because by forcing dereferencing twice, the only valid type is TInteger and therefore A, B, and C must also be dereferenced.

Member

mantkiew commented Sep 29, 2015

Another way of getting correct output:

abstract X -> integer

A : X = 1
B : X = 2
C : X = 3

xs ->> X *
[ xs.dref.dref = A, B, C ]

desugars correctly to

[c0_xs . dref . dref = c0_A . dref ++ c0_B . dref ++ c0_C . dref]

because by forcing dereferencing twice, the only valid type is TInteger and therefore A, B, and C must also be dereferenced.

@mantkiew

This comment has been minimized.

Show comment
Hide comment
@mantkiew

mantkiew Sep 29, 2015

Member

However, writing

[ xs.dref = A, B, C ]

should not cause A, B to be dereferenced. We get incorrect output today (with Clafer 0.4.1):

[c0_xs . dref = c0_A . dref ++ c0_B . dref ++ c0_C]

whereas we clearly want

[c0_xs . dref = c0_A ++ c0_B ++ c0_C]
Member

mantkiew commented Sep 29, 2015

However, writing

[ xs.dref = A, B, C ]

should not cause A, B to be dereferenced. We get incorrect output today (with Clafer 0.4.1):

[c0_xs . dref = c0_A . dref ++ c0_B . dref ++ c0_C]

whereas we clearly want

[c0_xs . dref = c0_A ++ c0_B ++ c0_C]

@mantkiew mantkiew modified the milestones: 0.4.3, 0.4.2 Oct 21, 2015

@mantkiew mantkiew modified the milestones: 0.4.4, 0.4.3 Dec 22, 2015

mantkiew added a commit that referenced this issue Jun 23, 2016

mantkiew added a commit that referenced this issue Jun 23, 2016

@mantkiew mantkiew closed this Jun 23, 2016

@mantkiew mantkiew referenced this issue Jun 24, 2016

Merged

Release 0.4.4 #88

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment