On Nov 2, 4:07 pm, Miron Brezuleanu <mbr...@gmail.com> wrote:
> On Mon, Nov 2, 2009 at 4:30 PM, dmiller <dmiller2...@gmail.com> wrote:
> > For ref & out parameters, the problem is that let bindings and fn
> > parameters are not variables. You can't change the values they are
> > bound to. ref and out change the values bound to the variables passed
> > as parameters.
One (non-trivial) way would be to implement a new kind of lexical
binding that is treated as immutable by Clojure code, but may be
changed by external CLR code (possibly only by methods expecting ref/
out arguments, with the compiler throwing an exception if they
don't?). Example in C# and Clojure:
class OutTest
{
static void setInt(out int x)
{
x = 1;
}
}
;; No pun intended
(with-out [number]
(OutTest/setInt number)
(do-something-with number))
This will widen the gap between ClojureJVM and ClojureCLR, of course,
and probably has other nasty implications.
> > So if we implement ref/out silently,
>
> > (let [ a nil ] ... (DateTime.TryParse "2009/10/20" a) ... )
>
> > where subsequent to the call the value bound to a has changed, then
> > we've just changed Clojure semantics non-trivially.
>
> I agree, changing let/fn bindings would be simply terrible. I thought
> a little about a solution, and the only decent alternative I see is
> treating out/ref as a clumsy syntax for returning a vector/list. So my
> suggestion would be that methods with out/ref return a list of results
> instead of just the result returned by the .NET method. The list would
> have the value returned by the method as the first parameter, and the
> out/ref values as the rest of the elements, in the order they appear
> in the parameter list.
>
> So TryParse could be called as:
> (let [[valid date] (DateTime/TryParse "2009/10/20" nil)] ... check
> 'valid', do something with 'date')
>
> I bet this simple solution has plenty of warts :-p For instance, we
> still need to pass the out/refs as arguments because they are in fact
> input/output arguments.
>
> The solution right now (without any CLR interop changes) would be to
> wrap the out/ref calls in methods without out/ref in C#, which is kind
> of painful... Implementing the 'return a list' suggestion above would
> in fact automate writing such wrappers by asking the Clojure
> compiler/runtime to generate that code.
>
> I hope there are better ways to handle ref/outs:-)
> --
> Miron Brezuleanu
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
