Re: "do" blocks and method args problem

If you want to make "do" be the same as "lexicalDo", you have my vote.

Otherwise, could we at least add an error path so that if an identifier is unknown inside a "do" but is found in the lexical context, the error it gives to the user explains the problem and suggests using lexicalDo?

--- In [email protected], Jeremy Tregunna <jeremy.tregunna@...> wrote:
>
> Given that this comes up every now and then (avg of once a year on this list it seems), I think it's worth considering changing the behaviour of do(). It only will have issues if people use = (not :=) inside do(). That's the only (as I can see) case where it could introduce subtle bugs. As far as I know however, no code does this (at least none of mine, and none of the standard lib code does).
> 
> Regards,
> 
> Jeremy Tregunna
> 
> 
> On Thursday, 12 April, 2012 at 10:17 PM, dennisf486 wrote:
> 
> >    
> > Haha OK I feel stupid, I just found "lexicalDo" in Io's C source code, it appears it does exactly that. Why doesn't lexicalDo show among the documented Object methods in the Io Reference on the website? And may I humbly suggest adding lexicalDo to the Guide and/or the Tutorial? I think this might be a pain point for new users of Io; I'm not arguing that the default behavior of regular "do" shouldn't be what it is, but I do think that it doesn't necessarily match a new user's intuition, especially if they come from "strongly lexically scoped" languages. Presenting "do" and "lexicalDo" side-by-side would both avert that potential confusion and be a primer for understanding scoping rules in Io in general.
> >  
> > --- In [email protected] (mailto:iolanguage%40yahoogroups.com), "dennisf486" <dennisf486@> wrote:
> > >
> > > I hit a snag in my script refactoring. I'm trying to wrap all my proto creations inside methods so that I can pass dependencies as arguments, but I can't access the method arguments from inside a do block.
> > >  
> > > This works (because the appendProto is outside the do block):
> > > // in file IdMap.io (http://IdMap.io)
> > > method(namespace_std,
> > > self IdMap := Object clone appendProto(namespace_std) do( /* other stuff */ ... )
> > > )
> > >  
> > > This does not work (but I wish it did):
> > > // in file IdMap.io (http://IdMap.io)
> > > method(namespace_std,
> > > self IdMap := Object clone do(
> > > appendProto(namespace_std)
> > > /* other stuff */
> > > )
> > >  
> > > The problem is that the method argument "namespace_std" is not in scope inside the do-block. In the case of one appendProto I can easily move the declaration to the outside,
> > > but this makes the declaration long when there are a lot of namespace-objects. And, I might want the argument for some other purpose than append proto.
> > >  
> > > I know that I could do something like:
> > > self IdMap := Object clone
> > > IdMap namespace_std := namespace std
> > > IdMap do( ... )
> > >  
> > > But I'm trying to avoid the repetition of the word "IdMap".
> > >  
> > > I think one possible solution would be to make the method context a proto of the object:
> > > method(namespace_std,
> > > self IdMap := Object clone appendProto(thisLocalContext) do(
> > > appendProto(namespace_std)
> > > )
> > >  
> > > Is this the best / only way? One side effect of this trick is that all of the method invocation's locals / arguments are now permanently uncollectible, even if the args aren't all used, because thisLocalContext has a reference to them and the object has a reference to thisLocalContext. I suppose I could do something weird like appendProto(thisLocalContext) at the top of the file and removeProto(thisLocalContext) at the bottom of the file. If I do this it would make sense to make a method to do that automatically; I would call it "doInLocalContext".
> > >  
> > > Why doesn't Io have a doInLocalContext method already?
> > >
> >  
> >
>