Re: accessing multiple return values

2012-01-03 Thread Cedric Greevey
On Tue, Jan 3, 2012 at 6:05 PM, meb wrote: > I see two fairly straightforward paths to simulating multiple returns > without breaking existing callers. Both take advantage of thread-local > state and establish one convention for the caller ... Both of them have reentrancy problems -- in the push-

Re: accessing multiple return values

2012-01-03 Thread Gary Trakhman
It seems like we're talking about conflation of language implementation details to simulate a hash-map. Why not just use a hash-map for named values? Or a lazy sequence? A function returns a 'value', which can be a single thing, a collection of things, or even an arbitrary graph of things. If a

Re: accessing multiple return values

2012-01-03 Thread meb
I see two fairly straightforward paths to simulating multiple returns without breaking existing callers. Both take advantage of thread-local state and establish one convention for the caller: before calling the function again, every caller interested the extra return values must ask for these extra

Re: accessing multiple return values

2012-01-03 Thread nchurch
> I think, I'll stop here.  You won't convince me that this approach is > practicable anytime soon. ;-) I certainly won't try too hard either. I'm not questioning here whether it is immediately practicable to implement (maybe not, and in case a very long discussion) but is it potentially useful?

Re: accessing multiple return values

2012-01-03 Thread Tassilo Horn
nchurch writes: > You're quite correct that the namespace \mechanism as it stands would > not work for thisgood point. I guess I am just suggesting using > the \syntax to do something let-like. Perhaps it would be better to > make up a completely different syntax. > > As for your example, I

Re: accessing multiple return values

2012-01-03 Thread nchurch
You're quite correct that the namespace \mechanism as it stands would not work for thisgood point. I guess I am just suggesting using the \syntax to do something let-like. Perhaps it would be better to make up a completely different syntax. As for your example, I'm still not sure we understa

Re: accessing multiple return values

2012-01-03 Thread Tassilo Horn
nchurch writes: > Replying to Tassilo: I'm not quite sure I understand this problem: > >> then changing its name requires changing all places where >> clojure.core.quotient/remainder is used > > surely the call to Values takes place inside the function definition, > which happens \once. If you w

Re: accessing multiple return values

2012-01-03 Thread nchurch
This is a really neat macro, but would people want to rewrite their programs in continuation-passing style just to be able to return multiple values sometimes? (And a macro is not a first-class entity.) Of course, much of the time, the easiest thing to do \is to return a vector or some other dest

Re: accessing multiple return values

2012-01-02 Thread Cedric Greevey
On Mon, Jan 2, 2012 at 2:16 PM, Tassilo Horn wrote: > nchurch writes: > > Hi, > >> Someone was asking on the list here about multiple return values, >> which Clojure does not have. >> >> If the facility were ever added, perhaps multiple values could be >> accessed via namespaces.  Functions would

Re: accessing multiple return values

2012-01-02 Thread Tassilo Horn
nchurch writes: Hi, > Someone was asking on the list here about multiple return values, > which Clojure does not have. > > If the facility were ever added, perhaps multiple values could be > accessed via namespaces. Functions would possess another level of > namespace and have the ability to in

accessing multiple return values

2012-01-02 Thread nchurch
Someone was asking on the list here about multiple return values, which Clojure does not have. If the facility were ever added, perhaps multiple values could be accessed via namespaces. Functions would possess another level of namespace and have the ability to inject values into the environment u