Re: accessing multiple return values
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-thread-bindings
case, only if a caller doesn't use the extra values (and pop the
thread bindings), but that may be a common case.
You mentioned memoization, though, which might offer a superior
alternative in the case of pure functions:
(let [foo-memo-cache (atom {})
bar-memo-cache (atom {})]
(defn foo ...)
(defn bar ...))
...
(foo x y)
(bar x y)
The idea here is that foo and bar can see and modify one anothers'
memoization caches. If computing (foo x y) can cheaply also compute
(bar x y), then it can stuff that into bar's memoization cache and
return its own result; the subsequent call to (bar x y) then doesn't
duplicate the computation, as the result's cached. Works well only if
foo and bar are (conceptually) pure functions. May be done so that foo
and bar can be called in either order. No problems with reentrancy or
thread-safety.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: accessing multiple return values
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 indirection by a name is required to reach a value later, then what you really have as your return value conceptually is a map, and actually returning the map would be more obvious than projecting the map onto a namespace, with all the baggage that comes with that. The downside would be having to refer to the first value in calling code by name, which I believe is an upside due to its clarity. A function that returns 'multiple objects' is equivalent to a function that returns a meta-object that points to the multiple objects. Isn't that much more explicit than documenting a hidden var with all its concurrency semantics, simpler, less verbose AFAICT, and more of a functional approach? On Jan 3, 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: before calling the > function again, every caller interested the extra return values must > ask for these extra returned values before calling the function again. > 1. Use and Abuse VarsThe multiple return idea sounds a lot like the > global errno facility used commonly in C to communicate out of band > errors that cannot be conveniently conveyed via the function's > actually return, except with namespacing to help multiple functions > cooperate for the scarce resources. That bit of magic can be pretty > nasty and metadata usually solves the majority of cases needed to move > that auxiliary information (errno changed from a simple global > variable to a complicated macro with the advent of multi-threaded C > applications). > However, in cases that metadata simply is unavailable, one way might > be to augment the run time system with a mapping of functions to a > thread local store of this auxiliary information just like errno. > Clojure already comes with batteries to handle this case called push- > thread-bindings. Push-thread-bindings allows a function to > arbitrarily associate data with predetermined vars, and get-thread- > bindings provides a function to retreive the information stored in the > thread. Then, all that would be necessary to establish multiple > returns would be to establish a dynamic var associated with each > function that wanted to be able to return multiple objects. The > interested caller would just know to read this preveriously var > (probably via macro) to get the extra data it wanted. > The only downside is that, per the documentation, push-thread-bindings > does not handle its own housekeeping: it requires the calling function > to ensure that the thread bindings are cleaned up via pop-thread- > bindings, called in a finally block. This, of course, is not ideal, > because the function that establishes the extra information can't be > sure when or even if its own caller will use it! A more magical push- > thread-bindings that could clean up after itself upon thread > completion is necessary. > Essentially, it sounds like dynamic vars work basically the way you > want. If there is a good way to garbage collect them when the thread > dies, a couple macros will make implementation relatively > straightforward. By the way, more flexibly handling dynamic vars > seems to be part of a general goal for the > future:http://dev.clojure.org/display/design/Improve+Binding. Directly using > the ThreadLocal class might also provide you with all the machinery > necessary to implement this idea and provide garbage collection for > free on thread completion. > 2. Use and Abuse Metadata on the FunctionSimilar to memoize, we could > store extra return values in function's own metadata via an atom that > mapped Java thread-id's to extra return values. To return an extra > value, the function would simply grab its own metadata set an extra > return value by thread-id. Callers wanting to access this extra data > would be provided a macro to look this value up on demand, probably > passing the function (something like (return-more! f)). Subsequent > calls could just continually update this value. This essentially > would emulate thread-local variables though, so the first approach is > probably preferable. > Either way, this sounds like it might be implementable via a nice > little library without having to change the language at all, with very > little namespace mucking required. > Hope that helps,Mark > On Jan 3, 12:24 pm, nchurch wrote: > > > > > > > > > > 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 imp
Re: accessing multiple return values
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 returned values before calling the function again. 1. Use and Abuse VarsThe multiple return idea sounds a lot like the global errno facility used commonly in C to communicate out of band errors that cannot be conveniently conveyed via the function's actually return, except with namespacing to help multiple functions cooperate for the scarce resources. That bit of magic can be pretty nasty and metadata usually solves the majority of cases needed to move that auxiliary information (errno changed from a simple global variable to a complicated macro with the advent of multi-threaded C applications). However, in cases that metadata simply is unavailable, one way might be to augment the run time system with a mapping of functions to a thread local store of this auxiliary information just like errno. Clojure already comes with batteries to handle this case called push- thread-bindings. Push-thread-bindings allows a function to arbitrarily associate data with predetermined vars, and get-thread- bindings provides a function to retreive the information stored in the thread. Then, all that would be necessary to establish multiple returns would be to establish a dynamic var associated with each function that wanted to be able to return multiple objects. The interested caller would just know to read this preveriously var (probably via macro) to get the extra data it wanted. The only downside is that, per the documentation, push-thread-bindings does not handle its own housekeeping: it requires the calling function to ensure that the thread bindings are cleaned up via pop-thread- bindings, called in a finally block. This, of course, is not ideal, because the function that establishes the extra information can't be sure when or even if its own caller will use it! A more magical push- thread-bindings that could clean up after itself upon thread completion is necessary. Essentially, it sounds like dynamic vars work basically the way you want. If there is a good way to garbage collect them when the thread dies, a couple macros will make implementation relatively straightforward. By the way, more flexibly handling dynamic vars seems to be part of a general goal for the future: http://dev.clojure.org/display/design/Improve+Binding. Directly using the ThreadLocal class might also provide you with all the machinery necessary to implement this idea and provide garbage collection for free on thread completion. 2. Use and Abuse Metadata on the FunctionSimilar to memoize, we could store extra return values in function's own metadata via an atom that mapped Java thread-id's to extra return values. To return an extra value, the function would simply grab its own metadata set an extra return value by thread-id. Callers wanting to access this extra data would be provided a macro to look this value up on demand, probably passing the function (something like (return-more! f)). Subsequent calls could just continually update this value. This essentially would emulate thread-local variables though, so the first approach is probably preferable. Either way, this sounds like it might be implementable via a nice little library without having to change the language at all, with very little namespace mucking required. Hope that helps,Mark On Jan 3, 12:24 pm, nchurch wrote: > > 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? (A shorter > discussion.) > > In answer to your questions: > > The name of a returned value, of course, \does become part of the > interface. Perhaps library writers would want to have a discipline of > using their own internal names and then passing them out in one final > values call inside of a let. > > As to the second: the recursive (bar ...) call has no effect on any > foo-values used outside of it, whether before or after. This accords > with our expectation for how functions work. > > Think of Values as a magical macro that \at \runtime reaches outside > of the function it was used in and writes a little let inside the > calling function's scope. Is this possible? I don't think so. > Presumably it would have to be part of the language, just like Values > is part of Common Lisp. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group,
Re: accessing multiple return values
> 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? (A shorter discussion.) In answer to your questions: The name of a returned value, of course, \does become part of the interface. Perhaps library writers would want to have a discipline of using their own internal names and then passing them out in one final values call inside of a let. As to the second: the recursive (bar ...) call has no effect on any foo-values used outside of it, whether before or after. This accords with our expectation for how functions work. Think of Values as a magical macro that \at \runtime reaches outside of the function it was used in and writes a little let inside the calling function's scope. Is this possible? I don't think so. Presumably it would have to be part of the language, just like Values is part of Common Lisp. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: accessing multiple return values
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'm still not sure we understand each other: > > (let [x (foo 17), dx foo/double-x] > (do-something-with x dx)) > > Yes, that is how it would \look (I've dropped the user. as it isn't > needed here). But why is the \name user.foo/double-x changing? Because the developer of the library refactored the foo function and thereby changed the local double-x to double-value. Library developers usually refrain from renaming functions, but the internals of a function itself shouldn't be of any interest to users. > At any rate, it would be better to describe these as names within a > function execution's \scope, not a function \namespace. Hopefully > that is less confusing. > > As for storing values: as I said they should be \function-local, so > that in > > (defn bar [...] >(foo ...) ;; 1 (bar ...) ;; 2 >(+ foo/double-x ...) > ) > > foo/double-x expires after bar returns. What if bar is recursive like above. What's the value of foo/double-x in that case? The value of the call in line 1, or the value from the last foo in the recursive call in 2? I think, I'll stop here. You won't convince me that this approach is practicable anytime soon. ;-) Bye, Tassilo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: accessing multiple return values
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 understand each other: (let [x (foo 17), dx foo/double-x] (do-something-with x dx)) Yes, that is how it would \look (I've dropped the user. as it isn't needed here). But why is the \name user.foo/double-x changing? It is dictated in the definition of foo, which is not itself changing. And (keeping in mind what I said above) once you refer to the \value in this way, it does not change. Later uses of foo should indeed \shadow this usage, not \change it. At any rate, it would be better to describe these as names within a function execution's \scope, not a function \namespace. Hopefully that is less confusing. As for storing values: as I said they should be \function-local, so that in (defn bar [...] (foo ...) (+ foo/double-x ...) ) foo/double-x expires after bar returns. On Jan 3, 2:15 pm, Tassilo Horn wrote: > 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 want a different variable name on \use, > > you use a let; if you want to return a different variable name on > > \definition, you use a let inside the function (or perhaps Values > > could have some sugar for renaming variables). > > I understand your proposal in such a way, that in a function > > (defn foo [x] > (let [double-x (* 2 x)] > (values x double-x))) > > the `values' was actually a macro that > > 1. creates a namespace for the function (user.foo) > > 2. creates a var holding the last second value (user.foo/double-x) > where the name of the var is dictated by the local var holding the > value > > 3. expands into code that sets user.foo/double-x at runtime and then > returns the first value x > > Then, if I want to use the second value returned by foo in my code, I'd > so something like > > (let [x (foo 17), dx user.foo/double-x] > (do-something-with x dx)) > > Since I have to refer to user.foo/double-x to get the second value, once > that name changes, I have to change my code, too. > > But probably, I've simply misunderstood your intent. > > > It's true that quotient/remainder must be thread-local (in fact it > > should really be function-local), but this makes it no different than > > a let-variable or a function parameter; it doesn't necessarily mean it > > is mutable. Is X mutable in > > > (let [X 1 > > X (inc X)]) > > > ? > > Nope, the latter X shadows the former X. But there's no such thing for > vars in a namespace. > > > If you slapped that X in a data structure, you would not find it > > changing under your nose. quotient/remainder really has to behave in > > the same wayimagine the quotient call creates an invisible let > > every time. > > Sorry, I don't get you. What am I misinterpreting in your approach? To > me, it looks like you want to bind the multiple values to vars in an > ad-hoc namespace corresponding to a function. Then, there's no such > thing as a lexical scope provided by let. A namespace is a globally > accessible thingy. > > > Perhaps I should explain why I think this is "simple". It's simple > > because a) it allows you to ignore the extra values unless you want > > them and > > Well, the Common Lisp approach does so, too. > > > b) it gives you ready-to-use names. To my taste, b) is very > > important. > > To me, that's a major downside. > > > (quotient 5 2) > > (quotient 8 3) > > > quotient(5 2)/remainder --> 1 > > Huh, you want to create a namespace not only for each function but for > each function call? And then store the multiple values for each of > them? > > Bye, > Tassilo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: accessing multiple return values
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 want a different variable name on \use, > you use a let; if you want to return a different variable name on > \definition, you use a let inside the function (or perhaps Values > could have some sugar for renaming variables). I understand your proposal in such a way, that in a function (defn foo [x] (let [double-x (* 2 x)] (values x double-x))) the `values' was actually a macro that 1. creates a namespace for the function (user.foo) 2. creates a var holding the last second value (user.foo/double-x) where the name of the var is dictated by the local var holding the value 3. expands into code that sets user.foo/double-x at runtime and then returns the first value x Then, if I want to use the second value returned by foo in my code, I'd so something like (let [x (foo 17), dx user.foo/double-x] (do-something-with x dx)) Since I have to refer to user.foo/double-x to get the second value, once that name changes, I have to change my code, too. But probably, I've simply misunderstood your intent. > It's true that quotient/remainder must be thread-local (in fact it > should really be function-local), but this makes it no different than > a let-variable or a function parameter; it doesn't necessarily mean it > is mutable. Is X mutable in > > (let [X 1 > X (inc X)]) > > ? Nope, the latter X shadows the former X. But there's no such thing for vars in a namespace. > If you slapped that X in a data structure, you would not find it > changing under your nose. quotient/remainder really has to behave in > the same wayimagine the quotient call creates an invisible let > every time. Sorry, I don't get you. What am I misinterpreting in your approach? To me, it looks like you want to bind the multiple values to vars in an ad-hoc namespace corresponding to a function. Then, there's no such thing as a lexical scope provided by let. A namespace is a globally accessible thingy. > Perhaps I should explain why I think this is "simple". It's simple > because a) it allows you to ignore the extra values unless you want > them and Well, the Common Lisp approach does so, too. > b) it gives you ready-to-use names. To my taste, b) is very > important. To me, that's a major downside. > (quotient 5 2) > (quotient 8 3) > > quotient(5 2)/remainder --> 1 Huh, you want to create a namespace not only for each function but for each function call? And then store the multiple values for each of them? Bye, Tassilo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: accessing multiple return values
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 destructureable object. But this changes the interface: the function no longer directly returns a singular value. Metadata avoids this problem, but doesn't work on numbers, among other things. So there really are cases where having multiple return values would help (when you want a function to give you one value unless you want more)preferably without judo! (altough judo is great too.) 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 want a different variable name on \use, you use a let; if you want to return a different variable name on \definition, you use a let inside the function (or perhaps Values could have some sugar for renaming variables). It's true that quotient/remainder must be thread-local (in fact it should really be function-local), but this makes it no different than a let-variable or a function parameter; it doesn't necessarily mean it is mutable. Is X mutable in (let [X 1 X (inc X)]) ? If you slapped that X in a data structure, you would not find it changing under your nose. quotient/remainder really has to behave in the same wayimagine the quotient call creates an invisible let every time. Perhaps I should explain why I think this is "simple". It's simple because a) it allows you to ignore the extra values unless you want them and b) it gives you ready-to-use names. To my taste, b) is very important. One of the reasons I dislike OOP is all the boilerplate like this.x = x. But how many times do you have to write (let [x (some-expensive function ... )] just so you can use the returned value more than once? What we would do here is write some-expensive-function/ the next time we want to use the value (assuming this is the notation for getting the \default value)so in this case we don't even \care about multiple return values. If we think of this as a name-generating facility that happens to handle multiple values, we could imagine extensions to it for distinguishing more values (quotient 5 2) (quotient 8 3) quotient(5 2)/remainder --> 1 (rand(1) 12) (rand(2) 12) rand(1)(12)/ This is all rather fanciful, and admittedly a huge extension to the language; but what's the harm in thinking about these things? The next time you are telling your kids a bedtime story, you might start as follows: "A man ate some soup. The man was bald, and the soup had an unhappy grasshopper in it. The grasshopper" Scratch that: you should tell it as follows: Let there be a man my-man, and some soup my-soup, and a grasshopper my- grasshopper. my-man ate some of my-soup. my-man was bald. my-soup had my-grasshopper in it. And my-grasshopper was unhappy This makes for earlier bedtimes but worse storytelling. On Jan 3, 12:36 am, Cedric Greevey wrote: > 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 possess another level of > >> namespace and have the ability to inject values into the environment > >> under that namespace. For instance: > > >> (defn quotient [x y] > >> . > >> (values quotient remainder)) > > >> (clojure.core/quotient 5 2) > >> --> 2 > >> clojure.core/quotient/remainder > >> --> 1 > > >> This seems simpler than the Common Lisp way. > > > I don't think so. And there are several major problems with that > > approach. First of all, your clojure.core.quotient/remainder var needs > > to be a mutable, thread-local var, because else you couldn't be sure > > that 1 is the remainder of the quotient call directly above, or the > > remainder of a call that happened a blink later in another thread (or > > ForkJoinTask). > > > Another problem is that if the var name is determined by the name of the > > local var in the function which is given to `values', then changing its > > name requires changing all places where clojure.core.quotient/remainder > > is used. > > On top of all that, how often is this needed anyway where > destructuring or metadata can't solve the problem? When performance > isn't a concern and you control the calling functions (or they're > generic things like map and reduce that just pass the return value > through to code you control, such as whatever processes the map > sequence output) you can replace something with a vector of that > some
Re: accessing multiple return values
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 possess another level of >> namespace and have the ability to inject values into the environment >> under that namespace. For instance: >> >> (defn quotient [x y] >> . >> (values quotient remainder)) >> >> (clojure.core/quotient 5 2) >> --> 2 >> clojure.core/quotient/remainder >> --> 1 >> >> This seems simpler than the Common Lisp way. > > I don't think so. And there are several major problems with that > approach. First of all, your clojure.core.quotient/remainder var needs > to be a mutable, thread-local var, because else you couldn't be sure > that 1 is the remainder of the quotient call directly above, or the > remainder of a call that happened a blink later in another thread (or > ForkJoinTask). > > Another problem is that if the var name is determined by the name of the > local var in the function which is given to `values', then changing its > name requires changing all places where clojure.core.quotient/remainder > is used. On top of all that, how often is this needed anyway where destructuring or metadata can't solve the problem? When performance isn't a concern and you control the calling functions (or they're generic things like map and reduce that just pass the return value through to code you control, such as whatever processes the map sequence output) you can replace something with a vector of that something and additional values, and destructure. And even when you don't control the calling functions, and replacing the return value with a wrapper of any kind would blow up, if that return value is a seq, vector, or other Clojure data type that supports metadata, you can attach metadata (and, to avoid collisions, use namespaced keywords in it) to smuggle the extra values out. In a similar vein, if a non-primitive, non-final Java type is the expected value, you can subclass it with added fields and getters to smuggle out the extra values (the old "decorator pattern") using deftype or reify or proxy. (Some of these don't let you explicitly add fields, but all of them let you define "getters" that close over locals in the function returning them. You'll need a definterface specifying the getters, too.) When the only objection to destructuring is performance, as is likely with your quotient-and-remainder case or similar mathematical-transform cases, there's a final judo move available: continuation-passing. You make the code that was going to *use* the results into a *parameter*, which takes all of the results as arguments. Pre-1.3 you'd probably write something like (defmacro quot-and-rem [a b q r & forms] `(let [a# (long ~a) b# (long ~b) t# (... a# ... b# ...) ~q (...) ~r (...)] ~@forms)) which would execute forms with q and r bound to the quot and rem, respectively, of a and b. Now you can also pass a function expecting two long primitives to a function that takes two long primitives and a function and calls that function with two long primitives, the quotient and the remainder. (The macro approach still gets you the potential benefits and drawbacks of inlining both functions: avoiding the overhead of calls and parameter passing, twice, but also making the current function larger, perhaps large enough to cause cache misses. Obviously it also lets you stay source-compatible with older Clojure versions, for whatever that's worth.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: accessing multiple return values
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 inject values into the environment > under that namespace. For instance: > > (defn quotient [x y] > . > (values quotient remainder)) > > (clojure.core/quotient 5 2) > --> 2 > clojure.core/quotient/remainder > --> 1 > > This seems simpler than the Common Lisp way. I don't think so. And there are several major problems with that approach. First of all, your clojure.core.quotient/remainder var needs to be a mutable, thread-local var, because else you couldn't be sure that 1 is the remainder of the quotient call directly above, or the remainder of a call that happened a blink later in another thread (or ForkJoinTask). Another problem is that if the var name is determined by the name of the local var in the function which is given to `values', then changing its name requires changing all places where clojure.core.quotient/remainder is used. Bye, Tassilo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
accessing multiple return values
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 under that namespace. For instance: (defn quotient [x y] . (values quotient remainder)) (clojure.core/quotient 5 2) --> 2 clojure.core/quotient/remainder --> 1 This seems simpler than the Common Lisp way. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
