Scrip result does not appear

Hello, I wrote the code but the “script result” doesn’t appear so I cannot check if the contract has been created. I am very new, sorry if this is a banal question, I don’t have a background in coding, I have just started. i would really appreciate your help !

Claudia

Hi @claudia_giannoni,

Welcome to the forum, to Daml, and to coding in general! It can be a bit frustrating at first, but in the long run it’s a lot of fun.

It’s a bit unclear exactly what you are trying to do. Let’s perhaps take a step back and check if your machine is properly configured. Can you try the following for me?

In a terminal, run the following commands:

daml new temp
cd temp
daml studio

That third command should open Visual Studio Code in the new project. There should already be a daml folder with a Main.daml file in it. If you open that file, in Visual Studio Code, and wait a few seconds, the script result annotation should appear.

Can you confirm whether that works for you?

1 Like

Hi Gary, thank you ever so much for coming back to me! So So kind of you!!!
Just tried and yes, in this file "scrpt result’ opens. Why doesn’t work on my real file?

Let’s try to figure it out together. I have a couple ideas:

  • Can you share your file itself? There may be errors in the file that prevent the script from running, and thus it has no results to show.
  • Is your project set up correctly? Specifically, a minimal Daml project consists of a folder that contains a daml.yaml file and a subfolder that contains your Daml code; Daml code files must end in .daml and start with a capital letter, and their name must match the module declartion at the top of the file.

Hi Gary, this was very useful for me to understand! I have checked the file you made me open and found a mistake in my file. I realised that there are some mistakes that I need to correct. In this module, it looks like it doesn’t recongnise the “with …” But in the course I was following the teacher was using it, or may be I didn’t understand?

controller to can
Receive: ContractId Receipt
do
received ← getTime
create receipt
with …

Hi @claudia_giannoni,

Daml is what we call a “significant whitespace” language, which means that the semantics of the code depend on how much whitespace there is in front of each line.

Because of how HTML works, I cannot see the whitespace in the code snippet you provided; in order to copy/paste code in the forum, you have to surround it with triple backticks: ``` above and below. If you do that, the code will “render as code” and the forum will preserve the whitespace. For example, taking the choice from the default template (i.e. the code you get from daml new myProject), without the backticks:

choice Give : AssetId
with
newOwner : Party
controller owner
do create this with
owner = newOwner

with the backticks:

    choice Give : AssetId
      with
        newOwner : Party
      controller owner
      do create this with
           owner = newOwner

The above is the code from the default template unchanged. But if I change it to this:

    choice Give : AssetId
      with
        newOwner : Party
      controller owner
      do create this with
        owner = newOwner

it no longer works, because the owner = newOwner line is not “far enough to the right” (not indented enough, as we say).

‘’'template PaymentClaim
with
amonut: Decimal
currency: Text
from: Party
to: Party
reference: Text
transaction :Text
where
signatory from

    controller to can
        Receive: ContractId Receipt
            do 
                received <- getTime
                create receipt with ..'''

‘’‘template PaymentClaim
with
amonut: Decimal
currency: Text
from: Party
to: Party
reference: Text
transaction :Text’‘’

Hi @claudia_giannoni,

Those are not the right types of quotes (I don’t know why there are so many); backticks are very rarely used outside programming. Unfortunately, I can’t tell you how to type them as we likely don’t have the same keyboard layout (mine is “Apple French”).

If you want, you can copy-paste these:

```

Sorry I think I am making a mistake in the backticks. I am using the same key but it only takes the ones at the end

template PaymentClaim
    with
        amonut: Decimal
        currency: Text
        from: Party
        to: Party
        reference: Text
        transaction :Text
    where
        signatory from

        controller to can
            Receive: ContractId Receipt
                do 
                    received <- getTime
                    create receipt with ..```

Ever so sorry.. You don't know how grateful I am for your patience

And what is the definition of Receipt?

     with
        amonut: Decimal
        currency: Text
        from: Party
        to: Party
        reference: Text
        transaction :Text
        received: Time
    where 
        signatory to, from
        
        controller from can
          Dismiss: ()
            with name : Type
            do return ()```
template Receipt
     with
        amonut: Decimal
        currency: Text
        from: Party
        to: Party
        reference: Text
        transaction :Text
        received: Time
    where 
        signatory to, from
        
        controller from can
          Dismiss: ()
            with name : Type
            do return ()```

Ok, here’s what’s going on. In addition to being picky about whitespace, Daml is also picky about casing: Receipt and receipt are two very different things.

The syntax Receipt with .. is valid, whereas the syntax receipt with .. is not. I’m not sure why, though; perhaps @akrmn can enlighten us here. Either way, the error message is bad, it really should be something along the lines of receipt does not exist.

So your immediate issue can be solved by simply capitalizing the r of receipt in the Receive choice. Receipt with .. means: create a new Receipt data structure and fill all of its fields with corresponding variables from the current scope. If we look at the current scope at that point, you do have all the values you need: all of the fields of Receipt are also in PaymentClaim, except for received, which is set on the previous line.

The syntax receipt with <something> is very similar, but it requires a preexisting variable called receipt, and it is meant to update selective fieds. In other words, receipt with amonut = 10.0 means "create a new receipt with the same fields as receipt except for amonut, which we set to 10.0. I’m not sure if there’s a fundamental reason to disallow receipt with .., but it does make sense to me that if you’re going to override all of the fields of receipt, you’re better off creating a brand new one anyway.

Does that help? It’s a bit of a subtle issue, so please don’t hesitate to ask any clarifying question you might have.

This was extremely helpful!!! Thank you ever so so much! It definitely clarifies a lot.

Thank you a lot for your time and your patience!

Hi @claudia_giannoni @Gary_Verhaegen. To clarify on

The syntax Receipt with .. is valid, whereas the syntax receipt with .. is not.
[…]
I’m not sure if there’s a fundamental reason to disallow receipt with .., but it does make sense to me that if you’re going to override all of the fields of receipt, you’re better off creating a brand new one anyway.

The emphasized part really sums it up from the user’s point of view.

The more fundamental reason is that the .. in a record construction expression gets expanded at compile time to assignments for the given record constructor’s fields which are missing in the braces. For example, given the type Rec

data Rec = Rec with 
    a : Int
    b : Text
    c : Bool
    d : Party
  deriving (Eq, Ord, Show)
r = Rec with { a = 42, b = "hello", .. } 
{- expands to 
r = Rec with { a = 42, b = "hello", c = c, d = d }
-}

Where c and d refer to whatever bindings are in scope.

However, when the .. appears in a record update expression, there’s no way to know at compile time what constructor was used for the value and thus what fields are missing assignments. When the type is defined as a record this might not be obvious, but consider a type like

data Sum 
  = SumAB with 
      a : Int
      b : Text
  | SumAC with 
      a : Int
      c : Party
  deriving (Eq, Ord, Show)

and a value val : Sum. Then, for the expression val { a = 100, .. }, there’s no way to know at compile time whether .. should expand to b = b or c = c, because it’s not known whether val is a SumAB or a SumAC.