echo keyword

[giacomocavalieri]

Hello! Since echo was reserved as a keyword I'd like to start talking about how it could work and be implemented to (hopefully) get it done in time for v1.6 :)

1. In its simplest form echo would be used followed by an expression to print. It could be any kind of expression, not just a String value.

   echo [1, 2, 3]
   // -> prints [1, 2, 3]
   
   echo function_call(wibble, wobble)
   // -> prints the result of the function

2. echo is not a function so we want it to not look like one (the same goes for panic and todo). So if echo is not followed by a value to print it should result in an error:

   pub fn main() {
     wibble(echo, 1)
   //       ^^^^ This is not valid!
   }

   I could see people trying to pass it as an higher order function so it might be nice to have a special error message if it's being passed in as if it were an argument to explain it's not a function that can be passed around.
3. Since everything is an expression echo will return the value it's being fed.

   pub fn wibble() -> List(Int) {
     echo [1, 2, 3]
     // -> prints [1, 2, 3] and returns it
   }

4. It could also be used as one of the steps of a pipeline. This is an exception to the "echo should always be followed by an expression to print" rule I explained earlier so it will probably need some care in the parser.

   [1, 2, 3]
   |> list.map(fn(x) { x + 1 })
   |> echo
   |> list.filter(...)
   // prints [2, 3, 4] and returns it

5. It would be nice to add a "tag" to an echo to make it easier to find a specific output. In that case one might add an as "string tag" to an echo:

   echo [1, 2, 3] as "wibble!"
   // prints something like `wibble!: [1, 2, 3]`

   In pipes this could look like this:

   [1, 2, 3]
   |> list.map(fn(x) { x + 1 })
   |> echo as "my list"
   |> list.filter(...)
   // prints `my list: [2, 3, 4]` and returns [2, 3, 4]

6. We don't want packages containing echo to be published to Hex, so if the build tool finds any it will have to refuse to publish a package explaining why. We already do this for todos so it could probably be pretty straightforward copying that.

Open questions

