<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 2:21 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank" class="cremed">echristo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>> This is pretty much the same as what Quentin proposed (with the addition of the enum), isn't it?<br>

>><br>
><br>
> Pretty close yeah.<br>
><br>
<br>
</div>Another thought and alternate strategy for dealing with these sorts of things:<br>
<br>
A much more broad set of callback machinery that allows the backend to<br>
communicate values or other information back to the front end that can<br>
then decide what to do. We can define an interface around this, but<br>
instead of having the backend vending diagnostics we have the callback<br>
take a "do something with this value" which can just be "communicate<br>
it back to the front end" or a diagnostic callback can be passed down<br>
from the front end, etc.<br>
<br>
This will probably take a bit more design to get a general framework<br>
set up, but imagine the usefulness of say being able to automatically<br>
reschedule a jitted function to a thread with a larger default stack<br>
size if the callback states that the thread size was N+1 where N is<br>
the size of the stack for a thread you've created.</blockquote></div><br>FWIW, *this* is what I was trying to get across. Not that it wouldn't be a callback-based mechanism, but that it should be a fully general mechanism rather than having something to do with warnings, errors, notes, etc. If a frontend chooses to use it to produce such diagnostics, cool, but there are other use cases that the same machinery should serve.</div>
</div>