# Yaml\_read atom vs string

**URL:** <https://swi-prolog.discourse.group/t/yaml-read-atom-vs-string/5782>\
**Category:** Help!\
**Created:** [September 19, 2022, 1:51pm UTC](https://swi-prolog.discourse.group/t/yaml-read-atom-vs-string/5782 "2022-09-19T13:51:11Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![remy.s](https://avatars.discourse-cdn.com/v4/letter/r/54ee81/32.png) [@remy.s](https://swi-prolog.discourse.group/u/remy.s)\
**Post date:** [September 19, 2022, 1:51pm UTC](https://swi-prolog.discourse.group/t/yaml-read-atom-vs-string/5782/1 "2022-09-19T13:51:11Z")

</div>

I want to process some data sourced from a yaml file using yaml\_read/2.  
As shown in the example below, prolog will render textual data as a **string** where I’d prefer an **atom**.  
By analogy, json\_read\_dict/3 is giving the user a choice by way of an option **value\_string\_as(+Type)**  
Is there such an option when dealing with yaml?

````prolog
?- yaml_read('test.yaml', D).
D = yaml{2022:"This year", string_data:"This is a string", string_tag:"more text", tag:"some text"}.```

````

The original text in test.yaml is:

```yaml
2022: This year
tag: some text
"string_tag": more text
string_data: "This is a string"

```

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [September 19, 2022, 2:28pm UTC](https://swi-prolog.discourse.group/t/yaml-read-atom-vs-string/5782/2 "2022-09-19T14:28:11Z")

</div>

Seems not. Using mapsubterms/3 it is rather simple to convert:

```prolog
to_atom(String, Atom) :- string(String), atom_string(Atom, String).

    ....,
    yaml_read(In, SData),
    mapsubterms(to_atom, SData, Data).

```

---

<div class="post-metadata">

**Author:** ![remy.s](https://avatars.discourse-cdn.com/v4/letter/r/54ee81/32.png) [@remy.s](https://swi-prolog.discourse.group/u/remy.s)\
**Post date:** [September 19, 2022, 2:47pm UTC](https://swi-prolog.discourse.group/t/yaml-read-atom-vs-string/5782/3 "2022-09-19T14:47:54Z")

</div>

yep, this looks promising.  
Still, yaml\_read/3 could/should provide a set of options much like its sibling json\_read\_dict/3!

---

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [September 19, 2022, 2:57pm UTC](https://swi-prolog.discourse.group/t/yaml-read-atom-vs-string/5782/4 "2022-09-19T14:57:48Z")

</div>

I’m still unsure about this. Using strings avoids the ambiguities wrt booleans, null, etc. It is also more efficient when it comes to (many) long texts. Only, some of the string values are more like _identifiers_ while others are more free text and we cannot tell which is which.

---

<div class="post-metadata">

**Author:** ![remy.s](https://avatars.discourse-cdn.com/v4/letter/r/54ee81/32.png) [@remy.s](https://swi-prolog.discourse.group/u/remy.s)\
**Post date:** [September 19, 2022, 3:07pm UTC](https://swi-prolog.discourse.group/t/yaml-read-atom-vs-string/5782/5 "2022-09-19T15:07:54Z")

</div>

That’s probably the reason why json\_read\_dict/3 has an option value\_string\_as(+Type).  
But here we are again in prolog’s never ending discussion of atom vs string.  
Btw. I’ll live with the mapsubterms/3 for now.  
Thanks for providing this solution!