<p>The round trip problem in programming is when you have 2 conversions functions (for example toJSON and fromJSON) that should be each others inverse but aren't. So you start with a value, then convert it but when you convert it back you don't get the value again.</p>
<p>So in this case: say you have created this datatype:</p>
<pre><code>data MyType = Yes | No

unstableMakeIsData ''MyType
</code></pre>
<p>Then you convert the value <code>Yes</code> to a value of type <code>Data</code> using <code>toBuiltinData</code>:</p>
<pre><code>yesAsData :: Data
yesAsData = toBuiltinData Yes
</code></pre>
<p>Later with a future version of Plutus you convert <code>yesAsData</code> back to a value of type <code>MyType</code> with <code>fromBuiltinData yesAsData</code> and you might get back <code>No</code> instead!</p>

CC BY-SA 4.0
2022-01-26T09:56:30.520Z
Well explained, thank you very much!
LexTRX
CC BY-SA 4.0
2022-01-26T09:39:10.370Z
2022-01-26T09:39:10.370Z
Sjoerd Visscher
<p>Lecture 2 of plutus-pioneer-program, introduces <strong>unstableMakeIsData</strong></p>
<p>In the lecture it is advised to use the <strong>Stable</strong> version in production.</p>
<p>Lars explains that the <strong>Unstable</strong> version does not make any guarantee that different constructor numbers will be preserved for future versions of Plutus. He further adds that:</p>
<blockquote>
<p><em>A newer version of plutus does it in a different way it would be incompatible and you would have <strong>round trip problems</strong></em> (??)</p>
</blockquote>
<p>I understand the incompatibility issue, sure, but <strong>what exactly is a round trip problem</strong> in this context?</p>

<plutus-pioneer-program>
What is a round trip problem? and why using Unstable functions could cause it? (unstableMakeIsData)
# What is a round trip problem? and why using Unstable functions could cause it? (unstableMakeIsData)

(Asked by: username_0 on 2022-01-25)

Lecture 2 of plutus-pioneer-program, introduces **unstableMakeIsData**

In the lecture it is advised to use the **Stable** version in production.

Lars explains that the **Unstable** version does not make any guarantee that different constructor numbers will be preserved for future versions of Plutus. He further adds that:

> *A newer version of plutus does it in a different way it would be incompatible and you would have **round trip problems*** (??)

I understand the incompatibility issue, sure, but **what exactly is a round trip problem** in this context?

**Tags:** plutus-pioneer-program

---

## 1 answers

### Answer by username_1 on 2022-01-26. Score: 3 | Accepted answer

The round trip problem in programming is when you have 2 conversions functions (for example toJSON and fromJSON) that should be each others inverse but aren't. So you start with a value, then convert it but when you convert it back you don't get the value again.
So in this case: say you have created this datatype:
data MyType = Yes | No

unstableMakeIsData ''MyType

Then you convert the value Yes to a value of type Data using toBuiltinData:
yesAsData :: Data
yesAsData = toBuiltinData Yes

Later with a future version of Plutus you convert yesAsData back to a value of type MyType with fromBuiltinData yesAsData and you might get back No instead!

> **Comments:**
> **username_0**: Well explained, thank you very much!  

---