1. If we allow to add a tag, should it always be a literal constant string? I think just allowing literal strings would be good as a starting point and we could always relax the constraint later.
2. What happens to io.debug after echo is implemented? I think that after echo is implemented we should deprecate and remove io.debug from stdlib to avoid having two ways to do the same thing. io.debug would be more awkward and the compiler doesn't give you the same guarantees that it won't end up in a published package by accident.
3. What would the output of echo look like? Do we want to copy what io.debug is doing, try do to something different (like Rust's debug formatting println!(":#?"))
4. Would future changes to echo's pretty printed output be considered breaking changes? And so do we need to nail it immediately or do we have room to improve it in the future without warranting a compiler's major version bump?
5. How can this be implemented? This is the most tricky one. I remember Louis telling me in the past the compiler could see if stdlib is a project's dependency and replace echo with a call to io.debug under the hood. What would happen in the unlikely case where a project doesn't depend on stdlib? In addition I believe the right way to move forward would be to deprecate and remove io.debug after echo is implemented in the language so I'd prefer to never depend on it for this feature to work
6. I'm not really sure how doable this is, but I was thinking since echo is implemented in the compiler itself we could rely on the type information to pick the better pretty printing strategy for the value at hand. For example if something is inferred to be a string vs something being inferred as a bit array. Right now, since io.debug relies solely on the runtime shape of the data we sometimes have to manually pick a different implementation (see io.debug vs bit_array.debug). There's cases where this would still be impossible:

   pub fn wibble(value: a) {
     echo value
     // Here the type is generic so we can't really
     // improve on what `io.debug` is already doing.
   }

   A problem I can see is one could get slightly different outputs based on the inferred type of the value so that might not be desirable.
   Whatever we end up deciding we should document somewhere these corner cases that would make interpreting echo's output a bit confusing for newcomers. For example how an Erlang tuple like {wibble, 1, 2} would be printed as Wibble(1, 2) even if the program doesn't define a type with a Wibble variant at all

Since stdlib is still v0.x we can stil afford to make a couple of breaking changes like removing io.debug and I suspect this won't break any published project worth using since it would be quite strange for a published package to call io.debug.

I would love to hear other's feedback especially on what echo's output could look like!

[lpil]

Thank you for this Jak! Very good write-up.

echo [1, 2, 3] as "wibble!"

I feel this syntax implies that the message syntax for let assert would be let assert Ok(x) = thing() as "blah" and for panic would be `panic x == 1 as "blah". I don't have any objections to this but wanted to highlight the impact this has on that addition.

If we allow to add a tag, should it always be a literal constant string? I think just allowing literal strings would be good as a starting point and we could always relax the constraint later.

I think it would make sense to be consistent with todo and panic and to permit expressions.

What happens to io.debug after echo is implemented? I think that after echo is implemented we should deprecate and remove io.debug from stdlib to avoid having two ways to do the same thing. io.debug would be more awkward and the compiler doesn't give you the same guarantees that it won't end up in a published package by accident.

Sounds reasonable.

What would the output of echo look like? Do we want to copy what io.debug is doing, try do to something different (like Rust's debug formatting println!(":#?"))

Would future changes to echo's pretty printed output be considered breaking changes? And so do we need to nail it immediately or do we have room to improve it in the future without warranting a compiler's major version bump?

We could also include the location of the expression perhaps?

We can iterate on this output too as it's not a stable interface, it's debug output.

How can this be implemented? This is the most tricky one. I remember Louis telling me in the past the compiler could see if stdlib is a project's dependency and replace echo with a call to io.debug under the hood. What would happen in the unlikely case where a project doesn't depend on stdlib? In addition I believe the right way to move forward would be to deprecate and remove io.debug after echo is implemented in the language so I'd prefer to never depend on it for this feature to work

The code would still be needed in stdlib for string.inspect. If we have this be part of the language then we'd need to duplicate this code into each module that uses echo, but perhaps that's OK as it's only for debugging and won't make it into production.

Deprecating io.debug sounds good to me.

I was thinking since echo is implemented in the compiler itself we could rely on the type information to pick the better pretty printing strategy for the value at hand

That's a really interesting idea! We could add labels as we could have the information statically!

I think this could be a future addition as the output is not a stable API.

[giacomocavalieri]

I feel this syntax implies that the message syntax for let assert would be let assert Ok(x) = thing() as "blah" and for panic would be `panic x == 1 as "blah". I don't have any objections to this but wanted to highlight the impact this has on that addition.

Mmh I don't think we can go this way, iirc we've ruled out let assert Ok(x) = thing as "blah" as it could be ambiguous:

// What is this?
let assert Ok(x) = todo as "blah"
//  ^^^^^^              ^^^^^^^^^ Is this `assert as "blah"`
//                 ^^^^^^^^^^^^^^ Or is this `todo as "blah"`

And thinking about it it would be ambiguous for echo for the same reason:

   echo todo as "blah"
// ^^^^      ^^^^^^^^^ Is this `echo as "blah"`
//      ^^^^^^^^^^^^^^ Or is it `todo as "blah"`

So we'll have to come up with something different if we want to allow attaching an additional string message to echo.
For now we could just start with no tagging and work something out later as we think about adding messages to assert too.

The code would still be needed in stdlib for string.inspect. If we have this be part of the language then we'd need to duplicate this code into each module that uses echo, but perhaps that's OK as it's only for debugging and won't make it into production.

Yeah I think it will be fine since it's just for debugging

---

So I could start implementing it in the simplest possible way:

• allow echo thing and wibble |> echo |> wobble
• replicate the look of stdlib's io.debug

So this would leave out:

• improving the pretty printing using additional type information (like labels, telling apart tuples and custom types, telling apart strings and bit arrays, ...)
• adding other info like location of the printed expression
• tagging with as "blah" until we figure out a design for assert too

Since the debug output is not supposed to be stable these three points could be addressed later as we receive feedback from people using echo. Does that sound like a plan?

[lpil]

None of the examples are ambiguous! The problem with let assert was that it forces you to add an alias to the pattern in order to also give a message to the assertion, which is undesirable.

echo todo as "blah" is unambiguously a message for todo and no message for echo. To add a message for echo you'd also need to add a message for todo, which seems fine to me.

Does that sound like a plan?

Sounds good to me!