digital-asset/daml
1
1
Fork 0
mirror of https://github.com/digital-asset/daml.git synced 2024-10-04 00:07:10 +03:00
Code Issues Projects Releases Wiki Activity

Daml case and logo (#8433)

Browse Source 
* Replace many occurrences of DAML with Daml

* Update docs logo

* A few more CLI occurrences

CHANGELOG_BEGIN
- Change DAML capitalization and docs logo
CHANGELOG_END

* Fix some over-eager replacements

* A few mor occurrences in md files

* Address comments in *.proto files

* Change case in comments and strings in .ts files

* Revert changes to frozen proto files

* Also revert LF 1.11

* Update get-daml.sh

* Update windows installer

* Include .py files

* Include comments in .daml files

* More instances in the assistant CLI

* some more help texts
This commit is contained in:
Bernhard Elsner 2021-01-08 13:50:15 +01:00 committed by GitHub
parent 0af4f522c7
commit cda93db944
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
245 changed files with 1828 additions and 1822 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.github/ISSUE_TEMPLATE.md vendored
View File

@ -1,9 +1,9 @@
<!--
This issue tracker is only for technical issues related to the DAML SDK.
This issue tracker is only for technical issues related to the Daml SDK.
If you suspect that your issue has a security impact, do not use this issue tracker. In that case, please contact security@digitalasset.com and follow our responsible disclosure policy: https://digitalasset.com/security/ .
For general questions about DAML and/or support requests you should use our forum: https://discuss.daml.com .
For general questions about Daml and/or support requests you should use our forum: https://discuss.daml.com .
-->

6
BAZEL-JVM.md
View File

@ -642,11 +642,11 @@ files.
[scalafmt]: https://github.com/scalameta/scalafmt
[scala_format_test]: https://github.com/DACH-NY/da/blob/e904c8eac1427633ef20b6106906a59f590de5a6/bazel_tools/scalafmt/scalafmt.bzl#L31
### DAML
### Daml
The SBT build of the `ledger-client` component defines a custom SBT plugin for
handling DAML code. It covers compilation to LF, packaging to DAR, Scala code
generation, and executing the DAML sandbox. This plugin was ported to Bazel as
handling Daml code. It covers compilation to LF, packaging to DAR, Scala code
generation, and executing the Daml sandbox. This plugin was ported to Bazel as
a set of custom Bazel rules defined in [`rules_daml`][rules_daml]. Refer to the
[user guide][bazel_user_guide] or the [API docs][bazel-api-documentation] for
details.

6
BAZEL-haskell.md
View File

@ -5,7 +5,7 @@ Finding your way around our Bazel build system from a Haskell developers' point
- How toolchains and external dependencies are defined;
- Specifiying stock `bazel` command options.
For this, one needs awareness of four files at the root level of the DAML repository : `WORKSPACE`, `deps.bzl`, `BUILD` and `.bazelrc`.
For this, one needs awareness of four files at the root level of the Daml repository : `WORKSPACE`, `deps.bzl`, `BUILD` and `.bazelrc`.
## `.bazelrc` the Bazel configuration file
@ -26,7 +26,7 @@ load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
```
This loads the contents of the files `http.bzl` and `git.bzl` from the external workspace [`bazel_tools`](https://github.com/bazelbuild/bazel/tree/master/tools) into the "environment". `bazel_tools` is an external workspace builtin to Bazel and provides rules for working with archives and git.
*[Note : Confusingly (?), `//bazel_tools` is a DAML package (a sub-directory of the root package directory containing a `BUILD.bazel` file). Don't confuse `@bazel_tools//..` with `//bazel_tools/..`]*.
*[Note : Confusingly (?), `//bazel_tools` is a Daml package (a sub-directory of the root package directory containing a `BUILD.bazel` file). Don't confuse `@bazel_tools//..` with `//bazel_tools/..`]*.
Straight after the loading of those rules, `deps.bzl` reads,
```
@ -259,6 +259,6 @@ may take some time if the required artifacts are not built or cached already.
## Further reading:
- ["Bazel User Guide"](https://github.com/digital-asset/daml/blob/main/BAZEL.md) (DAML specific)
- ["Bazel User Guide"](https://github.com/digital-asset/daml/blob/main/BAZEL.md) (Daml specific)
- ["A Users's Guide to Bazel"](https://docs.bazel.build/versions/master/guide.html) (official documentation)
- [`rules_haskell` documentation](https://api.haskell.build/index.html) (core Haskell rules, Haddock support, Linting, Defining toolchains, Support for protocol buffers, Interop with `cc_*` rules, Workspace rules)

34
BAZEL.md
View File

@ -1,6 +1,6 @@
# Bazel User Guide
This document explains how to use the Bazel build system on the DAML repository
This document explains how to use the Bazel build system on the Daml repository
from a users perspective. I.e. assuming the project you are working on has
already been ported to Bazel.
@ -13,7 +13,7 @@ project to Bazel.
## Setup
This section goes through the required steps for a basic but fully functioning
setup of the Bazel build system for work on the DAML repository. Additional setup
setup of the Bazel build system for work on the Daml repository. Additional setup
as for the IntelliJ integration is listed in its own section below.
### Bazel Executable
@ -92,7 +92,7 @@ details depend on the rule in question.
The following rules are commonly used in this repository. For Scala projects
`da_scala_library`, `da_scala_test_suite`, `da_scala_binary`. For Java projects
`java_library`, `java_test_suite`, `java_binary`. For DAML projects `daml`.
`java_library`, `java_test_suite`, `java_binary`. For Daml projects `daml`.
Labels can point to a specific target, or to a set of targets using a
wild-card. The following wild-card patterns are recognized.
@ -158,7 +158,7 @@ page][intellij_plugin_jetbrains].
To import a Bazel project into IntelliJ select "Import Bazel Project" in the
welcome dialog, or `File > Import Bazel Project` in the editor window. In the
import dialog under "Workspace:" enter the path to the DAML repository root.
import dialog under "Workspace:" enter the path to the Daml repository root.
The Bazel IntelliJ integration uses a *project view* file to define the list of
directories and targets to make accessible in IntelliJ and to control other
@ -254,7 +254,7 @@ _Sync project with BUILD files_). This process will take a while.
### Configuring the JDK in IntelliJ
DAML downloads the version of the JDK it uses from Nix. A symlink will be
Daml downloads the version of the JDK it uses from Nix. A symlink will be
created by the dev-env utilities (make sure you've set these up) in
_dev-env/jdk_.
@ -264,11 +264,11 @@ TO configure IntelliJ to use this JDK:
2. Under _Platform Settings_, select _SDKs_.
3. Press the _plus_ button and select "Add JDK".
4. Choose the _dev-env/jdk_ directory.
5. Name it "DAML JDK" or something similar.
5. Name it "Daml JDK" or something similar.
6. Ensure there's sources attached under the _Sourcepath_ tab. If not, add them.
Press the _plus_ button and select _dev-env/jdk/lib/openjdk/src.zip_.
7. Open _Project Settings_ → _Project_.
8. Select the DAML JDK from the _Project SDK_ list.
8. Select the Daml JDK from the _Project SDK_ list.
### Overview over Bazel IntelliJ Integration
@ -619,7 +619,7 @@ da_haskell_library(
visibility = ["//visibility:public"],
)
```
To build this single target from the root of the DAML repository, the
To build this single target from the root of the Daml repository, the
command would be:
```
bazel build //compiler/damlc/daml-compiler
@ -897,18 +897,18 @@ the target `foo_deploy.jar` next to the regular `foo.jar` target. Building the
`foo_deploy.jar` target will generate a self-contained fat JAR suitable to be
passed to `java -jar`.
### DAML Packages
### Daml Packages
DAML package targets are defined using the `daml` rule loaded from
Daml package targets are defined using the `daml` rule loaded from
`//rules_daml:daml.bzl`. To explain it we will take an example instance and
describe the individual attributes.
```
daml(
name = "it-daml",
# The main DAML file. This file will be passed to damlc.
# The main Daml file. This file will be passed to damlc.
main_src = "src/it/resources/TestAll.daml",
# Other DAML files that may be imported by the main DAML file.
# Other Daml files that may be imported by the main Daml file.
srcs = glob(["src/it/resources/**/*.daml"]),
# The directory prefix under which to create the DAR tree.
target_dir = "target/scala-2.12/resource_managed/it/dars",
@ -923,7 +923,7 @@ daml(
)
```
This will compile and package the DAML code into a DAR file under the following
This will compile and package the Daml code into a DAR file under the following
target, where `<group-dir>` is the `group` attribute with `.` replaced by `/`.
```
@ -951,10 +951,10 @@ For example:
it-daml.srcjar
```
### DAML Executables
### Daml Executables
The rule `daml_binary` is provided to generate executable targets that execute
the DAML sandbox on a given DAR package. For example:
the Daml sandbox on a given DAR package. For example:
```
daml_binary(
@ -964,7 +964,7 @@ daml_binary(
```
Such a target can then be executed as follows, where arguments after `--` are
passed to the DAML sandbox.
passed to the Daml sandbox.
```
bazel run //ledger-client/nanobot-sample-app:ping-pong-exec -- --help
@ -1006,7 +1006,7 @@ For an example, please see `compiler/daml-extension/BUILD.bazel`.
## Protocol buffers in Bazel
We use protocol buffers for DAML-LF and the Ledger API. The DAML-LF protocol
We use protocol buffers for Daml-LF and the Ledger API. The Daml-LF protocol
buffer build rules can be found from //daml-lf/archive/BUILD.bazel.
It produces bindings for Java and Haskell (via proto3-suite).

32
CONTRIBUTING.md
View File

@ -1,16 +1,16 @@
# Contributing to DAML
# Contributing to Daml
Welcome! This page gives a high-level overview of how to contribute to the development of DAML.
Welcome! This page gives a high-level overview of how to contribute to the development of Daml.
There are many ways you can contribute beyond coding. For example, you can report problems, clarify [issues](https://github.com/digital-asset/daml/issues), and write documentation. If you're completely new to open source development, the [Open Source Guides](https://opensource.guide) is a great place to start.
## Working on the codebase
For information on how to build, test, and work on the codebase, see ["Contributing to DAML" in the README](./README.md#contributing-to-daml).
For information on how to build, test, and work on the codebase, see ["Contributing to Daml" in the README](./README.md#contributing-to-daml).
## Code of conduct
This project and everyone participating in it is governed by the [DAML Code of Conduct](./CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to [community@digitalasset.com](mailto:community@digitalasset.com).
This project and everyone participating in it is governed by the [Daml Code of Conduct](./CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to [community@digitalasset.com](mailto:community@digitalasset.com).
## Git conventions
@ -88,9 +88,9 @@ Here are a few practical tips:
This list should cover the vast majority of needs. If unsure, ask on the relevant GitHub issue or PR.
* DAML Compiler
* DAML on SQL
* DAML Studio
* Daml Compiler
* Daml on SQL
* Daml Studio
* Distribution/Releases
* Extractor
* Java Bindings
@ -101,20 +101,20 @@ This list should cover the vast majority of needs. If unsure, ask on the relevan
* Ledger API Specification
* Integration Kit †
* Navigator
* DAML REPL
* Daml REPL
* Sandbox
* Scala Bindings
* Scala Codegen
* DAML Script
* DAML Assistant
* DAML Standard Library
* DAML Triggers
* Daml Script
* Daml Assistant
* Daml Standard Library
* Daml Triggers
† Covers the Ledger API Test Tool and changes to libraries that affect ledger integrations (e.g. `kvutils`)
## Working with issues
We use issues and [pull requests](https://help.github.com/articles/about-pull-requests/) to collaborate and track our work. Anyone is welcome to open an issue. If you just want to ask a question, please ask away on [the DAML forum](https://discuss.daml.com).
We use issues and [pull requests](https://help.github.com/articles/about-pull-requests/) to collaborate and track our work. Anyone is welcome to open an issue. If you just want to ask a question, please ask away on [the Daml forum](https://discuss.daml.com).
We encourage everyone to vote on issues that they support or not:
@ -138,7 +138,7 @@ We use labels to indicate what component the issue relates to (`component/...`).
By default, issues represent "work to be done" -- that might be features, improvements, non-critical bug fixes, and so on.
The DAML Language team uses labels to indicate priority (the DAML Runtime team does not):
The Daml Language team uses labels to indicate priority (the Daml Runtime team does not):
- `language/now`
- `language/soon`
@ -148,7 +148,7 @@ You can see all labels [here](https://github.com/digital-asset/daml/labels).
### Milestones
In addition to labels, we group issues into *milestones*. The DAML Language team has all issues in a single *Language* milestone; the DAML Runtime team uses them to group work efforts (*Add PostgreSQL backend to the Ledger* for example). *Maintenance* and *Backlog* are special milestones.
In addition to labels, we group issues into *milestones*. The Daml Language team has all issues in a single *Language* milestone; the Daml Runtime team uses them to group work efforts (*Add PostgreSQL backend to the Ledger* for example). *Maintenance* and *Backlog* are special milestones.
Issues without a milestone are treated as in need of triaging.
@ -156,7 +156,7 @@ You can see all the active milestones [here](https://github.com/digital-asset/da
## Discussions
Please hold discussions that are relevant to DAML development and not confidential in GitHub issues. That way, anyone who wants to contribute or follow along can do so. If you have private discussions, please summarise them in an issue or comment to an issue.
Please hold discussions that are relevant to Daml development and not confidential in GitHub issues. That way, anyone who wants to contribute or follow along can do so. If you have private discussions, please summarise them in an issue or comment to an issue.
You can also join a `#daml-contributors` channel on our Slack: [damldriven.slack.com](https://damldriven.slack.com/sso/saml/start).

20
README.md
View File

@ -1,4 +1,4 @@
[![DAML logo](daml-logo.png)](https://www.daml.com)
[![Daml logo](daml-logo.png)](https://www.daml.com)
[![Download](https://img.shields.io/github/release/digital-asset/daml.svg?label=Download)](https://docs.daml.com/getting-started/installation.html)
[![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://github.com/digital-asset/daml/blob/main/LICENSE)
@ -7,23 +7,23 @@
Copyright 2020 Digital Asset (Switzerland) GmbH and/or its affiliates. All Rights Reserved.
SPDX-License-Identifier: Apache-2.0
# Welcome to the DAML repository!
# Welcome to the Daml repository!
This repository hosts all code for the [DAML smart contract language and SDK](https://daml.com/), originally created by
[Digital Asset](https://www.digitalasset.com). DAML is an open-source smart contract language for building future-proof distributed applications on a safe, privacy-aware runtime. The SDK is a set of tools to help you develop applications based on DAML.
This repository hosts all code for the [Daml smart contract language and SDK](https://daml.com/), originally created by
[Digital Asset](https://www.digitalasset.com). Daml is an open-source smart contract language for building future-proof distributed applications on a safe, privacy-aware runtime. The SDK is a set of tools to help you develop applications based on Daml.
## Using DAML
## Using Daml
To download DAML, follow [the installation instructions](https://docs.daml.com/getting-started/installation.html).
To download Daml, follow [the installation instructions](https://docs.daml.com/getting-started/installation.html).
Once installed, to try it out, follow the [quickstart guide](https://docs.daml.com/getting-started/quickstart.html).
If you have questions about how to use DAML or how to build DAML-based solutions, please ask them on
If you have questions about how to use Daml or how to build Daml-based solutions, please ask them on
[StackOverflow using the `daml` tag](https://stackoverflow.com/tags/daml).
## Contributing to DAML
## Contributing to Daml
We warmly welcome [contributions](./CONTRIBUTING.md). If you are looking for ideas on how to contribute, please browse our
[issues](https://github.com/digital-asset/daml/issues). To build and test DAML:
[issues](https://github.com/digital-asset/daml/issues). To build and test Daml:
### 1. Clone this repository
@ -75,7 +75,7 @@ On Mac if building is causing trouble complaining about missing nix packages, yo
### 4. Installing a local copy
On Linux and Mac run `daml-sdk-head` which installs a version of the SDK with version number `0.0.0`. Set the `version:` field in any DAML project to 0.0.0 and it will use the locally installed one.
On Linux and Mac run `daml-sdk-head` which installs a version of the SDK with version number `0.0.0`. Set the `version:` field in any Daml project to 0.0.0 and it will use the locally installed one.
On Windows:

4
SECURITY.md
View File

@ -2,7 +2,7 @@
## Supported Versions
The latest released version of DAML is supported with security updates.
The latest released version of Daml is supported with security updates.
You can find the latest version at:
https://docs.daml.com/support/release-notes.html
@ -15,5 +15,5 @@ https://www.digitalasset.com/responsible-disclosure
To report an issue that does not have a security impact, open an issue on GitHub:
https://github.com/digital-asset/daml/issues/new
For general questions about DAML and/or support requests, please ask in our forum:
For general questions about Daml and/or support requests, please ask in our forum:
https://discuss.daml.com/

10
ci/docker/README.md
View File

@ -7,12 +7,12 @@ overwrite the one on Docker Hub should they differ.
-->
# Dockerized DAML SDK
# Dockerized Daml SDK
> This image is not supported for production use-cases. Please contact Digital
> Asset to obtain supported production-ready artifacts.
Digital Asset's [DAML SDK](https://docs.daml.com/) in a can.
Digital Asset's [Daml SDK](https://docs.daml.com/) in a can.
## Tags
@ -36,19 +36,19 @@ repository key of
## Quick start
* Ensure Docker is [installed](https://www.docker.com/get-started)
* Check out existing demo DAML project (or use your own):
* Check out existing demo Daml project (or use your own):
```
git clone https://github.com/digital-asset/ex-bond-trading.git
cd ex-bond-trading
```
* Run DAML scenarios:
* Run Daml scenarios:
```
DOCKER_CONTENT_TRUST=1 docker run --rm -it -v $PWD:/data digitalasset/daml-sdk:$SDK_VERSION bash -c "cd \$(mktemp -d) && cp -r /data/* ./ && DAML_SDK_VERSION=$SDK_VERSION daml test"
```
> Note: This image is primarily intended for CI workflows, where the benefits
> of caching Docker images can outweigh the awkwardness of the above command.
> For local development, we strongly recommend installing the DAML SDK on the
> For local development, we strongly recommend installing the Daml SDK on the
> host development machine instead, by running `curl https://get.daml.com |
> bash`. For production use-cases, we strongly recommend using a supported
> production binary, which can be obtained by contacting Digital Asset.

12
compatibility/README.md
View File

@ -62,17 +62,17 @@ that only iterates through stable versions up to HEAD. This ensures
that both individual migrations are correct as well as the migrations
from one stable version to the next work as a whole.
#### Backwards-compatibility for DAML Script
#### Backwards-compatibility for Daml Script
We test that the DAML Script runner from a given SDK version can load
DARs built against the DAML Script library from an older SDK. We only
We test that the Daml Script runner from a given SDK version can load
DARs built against the Daml Script library from an older SDK. We only
guarantee backwards compatibility here.
#### Backwards-compatibility for DAML Triggers
#### Backwards-compatibility for Daml Triggers
We test that the DAML Trigger runner from a given SDK version can load
DARs built against the DAML Script library from an older SDK. We only
We test that the Daml Trigger runner from a given SDK version can load
DARs built against the Daml Script library from an older SDK. We only
guarantee backwards compatibility here.
#### Backwards-compatibility for data-dependencies

2
compatibility/bazel_tools/create-daml-app/index.test.ts
View File

@ -106,7 +106,7 @@ const detached = process.platform != "win32";
const npmExeName = process.platform == "win32" ? "npm" : "npm-cli.js";
// Start the DAML and UI processes before the tests begin.
// Start the Daml and UI processes before the tests begin.
// To reduce test times, we reuse the same processes between all the tests.
// This means we need to use a different set of parties and a new browser page for each test.
beforeAll(async () => {

6
compiler/README.md
View File

@ -1,8 +1,8 @@
# DAML Compiler
# Daml Compiler
This directory contains several libraries used by and the executable for the
DAML compiler.
Daml compiler.
## Libraries
* `daml-lf-ast`: The DAML-LF AST and type checker.
* `daml-lf-ast`: The Daml-LF AST and type checker.

18
compiler/daml-extension/README.md
View File

@ -1,19 +1,19 @@
# DAML Studio
# Daml Studio
DAML Studio extends Visual Studio Code with the following DAML-specific
Daml Studio extends Visual Studio Code with the following Daml-specific
features:
- DAML syntax highlighting
- Daml syntax highlighting
- Real-time feedback on parse, name resolution, type-checking and
Scenario interpretation errors and viewer for the resulting ledger
- Jumping to and peeking at the definition of referenced toplevel functions
- Type-information on hover
- Renaming of symbols
- DAML snippet support
- Command to generate visualization for DAML project via command palette ctrl + p.
- Daml snippet support
- Command to generate visualization for Daml project via command palette ctrl + p.
Please note that this will only install the VSCode extension. Full use of the
above features will also require that you have a working DAML SDK installed,
above features will also require that you have a working Daml SDK installed,
which you can get with:
```
@ -22,12 +22,12 @@ curl -s https://get.daml.com | sh
To see graphs from `daml.visualize` command please install [Graphivz plugin](https://marketplace.visualstudio.com/items?itemName=EFanZh.graphviz-preview).
For more information on DAML please see [docs.daml.com](https://docs.daml.com).
For more information on Daml please see [docs.daml.com](https://docs.daml.com).
## Troubleshooting
The DAML language server log output is available under the "Output" panel
(View->Output). Select "DAML Language Server" from the dropdown in the panel
The Daml language server log output is available under the "Output" panel
(View->Output). Select "Daml Language Server" from the dropdown in the panel
to see the log.
## Debugging

8
compiler/daml-extension/extension_guide.md
View File

@ -1,11 +1,11 @@
# DAML Syntax Highlighter Dev Guide
In depth explanation syntax highlighting can be found on VS Code [website](https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide). This document contains a short guide and explanations of choices made for DAML plugin.
# Daml Syntax Highlighter Dev Guide
In depth explanation syntax highlighting can be found on VS Code [website](https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide). This document contains a short guide and explanations of choices made for Daml plugin.
## Overview
VS code uses [TextMate Grammar](https://macromates.com/manual/en/language_grammars). File processing is based on [Oniguruma regular expressions](https://macromates.com/manual/en/regular_expressions). These are generally written as JSON or [PList format](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/PropertyLists/UnderstandXMLPlist/UnderstandXMLPlist.html).
## Grammar File Format.
VS Code supports PList, JSON and YAML files to specify grammar. DAML VS code extension makes use of PList, as the haskell [extension](https://github.com/JustusAdam/language-haskell) and also using Plist makes having comments easy at the expense of making it more verbose.
VS Code supports PList, JSON and YAML files to specify grammar. Daml VS code extension makes use of PList, as the haskell [extension](https://github.com/JustusAdam/language-haskell) and also using Plist makes having comments easy at the expense of making it more verbose.
## Testing
@ -17,7 +17,7 @@ Example: ` employee : Party -- employee -> source.daml , Party -> storage.type.d
- `employee ->` Token employee is scoped to `source.daml` this can be viewed via VS code scope inspector tool
- `Party ->` Token party has three nested scopes and in the scope inspector they are listed in order
## DAML Specific constructs
## Daml Specific constructs
- Colon and double colon Daml considers `::` a cons operator and `:` as type operator.
- Keywords - there are a few daml specific keywords (eg: template, key, maintainer.).

20
compiler/daml-extension/src/extension.ts
View File

@ -134,7 +134,7 @@ function checkVersionUpgrade(version1: string, version2: string) {
return o.compare(comps2, comps1) > 0;
}
// Show the release notes from the DAML Blog.
// Show the release notes from the Daml Blog.
// We display the HTML in a new editor tab using a "webview":
// https://code.visualstudio.com/api/extension-guides/webview
async function showReleaseNotes(version: string) {
@ -144,7 +144,7 @@ async function showReleaseNotes(version: string) {
if (res.ok) {
const panel = vscode.window.createWebviewPanel(
'releaseNotes', // Identifies the type of the webview. Used internally
`New DAML SDK ${version} Available`, // Title of the panel displayed to the user
`New Daml SDK ${version} Available`, // Title of the panel displayed to the user
vscode.ViewColumn.One, // Editor column to show the new webview panel in
{} // No webview options for now
);
@ -179,7 +179,7 @@ function visualize() {
}
}
else {
vscode.window.showInformationMessage("Please open a DAML module to be visualized and then run the command")
vscode.window.showInformationMessage("Please open a Daml module to be visualized and then run the command")
}
}
@ -207,7 +207,7 @@ function addIfInConfig(config:vscode.WorkspaceConfiguration, baseArgs: string[],
export function createLanguageClient(config: vscode.WorkspaceConfiguration, telemetryConsent: boolean|undefined): LanguageClient {
// Options to control the language client
let clientOptions: LanguageClientOptions = {
// Register the server for DAML
// Register the server for Daml
documentSelector: ["daml"],
};
@ -221,7 +221,7 @@ export function createLanguageClient(config: vscode.WorkspaceConfiguration, tele
if (fs.existsSync(damlCmdPath)) {
command = damlCmdPath;
} else {
vscode.window.showErrorMessage("Failed to start the DAML language server. Make sure the assistant is installed.");
vscode.window.showErrorMessage("Failed to start the Daml language server. Make sure the assistant is installed.");
throw new Error("Failed to locate assistant.");
}
}
@ -245,11 +245,11 @@ export function createLanguageClient(config: vscode.WorkspaceConfiguration, tele
]);
if(config.get('experimental')){
vscode.window.showWarningMessage('DAMLs Experimental feature flag is enabled, this may cause instability')
vscode.window.showWarningMessage('Daml\'s Experimental feature flag is enabled, this may cause instability')
}
return new LanguageClient(
'daml-language-server', 'DAML Language Server',
'daml-language-server', 'Daml Language Server',
{ args: serverArgs, command: command, options: {cwd: vscode.workspace.rootPath }},
clientOptions, true);
}
@ -271,7 +271,7 @@ let keepAliveInterval = 60000; // Send KA every 60s.
// Wait for max 120s before restarting process.
// NOTE(JM): If you change this, make sure to also change the server-side timeouts to get
// detailed errors rather than cause a restart.
// Legacy DAML timeout for language server is defined in
// Legacy Daml timeout for language server is defined in
// DA.Daml.LanguageServer.
let keepAliveTimeout = 120000;
@ -287,7 +287,7 @@ function stopKeepAliveWatchdog() {
function keepAlive() {
function killDamlc() {
vscode.window.showErrorMessage(
"Sorry, you’ve hit a bug requiring a DAML Language Server restart. We’d greatly appreciate a bug report — ideally with example files."
"Sorry, you’ve hit a bug requiring a Daml Language Server restart. We’d greatly appreciate a bug report — ideally with example files."
);
// Terminate the damlc process with SIGTERM. The language client will restart the process automatically.
@ -461,7 +461,7 @@ let telemetryOverride = {
fromConsent: "From consent popup"
}
const options = {
yes : "Yes, I would like to help improve DAML!",
yes : "Yes, I would like to help improve Daml!",
no : "No, I'd rather not.",
read : "I'd like to read the privacy policy first."
}

6
compiler/daml-extension/syntaxes/README.md
View File

@ -2,13 +2,13 @@
Some notes on the files you find here.
- `daml.json` defines the syntax highlighting rules used before DAML
- `daml.json` defines the syntax highlighting rules used before Daml
1.2 (`daml.configuration.json` in the parent directory
configuration properties);
- `daml12.tmLanguage.xml` defines the syntax highlight rules used
starting with DAML 1.2;
starting with Daml 1.2;
- These rules are in fact general Haskell syntax highlighting
rules augmented with DAML specific keywords;
rules augmented with Daml specific keywords;
- `daml12.tmLanguage.xml` was produced from the file
`daml12.tmLanguage` by means of the VS-code extension,
["TextMate

8
compiler/daml-lf-verify/README.rst
View File

@ -1,10 +1,10 @@
.. Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
.. SPDX-License-Identifier: Apache-2.0
DAML Verification Tool
Daml Verification Tool
======================
This project performs fully automated formal verification of DAML code.
This project performs fully automated formal verification of Daml code.
Provided with a choice of a template and a field of a (potentially different) template, the verification tool employs symbolic
execution and an SMT solver, to verify whether the given choice always preserves
the total amount of the given field. This allows it to automatically answer
@ -14,13 +14,13 @@ money out of thin air?"
Installation
============
- Install the `DAML development dependecies`_.
- Install the `Daml development dependecies`_.
- Install the `Z3 SMT solver`_.
Note that on Linux, you can alternatively install Z3 using
``sudo apt install z3``.
.. _DAML development dependecies: https://github.com/digital-asset/daml/
.. _Daml development dependecies: https://github.com/digital-asset/daml/
.. _Z3 SMT solver: https://github.com/Z3Prover/z3
Running the Verification Tool

18
compiler/damlc/README.md
View File

@ -4,7 +4,7 @@ The following list is ordered topologicaly based on the dependency graph.
### daml-preprocessor
`daml-preprocessor` contains the DAML preprocessor which runs our version of the
`daml-preprocessor` contains the Daml preprocessor which runs our version of the
`record-dot-preprocessor` and the preprocessor for generating
`Generic` instances. The preprocessor also performs a few additional
checks, e.g., that you do not import internal modules.
@ -23,12 +23,12 @@ making everything depend on `daml-preprocessor`.
### daml-lf-conversion
`daml-lf-conversion` handles the conversion from GHC’s Core to DAML-LF.
`daml-lf-conversion` handles the conversion from GHC’s Core to Daml-LF.
### daml-ide-core
`daml-ide-core` is a wrapper around `ghcide` that adds DAML-specific
rules such as rules for producing `DAML-LF`.
`daml-ide-core` is a wrapper around `ghcide` that adds Daml-specific
rules such as rules for producing `Daml-LF`.
### daml-doc
@ -125,10 +125,10 @@ bazel build //compiler/damlc:daml-base-docs
This creates a tarball containing RST (ReStructured Text) docs, and a hoogle database.
## DAML Packages and Database
## Daml Packages and Database
A DAML project is compiled to a DAML package and can be distributed as a DAML archive (DAR). This is
essentially a zip archive containing the DAML source code of the library together with the compiled
A Daml project is compiled to a Daml package and can be distributed as a Daml archive (DAR). This is
essentially a zip archive containing the Daml source code of the library together with the compiled
.dalf file. The damlc package loading mechanism is based on GHC's package database
and uses the same .conf file format. GHC's package
database is documented at
@ -137,8 +137,8 @@ https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html.
### Loading packages
`damlc` loads packages from a package database given by the option `--package-db`. It creates a
map from package name to DAML-LF file from all the contained .dalf files in this directory and links
the created DAML-LF against these packages. It uses the .hi interface files created upon
map from package name to Daml-LF file from all the contained .dalf files in this directory and links
the created Daml-LF against these packages. It uses the .hi interface files created upon
installation of the packages for type checking.
### Base packages

2
compiler/damlc/base-hoogle-template.txt
View File

@ -4,7 +4,7 @@
-- (C) Copyright 2020 Digital Asset (Switzerland) GmbH and/or its affiliates.
-- All rights reserved. Any unauthorized use, duplication or distribution is strictly prohibited.
-- | DAML standard library.
-- | Daml standard library.
@url {{base-url}}
@package daml-stdlib
@version 1.2.0

4
compiler/damlc/base-md-template.md
View File

@ -1,11 +1,11 @@
# The standard library
The DAML standard library is a collection of DAML modules that can be used to implement concrete applications.
The Daml standard library is a collection of Daml modules that can be used to implement concrete applications.
## Usage
The standard library is included in the DAML compiler so it can
The standard library is included in the Daml compiler so it can
be used straight out of the box. You can import modules from the standard library just like your own, for example:
```

4
compiler/damlc/base-rst-index-template.rst
View File

@ -6,9 +6,9 @@
The standard library
====================
The DAML standard library is a collection of DAML modules that are bundled with the SDK, and can be used to implement DAML applications.
The Daml standard library is a collection of Daml modules that are bundled with the SDK, and can be used to implement Daml applications.
The :ref:`Prelude <module-prelude-6842>` module is imported automatically in every DAML module. Other modules must be imported manually, just like your own project's modules. For example:
The :ref:`Prelude <module-prelude-6842>` module is imported automatically in every Daml module. Other modules must be imported manually, just like your own project's modules. For example:
.. code-block:: daml

4
compiler/damlc/daml-prim-src/Control/Exception/Base.daml
View File

@ -26,7 +26,7 @@ import GHC.Types
-- https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Exception-Base.html#g:13
-- All of them take UTF8-encoded C strings of type 'Addr#' in ghc's Haskell
-- base library. Here, we must pass them 'Text' though to be able to call
-- 'error'. The conversion to DAML-LF basically pretends that 'Addr#' and
-- 'error'. The conversion to Daml-LF basically pretends that 'Addr#' and
-- 'Text' are the same type by lifting the C strings into 'Text'.
recSelError, recConError, runtimeError, nonExhaustiveGuardsError, patError, noMethodBindingError, absentError, typeError : forall liftedRep r . Text -> r
recSelError s = error (append "No match in record selector " s)
@ -43,7 +43,7 @@ absentSumFieldError = absentError " in unboxed sum."
{-
This function is copied from the same place as the functions above.
It's also modified to work with DAMLs Text type.
It's also modified to work with Daml's Text type.
(untangle coded message) expects "coded" to be of the form
"location|details"

2
compiler/damlc/daml-prim-src/DA/Internal/Erased.daml
View File

@ -9,5 +9,5 @@ module DA.Internal.Erased
import GHC.Types()
-- | Erased type used for kinds not supported by DAML-LF.
-- | Erased type used for kinds not supported by Daml-LF.
data Erased

6
compiler/damlc/daml-prim-src/DA/Internal/PromotedText.daml
View File

@ -9,10 +9,10 @@ module DA.Internal.PromotedText
import GHC.Types()
-- | Proxy type used to support type-level strings in DAML.
-- | Proxy type used to support type-level strings in Daml.
--
-- A type-level string "foo" will be represented as
-- `PromotedText {"foo": Unit}` in DAML-LF, where
-- `PromotedText {"foo": Unit}` in Daml-LF, where
-- `{"_foo": Unit}` is an LF struct with a single field
-- of unit type. The field name represents the type-level
-- string, after adding an underscore and some name
@ -20,7 +20,7 @@ import GHC.Types()
-- more details.
--
-- Note that there's no way to construct the requisite
-- LF struct directly in DAML. In DAML, instead of using
-- LF struct directly in Daml. In Daml, instead of using
-- this type, you should just use type-level strings
-- directly.
data PromotedText t

4
compiler/damlc/daml-prim-src/DA/Types.daml
View File

@ -22,8 +22,8 @@ import GHC.Types()
data Either a b = Left a | Right b
-- NOTE(MH): These types are not supposed to be used in DAML. The converter to
-- DAML-LF rewrites the types above to them, so they are visible to non-DAML users.
-- NOTE(MH): These types are not supposed to be used in Daml. The converter to
-- Daml-LF rewrites the types above to them, so they are visible to non-Daml users.
data Tuple2 a b =
Tuple2{_1 : a; _2 : b}
data Tuple3 a b c =

2
compiler/damlc/daml-prim-src/GHC/Base.daml
View File

@ -31,7 +31,7 @@ getTag : a -> Int#
getTag = magic @"getTag"
-- | HIDE This is referenced from error messages generated by ghc. Not
-- meant to be used in DAML, and not exported in Prelude. Use <> instead.
-- meant to be used in Daml, and not exported in Prelude. Use <> instead.
(++) : Text -> Text -> Text
(++) = primitive @"BEAppendText"
infixr 5 ++

2
compiler/damlc/daml-prim-src/GHC/CString.daml
View File

@ -6,7 +6,7 @@
-- | HIDE
-- An internal module based on ghc's base.GHC.CString. It is used for string
-- literals by ghc. All definitions are removed during conversion to DAML-LF.
-- literals by ghc. All definitions are removed during conversion to Daml-LF.
module GHC.CString
( unpackCString#
, unpackCStringUtf8#

2
compiler/damlc/daml-prim-src/GHC/Err.daml
View File

@ -17,7 +17,7 @@ import GHC.Types
-- | `error` stops execution and displays the given error message.
--
-- If called within a transaction, it will abort the current transaction.
-- Outside of a transaction (scenarios, DAML Script or DAML Triggers)
-- Outside of a transaction (scenarios, Daml Script or Daml Triggers)
-- it will stop the whole scenario/script/trigger.
error : Text -> a
error = primitive @"BEError"

8
compiler/damlc/daml-prim-src/GHC/Types.daml
View File

@ -80,7 +80,7 @@ ifThenElse c t f = case c of True -> t; False -> f
-- NOTE(MH): We're remove all the produced runtime represenations when
-- converting to DAML-LF but still need them here for type checking.
-- converting to Daml-LF but still need them here for type checking.
{- Note [Runtime representation of modules and tycons]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -137,11 +137,11 @@ data TyCon = TyCon Word# Word# -- Fingerprint
KindRep -- A representation of the type's kind
-- | HIDE A DAML-LF call to an external package
-- | HIDE A Daml-LF call to an external package
external : forall (f : Symbol) b. b
external = external --deleted by the compiler
-- | HIDE A DAML-LF primitive
-- | HIDE A Daml-LF primitive
primitive : forall (f : Symbol) b. b
primitive = primitive -- deleted by the compiler
@ -149,7 +149,7 @@ primitive = primitive -- deleted by the compiler
magic : forall (f : Symbol) b. b
magic = magic -- deleted by the compiler
-- | HIDE Dummy type to mark types built into DAML-LF.
-- | HIDE Dummy type to mark types built into Daml-LF.
data Opaque = Opaque
-- | A type for text strings, that can represent any unicode code point.

4
compiler/damlc/daml-stdlib-src/DA/Either.daml
View File

@ -61,10 +61,10 @@ eitherToOptional : Either a b -> Optional b
eitherToOptional (Left _) = None
eitherToOptional (Right x) = Some x
-- | Deprecated.
{-# DEPRECATED maybeToEither "DAML 1.2 compatibility helper, use 'optionalToEither' instead of 'maybeToEither'" #-}
{-# DEPRECATED maybeToEither "Daml 1.2 compatibility helper, use 'optionalToEither' instead of 'maybeToEither'" #-}
maybeToEither : a -> Optional b -> Either a b
maybeToEither = optionalToEither
-- | Deprecated.
{-# DEPRECATED eitherToMaybe "DAML 1.2 compatibility helper, use 'eitherToOptional' instead of 'eitherToMaybe'" #-}
{-# DEPRECATED eitherToMaybe "Daml 1.2 compatibility helper, use 'eitherToOptional' instead of 'eitherToMaybe'" #-}
eitherToMaybe : Either a b -> Optional b
eitherToMaybe = eitherToOptional

2
compiler/damlc/daml-stdlib-src/DA/Generics.daml
View File

@ -277,7 +277,7 @@ data DecidedStrictness = DecidedLazy
)
-- | Representable types of kind @*@.
-- This class is derivable in DAML with the @DeriveGeneric@ flag on.
-- This class is derivable in Daml with the @DeriveGeneric@ flag on.
--
-- A 'Generic' instance must satisfy the following laws:
--

54
compiler/damlc/daml-stdlib-src/DA/Internal/Compatible.daml
View File

@ -11,102 +11,102 @@ module DA.Internal.Compatible where
import DA.Internal.Prelude
import DA.Internal.LF
{-# DEPRECATED Datetime "DAML compatibility helper, use Time instead of 'Datetime'" #-}
{-# DEPRECATED Datetime "Daml compatibility helper, use Time instead of 'Datetime'" #-}
type Datetime = Time
{-# DEPRECATED Tuple "DAML compatibility helper, use (a,b) instead of 'Tuple a b'" #-}
{-# DEPRECATED Tuple "Daml compatibility helper, use (a,b) instead of 'Tuple a b'" #-}
type Tuple a b = (a,b)
{-# DEPRECATED tuple "DAML compatibility helper, use (,)" #-}
{-# DEPRECATED tuple "Daml compatibility helper, use (,)" #-}
tuple : a -> b -> (a,b)
tuple = (,)
{-# DEPRECATED Tuple3 "DAML compatibility helper, use (a,b,c) instead of 'Tuple3 a b c'" #-}
{-# DEPRECATED Tuple3 "Daml compatibility helper, use (a,b,c) instead of 'Tuple3 a b c'" #-}
type Tuple3 a b c = (a,b,c)
{-# DEPRECATED tuple3 "DAML compatibility helper, use (,,)" #-}
{-# DEPRECATED tuple3 "Daml compatibility helper, use (,,)" #-}
tuple3 : a -> b -> c -> (a,b,c)
tuple3 = (,,)
{-# DEPRECATED List "DAML compatibility helper, use [a] instead of 'List a'" #-}
{-# DEPRECATED List "Daml compatibility helper, use [a] instead of 'List a'" #-}
type List a = [a]
{-# DEPRECATED nil "DAML compatibility helper, use []" #-}
{-# DEPRECATED nil "Daml compatibility helper, use []" #-}
nil : [a]
nil = []
{-# DEPRECATED cons "DAML compatibility helper, use (::), which also works infix as 'x :: xs'" #-}
{-# DEPRECATED cons "Daml compatibility helper, use (::), which also works infix as 'x :: xs'" #-}
cons : a -> [a] -> [a]
cons = (::)
{-# DEPRECATED does "DAML compatibility helper, does is redundant and the first argument is ignored" #-}
{-# DEPRECATED does "Daml compatibility helper, does is redundant and the first argument is ignored" #-}
does : Party -> Update a -> Update a
does _ x = x
{-# DEPRECATED toText "DAML compatibility helper, use 'show' instead" #-}
{-# DEPRECATED toText "Daml compatibility helper, use 'show' instead" #-}
toText : Show a => a -> Text
toText = show
{-# DEPRECATED Integer "DAML compatibility helper, use 'Int' instead of 'Integer'" #-}
{-# DEPRECATED Integer "Daml compatibility helper, use 'Int' instead of 'Integer'" #-}
type Integer = Int
{-# DEPRECATED toInteger "DAML compatibility helper, use 'truncate' instead" #-}
{-# DEPRECATED toInteger "Daml compatibility helper, use 'truncate' instead" #-}
toInteger : Decimal -> Int
toInteger = truncate
{-# DEPRECATED mapU "DAML compatibility helper, use 'mapA' instead of 'mapU'" #-}
{-# DEPRECATED mapU "Daml compatibility helper, use 'mapA' instead of 'mapU'" #-}
mapU : Applicative m => (a -> m b) -> [a] -> m [b]
mapU = mapA
{-# DEPRECATED forU "DAML compatibility helper, use 'forA' instead of 'forU'" #-}
{-# DEPRECATED forU "Daml compatibility helper, use 'forA' instead of 'forU'" #-}
forU : Applicative m => [a] -> (a -> m b) -> m [b]
forU = forA
{-# DEPRECATED mapM "DAML compatibility helper, use 'mapA' instead of 'mapM'" #-}
{-# DEPRECATED mapM "Daml compatibility helper, use 'mapA' instead of 'mapM'" #-}
mapM : Applicative m => (a -> m b) -> [a] -> m [b]
mapM = mapA
{-# DEPRECATED forM "DAML compatibility helper, use 'forA' instead of 'forM'" #-}
{-# DEPRECATED forM "Daml compatibility helper, use 'forA' instead of 'forM'" #-}
forM : Applicative m => [a] -> (a -> m b) -> m [b]
forM = forA
{-# DEPRECATED Monad "DAML compatibility helper, use 'Action' instead of 'Monad'" #-}
{-# DEPRECATED Monad "Daml compatibility helper, use 'Action' instead of 'Monad'" #-}
type Monad = Action
{-# DEPRECATED String "DAML compatibility helper, use 'Text' instead of 'String'" #-}
{-# DEPRECATED String "Daml compatibility helper, use 'Text' instead of 'String'" #-}
type String = Text
{-# DEPRECATED MonadFail "DAML compatibility helper, use 'ActionFail' instead of 'MonadFail'" #-}
{-# DEPRECATED MonadFail "Daml compatibility helper, use 'ActionFail' instead of 'MonadFail'" #-}
type MonadFail = ActionFail
{-# DEPRECATED Num "DAML compatibility helper, use 'Number' instead of 'Num'" #-}
{-# DEPRECATED Num "Daml compatibility helper, use 'Number' instead of 'Num'" #-}
type Num = Number
{-# DEPRECATED commits "DAML compatibility helper, use 'submit' instead of 'commits'" #-}
{-# DEPRECATED commits "Daml compatibility helper, use 'submit' instead of 'commits'" #-}
infixr 0 `commits`
commits : Party -> Update a -> Scenario a
commits = submit
{-# DEPRECATED fails "DAML compatibility helper, use 'submitMustFail' instead of 'fails'" #-}
{-# DEPRECATED fails "Daml compatibility helper, use 'submitMustFail' instead of 'fails'" #-}
infixr 0 `fails`
fails : Party -> Update a -> Scenario ()
fails = submitMustFail
{-# DEPRECATED test "DAML compatibility helper, use 'scenario' instead" #-}
{-# DEPRECATED test "Daml compatibility helper, use 'scenario' instead" #-}
test : Scenario a -> Scenario a
test = identity
{-# DEPRECATED Maybe "DAML compatibility helper, use 'Optional' instead of 'Maybe'" #-}
{-# DEPRECATED Maybe "Daml compatibility helper, use 'Optional' instead of 'Maybe'" #-}
type Maybe = Optional
{-# DEPRECATED Nothing "DAML compatibility helper, use 'None' instead of 'Nothing'" #-}
{-# DEPRECATED Nothing "Daml compatibility helper, use 'None' instead of 'Nothing'" #-}
pattern Nothing : Maybe a
pattern Nothing = None
{-# DEPRECATED Just "DAML compatibility helper, use 'Some' instead of 'Just'" #-}
{-# DEPRECATED Just "Daml compatibility helper, use 'Some' instead of 'Just'" #-}
pattern Just : a -> Maybe a
pattern Just x = Some x
{-# DEPRECATED maybe "DAML compatibility helper, use 'optional' instead of 'maybe'" #-}
{-# DEPRECATED maybe "Daml compatibility helper, use 'optional' instead of 'maybe'" #-}
maybe : b -> (a -> b) -> Maybe a -> b
maybe = optional

2
compiler/damlc/daml-stdlib-src/DA/Internal/Date.daml
View File

@ -3,7 +3,7 @@
{-# LANGUAGE NoImplicitPrelude #-}
-- | MOVE Prelude DAML-LF types and primitives, apart from templates/contracts.
-- | MOVE Prelude Daml-LF types and primitives, apart from templates/contracts.
module DA.Internal.Date where
import DA.Internal.Prelude

16
compiler/damlc/daml-stdlib-src/DA/Internal/LF.daml
View File

@ -5,7 +5,7 @@
{-# LANGUAGE NoImplicitPrelude #-}
{-# OPTIONS -Wno-unused-binds #-} -- the opaque constructors are not exported
-- | MOVE Prelude DAML-LF types and primitives, apart from templates/contracts.
-- | MOVE Prelude Daml-LF types and primitives, apart from templates/contracts.
module DA.Internal.LF
( Party
, getParty
@ -51,13 +51,13 @@ import GHC.Stack.Types (HasCallStack)
import GHC.Types (Opaque, Symbol, primitive, magic)
import DA.Internal.Prelude
-- This module should not define any new types. It should only provide the DAML equivalent for LF
-- This module should not define any new types. It should only provide the Daml equivalent for LF
-- builtins using Opaque.
-- | The `Party` type represents a party to a contract.
data Party =
Party Opaque
-- Note that before DAML-LF 1.2 BEToText added single quotes around the party.
-- Note that before Daml-LF 1.2 BEToText added single quotes around the party.
-- now it does not, and the old behavior has been renamed BEPartyToQuotedText.
-- Since we want this to work with both versions, keep the old behavior.
instance Show Party where show = primitive @"BEPartyToQuotedText"
@ -75,7 +75,7 @@ partyToText : Party -> Text
partyToText = primitive @"BEToText"
-- | Converts a `Text` to `Party`. It returns `None` if the provided text contains
-- any forbidden characters. See DAML-LF spec for a specification on which characters
-- any forbidden characters. See Daml-LF spec for a specification on which characters
-- are allowed in parties. Note that this function accepts text _without_
-- single quotes.
--
@ -92,7 +92,7 @@ partyToText = primitive @"BEToText"
-- ∀ txt p. partyFromText txt = Some p ==> partyToText p = txt
-- ```
--
-- This function will crash at runtime if you compile DAML to DAML-LF < 1.2.
-- This function will crash at runtime if you compile Daml to Daml-LF < 1.2.
partyFromText : Text -> Optional Party
partyFromText = primitive @"BEPartyFromText"
@ -150,7 +150,7 @@ instance Show (ContractId a) where
show _ = "<contract-id>"
#endif
-- | HIDE This is currently used in the internals of DAML script and DAML triggers
-- | HIDE This is currently used in the internals of Daml script and Daml triggers
-- but not really something that we want to expose to users.
coerceContractId : ContractId a -> ContractId b
coerceContractId = primitive @"BECoerceContractId"
@ -239,11 +239,11 @@ infixr 0 `submitMustFail`
scenario : Scenario a -> Scenario a
scenario = identity
-- | HIDE A dummy type for the DAML-LF structural record type
-- | HIDE A dummy type for the Daml-LF structural record type
-- `<f1: a1, f2: a2>`.
data Pair (f1 : Symbol) (f2 : Symbol) a1 a2 = Pair Opaque
-- | HIDE Function to turn a DAML-LF structural record type into a DAML pair.
-- | HIDE Function to turn a Daml-LF structural record type into a Daml pair.
unpackPair : forall f1 f2 a1 a2. Pair f1 f2 a1 a2 -> (a1, a2)
unpackPair = magic @"unpackPair"

2
compiler/damlc/daml-stdlib-src/DA/Internal/Prelude.daml
View File

@ -79,7 +79,7 @@ class Functor f => Applicative f where
-- in imperative languages.
(>>) : Action m => m a -> m b -> m b
-- NOTE(MH): We need an `Action` constraint here rather than an `Applicative`
-- constrait since the conversion to DAML-LF rewrites `A >> B` into
-- constrait since the conversion to Daml-LF rewrites `A >> B` into
-- `A >>= \_ -> B`. This is to make `(>>)` lazy in its second argument and
-- hence give `do A; B` the desired semantics where `B` is not evaluated if
-- `A` short-circuits the monad computation..

2
compiler/damlc/daml-stdlib-src/DA/Internal/Template.daml
View File

@ -6,7 +6,7 @@
{-# LANGUAGE NoImplicitPrelude #-}
{-# LANGUAGE ScopedTypeVariables #-}
-- | MOVE Prelude DAML-LF primitives, just templates/contracts
-- | MOVE Prelude Daml-LF primitives, just templates/contracts
module DA.Internal.Template where
-- This module should only define stable types.

28
compiler/damlc/daml-stdlib-src/DA/Internal/Template/Functions.daml
View File

@ -10,7 +10,7 @@
-- which provides functions and typeclasses.
-- DA.Internal.Template ends up in its own module with
-- a fixed package id so that the hash of the types does not change.
-- | MOVE Prelude DAML-LF primitives, just templates/contracts
-- | MOVE Prelude Daml-LF primitives, just templates/contracts
module DA.Internal.Template.Functions where
#ifdef DAML_ANY_TYPE
@ -75,19 +75,19 @@ class HasArchive t where
-- | Archive the contract with the given contract ID.
archive : ContractId t -> Update ()
-- | Exposes `templateTypeRep` function in DAML-LF 1.7 or later.
-- | Exposes `templateTypeRep` function in Daml-LF 1.7 or later.
-- Part of the `Template` constraint.
class HasTemplateTypeRep t where
-- | HIDE
_templateTypeRep : proxy t -> TypeRep
-- | Exposes `toAnyTemplate` function in DAML-LF 1.7 or later.
-- | Exposes `toAnyTemplate` function in Daml-LF 1.7 or later.
-- Part of the `Template` constraint.
class HasToAnyTemplate t where
-- | HIDE
_toAnyTemplate : t -> Any
-- | Exposes `fromAnyTemplate` function in DAML-LF 1.7 or later.
-- | Exposes `fromAnyTemplate` function in Daml-LF 1.7 or later.
-- Part of the `Template` constraint.
class HasFromAnyTemplate t where
-- | HIDE
@ -110,13 +110,13 @@ class HasExercise t c r | t c -> r where
-- | Exercise a choice on the contract with the given contract ID.
exercise : ContractId t -> c -> Update r
-- | Exposes `toAnyChoice` function for DAML-LF 1.7 or later.
-- | Exposes `toAnyChoice` function for Daml-LF 1.7 or later.
-- Part of the `Choice` constraint.
class HasToAnyChoice t c r | t c -> r where
-- | HIDE
_toAnyChoice : proxy t -> c -> Any
-- | Exposes `fromAnyChoice` function for DAML-LF 1.7 or later.
-- | Exposes `fromAnyChoice` function for Daml-LF 1.7 or later.
-- Part of the `Choice` constraint.
class HasFromAnyChoice t c r | t c -> r where
-- | HIDE
@ -178,13 +178,13 @@ class HasMaintainer t k | t -> k where
maintainer : forall t k. HasMaintainer t k => k -> [Party]
maintainer = _maintainer ([] : [t])
-- | Exposes `toAnyContractKey` function in DAML-LF 1.7 or later.
-- | Exposes `toAnyContractKey` function in Daml-LF 1.7 or later.
-- Part of the `TemplateKey` constraint.
class HasToAnyContractKey t k | t -> k where
-- | HIDE
_toAnyContractKey : proxy t -> k -> Any
-- | Exposes `fromAnyContractKey` function in DAML-LF 1.7 or later.
-- | Exposes `fromAnyContractKey` function in Daml-LF 1.7 or later.
-- Part of the `TemplateKey` constraint.
class HasFromAnyContractKey t k | t -> k where
-- | HIDE
@ -261,14 +261,14 @@ deriving instance Ord TemplateTypeRep
-- | Wrap the template in `AnyTemplate`.
--
-- Only available for DAML-LF 1.7 or later.
-- Only available for Daml-LF 1.7 or later.
toAnyTemplate : HasToAnyTemplate t => t -> AnyTemplate
toAnyTemplate x = AnyTemplate (_toAnyTemplate x)
-- | Extract the underlying template from `AnyTemplate` if the type matches
-- or return `None`.
--
-- Only available for DAML-LF 1.7 or later.
-- Only available for Daml-LF 1.7 or later.
fromAnyTemplate : HasFromAnyTemplate t => AnyTemplate -> Optional t
fromAnyTemplate (AnyTemplate x) = _fromAnyTemplate x
@ -277,7 +277,7 @@ fromAnyTemplate (AnyTemplate x) = _fromAnyTemplate x
-- You must pass the template type `t` using an explicit type application.
-- For example `toAnyChoice @Account Withdraw`.
--
-- Only available for DAML-LF 1.7 or later.
-- Only available for Daml-LF 1.7 or later.
toAnyChoice : forall t c r. (HasTemplateTypeRep t, HasToAnyChoice t c r) => c -> AnyChoice
toAnyChoice c =
AnyChoice
@ -290,7 +290,7 @@ toAnyChoice c =
-- You must pass the template type `t` using an explicit type application.
-- For example `fromAnyChoice @Account choice`.
--
-- Only available for DAML-LF 1.7 or later.
-- Only available for Daml-LF 1.7 or later.
fromAnyChoice : forall t c r. (HasTemplateTypeRep t, HasFromAnyChoice t c r) => AnyChoice -> Optional c
fromAnyChoice (AnyChoice any typeRep)
| Some c <- _fromAnyChoice ([] : [t]) any
@ -302,7 +302,7 @@ fromAnyChoice (AnyChoice any typeRep)
-- You must pass the template type `t` using an explicit type application.
-- For example `toAnyContractKey @Proposal k`.
--
-- Only available for DAML-LF 1.7 or later.
-- Only available for Daml-LF 1.7 or later.
toAnyContractKey : forall t k. (HasTemplateTypeRep t, HasToAnyContractKey t k) => k -> AnyContractKey
toAnyContractKey k =
AnyContractKey
@ -315,7 +315,7 @@ toAnyContractKey k =
-- You must pass the template type `t` using an explicit type application.
-- For example `fromAnyContractKey @Proposal k`.
--
-- Only available for DAML-LF 1.7 or later.
-- Only available for Daml-LF 1.7 or later.
fromAnyContractKey : forall t k. (HasTemplateTypeRep t, HasFromAnyContractKey t k) => AnyContractKey -> Optional k
fromAnyContractKey (AnyContractKey any rep)
| Some k <- _fromAnyContractKey ([] : [t]) any

2
compiler/damlc/daml-stdlib-src/DA/Internal/Time.daml
View File

@ -3,7 +3,7 @@
{-# LANGUAGE NoImplicitPrelude #-}
-- | MOVE DA.Time DAML-LF types and primitives, apart from templates/contracts.
-- | MOVE DA.Time Daml-LF types and primitives, apart from templates/contracts.
module DA.Internal.Time where
import DA.Internal.Prelude

4
compiler/damlc/daml-stdlib-src/DA/Math.daml
View File

@ -4,7 +4,7 @@
-- | Math - Utility Math functions for `Decimal`
-- The this library is designed to give good precision, typically giving 9 correct decimal places.
-- The numerical algorithms run with many iterations to achieve that precision and are interpreted
-- by the DAML runtime so they are not performant. Their use is not advised in performance critical
-- by the Daml runtime so they are not performant. Their use is not advised in performance critical
-- contexts.
module DA.Math
( (**)
@ -90,7 +90,7 @@ type Sci = (Decimal, Int)
-- | `to36dig` tries to put a number in scientific notation in a form
-- where the `x` has order of magnitude 10^26. Given the fixed point
-- NUMBER(38,10) format of `Decimal` in DAML, this gives good
-- NUMBER(38,10) format of `Decimal` in Daml, this gives good
-- precision with a little bit of room to multiply with numbers less
-- than 100.
to36dig: Sci -> Sci

20
compiler/damlc/daml-stdlib-src/DA/Maybe.daml
View File

@ -7,42 +7,42 @@ module DA.Maybe(Maybe, pattern Nothing, pattern Just, maybe, module DA.Maybe) wh
import DA.Optional
{-# DEPRECATED fromJust "DAML 1.2 compatibility helper, use 'fromSome' from 'DA.Optional' instead of 'fromJust'" #-}
{-# DEPRECATED fromJust "Daml 1.2 compatibility helper, use 'fromSome' from 'DA.Optional' instead of 'fromJust'" #-}
fromJust : Optional a -> a
fromJust = fromSome
{-# DEPRECATED fromJustNote "DAML 1.2 compatibility helper, use 'fromSomeNote' from 'DA.Optional' instead of 'fromJustNote'" #-}
{-# DEPRECATED fromJustNote "Daml 1.2 compatibility helper, use 'fromSomeNote' from 'DA.Optional' instead of 'fromJustNote'" #-}
fromJustNote : Text -> Optional a -> a
fromJustNote = fromSomeNote
{-# DEPRECATED catMaybes "DAML 1.2 compatibility helper, use 'catOptionals' from 'DA.Optional' instead of 'catMaybes'" #-}
{-# DEPRECATED catMaybes "Daml 1.2 compatibility helper, use 'catOptionals' from 'DA.Optional' instead of 'catMaybes'" #-}
catMaybes : [Optional a] -> [a]
catMaybes = catOptionals
{-# DEPRECATED listToMaybe "DAML 1.2 compatibility helper, use 'listToOptional' from 'DA.Optional' instead of 'listToMaybe'" #-}
{-# DEPRECATED listToMaybe "Daml 1.2 compatibility helper, use 'listToOptional' from 'DA.Optional' instead of 'listToMaybe'" #-}
listToMaybe : [a] -> Optional a
listToMaybe = listToOptional
{-# DEPRECATED maybeToList "DAML 1.2 compatibility helper, use 'optionalToList' from 'DA.Optional' instead of 'maybeToList'" #-}
{-# DEPRECATED maybeToList "Daml 1.2 compatibility helper, use 'optionalToList' from 'DA.Optional' instead of 'maybeToList'" #-}
maybeToList : Optional a -> [a]
maybeToList = optionalToList
{-# DEPRECATED fromMaybe "DAML 1.2 compatibility helper, use 'fromOptional' from 'DA.Optional' instead of 'fromMaybe'" #-}
{-# DEPRECATED fromMaybe "Daml 1.2 compatibility helper, use 'fromOptional' from 'DA.Optional' instead of 'fromMaybe'" #-}
fromMaybe : a -> Optional a -> a
fromMaybe = fromOptional
{-# DEPRECATED isJust "DAML 1.2 compatibility helper, use 'isSome' from 'DA.Optional' instead of 'isJust'" #-}
{-# DEPRECATED isJust "Daml 1.2 compatibility helper, use 'isSome' from 'DA.Optional' instead of 'isJust'" #-}
isJust : Optional a -> Bool
isJust = isSome
{-# DEPRECATED isNothing "DAML 1.2 compatibility helper, use 'isNone' from 'DA.Optional' instead of 'isNothing'" #-}
{-# DEPRECATED isNothing "Daml 1.2 compatibility helper, use 'isNone' from 'DA.Optional' instead of 'isNothing'" #-}
isNothing : Optional a -> Bool
isNothing = isNone
{-# DEPRECATED mapMaybe "DAML 1.2 compatibility helper, use 'mapOptional' from 'DA.Optional' instead of 'mapMaybe'" #-}
{-# DEPRECATED mapMaybe "Daml 1.2 compatibility helper, use 'mapOptional' from 'DA.Optional' instead of 'mapMaybe'" #-}
mapMaybe : (a -> Optional b) -> [a] -> [b]
mapMaybe = mapOptional
{-# DEPRECATED whenJust "DAML 1.2 compatibility helper, use 'whenSome' from 'DA.Optional' instead of 'whenJust'" #-}
{-# DEPRECATED whenJust "Daml 1.2 compatibility helper, use 'whenSome' from 'DA.Optional' instead of 'whenJust'" #-}
whenJust : Applicative m => Optional a -> (a -> m ()) -> m ()
whenJust = whenSome

4
compiler/damlc/daml-stdlib-src/DA/Maybe/Total.daml
View File

@ -11,10 +11,10 @@ where
import DA.Maybe hiding (fromJust, fromJustNote)
import DA.Optional.Total
{-# DEPRECATED fromJust "DAML 1.2 compatibility helper, use 'fromSome' from 'DA.Optional.Total' instead of 'fromJust'" #-}
{-# DEPRECATED fromJust "Daml 1.2 compatibility helper, use 'fromSome' from 'DA.Optional.Total' instead of 'fromJust'" #-}
fromJust : ActionFail m => Optional a -> m a
fromJust = fromSome
{-# DEPRECATED fromJustNote "DAML 1.2 compatibility helper, use 'fromSomeNote' from 'DA.Optional.Total' instead of 'fromJustNote'" #-}
{-# DEPRECATED fromJustNote "Daml 1.2 compatibility helper, use 'fromSomeNote' from 'DA.Optional.Total' instead of 'fromJustNote'" #-}
fromJustNote : ActionFail m => Text -> Optional a -> m a
fromJustNote = fromSomeNote

2
compiler/damlc/daml-stdlib-src/DA/Next/Map.daml
View File

@ -170,7 +170,7 @@ instance (MapKey k, Show k, Show v) => Show (Map k v) where
deriving instance MapKey k => Semigroup (Map k v)
-- TODO(MH): The converter to DAML-LF can't handle deriving this right now.
-- TODO(MH): The converter to Daml-LF can't handle deriving this right now.
-- It fails with "Coercion with symco."
-- deriving instance MapKey k => Monoid (Map k v)
instance MapKey k => Monoid (Map k v) where

2
compiler/damlc/daml-stdlib-src/DA/Text.daml
View File

@ -324,7 +324,7 @@ parseDecimal = primitive @"BEDecimalFromText"
-- | Computes the SHA256 hash of the UTF8 bytes of the `Text`, and returns it in its hex-encoded
-- form. The hex encoding uses lowercase letters.
--
-- This function will crash at runtime if you compile DAML to DAML-LF < 1.2.
-- This function will crash at runtime if you compile Daml to Daml-LF < 1.2.
sha256 : Text -> Text
sha256 = primitive @"BESha256Text"

2
compiler/damlc/daml-stdlib-src/Prelude.daml
View File

@ -2,7 +2,7 @@
-- SPDX-License-Identifier: Apache-2.0
{-# LANGUAGE CPP #-}
-- | The pieces that make up the DAML language.
-- | The pieces that make up the Daml language.
module Prelude (module X) where
import DA.Internal.Prelude as X hiding (magic)

28
compiler/damlc/lib/DA/Cli/Damlc.hs
View File

@ -6,7 +6,7 @@
{-# LANGUAGE CPP #-}
{-# LANGUAGE MultiWayIf #-}
-- | Main entry-point of the DAML compiler
-- | Main entry-point of the Daml compiler
module DA.Cli.Damlc (main) where
import qualified "zip-archive" Codec.Archive.Zip as ZipArchive
@ -125,7 +125,7 @@ cmdIde :: Int -> Mod CommandFields Command
cmdIde numProcessors =
command "ide" $ info (helper <*> cmd) $
progDesc
"Start the DAML language server on standard input/output."
"Start the Daml language server on standard input/output."
<> fullDesc
where
cmd = execIde
@ -138,13 +138,13 @@ cmdLicense :: Mod CommandFields Command
cmdLicense =
command "license" $ info (helper <*> pure execLicense) $
progDesc
"License information for open-source projects included in DAML Connect."
"License information for open-source projects included in Daml Connect."
<> fullDesc
cmdCompile :: Int -> Mod CommandFields Command
cmdCompile numProcessors =
command "compile" $ info (helper <*> cmd) $
progDesc "Compile the DAML program into a Core/DAML-LF archive."
progDesc "Compile the Daml program into a Core/DAML-LF archive."
<> fullDesc
where
cmd = execCompile
@ -164,7 +164,7 @@ cmdCompile numProcessors =
cmdLint :: Int -> Mod CommandFields Command
cmdLint numProcessors =
command "lint" $ info (helper <*> cmd) $
progDesc "Lint the DAML program."
progDesc "Lint the Daml program."
<> fullDesc
where
cmd = execLint
@ -178,8 +178,8 @@ cmdTest numProcessors =
<> fullDesc
where
progDoc = unlines
[ "Test the current DAML project or the given files by running all test declarations."
, "Must be in DAML project if --files is not set."
[ "Test the current Daml project or the given files by running all test declarations."
, "Must be in Daml project if --files is not set."
]
cmd = runTestsInProjectOrFiles
<$> projectOpts "daml test"
@ -240,7 +240,7 @@ cmdBuild :: Int -> Mod CommandFields Command
cmdBuild numProcessors =
command "build" $
info (helper <*> cmd) $
progDesc "Initialize, build and package the DAML project" <> fullDesc
progDesc "Initialize, build and package the Daml project" <> fullDesc
where
cmd =
execBuild
@ -253,7 +253,7 @@ cmdBuild numProcessors =
cmdRepl :: Int -> Mod CommandFields Command
cmdRepl numProcessors =
command "repl" $ info (helper <*> cmd) $
progDesc "Launch the DAML REPL." <>
progDesc "Launch the Daml REPL." <>
fullDesc
where
cmd =
@ -347,21 +347,21 @@ cmdClean :: Mod CommandFields Command
cmdClean =
command "clean" $
info (helper <*> cmd) $
progDesc "Remove DAML project build artifacts" <> fullDesc
progDesc "Remove Daml project build artifacts" <> fullDesc
where
cmd = execClean <$> projectOpts "daml clean"
cmdInit :: Int -> Mod CommandFields Command
cmdInit numProcessors =
command "init" $
info (helper <*> cmd) $ progDesc "Initialize a DAML project" <> fullDesc
info (helper <*> cmd) $ progDesc "Initialize a Daml project" <> fullDesc
where
cmd = execInit <$> optionsParser numProcessors (EnableScenarioService False) (pure Nothing) <*> projectOpts "daml damlc init"
cmdPackage :: Int -> Mod CommandFields Command
cmdPackage numProcessors =
command "package" $ info (helper <*> cmd) $
progDesc "Compile the DAML program into a DAR (deprecated)"
progDesc "Compile the Daml program into a DAR (deprecated)"
<> fullDesc
where
cmd = execPackage
@ -374,7 +374,7 @@ cmdPackage numProcessors =
optFromDalf :: Parser FromDalf
optFromDalf = fmap FromDalf $
switch $
help "package an existing dalf file rather than compiling DAML sources" <>
help "package an existing dalf file rather than compiling Daml sources" <>
long "dalf" <>
internal
@ -872,7 +872,7 @@ parserInfo :: Int -> ParserInfo Command
parserInfo numProcessors =
info (helper <*> options numProcessors)
( fullDesc
<> progDesc "Invoke the DAML compiler. Use -h for help."
<> progDesc "Invoke the Daml compiler. Use -h for help."
<> headerDoc (Just $ PP.vcat
[ "damlc - Compiler and IDE backend for the Digital Asset Modelling Language"
, buildInfo

10
compiler/damlc/lib/DA/Cli/Options.hs
View File

@ -93,12 +93,12 @@ targetFileNameOpt = option (Just <$> str) $
packageNameOpt :: Parser GHC.UnitId
packageNameOpt = fmap GHC.stringToUnitId $ argument str $
metavar "PACKAGE-NAME"
<> help "Name of the DAML package"
<> help "Name of the Daml package"
lfVersionOpt :: Parser LF.Version
lfVersionOpt = option (str >>= select) $
metavar "DAML-LF-VERSION"
<> help ("DAML-LF version to output: " ++ versionsStr)
<> help ("Daml-LF version to output: " ++ versionsStr)
<> long "target"
<> value LF.versionDefault
<> internal
@ -113,7 +113,7 @@ lfVersionOpt = option (str >>= select) $
, version `elem` LF.supportedOutputVersions
-> return version
| otherwise
-> readerError $ "Unknown DAML-LF version: " ++ versionsStr
-> readerError $ "Unknown Daml-LF version: " ++ versionsStr
dotFileOpt :: Parser (Maybe FilePath)
dotFileOpt = option (Just <$> str) $
@ -200,7 +200,7 @@ projectOpts name = ProjectOpts <$> projectRootOpt <*> projectCheckOpt name
, "If you use the assistant, you should set the DAML_PROJECT environment variable instead."
])
projectCheckOpt cmdName = fmap (ProjectCheck cmdName) . switch $
help "Check if running in DAML project."
help "Check if running in Daml project."
<> long "project-check"
enableScenarioOpt :: Parser EnableScenarioService
@ -209,7 +209,7 @@ enableScenarioOpt = EnableScenarioService <$>
enableScriptsOpt :: Parser EnableScripts
enableScriptsOpt = EnableScripts <$>
flagYesNoAuto "daml-script" True "Enable/disable support for running DAML Scripts" internal
flagYesNoAuto "daml-script" True "Enable/disable support for running Daml Scripts" internal
dlintEnabledOpt :: Parser DlintUsage
dlintEnabledOpt = DlintEnabled

2
compiler/damlc/tests/daml-test-files/AliasCompression.daml
View File

@ -1,7 +1,7 @@
-- Copyright (c) 2020, Digital Asset (Switzerland) GmbH and/or its affiliates.
-- All rights reserved.
-- Check that alias compresion during the conversion to DAML-LF works properly
-- Check that alias compresion during the conversion to Daml-LF works properly
-- with chains of aliases.
module AliasCompression where

2
compiler/damlc/tests/daml-test-files/ClassMethodNames.daml
View File

@ -2,7 +2,7 @@
-- SPDX-License-Identifier: Apache-2.0
--
-- Ensure that class method names are preserved during the translation
-- to DAML-LF.
-- to Daml-LF.
--
-- @SINCE-LF 1.7
-- @QUERY-LF (.interned_strings | map(select(. == "m_baz")) == ["m_baz"])

2
compiler/damlc/tests/daml-test-files/ConstrainedRecursion.daml
View File

@ -1,4 +1,4 @@
-- Copyright (c) 2020 The DAML Authors. All rights reserved.
-- Copyright (c) 2020 The Daml Authors. All rights reserved.
-- SPDX-License-Identifier: Apache-2.0
--
-- @INFO range=12:1-13:21; Use foldl

4
compiler/damlc/tests/daml-test-files/DataTypes.daml
View File

@ -2,8 +2,8 @@
-- All rights reserved.
-- Check that various ways to define data types work. We're mostly interested
-- in the generated DAML-LF. Unfortunately, we don't have a way to test for
-- properties of the generated DAML-LF, cf. DEL-6418.
-- in the generated Daml-LF. Unfortunately, we don't have a way to test for
-- properties of the generated Daml-LF, cf. DEL-6418.
module DataTypes where

2
compiler/damlc/tests/daml-test-files/EnumLF.daml
View File

@ -1,7 +1,7 @@
-- Copyright (c) 2020 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
-- SPDX-License-Identifier: Apache-2.0
-- Check that enum types get translated to DAML-LF's enum types.
-- Check that enum types get translated to Daml-LF's enum types.
-- @SINCE-LF 1.6
-- @QUERY-LF .modules[] | .data_types[] | select(lf::get_dotted_name($pkg) == ["Color"]) | has("enum")
-- @QUERY-LF .modules[] | .values[] | select(.name_with_type | lf::get_value_name($pkg) == ["red"]) | .expr | has("enum_con")

2
compiler/damlc/tests/daml-test-files/ExerciseWithoutActors.daml
View File

@ -1,7 +1,7 @@
-- Copyright (c) 2020 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
-- SPDX-License-Identifier: Apache-2.0
-- Check that `exercise` is compiled to the DAML-LF `exercise` instruction
-- Check that `exercise` is compiled to the Daml-LF `exercise` instruction
-- without actors. Also check that `internalExerciseWithActors` actually
-- uses actors as a sanity check.

2
compiler/damlc/tests/daml-test-files/FreshNames.daml
View File

@ -1,5 +1,5 @@
-- Test that we don't use the hard coded variable names `v1`, `v2`, ... during
-- the conversion of some builtins to DAML-LF.
-- the conversion of some builtins to Daml-LF.
module FreshNames where
import DA.Assert

2
compiler/damlc/tests/daml-test-files/KindChecking.daml
View File

@ -2,7 +2,7 @@
-- All rights reserved.
-- @SINCE-LF 1.7
-- Make sure that invalid kinds are reported as errors by the DAML compiler.
-- Make sure that invalid kinds are reported as errors by the Daml compiler.
module KindChecking where
-- @ERROR range=10:1-10:4; Nat kind on the right-hand side of kind arrow

4
compiler/damlc/tests/daml-test-files/RecordProjection.daml
View File

@ -1,8 +1,8 @@
-- Copyright (c) 2020, Digital Asset (Switzerland) GmbH and/or its affiliates.
-- All rights reserved.
-- The tests here check that we compile all syntactic variants of DAML record
-- projection into the DAML-LF builtin for record projection as soon as we know
-- The tests here check that we compile all syntactic variants of Daml record
-- projection into the Daml-LF builtin for record projection as soon as we know
-- the record type and the field name.
module RecordProjection where

4
compiler/damlc/tests/daml-test-files/SemanticsEvalOrder.daml
View File

@ -169,7 +169,7 @@ evExpRecUpdErr2_3 = scenario do
pure (R1 {a=0, b=0})
{ a = error "EvExpRecUpdErr2_3 OK", a = error "EvExpRecUpdErr2_3 failed" }
-- Can't test LF struct evaluation order from DAML, since we purposely avoid
-- Can't test LF struct evaluation order from Daml, since we purposely avoid
-- evaluation of struct fields during typeclass desugaring, and we don't have
-- a way to construct LF structs directly.
@ -231,7 +231,7 @@ evExpUpFetchErr = scenario do
let _ : Update T = fetch (error "EvExpUpFetchErr OK")
pure ()
-- "exercise with actors" is not testable from DAML.
-- "exercise with actors" is not testable from Daml.
evExpUpExerciseWithoutActorsErr1 = scenario do
let _ : Update () =

8
compiler/damlc/tests/daml-test-files/SemanticsValue.daml
View File

@ -1,7 +1,7 @@
-- | This module checks that what is considered a value in
-- the operational semantics of DAML-LF matches what is
-- treated as a value in DAML.
-- the operational semantics of Daml-LF matches what is
-- treated as a value in Daml.
--
-- According to the spec, a value is "an expression which does not
-- need to be evaluated further". Any unevaluated subexpressions
@ -13,7 +13,7 @@
-- * updates with 'bind' or 'embed_expr'
-- * scenarios with 'sbind' or 'sembed_expr'
--
-- Where we can, we test this from DAML by using values with
-- Where we can, we test this from Daml by using values with
-- embedded error expressions. The value should evaluate without
-- raising an error.
--
@ -42,6 +42,6 @@ main = scenario do
let _ : Scenario () = do
_ <- pure ()
error "ValScenarioBind"
-- cannot test ValScenarioEmbedExpr from DAML, since
-- cannot test ValScenarioEmbedExpr from Daml, since
-- the compiler does not generate it.
pure ()

2
compiler/damlc/tests/daml-test-files/SemanticsValueSince17.daml
View File

@ -1,5 +1,5 @@
-- | Tests new "value cases" available since DAML 1.7
-- | Tests new "value cases" available since Daml 1.7
--
-- @SINCE-LF 1.7
module SemanticsValueSince17 where

2
compiler/damlc/tests/daml-test-files/SingleConEnum.daml
View File

@ -1,7 +1,7 @@
-- Copyright (c) 2020 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
-- SPDX-License-Identifier: Apache-2.0
-- Check that enum types get translated to DAML-LF's enum types.
-- Check that enum types get translated to Daml-LF's enum types.
-- @SINCE-LF 1.6
-- @QUERY-LF .modules[] | .data_types[] | select(lf::get_dotted_name($pkg) == ["Color"]) | has("enum")
-- @QUERY-LF .modules[] | .values[] | select(.name_with_type | lf::get_value_name($pkg) == ["red"]) | .expr | has("enum_con")

2
compiler/damlc/tests/daml-test-files/TypeVarShadowing.daml
View File

@ -20,7 +20,7 @@ type F f = forall a. f a
shadow : forall a. F (Either a)
shadow = error "shadow"
-- This breaks if we don't allow for shadowing type variables in DAML-LF.
-- This breaks if we don't allow for shadowing type variables in Daml-LF.
type Kont a = forall r. (a -> r) -> r
kont2 : Kont (Kont Int)

2
compiler/damlc/tests/daml-test-files/Unserializable.daml
View File

@ -1,7 +1,7 @@
-- Copyright (c) 2020, Digital Asset (Switzerland) GmbH and/or its affiliates.
-- All rights reserved.
-- Test the serializability checker for DAML LF.
-- Test the serializability checker for Daml LF.
-- We use the template typeclass and instances directly as otherwise the error
-- is caught prior due to missing Eq and Show instances.

2
compiler/damlc/tests/daml-test-files/UnserializableScenario.daml
View File

@ -1,4 +1,4 @@
-- Copyright (c) 2020 The DAML Authors. All rights reserved.
-- Copyright (c) 2020 The Daml Authors. All rights reserved.
-- SPDX-License-Identifier: Apache-2.0
-- @SINCE-LF 1.7

2
compiler/damlc/tests/daml-test-files/UseInteger.daml
View File

@ -7,7 +7,7 @@
-- Test that foo does not overflow
-- @ QUERY-LF .modules[] | .values[] | select(.name_with_type | lf::get_value_name($pkg) == ["foo"]) | .expr.prim_lit | lf::get_int64($pkg) == "1"
-- Test that DAML-LF can hold maxBound :: Int64
-- Test that Daml-LF can hold maxBound :: Int64
-- @ QUERY-LF .modules[] | .values[] | select(.name_with_type | lf::get_value_name($pkg) == ["bar"]) | .expr.prim_lit | lf::get_int64($pkg) == "9223372036854775807"
module UseInteger where

6
daml-assistant/daml-helper/src/DA/Daml/Helper/Main.hs
View File

@ -169,7 +169,7 @@ commandParser = subparser $ fold
<*> (SandboxOptions <$> many (strOption (long "sandbox-option" <> metavar "SANDBOX_OPTION" <> help "Pass option to sandbox")))
<*> (NavigatorOptions <$> many (strOption (long "navigator-option" <> metavar "NAVIGATOR_OPTION" <> help "Pass option to navigator")))
<*> (JsonApiOptions <$> many (strOption (long "json-api-option" <> metavar "JSON_API_OPTION" <> help "Pass option to HTTP JSON API")))
<*> (ScriptOptions <$> many (strOption (long "script-option" <> metavar "SCRIPT_OPTION" <> help "Pass option to DAML script interpreter")))
<*> (ScriptOptions <$> many (strOption (long "script-option" <> metavar "SCRIPT_OPTION" <> help "Pass option to Daml script interpreter")))
<*> stdinCloseOpt
<*> (SandboxClassic <$> switch (long "sandbox-classic" <> help "Deprecated. Run with Sandbox Classic."))
@ -198,7 +198,7 @@ commandParser = subparser $ fold
deployCmdInfo = mconcat
[ progDesc $ concat
[ "Deploy the current DAML project to a remote DAML ledger. "
[ "Deploy the current Daml project to a remote Daml ledger. "
, "This will allocate the project's parties on the ledger "
, "(if missing) and upload the project's built DAR file. You "
, "can specify the ledger in daml.yaml with the ledger.host and "
@ -245,7 +245,7 @@ commandParser = subparser $ fold
ledgerCmdInfo = mconcat
[ forwardOptions
, progDesc $ concat
[ "Interact with a remote DAML ledger. You can specify "
[ "Interact with a remote Daml ledger. You can specify "
, "the ledger in daml.yaml with the ledger.host and "
, "ledger.port options, or you can pass the --host "
, "and --port flags to each command below. "

10
daml-assistant/get-daml.sh
View File

@ -4,7 +4,7 @@
# SPDX-License-Identifier: Apache-2.0
#
# DAML is an open-source privacy-aware smart contract language.
# Daml is an open-source privacy-aware smart contract language.
# This script downloads and installs the SDK on Linux and macOS.
# This will overwrite any existing installation in ~/.daml
# For more information please visit https://daml.com/ and https://docs.daml.com/
@ -31,7 +31,7 @@ rmTmpDir() {
if [ -z $TEMPDIR ]; then
rm -rf $TMPDIR
else
echo "You may now remove the DAML installation files from $TEMPDIR"
echo "You may now remove the Daml installation files from $TEMPDIR"
fi
}
@ -47,7 +47,7 @@ trap cleanup EXIT
# Check that the temporary directory has enough space for the installation
#
if [ "$(df $TMPDIR | tail -1 | awk '{print $4}')" -lt $INSTALL_MINSIZE ]; then
echo "Not enough disk space available to extract DAML SDK in $TMPDIR."
echo "Not enough disk space available to extract Daml SDK in $TMPDIR."
echo ""
echo "You can specify an alternative extraction directory by"
echo "setting the TEMPDIR environment variable."
@ -71,7 +71,7 @@ else
MISSING="tar"
fi
if [ -n "$MISSING" ]; then
echo "Missing tools required for DAML installation: $MISSING"
echo "Missing tools required for Daml installation: $MISSING"
exit 1
fi
@ -142,6 +142,6 @@ fi
# Done.
#
trap - EXIT
echo "$(tput setaf 3)Successfully installed DAML.$(tput sgr 0)"
echo "$(tput setaf 3)Successfully installed Daml.$(tput sgr 0)"
cd $SWD
rmTmpDir

2
daml-assistant/scala-daml-project-config/README.md
View File

@ -1,3 +1,3 @@
# Scala DAML project config
# Scala Daml project config
This Scala library contains helpers to load SDK configuration files.

10
daml-assistant/src/DA/Daml/Assistant/Command.hs
View File

@ -90,7 +90,7 @@ sdkCommandArgsParser info = fromM (go (unwrapSdkCommandArgs $ sdkCommandArgs inf
commandParser :: [SdkCommandInfo] -> Parser Command
commandParser cmds | (hidden, visible) <- partition isHidden cmds = asum
[ subparser -- visible commands
$ builtin "version" "Display DAML version information" mempty (Version <$> versionParser <**> helper)
$ builtin "version" "Display Daml version information" mempty (Version <$> versionParser <**> helper)
<> builtin "install" "Install the specified SDK version" mempty (Install <$> installParser <**> helper)
<> builtin "uninstall" "Uninstall the specified SDK version" mempty (Uninstall <$> uninstallParser <**> helper)
<> foldMap dispatch visible
@ -105,19 +105,19 @@ versionParser :: Parser VersionOptions
versionParser = VersionOptions
<$> flagYesNoAuto "all" False "Display all available versions." idm
<*> flagYesNoAuto "snapshots" False "Display all available snapshot versions." idm
<*> flagYesNoAuto "assistant" False "Display DAML assistant version." idm
<*> flagYesNoAuto "assistant" False "Display Daml assistant version." idm
installParser :: Parser InstallOptions
installParser = InstallOptions
<$> optional (RawInstallTarget <$> argument str (metavar "TARGET" <> completeWith ["latest"] <> help "The SDK version to install. Use 'latest' to download and install the latest stable SDK version available. Run 'daml install' to see the full set of options."))
<*> flagYesNoAuto "snapshots" False "Pick up snapshot versions with daml install latest." idm
<*> (InstallAssistant <$> flagYesNoAuto' "install-assistant" "Install associated DAML assistant version. Can be set to \"yes\" (always installs), \"no\" (never installs), or \"auto\" (installs if newer). Default is \"auto\"." idm)
<*> (InstallAssistant <$> flagYesNoAuto' "install-assistant" "Install associated Daml assistant version. Can be set to \"yes\" (always installs), \"no\" (never installs), or \"auto\" (installs if newer). Default is \"auto\"." idm)
<*> iflag ActivateInstall "activate" hidden "Activate installed version of daml"
<*> iflag ForceInstall "force" (short 'f') "Overwrite existing installation"
<*> iflag QuietInstall "quiet" (short 'q') "Don't display installation messages"
<*> fmap SetPath (flagYesNoAuto' "set-path" "Adjust PATH automatically" idm)
<*> fmap BashCompletions (flagYesNoAuto' "bash-completions" "Install bash completions for DAML assistant. Default is yes for linux and mac, no for windows." idm)
<*> fmap ZshCompletions (flagYesNoAuto' "zsh-completions" "Install Zsh completions for DAML assistant. Default is yes for linux and mac, no for windows." idm)
<*> fmap BashCompletions (flagYesNoAuto' "bash-completions" "Install bash completions for Daml assistant. Default is yes for linux and mac, no for windows." idm)
<*> fmap ZshCompletions (flagYesNoAuto' "zsh-completions" "Install Zsh completions for Daml assistant. Default is yes for linux and mac, no for windows." idm)
where
iflag p name opts desc = fmap p (switch (long name <> help desc <> opts))

14
daml-lf/README.md
View File

@ -1,4 +1,4 @@
The unified DAML-LF interpreter and engine
The unified Daml-LF interpreter and engine
==========================================
This package contains the canonical in-memory LF ASTs of both the public
@ -22,7 +22,7 @@ Components
Protobuf utilities for reading it into a raw memory form. This should
reflect the [official LF specification][] at any given time. As with
the LF specification, changes to the Protobuf definition are governed
by the [DAML-LF Governance process][].
by the [Daml-LF Governance process][].
- `interface` is an ADT of the "public interface" of a given LF package,
meaning its templates, their choices, and serializable data types in
@ -84,13 +84,13 @@ Components
- `testing-tools` helps you run scenarios from Scalatest.
[official LF specification]: spec/daml-lf-1.rst
[DAML-LF Governance process]: governance.rst
[Daml-LF Governance process]: governance.rst
[CEK machine]: https://gist.github.com/ekmett/f081b5e36bac3fed1ea6b21eb25327c6
Building and testing
--------------------
DAML-LF uses Bazel to build and test the components. Please refer to top-level
Daml-LF uses Bazel to build and test the components. Please refer to top-level
`BAZEL.md` and `BAZEL-JVM.md` documents for high-level instructions on how to
use Bazel and how it works within IntelliJ.
@ -163,10 +163,10 @@ bazel run //daml-lf/scenario-interpreter:scenario-perf -- -p dar=/path/to/some/d
```
This can be combined with the `-f 0` flag as well.
These benchmarks are focused on DAML execution speed and try to avoid noise
These benchmarks are focused on Daml execution speed and try to avoid noise
caused by, say, I/O as much as possible.
DAML-LF-REPL Usage
Daml-LF-REPL Usage
------------------
The REPL can be compiled with `bazel build //:daml-lf-repl` and run with
@ -195,7 +195,7 @@ NOTE: When running via `bazel run` one needs to specify full path (or relative p
Profiling scenarios
-------------------
DAML-LF-REPL provides a command to run a scenario and collect profiling
Daml-LF-REPL provides a command to run a scenario and collect profiling
information while running it. This information is then written into a file that
can be viewed using the [speedscope](https://www.speedscope.app/) flamegraph
visualizer. The easiest way to install speedscope is to run

20
daml-lf/archive/README.md
View File

@ -1,7 +1,7 @@
# DAML-LF archive
# Daml-LF archive
This component contains the `.proto` definitions specifying the format
in which DAML-LF packages are stored -- the DAML-LF archive. All the
in which Daml-LF packages are stored -- the Daml-LF archive. All the
proto definitions are kept in the directory
`src/protobuf/com/daml/daml_lf_dev/`
@ -15,22 +15,22 @@ decoding of the payload is handled by Haskell and Java libraries in
`daml-core-package`, so that consumers and producers do not really
need to worry about it.
`ArchivePayload` is a sum type containing the various DAML-LF versions
supported by the DAML-LF archive. Currently we have two major versions:
`ArchivePayload` is a sum type containing the various Daml-LF versions
supported by the Daml-LF archive. Currently we have two major versions:
* `DAML-LF-0`, which is the deprecated legacy DAML core;
* `DAML-LF-1`, which is the first version of DAML-LF as specified by
* `Daml-LF-0`, which is the deprecated legacy Daml core;
* `Daml-LF-1`, which is the first version of Daml-LF as specified by
<https://github.com/digital-asset/daml/blob/main/daml-lf/spec/daml-lf-1.rst>.
## Snapshot versions
The component contains also an arbitrary number of snapshots of the
protobuf definitions as they were as the time a particular version of
DAML-LF was frozen. For versions <= 1.8, those snapshots are kept in the directories
Daml-LF was frozen. For versions <= 1.8, those snapshots are kept in the directories
`src/protobuf/com/digitalasset/daml_lf_x_y/`, where `x.y` is a
already frozen DAML-LF version. For newer versions, the directory is
already frozen Daml-LF version. For newer versions, the directory is
`src/protobuf/com/daml/daml_lf_x_y/`. A snapshot for version `x.y` can be
used to read any DAML-LF version from `1.0` to `x.y` without suffering
used to read any Daml-LF version from `1.0` to `x.y` without suffering
breaking changes (at the generated code level) often introduced in the
current version.
@ -81,7 +81,7 @@ message Foo {
## Conversion from the `.proto` to AST
The `.proto` definitions contain the serialized format for DAML-LF
The `.proto` definitions contain the serialized format for Daml-LF
packages, however the code to convert from the `.proto` definitions to
the actual AST lives elsewhere.

6
daml-lf/archive/src/main/protobuf/com/daml/daml_lf_dev/daml_lf.proto
View File

@ -11,7 +11,7 @@ import "com/daml/daml_lf_dev/daml_lf_1.proto";
message ArchivePayload {
// this is number 3 for historical reasons -- we had
// DAML-LF v0 and v1 before we had minor versions.
// Daml-LF v0 and v1 before we had minor versions.
string minor = 3;
reserved 9999; // for the removed "dev" major version
@ -43,8 +43,8 @@ message Archive {
//
// Note that the hash is computed directly on the blob and not
// on the decoded structure. This means that servers implementing
// a DAML ledger need to store the blob as-is somewhere to be able
// to always offer proof that they have a DAML package matching
// a Daml ledger need to store the blob as-is somewhere to be able
// to always offer proof that they have a Daml package matching
// the requested hash. We decided to go for this route rather than
// relying on a canonical encoding of the AST since such a scheme
// would be extremely hard (for example protobuf encoding is not

8
daml-lf/archive/src/main/protobuf/com/daml/daml_lf_dev/daml_lf_1.proto
View File

@ -1,7 +1,7 @@
// Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
// SPDX-License-Identifier: Apache-2.0
// .proto representation of the first version of the DAML-LF language,
// .proto representation of the first version of the Daml-LF language,
// as specified by
// <https://github.com/digital-asset/daml/blob/main/daml-lf/spec/daml-lf-1.rst>.
//
@ -441,7 +441,7 @@ enum PrimCon {
}
// Builtin functions
// Refer to DAML-LF major version 1 specification for types and behavior of those.
// Refer to Daml-LF major version 1 specification for types and behavior of those.
enum BuiltinFunction {
ADD_DECIMAL = 0; // *Available in versions < 1.7*
SUB_DECIMAL = 1; // *Available in versions < 1.7*
@ -907,7 +907,7 @@ message Expr {
Expr exception_expr = 3;
}
// Location of the expression in the DAML code source.
// Location of the expression in the Daml code source.
// Optional
Location location = 25;
@ -1390,7 +1390,7 @@ message DefTemplate {
int32 param_interned_str = 11; // *Available in versions >= 1.7*
}
// NOTE(MH): The new runtime authorization check for DAML 1.0 does not rely
// NOTE(MH): The new runtime authorization check for Daml 1.0 does not rely
// on the stakeholder signatures produced by the obligables computation
// anymore but uses the interpreter to compute the signatories and
// stakeholders of contract instances.

64
daml-lf/governance.rst
View File

@ -1,11 +1,11 @@
.. Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
.. SPDX-License-Identifier: Apache-2.0
DAML-LF Governance process
Daml-LF Governance process
==========================
These are the principles and rules by which changes to three data
formats are governed by the DAML Language team:
formats are governed by the Daml Language team:
* language,
* values and,
@ -15,38 +15,38 @@ formats are governed by the DAML Language team:
Overview
--------
* The *DAML-LF language* is the typed core calculus that DAML gets
* The *Daml-LF language* is the typed core calculus that Daml gets
compiled to, and that the ledger runs.
* *DAML-LF serializable values* or (DAML-LF values for brevity
(DAML-LF values for brevity in the rest in the rest of this document)
is the universe of DAML-LF values that can be stored on the
* *Daml-LF serializable values* or (Daml-LF values for brevity
(Daml-LF values for brevity in the rest in the rest of this document)
is the universe of Daml-LF values that can be stored on the
ledger. Currently nominal records, nominal variants, lists,
optionals, maps, and primitive types.
* *DAML-LF transaction nodes* (DAML-LF nodes for brevity in the rest
of this document) used to represent DAML actions described in the
DAML ledger model. Currently there are *create*, *exercise*,
* *Daml-LF transaction nodes* (Daml-LF nodes for brevity in the rest
of this document) used to represent Daml actions described in the
Daml ledger model. Currently there are *create*, *exercise*,
*fetch*, and *lookup-by-key* nodes.
* *DAML-F transactions* are sequences of transaction nodes that
* *Daml-F transactions* are sequences of transaction nodes that
defines an update to the ledger.
* The DAML-LF language is versioned using a major and minor component.
* The Daml-LF language is versioned using a major and minor component.
Changes to the major component allow us to drop features, or update
the serialization format. Changes to the minor component cannot
break backward compatibility, and operate on the same major version
of the serialization format in a backward compatible way. For
historical reason this scheme starts at `1.6`.
* DAML-LF values, nodes, and transactions are versioned using a common
* Daml-LF values, nodes, and transactions are versioned using a common
one component version scheme, called transaction version scheme.
For historical reason this scheme starts at `10`.
* DAML-LF Language, values, nodes, and transactions are evolved
* Daml-LF Language, values, nodes, and transactions are evolved
together without ever breaking backwards compatibility.
* DAML-LF values, nodes, and transactions, and language are involved
* Daml-LF values, nodes, and transactions, and language are involved
together, meaning the introduction of a new language version implies
the introduction of a new transaction version, and reciprocally.
@ -55,7 +55,7 @@ Overview
transactions. Moreover, a one-line summary of each version must be
present in the ``daml-lf-X.proto`` and ``transaction.proto`` files.
* Every change to DAML-LF values, nodes, transactions or languages
* Every change to Daml-LF values, nodes, transactions or languages
*must* be checked for governance rules conformance and be approved
by at least two persons among Rémy Haemmerle, Martin Huschenbett
and Sophia Mota. Proposed changes can be filed as tickets under
@ -66,17 +66,17 @@ Language
Some version bumps might not change the ``.proto`` at all, but just
add / change semantics in the specification. For example, the string
format for decimal numbers in DAML-LF values might be made more
format for decimal numbers in Daml-LF values might be made more
lenient, resulting in a version bump with no ``.proto`` schema changes
(but probably a comment).
Also note that the DAML-LF versioning is independent from the DAML
Also note that the Daml-LF versioning is independent from the Daml
surface language versioning.
"dev" version
~~~~~~~~~~~~~
Every DAML-LF major version includes a minor version, the *dev*
Every Daml-LF major version includes a minor version, the *dev*
version, which we use as staging area for the next stable minor
version of that major version.
@ -89,7 +89,7 @@ All newly-implemented minor version features or changes must be staged
in the *dev* version for later release as a stable group of
backward-compatible features.
The DAML-LF dev version is enabled in the sandbox and ledger server,
The Daml-LF dev version is enabled in the sandbox and ledger server,
but will never be emitted by damlc unless explicitly requested via
``--target 1.dev`` or similar.
@ -126,7 +126,7 @@ rather than "best-effort" consuming it in such a case, because any
field might be ignored when within values/transactions of later
versions.
For DAML-LF values, node and transaction we have a single document for
For Daml-LF values, node and transaction we have a single document for
all the versions, with annotations on version-specific features (in
the form of "since version XYZ").
@ -142,11 +142,11 @@ Unlike the language, values and transactions have only one major
version each; in terms of how language is versioned, they only have
minor versions. Their treatment is different for a few reasons:
- We expect DAML-LF values to be often stored in a long-term fashion -
- We expect Daml-LF values to be often stored in a long-term fashion -
for example a ledger needs to do so.
- It should be possible to revalidate old transactions at any time;
requiring users to maintain an archive of every DAML-LF engine
requiring users to maintain an archive of every Daml-LF engine
version they ever used in order to be able to revalidate would be
extremely onerous, and ledger operators should be able to upgrade
the engine freely.
@ -154,8 +154,8 @@ minor versions. Their treatment is different for a few reasons:
- While we could have major revisions and have each ledger deployment
to have a blessed set of major revisions, like we plan do for code,
we expect the impact of such a decision to be much greater, since
there is essentially only one consumer of DAML-LF code (the server),
while DAML-LF values will be stored all over the place, and the
there is essentially only one consumer of Daml-LF code (the server),
while Daml-LF values will be stored all over the place, and the
disruption of breaking changes would be too burdensome.
- It is *much* easier to preserve compatibility of simple first-order
@ -164,8 +164,8 @@ minor versions. Their treatment is different for a few reasons:
Working with LF data
--------------------
The language Team provides libraries to read and write DAML-LF values,
DAML-LF transactions, and DAML-LF packages in a version-aware manner,
The language Team provides libraries to read and write Daml-LF values,
Daml-LF transactions, and Daml-LF packages in a version-aware manner,
to aid the implementation of readers and writers.
With "version-aware" we mean that the libraries encoding and decoding
@ -175,7 +175,7 @@ becomes more complex as the specifications evolve, we strongly
recommend that JVM-hosted applications use our libraries for encoding
and decoding.
The ``daml-lf/transaction`` library for DAML-LF values and
The ``daml-lf/transaction`` library for Daml-LF values and
transactions includes:
.. todo include this at some point? - Specification
@ -187,12 +187,12 @@ transactions includes:
Scala and Java, and functions to decode / encode between the
``.proto`` and the data structures.
The ``daml-lf/lfpackage`` library for the DAML-LF language includes:
The ``daml-lf/lfpackage`` library for the Daml-LF language includes:
.. todo include this at some point? - Specifications, one per major revision
- Data structures to work with DAML-LF packages. Currently, this is an
AST that supports a set of DAML-LF versions, spanning across multiple
- Data structures to work with Daml-LF packages. Currently, this is an
AST that supports a set of Daml-LF versions, spanning across multiple
major revisions, either by having a larger type or by converting some
features into other features (e.g. if we add dependent functions the
library would convert non-dependent functions and foralls into
@ -214,8 +214,8 @@ The ``daml-lf/validation`` library includes:
Engine
------
The Language team provides the DAML-LF engine. The DAML-LF engine
will advertise what versions of the DAML-LF language it accepts.
The Language team provides the Daml-LF engine. The Daml-LF engine
will advertise what versions of the Daml-LF language it accepts.
It is guaranteed and engine will
accept all transaction version associated to those language versions.

2
daml-lf/interpreter/perf/daml/JsonParser.daml
View File

@ -4,7 +4,7 @@
{-# OPTIONS_GHC -Wall -Wno-name-shadowing #-}
-- This is not an industial strength JSON parser! (Although it is fairly complete)
-- The DAML code is written for sole intent of having a semi-realistic computationally heavy exmaple.
-- The Daml code is written for sole intent of having a semi-realistic computationally heavy exmaple.
-- The JSON parser is based on the Crockford grammar: https://www.json.org/json-en.html
-- The parser is written using parser-combinators, following:
-- "Parser combinators need four values to report errors", Andrew Partridge & David Wright

2
daml-lf/notes/README.md
View File

@ -1,3 +1,3 @@
The DAML-LF collective scratchpad. If you have some notes that you want
The Daml-LF collective scratchpad. If you have some notes that you want
to share and maintain to a certain extent, feel free to put it here.
Markdown and reStructuredText are preferred.

4
daml-lf/spec/contract-id.rst
View File

@ -8,7 +8,7 @@ V1 Contract ID allocation scheme
Goals
^^^^^
* Allows ordering contract IDs and make DAML semantics depend on this
* Allows ordering contract IDs and make Daml semantics depend on this
order, e.g., for comparison builtin and maps using IDs as keys.
* Eliminate all contract ID translations for central committer ledger
* Allows ledgers to store information about the contract and the
@ -18,7 +18,7 @@ Goals
Requirements
^^^^^^^^^^^^
**Executability**: DAML engine can determine ordering of the contract
**Executability**: Daml engine can determine ordering of the contract
IDs before it hands out the transaction to the write service.
**Validation**: The allocation scheme commutes with transaction

206
daml-lf/spec/daml-lf-1.rst
View File

@ -5,7 +5,7 @@ Copyright © 2020, `Digital Asset (Switzerland) GmbH
<https://www.digitalasset.com/>`_ and/or its affiliates. All rights
reserved.
DAML-LF 1 specification
Daml-LF 1 specification
=======================
.. contents:: Contents
@ -14,13 +14,13 @@ DAML-LF 1 specification
Introduction
^^^^^^^^^^^^
This document specifies version 1 of the DAML-LF language — the
language that DAML ledgers execute. DAML compiles to DAML-LF which
executes on DAML ledgers, similar to how Java compiles to JVM byte
code which executes on the JVM. “LF” in DAML-LF stands for “Ledger
Fragment”. DAML-LF is a small, strongly typed, functional language
This document specifies version 1 of the Daml-LF language — the
language that Daml ledgers execute. Daml compiles to Daml-LF which
executes on Daml ledgers, similar to how Java compiles to JVM byte
code which executes on the JVM. “LF” in Daml-LF stands for “Ledger
Fragment”. Daml-LF is a small, strongly typed, functional language
with strict evaluation that includes native representations for core
DAML concepts such as templates, updates, and parties. It is primarily
Daml concepts such as templates, updates, and parties. It is primarily
intended as a compilation target.
@ -69,31 +69,31 @@ symbols used in this doc::
Version history
~~~~~~~~~~~~~~~
The DAML-LF language is versioned using a major and minor component.
The Daml-LF language is versioned using a major and minor component.
Increasing the major component allows us to drop features, change
the semantics of existing features, or update the serialization format.
Changes to the minor component cannot break backward compatibility,
and operate on the same major version of the serialization format in
a backward compatible way. This document describes DAML-LF major version
a backward compatible way. This document describes Daml-LF major version
1, including all its minor versions.
Starting from SDK 1.0 release, DAML-LF versions older than 1.6 are
Starting from SDK 1.0 release, Daml-LF versions older than 1.6 are
deprecated. An engine compliant with the present specification must handle
all versions newer than or equal to DAML-LF 1.6, no requirement is made on
all versions newer than or equal to Daml-LF 1.6, no requirement is made on
handling older version.
Each DAML-LF program is accompanied by the version identifier of the
language it was serialized in. This number enables the DAML-LF engine
Each Daml-LF program is accompanied by the version identifier of the
language it was serialized in. This number enables the Daml-LF engine
to interpret previous versions of the language in a backward
compatibility way.
In the following of this document, we will use annotations between
square brackets such as *[Available in version < x.y]*, *[Available in
versions >= x.y]*, and *[Changed in version x.y]* to emphasize that a
particular feature is concerned with a change introduced in DAML x.y
particular feature is concerned with a change introduced in Daml x.y
version. In addition, we will mark lines within inference rules with
annotations of the form ``[DAML-LF < x.y]`` and ``[DAML-LF ≥ x.y]`` to
make the respective line conditional upon the DAML-LF version.
annotations of the form ``[Daml-LF < x.y]`` and ``[Daml-LF ≥ x.y]`` to
make the respective line conditional upon the Daml-LF version.
A *preview* version is an snapshot of the next 1.x version to be
released. It is provided for beta testing purpose and may only be
@ -104,7 +104,7 @@ changed without notice. Compliant implementations are not required to
implement any features exclusive to development version, but should
take them under advisement as likely elements of the next 1.x version.
Below, we list the versions of DAML-LF 1.x that a DAML-LF engine
Below, we list the versions of Daml-LF 1.x that a Daml-LF engine
compliant with the present specification must handle, in ascending
order. The optional preview version is marked with the tag *(preview)*
while the development version is marked with the tag *(development)*.
@ -229,7 +229,7 @@ Version: 1.dev (development)
Abstract syntax
^^^^^^^^^^^^^^^
This section specifies the abstract syntax tree of a DAML-LF
This section specifies the abstract syntax tree of a Daml-LF
package. We define identifiers, literals, types, expressions, and
definitions.
@ -293,7 +293,7 @@ brevity and readability.
Identifiers
~~~~~~~~~~~
In this section, we define the sorts of strings and identifiers that appear in
DAML-LF programs.
Daml-LF programs.
We first define two types of *strings*::
@ -316,7 +316,7 @@ We first define two types of *strings*::
<https://en.wikipedia.org/wiki/Unicode>`_ code points where the line
feed character ``\n``, the carriage return character ``\r``, the
double quote character ``\"``, and the backslash character ``\\`` must
be escaped with backslash ``\\``. DAML-LF considers legal `Unicode
be escaped with backslash ``\\``. Daml-LF considers legal `Unicode
code point <https://unicode.org/glossary/#code_point>`_ that is not a
`Surrogate Code Point
<https://unicode.org/glossary/#surrogate_code_point>`_, in other words
@ -367,7 +367,7 @@ restricted to US-ASCII while names are sequences of identifiers
intercalated with dots.
The character ``%`` is reserved for external languages built on
DAML-LF as a "not an Ident" notation, so should not be considered for
Daml-LF as a "not an Ident" notation, so should not be considered for
future addition to allowed identifier characters.
In the following, we will use identifiers to represent *built-in
@ -428,12 +428,12 @@ strings as *package identifiers*. ::
Contract identifiers can be created dynamically through interactions
with the underlying ledger. See the `operation semantics of update
statements <Update Interpretation_>`_ for the formal specification of
those interactions. Depending on its configuration, a DAML-LF engine
those interactions. Depending on its configuration, a Daml-LF engine
can produce V0 or V1 contract identifiers. When configured to produce
V0 contract identifiers, a DAML-LF compliant engine must refuse to
load any DAML-LF >= 1.11 archives. On the contrary, when configured
to produce V1 contract IDs, a DAML-LF compliant engine must accept to
load any non-deprecated DAML-LF version. V1 Contract IDs allocation
V0 contract identifiers, a Daml-LF compliant engine must refuse to
load any Daml-LF >= 1.11 archives. On the contrary, when configured
to produce V1 contract IDs, a Daml-LF compliant engine must accept to
load any non-deprecated Daml-LF version. V1 Contract IDs allocation
scheme is described in the `V1 Contract ID allocation
scheme specification <./contract-id.rst>`_.
@ -469,7 +469,7 @@ We now define all the literals that a program can handle::
Contract ID literals:
cid ::= cidV0 | cidV1 -- LitCid
The literals represent actual DAML-LF values:
The literals represent actual Daml-LF values:
* A ``LitNatType`` represents a natural number between ``0`` and
``38``, bounds inclusive.
@ -520,7 +520,7 @@ Then we can define our kinds, types, and expressions::
Kinds
k
::= 'nat' -- KindNat [DAML-LF ≥ 1.7]
::= 'nat' -- KindNat [Daml-LF ≥ 1.7]
| ek -- KindErasable
Erasable Kind
@ -547,26 +547,26 @@ Then we can define our kinds, types, and expressions::
| 'List' -- BTyList
| 'Optional' -- BTyOptional
| 'TextMap' -- BTTextMap: map with string keys
| 'GenMap' -- BTGenMap: map with general value keys [DAML-LF ≥ 1.11]
| 'GenMap' -- BTGenMap: map with general value keys [Daml-LF ≥ 1.11]
| 'ContractId' -- BTyContractId
| 'Any' -- BTyAny [DAML-LF ≥ 1.7]
| 'TypeRep' -- BTTypeRep [DAML-LF ≥ 1.7]
| 'Any' -- BTyAny [Daml-LF ≥ 1.7]
| 'TypeRep' -- BTTypeRep [Daml-LF ≥ 1.7]
| 'Update' -- BTyUpdate
| 'Scenario' -- BTyScenario
| 'AnyException' -- BTyAnyException [DAML-LF ≥ 1.dev]
| 'GeneralError' -- BTyGeneralError [DAML-LF ≥ 1.dev]
| 'ArithmeticError' -- BTyArithmeticError [DAML-LF ≥ 1.dev]
| 'ContractError' -- BTyContractError [DAML-LF ≥ 1.dev]
| 'AnyException' -- BTyAnyException [Daml-LF ≥ 1.dev]
| 'GeneralError' -- BTyGeneralError [Daml-LF ≥ 1.dev]
| 'ArithmeticError' -- BTyArithmeticError [Daml-LF ≥ 1.dev]
| 'ContractError' -- BTyContractError [Daml-LF ≥ 1.dev]
Types (mnemonic: tau for type)
τ, σ
::= α -- TyVar: Type variable
| n -- TyNat: Nat Type [DAML-LF ≥ 1.7]
| n -- TyNat: Nat Type [Daml-LF ≥ 1.7]
| τ σ -- TyApp: Type application
| ∀ α : k . τ -- TyForall: Universal quantification
| BuiltinType -- TyBuiltin: Builtin type
| Mod:T -- TyCon: type constructor
| |Mod:S τ₁ … τₘ| -- TySyn: type synonym [DAML-LF ≥ 1.8]
| |Mod:S τ₁ … τₘ| -- TySyn: type synonym [Daml-LF ≥ 1.8]
| ⟨ f₁: τ₁, …, fₘ: τₘ ⟩ -- TyStruct: Structural record type
Expressions
@ -602,15 +602,15 @@ Then we can define our kinds, types, and expressions::
| 'None' @τ -- ExpOptionalNone: Empty Optional
| 'Some' @τ e -- ExpOptionalSome: Non-empty Optional
| [t₁ ↦ e₁; …; tₙ ↦ eₙ] -- ExpTextMap
| 〚e₁ ↦ e₁; …; eₙ ↦ eₙ'〛 -- ExpGenMap [DAML-LF ≥ 1.11]
| 'to_any' @τ e -- ExpToAny: Wrap a value of the given type in Any [DAML-LF ≥ 1.7]
| 'from_any' @τ e -- ExpToAny: Extract a value of the given from Any or return None [DAML-LF ≥ 1.7]
| 'type_rep' @τ -- ExpToTypeRep: A type representation [DAML-LF ≥ 1.7]
| 〚e₁ ↦ e₁; …; eₙ ↦ eₙ'〛 -- ExpGenMap [Daml-LF ≥ 1.11]
| 'to_any' @τ e -- ExpToAny: Wrap a value of the given type in Any [Daml-LF ≥ 1.7]
| 'from_any' @τ e -- ExpToAny: Extract a value of the given from Any or return None [Daml-LF ≥ 1.7]
| 'type_rep' @τ -- ExpToTypeRep: A type representation [Daml-LF ≥ 1.7]
| u -- ExpUpdate: Update expression
| s -- ExpScenario: Scenario expression
| 'throw' @σ @τ e -- ExpThrow: throw exception
| 'make_any_exception' @τ eₘ eₚ -- ExpMakeAnyException: Turn a concrete exception into an 'AnyException' [DAML-LF ≥ 1.dev]
| 'from_any_exception' @τ e -- ExpFromAnyException: Extract a concrete exception from an 'AnyException' [DAML-LF ≥ 1.dev]
| 'make_any_exception' @τ eₘ eₚ -- ExpMakeAnyException: Turn a concrete exception into an 'AnyException' [Daml-LF ≥ 1.dev]
| 'from_any_exception' @τ e -- ExpFromAnyException: Extract a concrete exception from an 'AnyException' [Daml-LF ≥ 1.dev]
Patterns
p
@ -632,12 +632,12 @@ Then we can define our kinds, types, and expressions::
| 'fetch' @Mod:T e -- UpdateFetch
| 'exercise' @Mod:T Ch e₁ e₂ e₃ -- UpdateExercise
| 'exercise_without_actors' @Mod:T Ch e₁ e₂ -- UpdateExerciseWithoutActors
| 'exercise_by_key' @Mod:T Ch e₁ e₂ -- UpdateExerciseByKey [DAML-LF ≥ 1.11]
| 'exercise_by_key' @Mod:T Ch e₁ e₂ -- UpdateExerciseByKey [Daml-LF ≥ 1.11]
| 'get_time' -- UpdateGetTime
| 'fetch_by_key' @τ e -- UpdateFecthByKey
| 'lookup_by_key' @τ e -- UpdateLookUpByKey
| 'embed_expr' @τ e -- UpdateEmbedExpr
| 'try' @τ e₁ 'catch' x. e₂ -- UpdateTryCatch [DAML-LF ≥ 1.dev]
| 'try' @τ e₁ 'catch' x. e₂ -- UpdateTryCatch [Daml-LF ≥ 1.dev]
Scenario
s ::= 'spure' @τ e -- ScenarioPure
@ -708,7 +708,7 @@ available for usage::
, 'choices' { ChDef₁, …, ChDefₘ }
, KeyDef
}
| 'exception' T ↦ { 'message' e } -- DefException [DAML-LF ≥ 1.dev]
| 'exception' T ↦ { 'message' e } -- DefException [Daml-LF ≥ 1.dev]
Module (mnemonic: delta for definitions)
Δ ::= ε -- DefCtxEmpty
@ -721,8 +721,8 @@ available for usage::
PackageModules ∈ ModName ↦ Δ -- PackageModules
Package
Package ::= Package PackageModules PackageMetadata – since DAML-LF 1.8
Package ::= Package PackageModules -- until DAML-LF 1.8
Package ::= Package PackageModules PackageMetadata – since Daml-LF 1.8
Package ::= Package PackageModules -- until Daml-LF 1.8
Package collection
Ξ ∈ pid ↦ Package -- Packages
@ -738,7 +738,7 @@ module. The following feature flags are available:
+-------------------------------------------+----------------------------------------------------------+
| Flag | Semantic meaning |
+===========================================+==========================================================+
| ForbidPartyLiterals | Party literals are not allowed in a DAML-LF module. |
| ForbidPartyLiterals | Party literals are not allowed in a Daml-LF module. |
| | (See `Party Literal restriction`_ for more details) |
+-------------------------------------------+----------------------------------------------------------+
| DontDivulgeContractIdsInCreateArguments | contract IDs captured in ``create`` arguments are not |
@ -829,7 +829,7 @@ These two properties will be enforced by the notion of
Note ``↠`` is undefined on type contains an undefined type synonym or
a type synonym applied to a wrong number. Such types are assumed non
well-formed and will be rejected by the DAML-LF type checker.
well-formed and will be rejected by the Daml-LF type checker.
Well-formed types
@ -932,16 +932,16 @@ We now formally defined *well-formed types*. ::
————————————————————————————————————————————— TyScenario
Γ ⊢ 'Scenario' : ⋆ → ⋆
————————————————————————————————————————————— TyAnyException [DAML-LF ≥ 1.dev]
————————————————————————————————————————————— TyAnyException [Daml-LF ≥ 1.dev]
Γ ⊢ 'AnyException' : ⋆
————————————————————————————————————————————— TyGeneralError [DAML-LF ≥ 1.dev]
————————————————————————————————————————————— TyGeneralError [Daml-LF ≥ 1.dev]
Γ ⊢ 'GeneralError' : ⋆
————————————————————————————————————————————— TyArithmeticError [DAML-LF ≥ 1.dev]
————————————————————————————————————————————— TyArithmeticError [Daml-LF ≥ 1.dev]
Γ ⊢ 'ArithmeticError' : ⋆
————————————————————————————————————————————— TyContractError [DAML-LF ≥ 1.dev]
————————————————————————————————————————————— TyContractError [Daml-LF ≥ 1.dev]
Γ ⊢ 'ContractError' : ⋆
@ -1153,18 +1153,18 @@ Then we define *well-formed expressions*. ::
Γ ⊢ σ : ⋆
⊢ₑ τ
Γ ⊢ e : τ
——————————————————————————————————————————————————————————————— ExpThrow [DAML-LF ≥ 1.dev]
——————————————————————————————————————————————————————————————— ExpThrow [Daml-LF ≥ 1.dev]
Γ ⊢ 'throw' @σ @τ @e : σ
⊢ₑ τ
Γ ⊢ eₘ : 'Text'
Γ ⊢ eₚ : τ
——————————————————————————————————————————————————————————————— ExpMakeAnyException [DAML-LF ≥ 1.dev]
——————————————————————————————————————————————————————————————— ExpMakeAnyException [Daml-LF ≥ 1.dev]
Γ ⊢ 'make_any_exception' @τ eₘ eₚ : 'AnyException'
⊢ₑ τ
Γ ⊢ e : 'AnyException'
——————————————————————————————————————————————————————————————— ExpFromAnyException [DAML-LF ≥ 1.dev]
——————————————————————————————————————————————————————————————— ExpFromAnyException [Daml-LF ≥ 1.dev]
Γ ⊢ 'from_any_exception' @τ e : 'Optional' τ
Γ ⊢ τ : ⋆ Γ ⊢ e : τ
@ -1237,7 +1237,7 @@ Then we define *well-formed expressions*. ::
τ ↠ τ'
Γ ⊢ e₁ : 'Update' τ'
x : 'AnyException' · Γ ⊢ e₂ : 'Optional' ('Update' τ')
——————————————————————————————————————————————————————————————— UpdTryCatch [DAML-LF ≥ 1.dev]
——————————————————————————————————————————————————————————————— UpdTryCatch [Daml-LF ≥ 1.dev]
Γ ⊢ 'try' @τ e₁ 'catch' x. e₂ : 'Update' τ'
Γ ⊢ τ : ⋆ Γ ⊢ e : τ
@ -1542,7 +1542,7 @@ for the ``DefTemplate`` rule). ::
'record' T ↦ { f₁ : τ₁, …, fₙ : τₙ } ∈ 〚Ξ〛Mod
⊢ₛ Mod:T
⊢ e : Mod:T → 'Text'
——————————————————————————————————————————————————————————————— DefException [DAML-LF ≥ 1.dev]
——————————————————————————————————————————————————————————————— DefException [Daml-LF ≥ 1.dev]
⊢ 'exception' T ↦ { 'message' e }
┌───────────────────┐
@ -1577,7 +1577,7 @@ for the ``DefTemplate`` rule). ::
Γ ⊢ 'no_key'
⊢ₛ τ Γ ⊢ eₖ : τ
⊢ₖ eₖ [DAML-LF = 1.3]
⊢ₖ eₖ [Daml-LF = 1.3]
ε ⊢ eₘ : τ → 'List' 'Party'
——————————————————————————————————————————————————————————————— KeyDefSome
Γ ⊢ 'key' τ eₖ eₘ
@ -1620,10 +1620,10 @@ Party literal restriction
``ForbidPartyLiterals`` feature flag party literals were
allowed everywhere.
The usage of party literals is restricted in DAML-LF. By default,
The usage of party literals is restricted in Daml-LF. By default,
party literals are neither allowed in templates nor in values used in
templates directly or indirectly. In practice, this restricted the
usage of party literals to test cases written in DAML-LF. Usage of
usage of party literals to test cases written in Daml-LF. Usage of
party literals can be completely forbidden thanks to the `feature flag
<Feature flags_>`_ ``ForbidPartyLiterals``. If this flag is on, any
occurrence of a party literal anywhere in the module makes the module
@ -1633,7 +1633,7 @@ not well-formed.
Name collision restriction
~~~~~~~~~~~~~~~~~~~~~~~~~~
DAML-LF relies on `names and identifiers <Identifiers_>`_ to refer to
Daml-LF relies on `names and identifiers <Identifiers_>`_ to refer to
different kinds of constructs such as modules, type constructors,
variants constructor, and fields. These are relative; type names are
relative to modules; field names are relative to type record and so
@ -1644,7 +1644,7 @@ for module and type is different.
Fully resolved name
...................
DAML-LF restricts the way names and identifiers are used within a
Daml-LF restricts the way names and identifiers are used within a
package. This restriction relies on the notion of *fully resolved
name* construct as follows:
@ -1692,11 +1692,11 @@ collisions. Note also that value references are not concerned with
collisions as defined here.
Also note that while the collision is case-insensitive, name resolution
is *not* case-insensitive in DAML-LF. In other words, to refer to a
is *not* case-insensitive in Daml-LF. In other words, to refer to a
name, one must refer to it with the same case that it was defined with.
The case-insensitivity for collisions is in place since we often generate
files from DAML-LF packages, and we want to make sure for things to work
files from Daml-LF packages, and we want to make sure for things to work
smoothly when operating in case-insensitive file systems, while at the
same time preserving case sensitivity in the language.
@ -1704,7 +1704,7 @@ same time preserving case sensitivity in the language.
Name collision condition
........................
In DAML-LF, the only permitted name collisions are those occurring
In Daml-LF, the only permitted name collisions are those occurring
between variant constructors and record types defined in the same
module. Every other collision makes the module (and thus the package)
not well-formed. For example, a module ``Mod`` can contain the following
@ -1760,7 +1760,7 @@ usage ``Ξ``.
Values
~~~~~~
To define any call-by-value semantics for DAML-LF expression, we need
To define any call-by-value semantics for Daml-LF expression, we need
first to define the notion of *values*, the expressions which do not
need to be evaluated further. ::
@ -2183,7 +2183,7 @@ closure of ``<ₜ``.
Expression evaluation
~~~~~~~~~~~~~~~~~~~~~
DAML-LF evaluation is only defined on closed, well-typed expressions.
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
@ -2198,7 +2198,7 @@ preserved between different evaluations happening in the ledger. We
only guarantee that within a single evaluation each value definition
is evaluated at most once.
The output of any DAML-LF built-in function ``F`` fully applied to
The output of any Daml-LF built-in function ``F`` fully applied to
types ``@τ₁ … @τₘ`` and values ``v₁ … vₙ`` is deterministic. In the
following rules, we abstract this output with the notation ``𝕆(F @τ₁ …
@τₘ v₁ … vₙ)``. Please refer to the `Built-in functions`_ section for the
@ -3181,7 +3181,7 @@ About scenario interpretation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The interpretation of scenarios is a feature an engine can provide to
test business logic within a DAML-LF archive. Nevertheless, the
test business logic within a Daml-LF archive. Nevertheless, the
present specification does not define how scenarios should be actually
interpreted. An engine compliant with this specification does not have
to provide support for scenario interpretation. It must however accept
@ -3198,7 +3198,7 @@ evaluated during the interpretation of an update.
Built-in functions
^^^^^^^^^^^^^^^^^^
This section lists the built-in functions supported by DAML LF 1.
This section lists the built-in functions supported by Daml LF 1.
The functions come with their types and a description of their
behavior.
@ -3753,7 +3753,7 @@ Timestamp functions
* The output uses at least as many digits as necessary but may be
padded on the right with an unspecified number of "``0``".
* The output will not change within minor version of DAML-LF 1.
* The output will not change within minor version of Daml-LF 1.
Date functions
@ -4198,20 +4198,20 @@ Debugging functions
Program serialization
^^^^^^^^^^^^^^^^^^^^^
DAML-LF programs are serialized using `Protocol Buffers
Daml-LF programs are serialized using `Protocol Buffers
<https://developers.google.com/protocol-buffers/>`_. The
machine-readable definition of the serialization for DAML-LF major
machine-readable definition of the serialization for Daml-LF major
version 1 can be found in the `daml_lf_1.proto
<../archive/src/main/protobuf/com/daml/daml_lf_dev/daml_lf_1.proto>`_
file.
For the sake of brevity, we do no exhaustively describe how DAML-LF
For the sake of brevity, we do no exhaustively describe how Daml-LF
programs are (un)serialized into protocol buffer. In the rest of this
section, we describe the particularities of the encoding and how
DAML-LF version impacts it.
Daml-LF version impacts it.
Specificities of DAML-LF serialization
Specificities of Daml-LF serialization
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Required fields
@ -4294,7 +4294,7 @@ The message is interpreted as n applications ``(e e₁ … eₙ)`` where
``eᵢ`` is the interpretation of the ``iᵗʰ`` elements of ``args``
(whenever ``1 ≤ i ≤ n``) and ``e`` is the interpretation of ``fun``.
Note that the DAML-LF deserialization process verifies the repeated
Note that the Daml-LF deserialization process verifies the repeated
fields of those compressed structures are non-empty. For instance, the
previous message can be used only if it encodes at least one
application.
@ -4312,7 +4312,7 @@ Maps
....
The program serialization format does not provide any direct way to
encode either `TextMap` or `GenMap`. DAML-LF programs can create such
encode either `TextMap` or `GenMap`. Daml-LF programs can create such
objects only dynamically using the builtin functions prefixed by
`TEXTMAP_` or `'GENMAP_'`
@ -4357,8 +4357,8 @@ package if and only if the latter of these two validation passes.
Serialization changes since version 1.6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As explained in `Version history`_ section, DAML-LF programs are
accompanied by a number version. This enables the DAML-LF
As explained in `Version history`_ section, Daml-LF programs are
accompanied by a number version. This enables the Daml-LF
deserialization process to interpret different versions of the
language in a backward compatibility way. During deserialization, any
encoding that does not follow the minor version provided is rejected.
@ -4389,14 +4389,14 @@ in ``Package.interned_strings``.
+ An `interned identifier` is an `interned string` that can be
interpreted as a valid `identifier`
Starting from DAML-LF 1.7, all ``string`` (or ``repeated string``)
Starting from Daml-LF 1.7, all ``string`` (or ``repeated string``)
fields with the suffix ``_str`` are forbidden. Alternative fields of
type ``int32`` (or ``repeated int32``) with the suffix
``_interned_str`` must be used instead. Except
``PackageRef.package_id_interned_str`` which is [*Available in
versions >= 1.6*], all fields with suffix ``_interned_str`` are
[*Available in versions >= 1.7*]. The deserialization process will
reject any DAML-LF 1.7 (or later) that does not comply with this
reject any Daml-LF 1.7 (or later) that does not comply with this
restriction.
Name Interning
@ -4416,11 +4416,11 @@ so-called `interned name` is a valid zero-based index of this list. An
`interned name` is interpreted as the name built form the `name` it
points to in ``Package.interned_dotted_names``.
Starting from DAML-LF 1.7, all ``DottedName`` (or ``repeated
Starting from Daml-LF 1.7, all ``DottedName`` (or ``repeated
string``) fields with the suffix ``_dname`` are forbidden. Alternative
fields of type ``int32`` with the suffix ``_interned_dname``
[*Available in versions >= 1.7*] must be used instead. The
deserialization process will reject any DAML-LF 1.7 (or later) that
deserialization process will reject any Daml-LF 1.7 (or later) that
that does not comply this restriction.
Nat kind and Nat types
@ -4428,15 +4428,15 @@ Nat kind and Nat types
[*Available in versions >= 1.7*]
The deserialization process will reject any DAML-LF 1.6 (or earlier)
The deserialization process will reject any Daml-LF 1.6 (or earlier)
that uses ``nat`` field in ``Kind`` or ``Type`` messages.
Starting from DAML-LF 1.7 those messages are deserialized to ``nat``
Starting from Daml-LF 1.7 those messages are deserialized to ``nat``
kind and ``nat`` type respectively. The field ``nat`` of ``Type``
message must be a positive integer.
Note that despite there being no concrete way to build Nat types in a
DAML-LF 1.6 (or earlier) program, those are implicitly generated when
Daml-LF 1.6 (or earlier) program, those are implicitly generated when
reading as Numeric type and Numeric builtin as described in the next
section.
@ -4445,12 +4445,12 @@ Parametric scaled Decimals
[*Available in versions >= 1.7*]
DAML-LF 1.7 is the first version that supports parametric scaled
Daml-LF 1.7 is the first version that supports parametric scaled
decimals. Prior versions have decimal number with a fixed scale of 10
called Decimal. Backward compatibility with the current specification
is achieved as follows:
On the one hand, in case of DAML-LF 1.6 archive:
On the one hand, in case of Daml-LF 1.6 archive:
- The ``decimal`` field of the ``PrimLit`` message must match the
regexp::
@ -4486,10 +4486,10 @@ On the one hand, in case of DAML-LF 1.6 archive:
In other words ``numeric`` fields in ``PrimLit`` and ``PrimType``
messages must remain unset and Numeric ``BuiltinFunction`` (those
containing ``NUMERIC`` in their name) are forbidden. The
deserialization process will reject any DAML-LF 1.6 (or earlier)
deserialization process will reject any Daml-LF 1.6 (or earlier)
that does not comply those restrictions.
On the other hand, starting from DAML-LF 1.7:
On the other hand, starting from Daml-LF 1.7:
- The ``numeric`` field of the ``PrimLit`` message must match the
regexp:
@ -4506,16 +4506,16 @@ On the other hand, starting from DAML-LF 1.7:
In other words ``decimal`` fields in ``PrimLit`` and ``PrimType``
messages must remain unset and Decimal ``BuiltinFunction`` (those
containing ``DECIMAL`` in their name are forbidden). The
deserialization process will reject any DAML-LF 1.7 (or later)
deserialization process will reject any Daml-LF 1.7 (or later)
that does not comply those restrictions.
Any type and type representation
................................
DAML-LF 1.7 is the first version that supports any type and
Daml-LF 1.7 is the first version that supports any type and
type representation.
The deserialization process will reject any DAML-LF 1.6 program using
The deserialization process will reject any Daml-LF 1.6 program using
this data structure.
Generic Equality/Order
@ -4523,11 +4523,11 @@ Generic Equality/Order
[*Available in versions >= 1.11*]
The deserialization process will reject any DAML-LF 1.8 (or earlier)
The deserialization process will reject any Daml-LF 1.8 (or earlier)
program using the following builtin functions ``EQUAL``, ``LESS_EQ``,
``LESS``, ``GREATER_EQ``, ``GREATER``
The deserialization process will reject any DAML-LF 1.11 (or latter)
The deserialization process will reject any Daml-LF 1.11 (or latter)
program using the following builtin functions , ``EQUAL_INT64``,
``EQUAL_NUMERIC``, ``EQUAL_TEXT``, ``EQUAL_TIMESTAMP``,
``EQUAL_DATE``, ``EQUAL_PARTY``, ``EQUAL_BOOL``,
@ -4545,7 +4545,7 @@ Generic Map
[*Available in versions >= 1.11*]
The deserialization process will reject any DAML-LF 1.8 (or earlier)
The deserialization process will reject any Daml-LF 1.8 (or earlier)
program using the builtin type ``GENMAP`` or the builtin functions
``GENMAP_EMPTY``, ``GENMAP_INSERT``, ``GENMAP_LOOKUP``,
``GENMAP_DELETE``, ``GENMAP_KEYS``, ``GENMAP_VALUES``,
@ -4556,7 +4556,7 @@ exercise_by_key
[*Available in versions >= 1.11*]
The deserialization process will reject any DAML-LF 1.8 (or earlier)
The deserialization process will reject any Daml-LF 1.8 (or earlier)
program using the field ``exercise_by_key`` in the ``Update`` message.
TO_TEXT_CONTRACT_ID
@ -4564,7 +4564,7 @@ TO_TEXT_CONTRACT_ID
[*Available in versions >= 1.11*]
The deserialization process will reject any DAML-LF 1.8 (or earlier)
The deserialization process will reject any Daml-LF 1.8 (or earlier)
program using the builtin function ``TO_TEXT_CONTRACT_ID``.
Choice observers
@ -4576,7 +4576,7 @@ An optional `observer` expression may be attached to a flexible
choice. This allows the specification of additional parties to whom
the sub-transaction is disclosed.
The deserialization process will reject any DAML-LF 1.8 (or earlier)
The deserialization process will reject any Daml-LF 1.8 (or earlier)
program using the field ``observers`` in the ``TemplateChoice``
message.
@ -4585,7 +4585,7 @@ Exception
[*Available in versions >= 1.1dev*]
The deserialization process will reject any DAML-LF 1.11 (or earlier)
The deserialization process will reject any Daml-LF 1.11 (or earlier)
program exception using
- the field ``throw``, ``to_any_exception``, or ``from_any_exception``
in the ``Expr`` message,

38
daml-lf/spec/transaction.rst
View File

@ -2,13 +2,13 @@
.. SPDX-License-Identifier: Apache-2.0
DAML-LF Transaction Specification
Daml-LF Transaction Specification
=================================
**version 10, 25 March 2020**
This specification, in concert with the ``transaction.proto``
machine-readable definition, defines a format for *DAML LF
machine-readable definition, defines a format for *Daml LF
transactions*, to be used when inspecting ledger activity as a st
ream, or submitting changes to the ledger.
@ -17,9 +17,9 @@ A *ledger* can be viewed as a sequence of these transactions.
Do not read this without ``transaction.proto``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
``transaction.proto`` defines the baseline rules for *DAML-LF
``transaction.proto`` defines the baseline rules for *Daml-LF
transactions*; that file must be consulted in concert with this
document for a full specification of DAML-LF transactions. Except
document for a full specification of Daml-LF transactions. Except
where required for clarity, we do not repeat rules defined and
enforced in that file within this document. When consulting the
section on each message type, you must also refer to the same
@ -39,16 +39,16 @@ impossible to define all the requirements for transactions in the
``.proto`` format. All such rules are included in this document,
instead.
If you are constructing a DAML-LF transaction, it is not sufficient to
If you are constructing a Daml-LF transaction, it is not sufficient to
merely conform to the structure defined in ``transaction.proto``; you
must also conform to the rules defined in this document. A transaction
that happens to conform to ``transaction.proto``, yet violates some rule
of this document, is not a valid DAML-LF transaction.
of this document, is not a valid Daml-LF transaction.
Backward compatibility
^^^^^^^^^^^^^^^^^^^^^^
DAML-LF transaction nodes, and transactions are encoded according a
Daml-LF transaction nodes, and transactions are encoded according a
common versioning scheme, called the *transaction version scheme*.
Each version of this scheme, called a transaction version, is
associated to a language version.
@ -126,7 +126,7 @@ version 13* section must be ignored entirely.
Changing this specification
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Future versions of this specification must conform to the `DAML-LF
Future versions of this specification must conform to the `Daml-LF
Governance process`_ and preserve all invariants described above.
Where these are in conflict, the governance process takes priority.
@ -159,7 +159,7 @@ important subtlety in the comparison.
Additionally, you should update the following `Version history`_.
.. _`DAML-LF Governance process`: ../governance.rst
.. _`Daml-LF Governance process`: ../governance.rst
.. _`value`: value.rst
Version history
@ -221,7 +221,7 @@ message ContractInstance
*since version 10*
An instance of a DAML-LF template, represented by the DAML-LF value used
An instance of a Daml-LF template, represented by the Daml-LF value used
to construct that instance.
As of version 10, these fields are included:
@ -232,7 +232,7 @@ As of version 10, these fields are included:
``template_id`` and ``value`` are required; ``agreement`` is optional.
``value`` must conform to the type of the DAML-LF associated data type
``value`` must conform to the type of the Daml-LF associated data type
indicated by ``template_id``.
``template_id``'s structure is defined by `the value specification`_;
@ -332,7 +332,7 @@ message NodeCreate
*since version 10*
The creation of a contract by instantiating a DAML-LF template with the
The creation of a contract by instantiating a Daml-LF template with the
given argument.
As of version 10, these fields are included:
@ -356,7 +356,7 @@ Every element of ``stakeholders`` is a party identifier.
The stakeholders of a contract are the signatories and the observers of
said contract.
The signatories of a contract are specified in the DAML-LF definition of
The signatories of a contract are specified in the Daml-LF definition of
the template for said contract. Conceptually, they are the parties that
agreed for that contract to be created.
@ -368,7 +368,7 @@ Every element of ``stakeholders`` is a party identifier.
* Its ``key`` must conform to the key definition for the ``template_id``
in the ``contract_instance``.
The maintainers of a contract key are specified in the DAML-LF definition of
The maintainers of a contract key are specified in the Daml-LF definition of
the template for the contract.
message NodeFetch
@ -376,7 +376,7 @@ message NodeFetch
*since version 10*
Evidence of a DAML-LF ``fetch`` invocation.
Evidence of a Daml-LF ``fetch`` invocation.
As of version 10, these fields are included:
@ -407,7 +407,7 @@ identifier.
contract itself.
``key_with_maintainers`` is optional. It is present if and only if the
``template_id`` field refers to a template with a DAML-LF key
``template_id`` field refers to a template with a Daml-LF key
definition. When present, the field's sub-fields ``key`` and
``maintainers`` must conform to the key definition for the
``template_id``.
@ -418,7 +418,7 @@ message NodeExercise
*since version 10*
The exercise of a choice on a contract, selected from the available
choices in the associated DAML-LF template definition.
choices in the associated Daml-LF template definition.
As of version 10, these fields are included:
@ -444,10 +444,10 @@ to be non-empty.
the version of that specification to use when consuming it is the
``version`` field of ``chosen_value``.
``choice`` must be the name of a choice defined in the DAML-LF template
``choice`` must be the name of a choice defined in the Daml-LF template
definition referred to by ``template_id``.
``chosen_value`` must conform to the DAML-LF argument type of the
``chosen_value`` must conform to the Daml-LF argument type of the
``choice``.
``children`` is constrained as described under `field node_id`_. Every

38
daml-lf/spec/value.rst
View File

@ -1,21 +1,21 @@
.. Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
.. SPDX-License-Identifier: Apache-2.0
DAML-LF Value Specification
Daml-LF Value Specification
===========================
**version 6, 10 Dec 2020**
The DAML-LF language includes ways to define *data types*,
The Daml-LF language includes ways to define *data types*,
specifications of structure, and includes rules by which a restricted
subset of those data types are considered *serializable*.
This specification, in concert with the ``value.proto`` machine-readable
definition, defines a format by which *values* of *serializable DAML-LF
definition, defines a format by which *values* of *serializable Daml-LF
types* may be represented. Only such *serializable values* may be
stored on a ledger.
Values are typically consumed in tandem with related DAML-LF type
Values are typically consumed in tandem with related Daml-LF type
information, so many fields that may be inferred with this information
are optional. For example, `message RecordField`_ names are defined as
part of their respective LF datatypes, so there is no need to repeat
@ -26,7 +26,7 @@ Do not read this without ``value.proto``
``value.proto`` defines the baseline rules for values; that file must be
consulted in concert with this document for a full specification of
DAML-LF values. Except where required for clarity, we do not repeat
Daml-LF values. Except where required for clarity, we do not repeat
rules defined and enforced in that file within this document. When
consulting the section on each message type, you must also refer to the
same definition in ``value.proto`` for a full definition of the
@ -43,16 +43,16 @@ full specification of the value format, because it is impossible to
define all the requirements for values in the ``.proto`` format. All
such rules are included in this document, instead.
If you are constructing a DAML-LF value, it is not sufficient to merely
If you are constructing a Daml-LF value, it is not sufficient to merely
conform to the structure defined in ``value.proto``; you must also
conform to the rules defined in this document. A value that happens to
conform to ``value.proto``, yet violates some rule of this document, is
not a valid DAML-LF value.
not a valid Daml-LF value.
Backward compatibility
^^^^^^^^^^^^^^^^^^^^^^
DAML-LF values are accompanied by a version identifier; every change to
Daml-LF values are accompanied by a version identifier; every change to
``value.proto`` entails a change to this specification, and every change
to this specification introduces a unique new version. `Version
history`_ defines a total ordering of all past versions; any version *y*
@ -104,7 +104,7 @@ must be ignored entirely.
Changing this specification
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Future versions of this specification must conform to the `DAML-LF
Future versions of this specification must conform to the `Daml-LF
Governance process`_ and preserve all invariants described above. Where
these are in conflict, the governance process takes priority.
@ -137,7 +137,7 @@ important subtlety in the comparison.
Additionally, you should update the following `Version history`_.
.. _`DAML-LF Governance process`: ../governance.rst
.. _`Daml-LF Governance process`: ../governance.rst
.. _`transaction`: transaction.rst
Version history
@ -196,7 +196,7 @@ message Value
*since version 6*
An actual DAML-LF *serializable value*.
An actual Daml-LF *serializable value*.
As of version 6, may be any one of these:
@ -288,7 +288,7 @@ field unit
While ``Empty`` contains no information, conforming consumers are
permitted to expect this member of `message Value`_ to be chosen
correctly in appropriate contexts. So if the ``Value``'s DAML-LF type
correctly in appropriate contexts. So if the ``Value``'s Daml-LF type
is ``Unit``, a consumer *may* reject the message if the ``Value`` is not
the ``unit`` member of the sum, so value producers must take care to
select this member and not another value as a placeholder (e.g. 0,
@ -322,7 +322,7 @@ field record_id
*since version 6*
The fully-qualified `message Identifier`_ of the DAML-LF record type.
The fully-qualified `message Identifier`_ of the Daml-LF record type.
It may be omitted.
field fields
@ -332,13 +332,13 @@ field fields
Zero or more `message RecordField`_ values.
The number and types of values in the fields must match the DAML-LF
The number and types of values in the fields must match the Daml-LF
record type associated with the `message Record`_, whether that record
type is inferred from context or explicitly supplied as a `field
record_id`_.
Additionally, the *order* of fields must match the order in which they
are declared in DAML-LF for that record type. Neither producers nor
are declared in Daml-LF for that record type. Neither producers nor
consumers are permitted to use ``label`` to reorder the fields.
So, for example, it is unsafe to use a ``Map``, ``HashMap``, or some
@ -360,7 +360,7 @@ As of version 6, these fields are included:
* `message Value`_ value
``label`` may be an empty string. However, if ``label`` is non-empty,
it must match the name of the field in this position in the DAML-LF
it must match the name of the field in this position in the Daml-LF
record type under consideration. For example, if the second field of an
LF record type is named ``bar``, then label of the second element of
`field fields`_ may be ``"bar"``, or an empty string in circumstances
@ -375,7 +375,7 @@ message Identifier
*since version 6*
A reference to a DAML-LF record or variant type.
A reference to a Daml-LF record or variant type.
As of version 1, these fields are included, all required to be
non-empty:
@ -384,7 +384,7 @@ non-empty:
* repeated ``string`` module_name
* repeated ``string`` name
``package_id`` is a DAML-LF package ID, indicating the LF package in
``package_id`` is a Daml-LF package ID, indicating the LF package in
which the type is defined. package ID are restricted to be a
non-empty string of printable US-ASCII characters (characters ranging
from '\32' to '\127').
@ -427,7 +427,7 @@ field variant_id
*since version 6*
The fully-qualified `message Identifier`_ of the DAML-LF variant type.
The fully-qualified `message Identifier`_ of the Daml-LF variant type.
It may be omitted.
field constructor

4
daml-lf/transaction/src/main/protobuf/com/daml/lf/transaction.proto
View File

@ -2,7 +2,7 @@
// SPDX-License-Identifier: Apache-2.0
// Please refer to the transaction spec (in daml-foundations/daml-lf/spec/transaction.rst)
// which describes the semantics of DAML-LF transactions in more detail.
// which describes the semantics of Daml-LF transactions in more detail.
//
// [one-line] version summary
// * 10: new field key_with_maintainers in NodeFetch
@ -15,7 +15,7 @@ option java_package = "com.daml.lf.transaction";
import "com/daml/lf/value.proto";
// data structure represent an update to the ledger. executing a DAML-LF action of type
// data structure represent an update to the ledger. executing a Daml-LF action of type
// Update A produces produces one of these.
// architecture-handbook-entry-begin: Transaction
message Transaction {

4
daml-lf/transaction/src/main/protobuf/com/daml/lf/value.proto
View File

@ -2,7 +2,7 @@
// SPDX-License-Identifier: Apache-2.0
// Please refer to the value spec (in daml-foundations/daml-lf/spec/value.rst)
// which describes the semantics of DAML-LF values in more detail.
// which describes the semantics of Daml-LF values in more detail.
//
// [one-line] version summary
// * 6: initial version
@ -20,7 +20,7 @@ message VersionedValue {
Value value = 2;
}
// The universe of serializable DAML-LF values.
// The universe of serializable Daml-LF values.
// architecture-handbook-entry-begin: Value
message Value {
oneof sum {

12
daml-script/daml/Daml/Script.daml
View File

@ -147,10 +147,10 @@ data SetTimePayload a = SetTimePayload
-- | Set the time via the time service.
--
-- This is only supported in static time mode when running over the gRPC API
-- and in DAML Studio.
-- and in Daml Studio.
--
-- Note that the ledger time service does not support going backwards in time.
-- However, you can go back in time in DAML Studio.
-- However, you can go back in time in Daml Studio.
setTime : Time -> Script ()
setTime time = lift $ Free $ SetTime $ SetTimePayload with
time
@ -159,12 +159,12 @@ setTime time = lift $ Free $ SetTime $ SetTimePayload with
-- | Advance ledger time by the given interval.
--
-- Only supported in static time mode when running over the gRPC API
-- and in DAML Studio. Note that this is not an atomic operation over the
-- and in Daml Studio. Note that this is not an atomic operation over the
-- gRPC API so no other clients should try to change time while this is
-- running.
--
-- Note that the ledger time service does not support going backwards in time.
-- However, you can go back in time in DAML Studio.
-- However, you can go back in time in Daml Studio.
passTime : RelTime -> Script ()
passTime rt = do
t <- getTime
@ -332,7 +332,7 @@ instance HasSubmit Script Commands where
--
-- 1. NonEmpty Party -> [Party] -> …
-- This is the safest one but it’s rather awkward to use since NonEmpty is
-- long and fairly uncommon. Given that DAML Script is primarily used during
-- long and fairly uncommon. Given that Daml Script is primarily used during
-- testing and development, the extra safety is also not that crucial.
-- It is also different from signatories which also needs to be nonempty but
-- does not enforce this statically.
@ -375,7 +375,7 @@ submitMultiMustFail actAs readAs cmds =
continue = const ()
locations = getCallStack callStack
-- | This is the type of A DAML script. `Script` is an instance of `Action`,
-- | This is the type of A Daml script. `Script` is an instance of `Action`,
-- so you can use `do` notation.
data Script a = Script with
runScript : () -> (Free ScriptF (a, ()))

2
daml-script/daml/daml-script-hoogle-template.txt
View File

@ -4,7 +4,7 @@
-- (C) Copyright 2020 Digital Asset (Switzerland) GmbH and/or its affiliates.
-- All rights reserved. Any unauthorized use, duplication or distribution is strictly prohibited.
-- | DAML Script library.
-- | Daml Script library.
@url {{base-url}}
@package daml-script
@version 1.2.0

4
daml-script/daml/daml-script-index-template.rst
View File

@ -3,9 +3,9 @@
.. _daml-script-api-docs:
DAML Script Library
Daml Script Library
====================
The DAML Script library defines the API used to implement DAML scripts. See :doc:`/daml-script/index`:: for more information on DAML script.
The Daml Script library defines the API used to implement Daml scripts. See :doc:`/daml-script/index`:: for more information on Daml script.
{{{body}}}

4
dev-env/dotfiles/README.md
View File

@ -1,4 +1,4 @@
# Editor DAML Language Integration
# Editor Daml Language Integration
## Vim
@ -15,7 +15,7 @@ your `~/.vimrc`.
## VS Code
Follow the DAML Studio installation instructions in the DAML user guide.
Follow the Daml Studio installation instructions in the Daml user guide.
## Update Keywords

4
docs/README.md
View File

@ -1,4 +1,4 @@
# DAML Documentation
# Daml Documentation
This directory contains all of the documentation that gets published to docs.daml.com.
@ -20,7 +20,7 @@ To edit documentation:
Not all of our docs are in rst files: some get generated. They are:
- the ledger API proto docs
- the DAML standard library reference
- the Daml standard library reference
- the Java bindings reference
To edit those docs, edit the content inside the code source.

14
docs/configs/html/conf.py
View File

@ -3,7 +3,7 @@
# -*- coding: utf-8 -*-
#
# DAML SDK documentation build configuration file, created by
# Daml SDK documentation build configuration file, created by
# sphinx-quickstart on Wed Jul 5 17:39:28 2017.
#
# This file is execfile()d with the current directory set to its
@ -51,8 +51,8 @@ source_suffix = '.rst'
master_doc = 'index'
# General information about the project.
project = u'DAML SDK'
copyright = u'© Copyright 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved. Any unauthorized use, duplication or distribution is strictly prohibited. "Digital Asset" and "DAML" are Registered in the U.S. Patent and Trademark Office.'
project = u'Daml SDK'
copyright = u'© Copyright 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved. Any unauthorized use, duplication or distribution is strictly prohibited. "Digital Asset" and "Daml" are Registered in the U.S. Patent and Trademark Office.'
author = u'Digital Asset'
# The version info for the project you're documenting, acts as replacement for
@ -145,7 +145,7 @@ latex_elements = {
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'DigitalAssetSDK.tex', u'DAML SDK Documentation',
(master_doc, 'DigitalAssetSDK.tex', u'Daml SDK Documentation',
u'Digital Asset', 'manual'),
]
@ -155,7 +155,7 @@ latex_documents = [
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
(master_doc, 'digitalassetsdk', u'DAML SDK Documentation',
(master_doc, 'digitalassetsdk', u'Daml SDK Documentation',
[author], 1)
]
@ -166,7 +166,7 @@ man_pages = [
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
(master_doc, 'DigitalAssetSDK', u'DAML SDK Documentation',
(master_doc, 'DigitalAssetSDK', u'Daml SDK Documentation',
author, 'DigitalAssetSDK', 'One line description of project.',
'Miscellaneous'),
]
@ -178,7 +178,7 @@ rst_prolog = """
.. _http-json: https://github.com/digital-asset/daml/releases/download/v{release}/http-json-{release}.jar
""".format(release = release)
# Import the DAML lexer
# Import the Daml lexer
def setup(sphinx):
from pygments_daml_lexer import DAMLLexer
sphinx.add_lexer("daml", DAMLLexer())

14
docs/configs/pdf/conf.py
View File

@ -3,7 +3,7 @@
# -*- coding: utf-8 -*-
#
# DAML SDK documentation build configuration file, created by
# Daml SDK documentation build configuration file, created by
# sphinx-quickstart on Wed Jul 5 17:39:28 2017.
#
# This file is execfile()d with the current directory set to its
@ -53,7 +53,7 @@ source_suffix = '.rst'
master_doc = 'index'
# General information about the project.
project = u'DAML SDK'
project = u'Daml SDK'
copyright = u'© Copyright 2020 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved. Any unauthorized use, duplication or distribution is strictly prohibited.'
author = u'Digital Asset'
@ -256,7 +256,7 @@ latex_elements = {
\centering
\vspace*{40mm} %%% * is used to give space from top
\textcolor{headerblue}{\sffamily{\textbf{\Huge {DAML SDK Documentation}}}}
\textcolor{headerblue}{\sffamily{\textbf{\Huge {Daml SDK Documentation}}}}
\vspace{20mm}
\begin{figure}[!h]
@ -303,7 +303,7 @@ latex_logo = 'logo.png'
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'DigitalAssetSDK.tex', u'DAML SDK Documentation',
(master_doc, 'DigitalAssetSDK.tex', u'Daml SDK Documentation',
u'Digital Asset', 'manual'),
]
@ -313,7 +313,7 @@ latex_documents = [
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
(master_doc, 'digitalassetsdk', u'DAML SDK Documentation',
(master_doc, 'digitalassetsdk', u'Daml SDK Documentation',
[author], 1)
]
@ -324,7 +324,7 @@ man_pages = [
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
(master_doc, 'DigitalAssetSDK', u'DAML SDK Documentation',
(master_doc, 'DigitalAssetSDK', u'Daml SDK Documentation',
author, 'DigitalAssetSDK', 'One line description of project.',
'Miscellaneous'),
]
@ -336,7 +336,7 @@ rst_prolog = """
.. _api-test-tool: https://repo1.maven.org/maven2/com/daml/ledger-api-test-tool/{release}/ledger-api-test-tool-{release}.jar
""".format(release = release)
# Import the DAML lexer
# Import the Daml lexer
def setup(sphinx):
from pygments_daml_lexer import DAMLLexer
sphinx.add_lexer("daml", DAMLLexer())

14
docs/configs/pdf/index.rst
View File

@ -1,7 +1,7 @@
.. Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
.. SPDX-License-Identifier: Apache-2.0
DAML Documentation
Daml Documentation
==================
Getting started
@ -18,7 +18,7 @@ Getting started
getting-started/testing
Cheat Sheet <https://docs.daml.com/cheat-sheet>
Writing DAML
Writing Daml
------------
.. toctree::
@ -42,13 +42,13 @@ Building applications
app-dev/app-arch
app-dev/bindings-ts/index
json-api/index
DAML Script <daml-script/index>
DAML REPL <daml-repl/index>
Daml Script <daml-script/index>
Daml REPL <daml-repl/index>
upgrade/index
app-dev/authorization
app-dev/ledger-api
Deploying to DAML ledgers
Deploying to Daml ledgers
-------------------------
.. toctree::
@ -59,7 +59,7 @@ Deploying to DAML ledgers
deploy/generic_ledger
deploy/ledger-topologies
Operating DAML
Operating Daml
--------------
.. toctree::
@ -117,7 +117,7 @@ Early Access Features
tools/trigger-service
concepts/interoperability
DAML Ecosystem
Daml Ecosystem
--------------
.. toctree::

2
docs/configs/static/pygments_daml_lexer.py
View File

@ -7,7 +7,7 @@ from pygments.token import *
class DAMLLexer(HaskellLexer):
name = 'DAML'
name = 'Daml'
aliases = ['daml']
filenames = ['*.daml']

68
docs/source/app-dev/app-arch.rst
View File

@ -6,13 +6,13 @@
Application architecture
########################
This section describes our recommended design of a full-stack DAML application.
This section describes our recommended design of a full-stack Daml application.
.. image:: ./recommended_architecture.svg
The above image shows the recommended architecture. Of course there are many ways how you can change
the architecture and technology stack to fit your needs, which we'll mention in the corresponding
sections. Note that the Participant Node is integrated into the DAML drivers in some cases rather
sections. Note that the Participant Node is integrated into the Daml drivers in some cases rather
than being part of the Application Backend. See :doc:`/support/overview` for more details.
To get started quickly with the recommended application architecture clone the
@ -25,34 +25,34 @@ To get started quickly with the recommended application architecture clone the
``create-daml-app`` is a small, but fully functional demo application implementing the recommended
architecture, providing you with an excellent starting point for your own application. It showcases
- using DAML React libraries
- quick iteration against the :ref:`DAML Sandbox <sandbox-manual>`.
- using Daml React libraries
- quick iteration against the :ref:`Daml Sandbox <sandbox-manual>`.
- authorization
- deploying your application in the cloud as a Docker container
Backend
~~~~~~~
The backend for your application can be any DAML ledger implementation running your DAR
(:ref:`DAML Archive <dar-file-dalf-file>`) file.
The backend for your application can be any Daml ledger implementation running your DAR
(:ref:`Daml Archive <dar-file-dalf-file>`) file.
We recommend using the :ref:`DAML JSON API <json-api>` as an interface to your frontend. It is
We recommend using the :ref:`Daml JSON API <json-api>` as an interface to your frontend. It is
served by the HTTP JSON API server connected to the ledger API server. It provides simple HTTP
endpoints to interact with the ledger via GET/POST requests. However, if you prefer, you can also
use the :ref:`gRPC Ledger API <grpc>` directly.
When you use the ``create-daml-app`` template application, you can start a DAML Sandbox together
When you use the ``create-daml-app`` template application, you can start a Daml Sandbox together
with a JSON API server by running
.. code-block:: bash
daml start --start-navigator=no
in the root of the project. DAML Sandbox exposes the same DAML Ledger API a Participant Node would
expose without requiring a fully-fledged DAML network to back the application. Once your
in the root of the project. Daml Sandbox exposes the same Daml Ledger API a Participant Node would
expose without requiring a fully-fledged Daml network to back the application. Once your
application matures and becomes ready for production, the ``daml deploy`` command helps you deploy
your frontend and DAML artifacts of your project to a production DAML network. See
:ref:`Deploying to DAML Ledgers <deploy-ref_overview>` for an in depth manual for specific ledgers.
your frontend and Daml artifacts of your project to a production Daml network. See
:ref:`Deploying to Daml Ledgers <deploy-ref_overview>` for an in depth manual for specific ledgers.
Frontend
~~~~~~~~
@ -64,21 +64,21 @@ you can choose virtually any language for your frontend and interact with the le
:ref:`gRPC Ledger API <grpc>` directly.
We provide two libraries to build your React frontend for a DAML application.
We provide two libraries to build your React frontend for a Daml application.
+--------------------------------------------------------------+--------------------------------------------------------------------------+
| Name | Summary |
+==============================================================+==========================================================================+
| `@daml/react <https://www.npmjs.com/package/@daml/react>`_ | React hooks to query/create/exercise DAML contracts |
| `@daml/react <https://www.npmjs.com/package/@daml/react>`_ | React hooks to query/create/exercise Daml contracts |
+--------------------------------------------------------------+--------------------------------------------------------------------------+
| `@daml/ledger <https://www.npmjs.com/package/@daml/ledger>`_ | DAML ledger object to connect and directly submit commands to the ledger |
| `@daml/ledger <https://www.npmjs.com/package/@daml/ledger>`_ | Daml ledger object to connect and directly submit commands to the ledger |
+--------------------------------------------------------------+--------------------------------------------------------------------------+
You can install any of these libraries by running ``npm install <library>`` in the ``ui`` directory of
your project, e.g. ``npm install @daml/react``. Please explore the ``create-daml-app`` example project
to see the usage of these libraries.
To make your life easy when interacting with the ledger, the DAML assistant can generate JavaScript
To make your life easy when interacting with the ledger, the Daml assistant can generate JavaScript
libraries with TypeScript typings from the data types declared in the deployed DAR.
.. code-block:: bash
@ -100,10 +100,10 @@ Authorization
When you deploy your application to a production ledger, you need to authenticate the identities of
your users.
DAML ledgers support a unified interface for authorization of commands. Some DAML ledgers, like for
Daml ledgers support a unified interface for authorization of commands. Some Daml ledgers, like for
example https://projectdabl.com, offer integrated authentication and authorization, but you can also
use an external service provider like https://auth0.com. The DAML react libraries support interfacing
with a DAML ledger that validates authorization of incoming requests. Simply initialize your
use an external service provider like https://auth0.com. The Daml react libraries support interfacing
with a Daml ledger that validates authorization of incoming requests. Simply initialize your
``DamlLedger`` object with the token obtained by the respective token issuer. How authorization works and the
form of the required tokens is described in the :ref:`Authorization <authorization>` section.
@ -111,18 +111,18 @@ Developer workflow
~~~~~~~~~~~~~~~~~~
The SDK enables a local development environment with fast iteration cycles. If you run
``daml-reload-on-change.sh`` of the ``create-daml-app``, a local DAML Sandbox is started that
is updated with your most recent DAML code on any change. Next, you can start your frontend in
``daml-reload-on-change.sh`` of the ``create-daml-app``, a local Daml Sandbox is started that
is updated with your most recent Daml code on any change. Next, you can start your frontend in
development mode by changing to your ``ui`` directory and run ``npm start``. This will reload your
frontend whenever you make changes to it. You can add unit tests for your DAML models by writing
:ref:`DAML scenarios <testing-using-scenarios>`. These will also be reevaluated on change. A
typical DAML developer workflow is to
frontend whenever you make changes to it. You can add unit tests for your Daml models by writing
:ref:`Daml scenarios <testing-using-scenarios>`. These will also be reevaluated on change. A
typical Daml developer workflow is to
#. Make a small change to your DAML data model
#. Optionally test your DAML code and with :ref:`scenarios <testing-using-scenarios>`
#. Edit your React components to be aligned with changes made in DAML code
#. Make a small change to your Daml data model
#. Optionally test your Daml code and with :ref:`scenarios <testing-using-scenarios>`
#. Edit your React components to be aligned with changes made in Daml code
#. Extend the UI to make use of the newly introduced feature
#. Make further changes either to your DAML and/or React code until you're happy with what you've developed
#. Make further changes either to your Daml and/or React code until you're happy with what you've developed
.. image:: ./developer_workflow.svg
@ -131,12 +131,12 @@ typical DAML developer workflow is to
Command deduplication
*********************
The interaction of a DAML application with the ledger is inherently asynchronous: applications send commands to the ledger, and some time later they see the effect of that command on the ledger.
The interaction of a Daml application with the ledger is inherently asynchronous: applications send commands to the ledger, and some time later they see the effect of that command on the ledger.
There are several things that can fail during this time window: the application can crash, the participant node can crash, messages can be lost on the network, or the ledger may be just slow to respond due to a high load.
If you want to make sure that a command is not executed twice, your application needs to robustly handle all the various failure scenarios.
DAML ledgers provide a mechanism for :ref:`command deduplication <command-submission-service-deduplication>` to help deal this problem.
Daml ledgers provide a mechanism for :ref:`command deduplication <command-submission-service-deduplication>` to help deal this problem.
For each command applications provide a command ID and an optional parameter that specifies the deduplication time. If the latter parameter is not specified in the command submission itself, the ledger will fall back to using the configured maximum deduplication time.
The ledger will then guarantee that commands for the same submitting party and command ID will be ignored within the deduplication time window.
@ -156,7 +156,7 @@ For more details on command deduplication, see the :ref:`Ledger API Services <co
Failing over between Ledger API endpoints
*****************************************
Some DAML Ledgers support exposing multiple eventually consistent Ledger API
Some Daml Ledgers support exposing multiple eventually consistent Ledger API
endpoints where command deduplication works across these Ledger API endpoints.
For example, these endpoints might be hosted by separate Ledger API servers
that replicate the same data and host the same parties. Contact your ledger
@ -191,9 +191,9 @@ new endpoint, it will resume normal operation.
Dealing with time
*****************
The DAML language contains a function :ref:`getTime <daml-ref-gettime>` which returns a rough estimate of “current time” called *Ledger Time*. The notion of time comes with a lot of problems in a distributed setting: different participants might run different clocks, there may be latencies due to calculation and network, clocks may drift against each other over time, etc.
The Daml language contains a function :ref:`getTime <daml-ref-gettime>` which returns a rough estimate of “current time” called *Ledger Time*. The notion of time comes with a lot of problems in a distributed setting: different participants might run different clocks, there may be latencies due to calculation and network, clocks may drift against each other over time, etc.
In order to provide a useful notion of time in DAML without incurring severe performance or liveness penalties, DAML has two notions of time: *Ledger Time* and *Record Time*:
In order to provide a useful notion of time in Daml without incurring severe performance or liveness penalties, Daml has two notions of time: *Ledger Time* and *Record Time*:
- As part of command interpretation, each transaction is automatically assigned a *Ledger Time* by the participant server.
- All calls to ``getTime`` within a transaction return the *Ledger Time* assigned to that transaction.
@ -205,7 +205,7 @@ Some commands might take a long time to process, and by the time the resulting t
How is this used in practice?
- Be aware that ``getTime`` is only reasonably close to real time, and not completely monotonic. Avoid DAML workflows that rely on very accurate time measurements or high frequency time changes.
- Be aware that ``getTime`` is only reasonably close to real time, and not completely monotonic. Avoid Daml workflows that rely on very accurate time measurements or high frequency time changes.
- Set ``min_ledger_time_abs`` or ``min_ledger_time_rel`` if the duration of command interpretation and transmission is likely to take a long time relative to the tolerance interval set by the ledger.
- In some corner cases, the participant node may be unable to determine a suitable Ledger Time by itself. If you get an error that no Ledger Time could be found, check whether you have contention on any contract referenced by your command or whether the referenced contracts are sensitive to small changes of ``getTime``.

24
docs/source/app-dev/authorization.rst
View File

@ -6,7 +6,7 @@
Authorization
#############
When developing DAML applications using SDK tools,
When developing Daml applications using SDK tools,
your local setup will most likely not verify any authorization -
by default, any valid ledger API request will be accepted by the sandbox.
@ -19,22 +19,22 @@ The :doc:`Ledger API </app-dev/ledger-api>` is used to request changes to the le
wants to exercise choice X on contract Y*"), or to read data from the ledger (e.g., "*Alice wants to
see all active contracts*").
What requests are valid is defined by :ref:`integrity <da-model-integrity>` and :ref:`privacy <da-model-privacy>` parts the :ref:`DAML Ledger Model <da-ledgers>`.
This model is defined in terms of :ref:`DAML parties <glossary-party>`,
What requests are valid is defined by :ref:`integrity <da-model-integrity>` and :ref:`privacy <da-model-privacy>` parts the :ref:`Daml Ledger Model <da-ledgers>`.
This model is defined in terms of :ref:`Daml parties <glossary-party>`,
and does not require any cryptographic information to be sent along with requests.
In particular, this model does not talk about authentication ("*Is the request claiming to come from Alice really sent by Alice?*")
and authorization ("*Is Alice authorized to add a new DAML package to the ledger?*").
and authorization ("*Is Alice authorized to add a new Daml package to the ledger?*").
In practice, DAML ledgers will therefore need to add authentication to the ledger API.
In practice, Daml ledgers will therefore need to add authentication to the ledger API.
.. note::
Depending on the ledger topology, a DAML ledger may consist of multiple participant nodes,
Depending on the ledger topology, a Daml ledger may consist of multiple participant nodes,
each having its own ledger API server.
Each participant node typically hosts different DAML parties,
and only sees data visible to the parties hosted on that node (as defined by the DAML privacy model).
Each participant node typically hosts different Daml parties,
and only sees data visible to the parties hosted on that node (as defined by the Daml privacy model).
For more details on DAML ledger topologies, refer to the :ref:`DAML Ledger Topologies <daml-ledger-topologies>` documentation.
For more details on Daml ledger topologies, refer to the :ref:`Daml Ledger Topologies <daml-ledger-topologies>` documentation.
Adding authentication
=====================
@ -42,14 +42,14 @@ Adding authentication
How authentication is set up on a particular ledger is defined by the ledger operator.
However, most authentication setups share the following pattern:
First, the DAML application contacts a token issuer to get an access token.
First, the Daml application contacts a token issuer to get an access token.
The token issuer verifies the identity of the requesting user
(e.g., by checking the username/password credentials sent with the request),
looks up the privileges of the user,
and generates a signed access token describing those privileges.
Then, the DAML application sends the access token along with each ledger API request.
The DAML ledger verifies the signature of the token (to make sure it has not been tampered with),
Then, the Daml application sends the access token along with each ledger API request.
The Daml ledger verifies the signature of the token (to make sure it has not been tampered with),
and then checks that the privileges described in the token authorize the given ledger API request.
.. image:: ./images/Authentication.svg

36
docs/source/app-dev/bindings-java/codegen.rst
View File

@ -3,13 +3,13 @@
.. _daml-codegen-java:
Generate Java code from DAML
Generate Java code from Daml
############################
Introduction
============
When writing applications for the ledger in Java, you want to work with a representation of DAML templates and data types in Java that closely resemble the original DAML code while still being as true to the native types in Java as possible. To achieve this, you can use DAML to Java code generator ("Java codegen") to generate Java types based on a DAML model. You can then use these types in your Java code when reading information from and sending data to the ledger.
When writing applications for the ledger in Java, you want to work with a representation of Daml templates and data types in Java that closely resemble the original Daml code while still being as true to the native types in Java as possible. To achieve this, you can use Daml to Java code generator ("Java codegen") to generate Java types based on a Daml model. You can then use these types in your Java code when reading information from and sending data to the ledger.
Download
========
@ -25,7 +25,7 @@ You can download the `latest version <https://search.maven.org/artifact/com.daml
Run the Java codegen
====================
The Java codegen takes DAML archive (DAR) files as input and generates Java files for DAML templates, records, and variants. For information on creating DAR files see :ref:`assistant-manual-building-dars`. To use the Java codegen, run this command in a terminal:
The Java codegen takes Daml archive (DAR) files as input and generates Java files for Daml templates, records, and variants. For information on creating DAR files see :ref:`assistant-manual-building-dars`. To use the Java codegen, run this command in a terminal:
.. code-block:: none
@ -116,13 +116,13 @@ The Java codegen generates source files in a directory tree under the output dir
.. _daml-codegen-java-primitive-types:
Map DAML primitives to Java types
Map Daml primitives to Java types
---------------------------------
DAML built-in types are translated to the following equivalent types in Java:
Daml built-in types are translated to the following equivalent types in Java:
+--------------------------------+--------------------------------------------+------------------------+
| DAML type | Java type | Java Bindings |
| Daml type | Java type | Java Bindings |
| | | Value Type |
+================================+============================================+========================+
| ``Int`` | ``java.lang.Long`` | `Int64`_ |
@ -147,7 +147,7 @@ DAML built-in types are translated to the following equivalent types in Java:
| ``Optional`` | ``java.util.Optional`` | `DamlOptional`_ |
+--------------------------------+--------------------------------------------+------------------------+
| ``()`` (Unit) | **None** since the Java language doesn’t | `Unit`_ |
| | have a direct equivalent of DAML’s Unit | |
| | have a direct equivalent of Daml’s Unit | |
| | type ``()``, the generated code uses the | |
| | Java Bindings value type. | |
+--------------------------------+--------------------------------------------+------------------------+
@ -160,7 +160,7 @@ DAML built-in types are translated to the following equivalent types in Java:
Understand escaping rules
-------------------------
To avoid clashes with Java keywords, the Java codegen applies escaping rules to the following DAML identifiers:
To avoid clashes with Java keywords, the Java codegen applies escaping rules to the following Daml identifiers:
* Type names (except the already mapped :ref:`built-in types <daml-codegen-java-primitive-types>`)
* Constructor names
@ -173,12 +173,12 @@ If any of these identifiers match one of the `Java reserved keywords <https://do
Understand the generated classes
--------------------------------
Every user-defined data type in DAML (template, record, and variant) is represented by one or more Java classes as described in this section.
Every user-defined data type in Daml (template, record, and variant) is represented by one or more Java classes as described in this section.
The Java package for the generated classes is the equivalent of the lowercase DAML module name.
The Java package for the generated classes is the equivalent of the lowercase Daml module name.
.. code-block:: daml
:caption: DAML
:caption: Daml
module Foo.Bar.Baz where
@ -190,7 +190,7 @@ The Java package for the generated classes is the equivalent of the lowercase DA
Records (a.k.a product types)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A :ref:`DAML record <daml-ref-record-types>` is represented by a Java class with fields that have the same name as the DAML record fields. A DAML field having the type of another record is represented as a field having the type of the generated class for that record.
A :ref:`Daml record <daml-ref-record-types>` is represented by a Java class with fields that have the same name as the Daml record fields. A Daml field having the type of another record is represented as a field having the type of the generated class for that record.
.. literalinclude:: ./code-snippets/Com/Acme/ProductTypes.daml
:language: daml
@ -237,7 +237,7 @@ A Java file is generated that defines the class for the type ``Name``:
Templates
^^^^^^^^^
The Java codegen generates three classes for a DAML template:
The Java codegen generates three classes for a Daml template:
**TemplateName**
Represents the contract data or the template fields.
@ -393,9 +393,9 @@ Parameterized types
This section is only included for completeness: we don't expect users to make use of the ``fromValue`` and ``toValue methods``, because they would typically come from a template that doesn't have any unbound type parameters.
The Java codegen uses Java Generic types to represent :ref:`DAML parameterized types <daml-ref-parameterized-types>`.
The Java codegen uses Java Generic types to represent :ref:`Daml parameterized types <daml-ref-parameterized-types>`.
This DAML fragment defines the parameterized type ``Attribute``, used by the ``BookAttribute`` type for modeling the characteristics of the book:
This Daml fragment defines the parameterized type ``Attribute``, used by the ``BookAttribute`` type for modeling the characteristics of the book:
.. literalinclude:: ./code-snippets/Com/Acme/ParameterizedTypes.daml
:language: daml
@ -489,9 +489,9 @@ Below is a Java fragment that converts an attribute with a ``java.lang.Long`` va
Value serializedPages = pagesAttribute.toValue(Int64::new);
See :ref:`DAML To Java Type Mapping <daml-codegen-java-primitive-types>` for an overview of the Java Bindings `Value`_ types.
See :ref:`Daml To Java Type Mapping <daml-codegen-java-primitive-types>` for an overview of the Java Bindings `Value`_ types.
Note: If the DAML type is a record or variant with more than one type parameter, you need to pass a conversion function to the ``toValue`` method for each type parameter.
Note: If the Daml type is a record or variant with more than one type parameter, you need to pass a conversion function to the ``toValue`` method for each type parameter.
Create a value of a generated type from a Java Bindings value
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
@ -550,7 +550,7 @@ of the container.
Value serializedAuthors =
authorsAttribute.toValue(f -> f.stream().collect(DamlCollector.toList(Text::new));
To convert back DAML containers to Java ones, one must use the
To convert back Daml containers to Java ones, one must use the
containers methods ``toList`` or ``toMap``. Those methods expect
functions to convert back the container's entries.

6
docs/source/app-dev/bindings-java/example.rst
View File

@ -8,7 +8,7 @@ To try out the Java bindings library, use the `examples on GitHub <https://githu
The former example does not use the Reactive Components, and the latter example does. Both examples implement the ``PingPong`` application, which consists of:
- a DAML model with two contract templates, ``Ping`` and ``Pong``
- a Daml model with two contract templates, ``Ping`` and ``Pong``
- two parties, ``Alice`` and ``Bob``
The logic of the application goes like this:
@ -16,7 +16,7 @@ The logic of the application goes like this:
#. The application injects a contract of type ``Ping`` for ``Alice``.
#. ``Alice`` sees this contract and exercises the consuming choice ``RespondPong`` to create a contract of type ``Pong`` for ``Bob``.
#. ``Bob`` sees this contract and exercises the consuming choice ``RespondPing`` to create a contract of type ``Ping`` for ``Alice``.
#. Points 2 and 3 are repeated until the maximum number of contracts defined in the DAML is reached.
#. Points 2 and 3 are repeated until the maximum number of contracts defined in the Daml is reached.
Setting up the example projects
*******************************
@ -33,7 +33,7 @@ PingPongMain.java
The entry point for the Java code is the main class ``src/main/java/examples/pingpong/grpc/PingPongMain.java``. Look at this class to see:
- how to connect to and interact with a DAML Ledger via the Java bindings
- how to connect to and interact with a Daml Ledger via the Java bindings
- how to use the Reactive layer to build an automation for both parties.
At high level, the code does the following steps:

18
docs/source/app-dev/bindings-java/index.rst
View File

@ -14,7 +14,7 @@ Java bindings
Iou Quickstart Tutorial <quickstart>
The Java bindings is a client implementation of the *Ledger API*
based on `RxJava <https://github.com/ReactiveX/RxJava>`_, a library for composing asynchronous and event-based programs using observable sequences for the Java VM. It provides an idiomatic way to write DAML Ledger applications.
based on `RxJava <https://github.com/ReactiveX/RxJava>`_, a library for composing asynchronous and event-based programs using observable sequences for the Java VM. It provides an idiomatic way to write Daml Ledger applications.
.. seealso::
This documentation for the Java bindings API includes the `JavaDoc reference documentation <javadocs/index.html>`_.
@ -38,11 +38,11 @@ The Java bindings library is composed of:
The Reactive Layer also exposes the main interface representing a client
connecting via the Ledger API. This interface is called ``LedgerClient`` and the
main implementation working against a DAML Ledger is the ``DamlLedgerClient``.
main implementation working against a Daml Ledger is the ``DamlLedgerClient``.
Can be found in the java package ``com.daml.ledger.rxjava``.
- The Reactive Components
A set of optional components you can use to assemble DAML Ledger applications. These components are deprecated as of 2020-10-14.
A set of optional components you can use to assemble Daml Ledger applications. These components are deprecated as of 2020-10-14.
The most important components are:
@ -54,16 +54,16 @@ The Java bindings library is composed of:
Code generation
===============
When writing applications for the ledger in Java, you want to work with a representation of DAML templates and data types in Java that closely resemble the original DAML code while still being as true to the native types in Java as possible.
When writing applications for the ledger in Java, you want to work with a representation of Daml templates and data types in Java that closely resemble the original Daml code while still being as true to the native types in Java as possible.
To achieve this, you can use DAML to Java code generator ("Java codegen") to generate Java types based on a DAML model. You can then use these types in your Java code when reading information from and sending data to the ledger.
To achieve this, you can use Daml to Java code generator ("Java codegen") to generate Java types based on a Daml model. You can then use these types in your Java code when reading information from and sending data to the ledger.
For more information on Java code generation, see :doc:`/app-dev/bindings-java/codegen`.
Connecting to the ledger: LedgerClient
======================================
Connections to the ledger are made by creating instance of classes that implement the interface ``LedgerClient``. The class ``DamlLedgerClient`` implements this interface, and is used to connect to a DAML ledger.
Connections to the ledger are made by creating instance of classes that implement the interface ``LedgerClient``. The class ``DamlLedgerClient`` implements this interface, and is used to connect to a Daml ledger.
This class provides access to the ledgerId, and all clients that give access to the various ledger services, such as the active contract set, the transaction service, the time service, etc. This is described :ref:`below <ledger-api-java-binding-connecting>`. Consult the `JavaDoc for DamlLedgerClient <javadocs/com/daml/ledger/rxjava/DamlLedgerClient.html>`_ for full details.
@ -127,11 +127,11 @@ If you're communicating with a ledger that verifies authorization it's very impo
Connecting securely
===================
The Java bindings library lets you connect to a DAML Ledger via a secure connection. The builders created by
The Java bindings library lets you connect to a Daml Ledger via a secure connection. The builders created by
``DamlLedgerClient.newBuilder`` default to a plaintext connection, but you can invoke ``withSslContext`` to pass an ``SslContext``.
Using the default plaintext connection is useful only when connecting to a locally running Sandbox for development purposes.
Secure connections to a DAML Ledger must be configured to use client authentication certificates, which can be provided by a Ledger Operator.
Secure connections to a Daml Ledger must be configured to use client authentication certificates, which can be provided by a Ledger Operator.
For information on how to set up an ``SslContext`` with the provided certificates for client authentication, please consult the gRPC documentation on
`TLS with OpenSSL <https://github.com/grpc/grpc-java/blob/master/SECURITY.md#tls-with-openssl>`_ as well as the
@ -170,7 +170,7 @@ for the application, the application ``LedgerView`` is updated to contain that c
Writing automations: Bot
------------------------
The ``Bot`` is an abstraction used to write automation for a DAML Ledger. It is conceptually
The ``Bot`` is an abstraction used to write automation for a Daml Ledger. It is conceptually
defined by two aspects:
- the ``LedgerView``

64
docs/source/app-dev/bindings-java/quickstart.rst
View File

@ -6,7 +6,7 @@
IOU Quickstart Tutorial
#######################
In this guide, you will learn about developer tools and DAML applications by:
In this guide, you will learn about developer tools and Daml applications by:
- developing a simple ledger application for issuing, managing, transferring and trading IOUs ("I Owe You!")
- developing an integration layer that exposes some of the functionality via custom REST services
@ -21,7 +21,7 @@ Prerequisites:
Download the quickstart application
***********************************
You can get the quickstart application using the DAML assistant (``daml``):
You can get the quickstart application using the Daml assistant (``daml``):
#. Run ``daml new quickstart --template quickstart-java``
@ -58,9 +58,9 @@ The project contains the following files:
└── resources
└── logback.xml
- ``daml.yaml`` is a DAML project config file used by the SDK to find out how to build the DAML project and how to run it.
- ``daml`` contains the :ref:`DAML code <quickstart-daml>` specifying the contract model for the ledger.
- ``daml/Tests`` contains :ref:`test scenarios <quickstart-scenarios>` for the DAML model.
- ``daml.yaml`` is a Daml project config file used by the SDK to find out how to build the Daml project and how to run it.
- ``daml`` contains the :ref:`Daml code <quickstart-daml>` specifying the contract model for the ledger.
- ``daml/Tests`` contains :ref:`test scenarios <quickstart-scenarios>` for the Daml model.
- ``frontend-config.js`` and ``ui-backend.conf`` are configuration files for the :ref:`Navigator <quickstart-navigator>` frontend.
- ``pom.xml`` and ``src/main/java`` constitute a :ref:`Java application <quickstart-application>` that provides REST services to interact with the ledger.
@ -75,7 +75,7 @@ To run through this guide, you will need to understand what an IOU is. This sect
A bank bill represents a contract between the owner of the bill and its issuer, the central bank. Historically, it is a bearer instrument - it gives anyone who holds it the right to demand a fixed amount of material value, often gold, from the issuer in exchange for the note.
To do this, the note must have certain properties. In particular, the British pound note shown below illustrates the key elements that are needed to describe money in DAML:
To do this, the note must have certain properties. In particular, the British pound note shown below illustrates the key elements that are needed to describe money in Daml:
.. figure:: quickstart/images/poundNote.jpg
:align: center
@ -109,11 +109,11 @@ The note itself is printed on paper, and its legal owner is the person holding i
Run the application using prototyping tools
*******************************************
In this section, you will run the quickstart application and get introduced to the main tools for prototyping DAML:
In this section, you will run the quickstart application and get introduced to the main tools for prototyping Daml:
#. To compile the DAML model, run ``daml build``
#. To compile the Daml model, run ``daml build``
This creates a :ref:`DAR file <dar-file-dalf-file>` (DAR is just the format that DAML compiles to) called ``.daml/dist/quickstart-0.0.1.dar``. The output should look like this:
This creates a :ref:`DAR file <dar-file-dalf-file>` (DAR is just the format that Daml compiles to) called ``.daml/dist/quickstart-0.0.1.dar``. The output should look like this:
.. code-block:: none
@ -142,7 +142,7 @@ In this section, you will run the quickstart application and get introduced to t
#. Open a new terminal window and navigate to your project directory, ``quickstart``.
#. To initialize the ledger with some parties and contracts we use :doc:`DAML Script </daml-script/index>` by running ``daml script --dar .daml/dist/quickstart-0.0.1.dar --script-name Main:initialize --ledger-host localhost --ledger-port 6865 --static-time``
#. To initialize the ledger with some parties and contracts we use :doc:`Daml Script </daml-script/index>` by running ``daml script --dar .daml/dist/quickstart-0.0.1.dar --script-name Main:initialize --ledger-host localhost --ledger-port 6865 --static-time``
.. _quickstart-navigator:
@ -168,7 +168,7 @@ Now everything is running, you can try out the quickstart application:
This is showing you what contracts are currently active on the sandbox ledger and visible to *Alice*. You can see that there is a single such contract, in our case with Id ``#9:1``, created from a *template* called ``Iou:Iou@ffb...``.
Your contract ID may vary. There's a lot going on in a DAML ledger, so things could have happened in a different order, or other internal ledger events might have occurred. The actual value doesn't matter. We'll refer to this contract as ``#9:1`` in the rest of this document, and you'll need to substitute your own value mentally.
Your contract ID may vary. There's a lot going on in a Daml ledger, so things could have happened in a different order, or other internal ledger events might have occurred. The actual value doesn't matter. We'll refer to this contract as ``#9:1`` in the rest of this document, and you'll need to substitute your own value mentally.
#. On the left-hand side, you can see what the pages the Navigator contains:
@ -200,14 +200,14 @@ Now everything is running, you can try out the quickstart application:
The screen shows the same contract ``#9:1`` that you already saw on the *Contracts* page. It is an Iou for €100, issued by *EUR_Bank*.
#. Go to the **Iou Transfers** page. It shows the transfer of your recently issued Iou to Bob, but Bob has not accepted the transfer, so it is not settled.
This is an important part of DAML: nobody can be forced into owning an *Iou*, or indeed agreeing to any other contract. They must explicitly consent.
This is an important part of Daml: nobody can be forced into owning an *Iou*, or indeed agreeing to any other contract. They must explicitly consent.
You could cancel the transfer by using the *IouTransfer_Cancel* choice within it, but for this walk-through, leave it alone for the time being.
#. Try asking *Bob* to exchange your €100 for $110. To do so, you first have to show your Iou to *Bob* so that he can verify the settlement transaction, should he accept the proposal.
Go back to *Owned Ious*, open the Iou for €100 and click on the button *Iou_AddObserver*. Submit *Bob* as the *newObserver*.
Contracts in DAML are immutable, meaning they cannot be changed, only created and archived. If you head back to the **Owned Ious** screen, you can see that the Iou now has a new Contract ID. In our case, it's `#13:1`.
Contracts in Daml are immutable, meaning they cannot be changed, only created and archived. If you head back to the **Owned Ious** screen, you can see that the Iou now has a new Contract ID. In our case, it's `#13:1`.
#. To propose the trade, go to the **Templates** screen. Click on the *IouTrade:IouTrade* template, fill in the form as shown below and submit the transaction.
.. figure:: quickstart/images/tradeProp.png
@ -223,7 +223,7 @@ Now everything is running, you can try out the quickstart application:
#. Settle the trade. Go to the **Trades** page, and click on the row of the proposal. Accept the trade by clicking **IouTrade_Accept**. In the popup, enter the Contract ID you just noted as the *quoteIouCid*, then click **Submit**.
The two legs of the transfer are now settled atomically in a single transaction. The trade either fails or succeeds as a whole.
#. Privacy is an important feature of DAML. You can check that Alice and Bob's privacy relative to the Banks was preserved.
#. Privacy is an important feature of Daml. You can check that Alice and Bob's privacy relative to the Banks was preserved.
To do this, log out, then log in as **USD_Bank**.
@ -250,12 +250,12 @@ Now everything is running, you can try out the quickstart application:
.. _quickstart-daml:
Get started with DAML
Get started with Daml
*********************
The *contract model* specifies the possible contracts, as well as the allowed transactions on the ledger, and is written in DAML.
The *contract model* specifies the possible contracts, as well as the allowed transactions on the ledger, and is written in Daml.
The core concept in DAML is a *contract template* - you used them earlier to create contracts. Contract templates specify:
The core concept in Daml is a *contract template* - you used them earlier to create contracts. Contract templates specify:
- a type of contract that may exist on the ledger, including a corresponding data type
- the *signatories*, who need to agree to the *creation* of a contract of that type
@ -263,14 +263,14 @@ The core concept in DAML is a *contract template* - you used them earlier to cre
- constraints or conditions on the data on a contract
- additional parties, called observers, who can see the contract
For more information about DAML Ledgers, consult :ref:`da-ledgers` for an in-depth technical description.
For more information about Daml Ledgers, consult :ref:`da-ledgers` for an in-depth technical description.
Develop with DAML Studio
Develop with Daml Studio
========================
Take a look at the DAML that specifies the contract model in the quickstart application. The core template is ``Iou``.
Take a look at the Daml that specifies the contract model in the quickstart application. The core template is ``Iou``.
#. Open :doc:`DAML Studio </daml/daml-studio>`, a DAML IDE based on VS Code, by running ``daml studio`` from the root of your project.
#. Open :doc:`Daml Studio </daml/daml-studio>`, a Daml IDE based on VS Code, by running ``daml studio`` from the root of your project.
#. Using the explorer on the left, open ``daml/Iou.daml``.
The first two lines specify language version and module name:
@ -327,24 +327,24 @@ A more interesting choice is ``IouTrade_Accept``. To look at it, open ``IouTrade
:language: daml
:lines: 25-46
This choice uses the ``===`` operator from the :doc:`DAML Standard Library </daml/stdlib/index>` to check pre-conditions. The standard library is imported using ``import DA.Assert`` at the top of the module.
This choice uses the ``===`` operator from the :doc:`Daml Standard Library </daml/stdlib/index>` to check pre-conditions. The standard library is imported using ``import DA.Assert`` at the top of the module.
Then, it *composes* the ``Iou_Transfer`` and ``IouTransfer_Accept`` choices to build one big transaction. In this transaction, ``buyer`` and ``seller`` exchange their Ious atomically, without disclosing the entire transaction to all parties involved.
The *Issuers* of the two Ious, which are involved in the transaction because they are signatories on the ``Iou`` and ``IouTransfer`` contracts, only get to see the sub-transactions that concern them, as we saw earlier.
For a deeper introduction to DAML, consult the :doc:`DAML Reference </daml/reference/index>`.
For a deeper introduction to Daml, consult the :doc:`Daml Reference </daml/reference/index>`.
.. _quickstart-scenarios:
Test using scenarios
====================
You can check the correct authorization and privacy of a contract model using *scenarios*: tests that are written in DAML.
You can check the correct authorization and privacy of a contract model using *scenarios*: tests that are written in Daml.
Scenarios are a linear sequence of transactions that is evaluated using the same consistency, conformance and authorization rules as it would be on the full ledger server or the sandbox ledger. They are integrated into DAML Studio, which can show you the resulting transaction graph, making them a powerful tool to test and troubleshoot the contract model.
Scenarios are a linear sequence of transactions that is evaluated using the same consistency, conformance and authorization rules as it would be on the full ledger server or the sandbox ledger. They are integrated into Daml Studio, which can show you the resulting transaction graph, making them a powerful tool to test and troubleshoot the contract model.
To take a look at the scenarios in the quickstart application, open ``daml/Tests/Trade.daml`` in DAML Studio.
To take a look at the scenarios in the quickstart application, open ``daml/Tests/Trade.daml`` in Daml Studio.
A scenario test is defined with ``trade_test = scenario do``. The ``submit`` function takes a submitting party and a transaction, which is specified the same way as in contract choices.
@ -456,7 +456,7 @@ The ``submit`` function used in this scenario tries to perform a transaction and
.. Interact with the ledger through the command line
*************************************************
All interaction with a DAML ledger, be it sandbox or any other implementation, happens via the :doc:`Ledger API </app-dev/ledger-api>`. It is based on `gRPC <https://grpc.io/>`_.
All interaction with a Daml ledger, be it sandbox or any other implementation, happens via the :doc:`Ledger API </app-dev/ledger-api>`. It is based on `gRPC <https://grpc.io/>`_.
The Navigator uses this API, as will any :ref:`custom integration <quickstart-application>`.
@ -473,9 +473,9 @@ The ``submit`` function used in this scenario tries to perform a transaction and
Integrate with the ledger
*************************
A distributed ledger only forms the core of a full DAML application.
A distributed ledger only forms the core of a full Daml application.
To build automations and integrations around the ledger, DAML Connect has :doc:`language bindings </app-dev/bindings-java/index>` for the Ledger API in several programming languages.
To build automations and integrations around the ledger, Daml Connect has :doc:`language bindings </app-dev/bindings-java/index>` for the Ledger API in several programming languages.
To compile the Java integration for the quickstart application, we first need to run the Java codegen on the DAR we built before::
@ -524,7 +524,7 @@ The automation is based on the :doc:`Java bindings </app-dev/bindings-java/index
:language: xml
:lines: 22-32
It consists of the application in file ``IouMain.java``. It uses the class ``Iou`` from ``Iou.java``, which is generated from the DAML model with the Java code generator. The ``Iou`` class provides better serialization and de-serialization to JSON via `gson <https://github.com/google/gson>`_.
It consists of the application in file ``IouMain.java``. It uses the class ``Iou`` from ``Iou.java``, which is generated from the Daml model with the Java code generator. The ``Iou`` class provides better serialization and de-serialization to JSON via `gson <https://github.com/google/gson>`_.
#. A connection to the ledger is established using a ``LedgerClient`` object.
@ -590,7 +590,7 @@ Great - you've completed the quickstart guide!
Some steps you could take next include:
- Explore `examples <https://daml.com/examples>`_ for guidance and inspiration.
- :doc:`Learn DAML </daml/intro/0_Intro>`.
- :doc:`Learn Daml </daml/intro/0_Intro>`.
- :doc:`Language reference </daml/reference/index>`.
- Learn more about :doc:`application development </app-dev/app-arch>`.
- Learn about the :doc:`conceptual models </concepts/ledger-model/index>` behind DAML.
- Learn about the :doc:`conceptual models </concepts/ledger-model/index>` behind Daml.

16
docs/source/app-dev/bindings-scala/index.rst
View File

@ -8,30 +8,30 @@ Scala bindings
The Scala bindings are deprecated as of 2020-10-14.
This page provides a basic Scala programmer's introduction to working with DAML Ledgers,
This page provides a basic Scala programmer's introduction to working with Daml Ledgers,
using the Scala programming language and the **Ledger API**.
Introduction
============
The Scala bindings is a client implementation of the **Ledger API**. The Scala bindings library lets you write applications that connect to a DAML Ledger using the Scala programming language.
The Scala bindings is a client implementation of the **Ledger API**. The Scala bindings library lets you write applications that connect to a Daml Ledger using the Scala programming language.
There are two main components:
- Scala codegen
DAML to Scala code generator. Use this to generate Scala classes from DAML models. The generated Scala code provides a type safe way of creating contracts (:ref:`com.daml.ledger.api.v1.CreateCommand`) and exercising contract choices (:ref:`com.daml.ledger.api.v1.ExerciseCommand`).
Daml to Scala code generator. Use this to generate Scala classes from Daml models. The generated Scala code provides a type safe way of creating contracts (:ref:`com.daml.ledger.api.v1.CreateCommand`) and exercising contract choices (:ref:`com.daml.ledger.api.v1.ExerciseCommand`).
- Akka Streams-based API
The API that you use to send commands to the ledger and receive transactions back.
In order to use the Scala bindings, you should be familiar with:
- :doc:`DAML language </daml/reference/index>`
- :doc:`Daml language </daml/reference/index>`
- :doc:`Ledger API </app-dev/grpc/index>`
- `Akka Streams API <https://doc.akka.io/docs/akka/current/stream/index.html>`_
- `Scala programming language <https://www.scala-lang.org>`_
- :ref:`assistant-manual-building-dars`
- :doc:`DAML codegen </tools/codegen>`
- :doc:`Daml codegen </tools/codegen>`
Getting started
===============
@ -61,9 +61,9 @@ Generating Scala code
1) Install :doc:`the latest version of the SDK </getting-started/installation>`.
2) Build a **DAR** file from a **DAML** model. Refer to :ref:`assistant-manual-building-dars` for more instructions.
2) Build a **DAR** file from a **Daml** model. Refer to :ref:`assistant-manual-building-dars` for more instructions.
3) Configure ``codegen`` in the ``daml.yaml`` (for more details see :doc:`DAML codegen </tools/codegen>` documentation).
3) Configure ``codegen`` in the ``daml.yaml`` (for more details see :doc:`Daml codegen </tools/codegen>` documentation).
.. literalinclude:: ./code-snippets/quickstart-scala/daml.yaml
:start-after: # <doc-ref:codegen-scala>
@ -93,7 +93,7 @@ Example code
In this section we will demonstrate how to use the Scala bindings library.
This section refers to the IOU DAML example from the :doc:`Quickstart guide </app-dev/bindings-java/quickstart>` and
This section refers to the IOU Daml example from the :doc:`Quickstart guide </app-dev/bindings-java/quickstart>` and
`quickstart-scala example <https://github.com/digital-asset/daml/tree/main/language-support/scala/examples/quickstart-scala>`_ that we already mentioned above.
Please keep in mind that **quickstart-scala example** compiles with ``-Xsource:2.13`` **scalac** option, this is to activate the fix for a Scala bug that forced users to add extra imports for implicits that should not be needed.

32
docs/source/app-dev/bindings-ts/daml2js.rst
View File

@ -4,16 +4,16 @@
JavaScript Code Generator
#########################
The command ``daml codegen js`` generates JavaScript (and TypeScript) that can be used in conjunction with the `JavaScript Client Libraries <../index>`_ for interacting with a DAML ledger via the `HTTP JSON API <../json-api/index.html>`_.
The command ``daml codegen js`` generates JavaScript (and TypeScript) that can be used in conjunction with the `JavaScript Client Libraries <../index>`_ for interacting with a Daml ledger via the `HTTP JSON API <../json-api/index.html>`_.
Inputs to the command are DAR files. Outputs are JavaScript packages with TypeScript typings containing metadata and types for all DAML packages included in the DAR files.
Inputs to the command are DAR files. Outputs are JavaScript packages with TypeScript typings containing metadata and types for all Daml packages included in the DAR files.
The generated packages use the library `@daml/types <https://github.com/digital-asset/daml/tree/main/language-support/ts/daml-types>`_.
Usage
-----
In outline, the command to generate JavaScript and TypeScript typings from DAML is ``daml codegen js -o OUTDIR DAR`` where ``DAR`` is the path to a DAR file (generated via ``daml build``) and ``OUTDIR`` is a directory where you want the artifacts to be written.
In outline, the command to generate JavaScript and TypeScript typings from Daml is ``daml codegen js -o OUTDIR DAR`` where ``DAR`` is the path to a DAR file (generated via ``daml build``) and ``OUTDIR`` is a directory where you want the artifacts to be written.
Here's a complete example on a project built from the standard "skeleton" template.
@ -22,24 +22,24 @@ Here's a complete example on a project built from the standard "skeleton" templa
daml new my-proj --template skeleton # Create a new project based off the skeleton template
cd my-proj # Enter the newly created project directory
daml build # Compile the project's DAML files into a DAR
daml build # Compile the project's Daml files into a DAR
daml codegen js -o daml.js .daml/dist/my-proj-0.0.1.dar # Generate JavaScript packages in the daml.js directory
- On execution of these commands:
- The directory ``my-proj/daml.js`` contains generated JavaScript packages with TypeScript typings;
- The files are arranged into directories;
- One of those directories will be named my-proj-0.0.1 and will contain the definitions corresponding to the DAML files in the project;
- One of those directories will be named my-proj-0.0.1 and will contain the definitions corresponding to the Daml files in the project;
- For example, ``daml.js/my-proj-0.0.1/lib/index.js`` provides access to the definitions for ``daml/Main.daml``;
- The remaining directories correspond to modules of the DAML standard library;
- Those directories have numeric names (the names are hashes of the DAML-LF package they are derived from).
- The remaining directories correspond to modules of the Daml standard library;
- Those directories have numeric names (the names are hashes of the Daml-LF package they are derived from).
To get a quickstart idea of how to use what has been generated, you may wish to jump to the `Templates and choices`_ section and return to the reference material that follows as needed.
Primitive DAML types: @daml/types
Primitive Daml types: @daml/types
---------------------------------
To understand the TypeScript typings produced by the code generator, it is helpful to keep in mind this quick review of the TypeScript equivalents of the primitive DAML types provided by @daml/types.
To understand the TypeScript typings produced by the code generator, it is helpful to keep in mind this quick review of the TypeScript equivalents of the primitive Daml types provided by @daml/types.
**Interfaces**:
@ -49,7 +49,7 @@ To understand the TypeScript typings produced by the code generator, it is helpf
**Types**:
+-------------------+--------------------+----------------------------------+
| DAML | TypeScript | TypeScript definition |
| Daml | TypeScript | TypeScript definition |
+===================+====================+==================================+
| ``()`` | ``Unit`` | ``{}`` |
+-------------------+--------------------+----------------------------------+
@ -93,15 +93,15 @@ To understand the TypeScript typings produced by the code generator, it is helpf
.. note::
The TypeScript definition of type ``Optional<τ>`` in the above table might look complicated. It accounts for differences in the encoding of optional values when nested versus when they are not (i.e. "top-level"). For example, ``null`` and ``"foo"`` are two possible values of ``Optional<Text>`` whereas, ``[]`` and ``["foo"]`` are two possible values of type ``Optional<Optional<Text>>`` (``null`` is another possible value, ``[null]`` is **not**).
DAML to TypeScript mappings
Daml to TypeScript mappings
---------------------------
The mappings from DAML to TypeScript are best explained by example.
The mappings from Daml to TypeScript are best explained by example.
Records
~~~~~~~
In DAML, we might model a person like this.
In Daml, we might model a person like this.
.. code-block:: daml
:linenos:
@ -126,7 +126,7 @@ Given the above definition, the generated TypeScript code will be as follows.
Variants
~~~~~~~~
This is a DAML type for a language of additive expressions.
This is a Daml type for a language of additive expressions.
.. code-block:: daml
:linenos:
@ -181,7 +181,7 @@ The thing to note is how the definition of the ``Add`` case has given rise to a
Enums
~~~~~
Given a DAML enumeration like this,
Given a Daml enumeration like this,
.. code-block:: daml
:linenos:
@ -205,7 +205,7 @@ the generated TypeScript will consist of a type declaration and the definition o
Templates and choices
~~~~~~~~~~~~~~~~~~~~~
Here is a DAML template of a basic 'IOU' contract.
Here is a Daml template of a basic 'IOU' contract.
.. code-block:: daml
:linenos:

8
docs/source/app-dev/bindings-ts/index.rst
View File

@ -6,15 +6,15 @@ JavaScript Client Libraries
.. _typescript:
The JavaScript Client Libraries are the recommended way to build a frontend for a DAML application.
The :doc:`JavaScript Code Generator <daml2js>` can automatically generate JavaScript containing metadata about DAML packages that is required to use these libraries.
The JavaScript Client Libraries are the recommended way to build a frontend for a Daml application.
The :doc:`JavaScript Code Generator <daml2js>` can automatically generate JavaScript containing metadata about Daml packages that is required to use these libraries.
We provide an integration for the `React <https://reactjs.org>`_ framework with the
`@daml/react <daml-react/index.html>`_ library. However, you can choose any JavaScript/TypeScript based framework
and use the `@daml/ledger <daml-ledger/index.html>`_ library directly to connect and interact with a
DAML ledger via its :ref:`HTTP JSON API <json-api>`.
Daml ledger via its :ref:`HTTP JSON API <json-api>`.
The `@daml/types <daml-types/index.html>`_ library contains TypeScript data types corresponding to
primitive DAML data types, such as ``Party`` or ``Text``. It is used by the `@daml/react <daml-react/index.html>`_
primitive Daml data types, such as ``Party`` or ``Text``. It is used by the `@daml/react <daml-react/index.html>`_
and `@daml/ledger <daml-ledger/index.html>`_ libraries.
.. toctree::

12
docs/source/app-dev/bindings-x-lang/index.rst
View File

@ -4,7 +4,7 @@
Creating your own bindings
##########################
This page gets you started with creating custom bindings for a DAML Ledger.
This page gets you started with creating custom bindings for a Daml Ledger.
Bindings for a language consist of two main components:
@ -12,7 +12,7 @@ Bindings for a language consist of two main components:
Client "stubs" for the programming language, -- the remote API that allows sending ledger commands and receiving ledger transactions. You have to generate **Ledger API** from `the gRPC protobuf definitions in the daml repository on GitHub <https://github.com/digital-asset/daml/tree/main/ledger-api/grpc-definitions>`_. **Ledger API** is documented on this page: :doc:`/app-dev/grpc/index`. The `gRPC <https://grpc.io/docs/>`_ tutorial explains how to generate client "stubs".
- Codegen
A code generator is a program that generates classes representing DAML contract templates in the language. These classes incorporate all boilerplate code for constructing: :ref:`com.daml.ledger.api.v1.CreateCommand` and :ref:`com.daml.ledger.api.v1.ExerciseCommand` corresponding for each DAML contract template.
A code generator is a program that generates classes representing Daml contract templates in the language. These classes incorporate all boilerplate code for constructing: :ref:`com.daml.ledger.api.v1.CreateCommand` and :ref:`com.daml.ledger.api.v1.ExerciseCommand` corresponding for each Daml contract template.
Technically codegen is optional. You can construct the commands manually from the auto-generated **Ledger API** classes. However, it is very tedious and error-prone. If you are creating *ad hoc* bindings for a project with a few contract templates, writing a proper codegen may be overkill. On the other hand, if you have hundreds of contract templates in your project or are planning to build language bindings that you will share across multiple projects, we recommend including a codegen in your bindings. It will save you and your users time in the long run.
@ -44,7 +44,7 @@ Here is how to manually build a :ref:`com.daml.ledger.api.v1.CreateCommand` for
:start-after: // <doc-ref:iou-no-codegen-create-command>
:end-before: // </doc-ref:iou-no-codegen-create-command>
If you do not specify any of the above fields or type their names or values incorrectly, or do not order them exactly as they are in the DAML template, the above code will compile but fail at run-time because you did not structure your create command correctly.
If you do not specify any of the above fields or type their names or values incorrectly, or do not order them exactly as they are in the Daml template, the above code will compile but fail at run-time because you did not structure your create command correctly.
Codegen should simplify the command construction by providing auto-generated utilities to help you construct commands. For example, when you use :doc:`Scala codegen </app-dev/bindings-scala/index>` to generate contract classes, a similar contract instantiation would look like this:
@ -77,11 +77,11 @@ versus creating the same command using a value class generated by :doc:`Scala co
Summary
=======
When creating custom bindings for DAML Ledgers, you will need to:
When creating custom bindings for Daml Ledgers, you will need to:
- generate **Ledger API** from the gRPC definitions
- decide whether to write a codegen to generate ledger commands or manually build them for all contracts defined in your DAML model.
- decide whether to write a codegen to generate ledger commands or manually build them for all contracts defined in your Daml model.
The above examples should help you get started. If you are creating custom binding or have any questions, see the :doc:`/support/support` page for how to get in touch with us.
@ -96,7 +96,7 @@ Links
- Documentation for Protobuf "well known types": https://developers.google.com/protocol-buffers/docs/reference/google.protobuf
- DAML Ledger API gRPC Protobuf definitions
- Daml Ledger API gRPC Protobuf definitions
- current main: https://github.com/digital-asset/daml/tree/main/ledger-api/grpc-definitions
- for specific versions: https://github.com/digital-asset/daml/releases

68
docs/source/app-dev/daml-lf-translation.rst
View File

@ -1,28 +1,28 @@
.. Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
.. SPDX-License-Identifier: Apache-2.0
How DAML types are translated to DAML-LF
How Daml types are translated to Daml-LF
########################################
This page shows how types in DAML are translated into DAML-LF. It should help you understand and predict the generated client interfaces, which is useful when you're building a DAML-based application that uses the Ledger API or client bindings in other languages.
This page shows how types in Daml are translated into Daml-LF. It should help you understand and predict the generated client interfaces, which is useful when you're building a Daml-based application that uses the Ledger API or client bindings in other languages.
For an introduction to DAML-LF, see :ref:`daml-lf-intro`.
For an introduction to Daml-LF, see :ref:`daml-lf-intro`.
Primitive types
***************
:ref:`Built-in data types <daml-ref-built-in-types>` in DAML have straightforward mappings to DAML-LF.
:ref:`Built-in data types <daml-ref-built-in-types>` in Daml have straightforward mappings to Daml-LF.
This section only covers the serializable types, as these are what client applications can interact with via the generated DAML-LF. (Serializable types are ones whose values can be written in a text or binary format. So not function types, ``Update`` and ``Scenario`` types, as well as any types built up from those.)
This section only covers the serializable types, as these are what client applications can interact with via the generated Daml-LF. (Serializable types are ones whose values can be written in a text or binary format. So not function types, ``Update`` and ``Scenario`` types, as well as any types built up from those.)
Most built-in types have the same name in DAML-LF as in DAML. These are the exact mappings:
Most built-in types have the same name in Daml-LF as in Daml. These are the exact mappings:
.. list-table::
:widths: 10 15
:header-rows: 1
* - DAML primitive type
- DAML-LF primitive type
* - Daml primitive type
- Daml-LF primitive type
* - ``Int``
- ``Int64``
* - ``Time``
@ -44,41 +44,41 @@ Most built-in types have the same name in DAML-LF as in DAML. These are the exac
* - ``ContractId``
- ``ContractId``
Be aware that only the DAML primitive types exported by the :ref:`Prelude <module-prelude-6842>` module map to the DAML-LF primitive types above. That means that, if you define your own type named ``Party``, it will not translate to the DAML-LF primitive ``Party``.
Be aware that only the Daml primitive types exported by the :ref:`Prelude <module-prelude-6842>` module map to the Daml-LF primitive types above. That means that, if you define your own type named ``Party``, it will not translate to the Daml-LF primitive ``Party``.
Tuple types
***********
DAML tuple type constructors take types ``T1, T2, …, TN`` to the type ``(T1, T2, …, TN)``. These are exposed in the DAML surface language through the :ref:`Prelude <module-prelude-6842>` module.
Daml tuple type constructors take types ``T1, T2, …, TN`` to the type ``(T1, T2, …, TN)``. These are exposed in the Daml surface language through the :ref:`Prelude <module-prelude-6842>` module.
The equivalent DAML-LF type constructors are ``daml-prim:DA.Types:TupleN``, for each particular N (where 2 <= N <= 20). This qualified name refers to the package name (``ghc-prim``) and the module name (``GHC.Tuple``).
The equivalent Daml-LF type constructors are ``daml-prim:DA.Types:TupleN``, for each particular N (where 2 <= N <= 20). This qualified name refers to the package name (``ghc-prim``) and the module name (``GHC.Tuple``).
For example: the DAML pair type ``(Int, Text)`` is translated to ``daml-prim:DA.Types:Tuple2 Int64 Text``.
For example: the Daml pair type ``(Int, Text)`` is translated to ``daml-prim:DA.Types:Tuple2 Int64 Text``.
Data types
**********
DAML-LF has three kinds of data declarations:
Daml-LF has three kinds of data declarations:
- **Record** types, which define a collection of data
- **Variant** or **sum** types, which define a number of alternatives
- **Enum**, which defines simplified **sum** types without type parameters nor argument.
:ref:`Data type declarations in DAML <daml-ref-data-constructors>` (starting with the ``data`` keyword) are translated to record, variant or enum types. It’s sometimes not obvious what they will be translated to, so this section lists many examples of data types in DAML and their translations in DAML-LF.
:ref:`Data type declarations in Daml <daml-ref-data-constructors>` (starting with the ``data`` keyword) are translated to record, variant or enum types. It’s sometimes not obvious what they will be translated to, so this section lists many examples of data types in Daml and their translations in Daml-LF.
.. In the tables below, the left column uses DAML 1.2 syntax and the right column uses the notation from the `DAML-LF specification <https://github.com/digital-asset/daml/blob/main/daml-lf/spec/daml-lf-1.rst>`_.
.. In the tables below, the left column uses Daml 1.2 syntax and the right column uses the notation from the `Daml-LF specification <https://github.com/digital-asset/daml/blob/main/daml-lf/spec/daml-lf-1.rst>`_.
Record declarations
===================
This section uses the syntax for DAML :ref:`records <daml-ref-record-types>` with curly braces.
This section uses the syntax for Daml :ref:`records <daml-ref-record-types>` with curly braces.
.. list-table::
:widths: 10 15
:header-rows: 1
* - DAML declaration
- DAML-LF translation
* - Daml declaration
- Daml-LF translation
* - ``data Foo = Foo { foo1: Int; foo2: Text }``
- ``record Foo ↦ { foo1: Int64; foo2: Text }``
* - ``data Foo = Bar { bar1: Int; bar2: Text }``
@ -99,8 +99,8 @@ Variant declarations
:widths: 10 15
:header-rows: 1
* - DAML declaration
- DAML-LF translation
* - Daml declaration
- Daml-LF translation
* - ``data Foo = Bar Int | Baz Text``
- ``variant Foo ↦ Bar Int64 | Baz Text``
* - ``data Foo a = Bar a | Baz Text``
@ -135,8 +135,8 @@ Enum declarations
:widths: 10 15
:header-rows: 1
* - DAML declaration
- DAML-LF declaration
* - Daml declaration
- Daml-LF declaration
* - ``data Foo = Bar | Baz``
- ``enum Foo ↦ Bar | Baz``
* - ``data Color = Red | Green | Blue``
@ -145,13 +145,13 @@ Enum declarations
Banned declarations
===================
There are two gotchas to be aware of: things you might expect to be able to do in DAML that you can't because of DAML-LF.
There are two gotchas to be aware of: things you might expect to be able to do in Daml that you can't because of Daml-LF.
The first: a single constructor data type must be made unambiguous as to whether it is a record or a variant type. Concretely, the data type declaration ``data Foo = Foo`` causes a compile-time error, because it is unclear whether it is declaring a record or a variant type.
To fix this, you must make the distinction explicitly. Write ``data Foo = Foo {}`` to declare a record type with no fields, or ``data Foo = Foo ()`` for a variant with a single constructor taking unit argument.
The second gotcha is that a constructor in a data type declaration can have at most one unlabelled argument type. This restriction is so that we can provide a straight-forward encoding of DAML-LF types in a variety of client languages.
The second gotcha is that a constructor in a data type declaration can have at most one unlabelled argument type. This restriction is so that we can provide a straight-forward encoding of Daml-LF types in a variety of client languages.
.. list-table::
:widths: 10 15
@ -173,16 +173,16 @@ The second gotcha is that a constructor in a data type declaration can have at m
Type synonyms
*************
:ref:`Type synonyms <daml-ref-type-synonyms>` (starting with the ``type`` keyword) are eliminated during conversion to DAML-LF. The body of the type synonym is inlined for all occurrences of the type synonym name.
:ref:`Type synonyms <daml-ref-type-synonyms>` (starting with the ``type`` keyword) are eliminated during conversion to Daml-LF. The body of the type synonym is inlined for all occurrences of the type synonym name.
For example, consider the following DAML type declarations.
For example, consider the following Daml type declarations.
.. literalinclude:: code-snippets/LfTranslation.daml
:language: daml
:start-after: -- start code snippet: type synonyms
:end-before: -- end code snippet: type synonyms
The ``Username`` type is eliminated in the DAML-LF translation, as follows:
The ``Username`` type is eliminated in the Daml-LF translation, as follows:
.. code-block:: none
@ -191,9 +191,9 @@ The ``Username`` type is eliminated in the DAML-LF translation, as follows:
Template types
**************
A :ref:`template declaration <daml-ref-template-name>` in DAML results in one or more data type declarations behind the scenes. These data types, detailed in this section, are not written explicitly in the DAML program but are created by the compiler.
A :ref:`template declaration <daml-ref-template-name>` in Daml results in one or more data type declarations behind the scenes. These data types, detailed in this section, are not written explicitly in the Daml program but are created by the compiler.
They are translated to DAML-LF using the same rules as for record declarations above.
They are translated to Daml-LF using the same rules as for record declarations above.
These declarations are all at the top level of the module in which the template is defined.
@ -214,7 +214,7 @@ results in this record declaration:
:start-after: -- start snippet: data from template
:end-before: -- end snippet: data from template
This translates to the DAML-LF record declaration:
This translates to the Daml-LF record declaration:
.. code-block:: none
@ -239,7 +239,7 @@ This results in these two record types:
Whether the choice is consuming or nonconsuming is irrelevant to the data type declaration. The data type is a record even if there are no fields.
These translate to the DAML-LF record declarations:
These translate to the Daml-LF record declarations:
.. code-block:: none
@ -249,7 +249,7 @@ These translate to the DAML-LF record declarations:
Names with special characters
*****************************
All names in DAML—of types, templates, choices, fields, and variant data constructors—are translated to the more restrictive rules of DAML-LF. ASCII letters, digits, and ``_`` underscore are unchanged in DAML-LF; all other characters must be mangled in some way, as follows:
All names in Daml—of types, templates, choices, fields, and variant data constructors—are translated to the more restrictive rules of Daml-LF. ASCII letters, digits, and ``_`` underscore are unchanged in Daml-LF; all other characters must be mangled in some way, as follows:
- ``$`` changes to ``$$``,
- Unicode codepoints less than 65536 translate to ``$uABCD``, where ``ABCD`` are exactly four (zero-padded) hexadecimal digits of the codepoint in question, using only lowercase ``a-f``, and
@ -259,8 +259,8 @@ All names in DAML—of types, templates, choices, fields, and variant data const
:widths: 10 15
:header-rows: 1
* - DAML name
- DAML-LF identifier
* - Daml name
- Daml-LF identifier
* - ``Foo_bar``
- ``Foo_bar``
* - ``baz'``

10
docs/source/app-dev/grpc/daml-to-ledger-api.rst
View File

@ -1,15 +1,15 @@
.. Copyright (c) 2021 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
.. SPDX-License-Identifier: Apache-2.0
How DAML types are translated to protobuf
How Daml types are translated to protobuf
#########################################
This page gives an overview and reference on how DAML types and contracts are represented by the Ledger API as protobuf messages, most notably:
This page gives an overview and reference on how Daml types and contracts are represented by the Ledger API as protobuf messages, most notably:
- in the stream of transactions from the :ref:`com.daml.ledger.api.v1.transactionservice`
- as payload for :ref:`com.daml.ledger.api.v1.createcommand` and :ref:`com.daml.ledger.api.v1.exercisecommand` sent to :ref:`com.daml.ledger.api.v1.commandsubmissionservice` and :ref:`com.daml.ledger.api.v1.commandservice`.
The DAML code in the examples below is written in DAML *1.1*.
The Daml code in the examples below is written in Daml *1.1*.
Notation
********
@ -30,7 +30,7 @@ The name of messages is added as a comment after the opening curly brace.
Records and primitive types
***************************
Records or product types are translated to :ref:`com.daml.ledger.api.v1.record`. Here's an example DAML record type that contains a field for each primitive type:
Records or product types are translated to :ref:`com.daml.ledger.api.v1.record`. Here's an example Daml record type that contains a field for each primitive type:
.. literalinclude:: ../code-snippets/Types.daml
:language: daml
@ -42,7 +42,7 @@ And here's an example of creating a value of type `MyProductType`:
:language: daml
:lines: 29,31,33-41
For this data, the respective data on the Ledger API is shown below. Note that this value would be enclosed by a particular contract containing a field of type `MyProductType`. See `Contract templates`_ for the translation of DAML contracts to the representation by the Ledger API.
For this data, the respective data on the Ledger API is shown below. Note that this value would be enclosed by a particular contract containing a field of type `MyProductType`. See `Contract templates`_ for the translation of Daml contracts to the representation by the Ledger API.
.. literalinclude:: ../code-snippets/records.payload

Some files were not shown because too many files have changed in this diff Show More