> On 19 May 2015, at 01:51, Ben Coman <[email protected]> wrote:
>
>
> On Wed, May 13, 2015 at 4:41 PM, Damien Pollet <[email protected]
> <mailto:[email protected]>> wrote:
> On 13 May 2015 at 08:35, Marcus Denker <[email protected]
> <mailto:[email protected]>> wrote:
> Only three methods are needed to allow generating executable methods from
> such an AST: the SyntaxErrorNotification
> is raised at runtime instead of compile time.
>
>
> What is the advantage of allowing syntax errors into the running system, when
> they can be trapped statically before that ? It seems to me the advantage of
> this change is that it allows compilation to complete rather than bombing out
> part way through. But just because compilation finishes, doesn't mean it
> needs to be committed into the runtime system.
> Syntax errors shouldn't require immediate fixing during compilation per se,
> but there should be a way to deal with them "at compile time" —whatever that
> means for us.
> For instance, faulty methods could have a flashy icon in the browser; I think
> I'd even color the whole package-class-protocol-selector in red if either of
> them contain faulty methods.
>
> I guess it *should* mean that the faulty-compiled-method is not committed but
> stored in a temporary buffer similar to how editing source is effectively
> done in a temporary buffer. Indication of the fault would only be needed in
> the window that compiled the fault.
>
No, we once experimented with adding support to Nautilus for that. But the
result is that it is very easy to loose code. And you never know what is
“really saved” and what not.
But in general: I know that this is one of those things that I will not be able
to convince anyone that it is useful before it is done… which is good: I like
to explore directions that everyone else rejects immediately.
Marcus
