Skip to content
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.

Sign up for GitHub

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

fix a few more things in the daml-lf spec #11851

Merged
merged 3 commits into from
Nov 25, 2021
Merged

fix a few more things in the daml-lf spec #11851

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
0d922c8
fix a few more things in the daml-lf spec
andreaslochbihler-da Nov 24, 2021
ea3000e
fixes
remyhaemmerle-da Nov 24, 2021
1823838
fix order
remyhaemmerle-da Nov 24, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 32 additions & 22 deletions daml-lf/spec/daml-lf-1.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
.. Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
.. SPDX-License-Identifier: Apache-2.0

Copyright © 2020, `Digital Asset (Switzerland) GmbH
Copyright © 2021, `Digital Asset (Switzerland) GmbH
<https://www.digitalasset.com/>`_ and/or its affiliates. All rights
reserved.

Expand Down Expand Up @@ -1231,9 +1231,9 @@ Then we define *well-formed expressions*. ::
——————————————————————————————————————————————————————————————— ExpFromAnyException [Daml-LF ≥ 1.14]
Γ ⊢ 'from_any_exception' @τ e : 'Optional' τ

Γ ⊢ τ : ⋆ Γ ⊢ e : τ
τ ↠ τ' Γ ⊢ τ' : ⋆ Γ ⊢ e : τ'
——————————————————————————————————————————————————————————————— UpdPure
Γ ⊢ 'pure' e : 'Update' τ
Γ ⊢ 'pure' @τ e : 'Update' τ'

τ₁ ↠ τ₁' Γ ⊢ τ₁' : ⋆ Γ ⊢ e₁ : 'Update' τ₁'
x₁ : τ₁' · Γ ⊢ e₂ : 'Update' τ₂
Expand Down Expand Up @@ -1297,7 +1297,7 @@ Then we define *well-formed expressions*. ::

Γ ⊢ τ : ⋆ Γ ⊢ e : τ
——————————————————————————————————————————————————————————————— ScnPure
Γ ⊢ 'spure' e : 'Scenario' τ
Γ ⊢ 'spure' @τ e : 'Scenario' τ

τ₁ ↠ τ₁' Γ ⊢ τ₁' : ⋆ Γ ⊢ e₁ : 'Scenario' τ₁'
x₁ : τ₁' · Γ ⊢ e₂ : 'Scenario' τ₂
Expand Down Expand Up @@ -1921,7 +1921,7 @@ need to be evaluated further. ::
——————————————————————————————————————————————————— ValScenario
⊢ᵥ s

——————————————————————————————————————————————————— ValUnBondedMathContext
——————————————————————————————————————————————————— ValUnboundedMathContext
⊢ᵥ LitRoundingMode


Expand All @@ -1933,7 +1933,7 @@ need to be evaluated further. ::
——————————————————————————————————————————————————— ValUpdatePure
⊢ᵥᵤ 'pure' @τ e

⊢ᵥ e₁
⊢ᵥᵤ e₁
Copy link
Collaborator

@remyhaemmerle-da remyhaemmerle-da Nov 24, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

problably better like that, but note that thanks to ValUpdate rule this was actually correct as well before your changed.

Copy link
Collaborator

@remyhaemmerle-da remyhaemmerle-da Nov 24, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For well-typed terms, the two are equivalent. But I find it easier to understand if we require an update value here rather than an arbitrary value.

In this case, I agree.

——————————————————————————————————————————————————— ValUpdateBind
⊢ᵥᵤ 'bind' x₁ : τ₁ ← e₁ 'in' e₂

Expand Down Expand Up @@ -2247,17 +2247,8 @@ Expression evaluation
Daml-LF evaluation is only defined on closed, well-typed expressions.

Note that the evaluation of the body of a value definition is lazy. It
happens only when needed and cached to avoid repeated computations. We
formalize this using an *evaluation environment* that associates to
each value reference the result of the evaluation of the corresponding
definition (See rules ``EvExpVal`` and ``EvExpValCached``.). The
evaluation environment is updated each time a value reference is
encountered for the first time.

Note that we do not specify if and how the evaluation environment is
preserved between different evaluations happening in the ledger. We
only guarantee that within a single evaluation each value definition
is evaluated at most once.
happens only when needed. The evaluation semantics itself does not cache
values to avoid recomputations, but actual implementations may do so.

