In Erlang there are two types of file what we can use. The first is (non-raw) file which spawns a process for the file, so every file operation is a message passing. Thursday Next Series Epub. Erlang term_to_binary - Learn Erlang in simple and easy steps starting from Overview, Environment, Basic Syntax, Shell, Data Types, Variables, Operators, Loops.

I notice that there are a few little helper functions I seem to always wind up writing given different contexts. In Erlang one of these is an inverse function for file:consult/1, which I have to write any time I use a text file to store config data*. Very simply: write_terms(Filename, List) ->Format = fun(Term) ->io_lib:format('~tp.~n', [Term]) end, Text = lists:map(Format, List), file:write_file(Filename, Text). [Note that this *should* return the atom 'ok' — and if you want to check and assertion or crash on failure, you want to do ok = write_terms(Filename, List) in your code.] This separates each term in a list by a period in the text file, which causes file:consult/1 to return the same list back (in order — though this detail usually does not matter because most conf files are used as proplists and are keysearched anyway).

An annoyance with most APIs is a lack of inverse functions where they could easily be written. Even if the original authors of the library don’t conceive of a use for an inverse of some particular function, whenever there is an opportunity for this leaving it out just makes an API feel incomplete (and don’t get me started on “web APIs” ugh). This is just one case of that. Why does Erlang have a file:consult/1 but not a file:write_terms/2 (or “ file:deconsult/2” or whatever)? I don’t know. Ad D 2nd Edition Character Generator more.

But this bugs me in most libs in most languages — this is the way I usually deal with this particular situation in Erlang. [* term_to_binary/1 ←→ binary_to_term/1 is not an acceptable solution for config data!] Tags:,, This entry was posted on Sunday, March 8th, 2015 at 10:51 and is filed under. You can follow any responses to this entry through the feed. You can skip to the end and leave a response. Pinging is currently not allowed.

9 Responses to “Erlang: Writing Terms to a File for file:consult/1”. Because the binary data on disk is not something that an administrator, user or anyone else can edit if your system goes to shit. Its not scriptable with non-Erlang tools [insert 40-year-old arguments against non-text settings files] and so on. Settings should be something that a user who knows nothing about Erlang should be able to modify.

You strip them of that when you start putting settings in binary files that only an Erlang program can read. Considering the ease of simply not putting settings in binary files, and that it gains you nothing, there is no reason to contemplate this. The wording is indeed silly. File:consult(File) doesn’t feel as natural as file:read_terms(File) and file:write_terms(File, Terms). I get the effect they were going for, but what is the reverse operation of file:consult(File)?