no_io option for compiling

[Licenser]

It would be nice to have an option to supress print statements from the compiler during compilation.

[j14159]

Agreed. More broadly I think I'd like to tie this to something that captures and logs output in a machine-usable manner to support other tools' use of it. There have been similar discussions around capturing typing decisions for later use/analysis.

Thoughts?

[Licenser]

I thought the {error, Reason} was exactly that, the machine parsable output for tools using it? But generally yap that's awesoime

[j14159]

In many cases we just dump tuples straight to io:format/2 at the moment - I'd like at some point to have maybe a few different compiler event streams/processes that can be configured for various things.

[lepoetemaudit]

There are definitely some places where it's noisy. Even outside of the Alpaca compiler itself, the functions in Erlang's compile module print warnings directly depending on options passed (I've hit this in the REPL when defining functions as sometimes it prints a warning about unused code).

IIRC the exhaustiveness checker prints directly, and runs even for modules that have already been compiled, so we might need to bypass it for those.

Also messages relating to locating gettext PO files seem to print a lot.

I'd like to perform a few cleanups and consistency improvements in 0.2.9 for this sort of thing, part of a wider conversation about error and warning reporting I guess.

[j14159]

@lepoetemaudit does the gettext stuff print only when building the compiler or when using master via your rebar3 work as well?

[lepoetemaudit]

@j14159 actually you're right, it no longer prints when it loads Alpaca from the BEAM files so those messages don't show anymore unless you're compiling so they're not really an issue.

[j14159]

OK great. Maybe we should turn this into a larger question of how we want to handle feedback from the compiler, including:

• debugging output
• typing decisions
• feedback for the user to act on, e.g. type and syntax errors

Those all seem like three basic streams of information, the last item being what @lepoetemaudit and @Licenser have been concerned with the formatting of for REPL and rebar3 output/rendering.

Overly simplistic approach to start from: maybe this is three processes that understand tuples corresponding to the arguments io:format/2 takes and then these three processes can accept functions with which to render the tuples (e.g. write to file, render with colour to stdio, etc).

I don't know that the above is sufficient, thoughts?

[Licenser]

So my unqualified thought.

• errors/etc are returned by the call.
• typing decisions, this could be an extra function the same way EXPLAIN works on SQLs?
• Now you'll hate me, how about a callback function for debug output? i.e. calling alpaca:compile(...code..., [{debug, fun(O) -> io:format("~p~n", [O]) end}]). and default to just printing it?

[j14159]

errors/etc are returned by the call.

Agreed, I don't think this should be changed, went too far in my list above perhaps. It's possible of course we might want an additional feed of this for multiple errors encountered or something like that?

typing decisions, this could be an extra function the same way EXPLAIN works on SQLs?

I was thinking of this as a machine-readable log of decisions that actually happen at the reference cell level. Something that one could build a thing like EXPLAIN on top of or anything else, really.

Now you'll hate me, how about a callback function for debug output?

That's actually exactly what I'd like :) The main difference is that whatever thing is calling the Alpaca compiler would provide at least two callback functions that would:

• render or store typing decisions as they occur in reference cells
• write debugging output as described above, potentially with a default of io:format/2

I think the functions would be provided to two logging processes that would use them. I suppose we could just call them directly? I was thinking of decoupling things a bit more but maybe that's overkill?