The output of any Daml-LF built-in function ``F`` fully applied to
types ``@τ₁ … @τₘ`` and values ``v₁ … vₙ`` is deterministic. In the
Expand Down Expand Up @@ -2803,7 +2794,7 @@ as described by the ledger model::
└──────────────┘

—————————————————————————————————————————————————————————————————————— EvUpdPure
'pure' v ‖ (st, keys) ⇓ᵤ (Ok v, ε) ‖ (st, keys)
'pure' @τ v ‖ (st, keys) ⇓ᵤ (Ok v, ε) ‖ (st, keys)

u₁ ‖ S₀ ⇓ᵤ (Err E, tr)
—————————————————————————————————————————————————————————————————————— EvUpdBindErr1
Expand Down Expand Up @@ -2982,12 +2973,22 @@ as described by the ledger model::
'tpl' (x : T)
↦ { 'choices' { …, 'choice' ChKind Ch (y : 'ContractId' Mod:T) (z : τ) : σ 'by' eₚ 'observers' eₒ ↦ eₐ, … }, … } ∈ 〚Ξ〛Mod
cid ∈ dom(st₀)
st₀(cid) = (Mod:T, vₜ, 'inactive')
st₀(cid) = (Mod':T', vₜ, 'inactive')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in person, I am not sure if we really evaluate controllers before checking for template id mismatches.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right. It should be just after Inactive rule.

—————————————————————————————————————————————————————————————————————— EvUpdExercInactive
'exercise' Mod:T.Ch cid v₁ ‖ (st₀; keys₀)
⇓ᵤ
(Err (Fatal "Exercise on inactive contract"), ε)

'tpl' (x : T)
↦ { 'choices' { …, 'choice' ChKind Ch (y : 'ContractId' Mod:T) (z : τ) : σ 'by' eₚ 'observers' eₒ ↦ eₐ, … }, … } ∈ 〚Ξ〛Mod
cid ∈ dom(st₀)
st₀(cid) = (Mod':T', vₜ, 'active')
Mod:T ≠ Mod':T'
—————————————————————————————————————————————————————————————————————— EvUpdExercWrongTemplate
'exercise' Mod:T.Ch cid v₁ ‖ (st; keys₀)
⇓ᵤ
(Err (Fatal "Exercise on contract of wrong template"), ε)

'tpl' (x : T)
↦ { 'choices' { …, 'choice' ChKind Ch (y : 'ContractId' Mod:T) (z : τ) : σ 'by' eₚ 'observers' eₒ ↦ eₐ, … }, … } ∈ 〚Ξ〛Mod
cid ∈ dom(st₀)
Expand Down Expand Up @@ -3129,15 +3130,24 @@ as described by the ledger model::
—————————————————————————————————————————————————————————————————————— EvUpdFetchMissing
'fetch' @Mod:T cid ‖ (st; keys)
⇓ᵤ
(Err (Fatal "Exercise on unknown contract"), ε)
(Err (Fatal "Fetch on unknown contract"), ε)

'tpl' (x : T) ↦ … ∈ 〚Ξ〛Mod
cid ∈ dom(st)
st(cid) = (Mod:T, vₜ, 'inactive')
st(cid) = (Mod:T', vₜ, 'inactive')
—————————————————————————————————————————————————————————————————————— EvUpdFetchInactive
'fetch' @Mod:T cid ‖ (st; keys)
⇓ᵤ
(Err (Fatal "Exercise on inactive contract"), ε)
(Err (Fatal "Fetch on inactive contract"), ε)

'tpl' (x : T) ↦ … ∈ 〚Ξ〛Mod
cid ∈ dom(st)
st(cid) = (Mod':T', vₜ, 'inactive')
Mod:T ≠ Mod':T'
—————————————————————————————————————————————————————————————————————— EvUpdFetchWrongTemplate
'fetch' @Mod:T cid ‖ (st; keys)
⇓ᵤ
(Err (Fatal "Fetch on contract of wrong template"), ε)

'tpl' (x : T) ↦ … ∈ 〚Ξ〛Mod
cid ∈ dom(st)
Expand Down