# Expr to String conversion

**URL:** https://discourse.julialang.org/t/expr-to-string-conversion/4118
**Category:** New to Julia
**Created:** [June 6, 2017, 10:48pm UTC](https://discourse.julialang.org/t/expr-to-string-conversion/4118 "2017-06-06T22:48:18Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [June 7, 2017, 5:45am UTC](https://discourse.julialang.org/t/expr-to-string-conversion/4118/3 "2017-06-07T05:45:38Z")

</div>

`repr` in julia does not promise to do this.  
I think it should.  
But it does not.

> help?\> repr  
> **repr(x)**  
> Create a string from any value using the showall function.
> 
> help?\> showall  
> **showall(x)**  
> Similar to show, except shows all elements of arrays.
> 
> help?\> show  
> **show(stream, mime, x)**  
> The display functions ultimately call show in order to write an object x as a given mime type to a given I/O stream (usually a memory buffer), if possible. In order to  
> provide a rich multimedia representation of a user-defined type T, it is only necessary to define a new show method f  
> …  
> The default MIME type is MIME"text/plain". There is a fallback definition for text/plain output that calls show with 2 arguments. Therefore, this case should be  
> handled by defining a 2-argument show(stream::IO, x::MyType) method.  
> …  
> **show(x)**

> Write an informative text representation of a value to the current output stream. New types should overload show(io, x) where the first argument is a stream. The  
> representation used by show generally includes Julia-specific formatting and type information.

By docs,  
we have an indirect statement that  
the results of `repr` will be similar to those of a function that says that it will return a _“representation … [that] …generally includes Julia-specific formatting and type information.”_

Which is a pretty weak promise, vs: `eval(parse(repr(x)) == x`  
Which would be a nicely strong statement.  
But has its own issues like requiring equality to be defined for all types with `repr` defined.  
And its own issues for objects of types that can not be trivially duplicated (eg file handles).

A weaker statement might be something like:  
`x->eval(parse(repr(x)))` shall be functionally equivalent to `deepcopy`.

Basically as far as julia’s docs for `repr` are concerned,  
`repr` probably gives you an in informative string.  
By a stretch of meaning one could interpret “julia specific formatting” as “parsable”.  
In practice it tends to follow the promise I suggested.

Contrast [Python :](https://docs.python.org/3/library/functions.html#repr)

> repr(object)  
> Return a string containing a printable representation of an object. For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval(), otherwise the representation is a string enclosed in angle brackets that contains the name of the type of the object together with additional information often including the name and address of the object. A class can control what this function returns for its instances by defining a **repr** () method.

Very clear as to what it does. Does have some wiggle with saying “for many types”,  
but for types following the convention then they either return an `eval` able string that gives a equal object,  
or if they can not, then the string they give back is wrapped in angle brrackeds and contains the type name and some additional information.

---

_[View the full topic](https://discourse.julialang.org/t/expr-to-string-conversion/4118)._