passing non-block to #do: freezes slate

[Brian T. Rice]

Hi Tim,

On Mon, May 15, 2006 11:29 am, Timmy Douglas said:
>
> running:
>
> #(1 2 3) do: {| :blah | blah }.
>
> doesn't seem to return. It should probably throw an error instead.

Agreed. What I think is happening (without Slate at-hand) is an attempt to
call #do/#applyTo: on the array and then a MethodNotFound error should be
raised. Why this would induce an infinite loop, I cannot say just yet.

I've considered using dispatch on the second argument of do: for
polymorphism (with Predicate objects, say) and the relative amount of
type-safety that could be had, but it's probably better just to improve
this case which would affect every way in which a block is expected but
not provided.

> (It'd be nice if repl noviceMode would be false by default, or at
> least the default behavior would drop the user into the debugger
> instead of skipping over errors.)

Actually, there does need to be some way to avoid parsing and evaluating
the rest of the statements once an abnormal return happens - see below.

> It also seems like if i paste a lot of loads into the repl, it will
> keep loading new files after it hits an error even when noviceMode is
> false.

This has to do with the fact that the Parser is a Stream at the top-level
and just executes top-level expressions in sequence. If you enclose the
statements in parentheses, it will make them one top-level statement so
aborting due to an error should prevent executing the following parts. I
don't have Slate in front of me to confirm this, but it should work. At
the very least it should work if you use code block brackets around the
statements. Yes, it's occurred to me to do this implicitly for the REPL
but I haven't spent time to figure out how to make that happen decently.
load: could also work this way, and in effect it already does.

-- 
http://tunes.org/~water/brice.vcf