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-
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
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
> 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?
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
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
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
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
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
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
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
11 matches
Mail list logo