record_test = script do
let
my_record = MyRecord with
my_txt = “Text”
my_int = 2
my_dec = 2.5
my_list = [“One”, “Two”, “Three”]
my_coord = Coordinate with
x = 1.0
y = 2.0
z = 3.0
-- `my_text_int` has type `KeyValue Text Int`
my_text_int = KeyValue with
my_key = "Key"
my_val = 1
-- `my_int_decimal` has type `KeyValue Int Decimal`
my_int_decimal = KeyValue with
my_key = 2
my_val = 2.0 : Decimal
-- If variables are in scope that match field names, we can pick them up
-- implicitly, writing just `my_coord` instead of `my_coord = my_coord`.
my_nested = Nested with
my_coord
my_record
my_kv = my_text_int
– Fields can be accessed with dot syntax
assert (my_coord.x == 1.0)
assert (my_text_int.my_key == “Key”)
assert (my_nested.my_record.my_dec == 2.5)
– RECORD_TEST_END
Welcome to the Forum, and thank you for that question. I am using GNU/Linux (Ubuntu) and I too have the syntax (blue squiggly) highlighting on all instances of the assert keyword through the /…/intro3/daml/Record.daml
With a message that perhaps I meant to use ===, which I didn’t. I have verified twice that this example will actually Build and Start as required with no generated error output.
My package specs:
Daml Enterprise v2.4.0
VS Code v1.72.1 (x64)
Perhaps one of the Daml Language team might have a better analysis of this highlighting, but it seems useable for me.
The blue squiggly lines are not errors but warnings emitted by dlint, the Daml language linting tool. There’s nothing inherently bad in keeping those in, but they may give you indications on small improvements you can make.
We considered switching to === instead of assert in the past, but since those are aimed at beginners we thought that assert is more readable and immediate to any people with a little coding experience. We may reconsider this in light of the dlint warning. Thanks for flagging this.
The linter can be configured through the .dlint.yaml file that is part of most daml-assistant templates (daml new ...). The default template has this .dlint.yaml file:
# This file controls the behaviour of the dlint linting tool. Below are two
# examples of how to enable or disable a rule.
# This rule is enabled by default. Uncomment to disable.
#- ignore: {name: Use fewer imports}
# This rule is disabled by default. Uncomment to enable.
#- suggest: {name: Use module export list}
If you do not want to get the === suggestion in your project, you can add this line to your .dlint.yaml (possibly creating the file; just this line is a valid .dlint.yaml):
- ignore: {name: Use === for better error messages}
You may need to restart Daml Studio for changes to the .dlint.yaml files to be applied.
Perhaps something closer to how we treat stronger warnings in general is called for. Because, despite the newcomer-friendliness of assert, it really is the case that === is strictly better from a usability perspective. Ease should be balanced with the cost of inculcating bad habits and technical debt.
When you are just starting out, seeing a huge set of warnings can easily be overwhelming and distract from what you are actually working on. However, as you get more experienced and more people work on a Daml project, enabling additional warnings (and enforcing their absence in CI) can be useful.
Going to that link and copy-pasting the recommended boilerplate into daml.yaml isn’t the best on-ramp to stricter Daml, but maybe there is a way we could “ramp up” these and the dlint warnings without quite so much copypasta.
