Questions about LSharp
_hrrld
First off, neat work, LSharp looks very interesting. I was wondering
if you would answer a couple of questions.
1) I see that you've implemented a good deal of "Sequence"
abstraction, can you compare and contrast what you've done (at a high
level) with Clojure's "Seq". It looks similar on the surface, but I
was wondering if you had any additional insight.
2) What you've done with using the LINQ expression compiler is very
intriguing and clever seeming. Did you consider any other techniques
before you decided to go that way? Can you describe some of the ups
and downs of implementing the LSharp compiler in this way?
Thanks again and in advance for your time/insight. I'm enjoying
digging through LSharp.
Regards,
-Harold
Rob Blackwell
I've been playing with Clojure quite a bit more lately and generally I
really like it, so I guess it will continue to be a big influence on
future LSharp. Clojure has so much traction now, that we'd be foolish to
ignore it. I'd be interested in your thoughts on how far we should take
this - Should LSharp be compatible with Clojure at some future version
??
1. I have implemented a good deal of the Sequence abstraction, but it
probably still needs more work. I've tried to make it work seamlessly
with .NET - I think the key is to make as many things as possible in the
framework behave like sequences automagically - I have had some
difficulty with Clojure on this one and I seem to have to convert to
vectors more often than I'd like, e.g. this seems messy, but maybe I'm
just being stupid.
(defn iterator-to-vector [iter]
(loop [coll (vector)]
(if (.hasNext iter)
(recur (conj coll (.next iter)))
coll)))
2. I originally set out to use the Dynamic Language Runtime (DLR) (The
thing that underpins IronRuby and IronPython), but I found that I didn't
need all that complexity and the stuff in LINQ expression trees was good
enough for compiling LISP. One of the big advantages that LISP has is
that its syntax rules are so simple, that it's easy to parse and
relatively easy to compile. My understanding is that the DLR and LINQ
expression trees are going to come together at some point in the future,
if that's the case, the DLR may allow us some optimisation. Both DLR and
Expression trees compile to IL so they take the hard work out of
building compilers. I haven't done any serious performance analysis, but
informal testing suggests that LSharp is in a similar ballpark to
IronRuby and IronPython.
BTW, Have you seen my LSharp in the Cloud video? -
http://www.robblackwell.org.uk/?p=152 I recently managed to get LSharp
working in Windows Azure, with a publicly accessible REPL. LSharp
continues to throw up new and fun things for me too!
Thanks for your comments and feedback!
/rob
Harold Hausman
> I'd be interested in your thoughts on how far we should take
> this - Should LSharp be compatible with Clojure at some future version
> ??
Clojure is an excellent step forward, and I believe there are many
bright ideas there that are clearly worth pilfering, but complete
Clojure compatibility in L# seems unnecessary from my point of view.
In particular, I believe that the Clojure community is doing good work
in terms of choosing names. To me at least, the names chosen for
everything in Clojure are a definite improvement over the names for
the 'same' things in Scheme or Common Lisp.
Three great ideas I would steal right away:
1) Reader syntax for what Clojure calls Vectors and HashMaps
- It looks like this is partially done, at least for Vectors (Using
.NET Lists). A curly-brace syntax for some kind of map-like data
structure (.NET Dictionary?) would be neat.
2) Seq and Assoc abstractions, which allow algorithms to be written in
a data structure independent way.
- Again, this appears to be partially done, at least. It's been a big
win in a couple of my Clojure programs to be able to so easily switch
a representation of some of my data from a Vector to a HashMap, or
vice versa.
3) Platform inter-op macros.
- doto, ->, .., etc. Clojure makes it as easy as possible to call
into Java code and libraries. The more L# can do this for .NET, the
better.
---
The one big Clojure concept that would make full compatibility really
hard is their concurrency semantics: dosync, refs, agents, vars, and
their persistent immutable data structures.
Clojure is at the forefront of some interesting research in new
concurrent programming models and their system of refs and agents atop
persistent data structures is a huge jump forward in concurrent
programming, but it's far from perfect. Emulating all of those systems
that just for compatibility would be painful. It would be better to
focus on a completely separate niche, perhaps something like
'lightweight scripting'. Or, if you want to attack concurrent
programming models with L#, it could be better to maybe seek
incremental improvement over what Clojure's done in this area (perhaps
through simplification).
> ... this seems messy, but maybe I'm
> just being stupid.
>
> (defn iterator-to-vector [iter]
> (loop [coll (vector)]
> (if (.hasNext iter)
> (recur (conj coll (.next iter)))
> coll)))
>
I've read that Clojure Seqs are Java Iterable, but I don't know how it
works the other way round. There may be a more elegant way to do what
you've done there, but I don't know what it is right off the top of my
head.
> 2. I originally set out to use the Dynamic Language Runtime (DLR) (The
> thing that underpins IronRuby and IronPython), but I found that I didn't
> need all that complexity and the stuff in LINQ expression trees was good
> enough for compiling LISP.
That is super interesting and really great. What luck to have stumbled
upon the LINQ expressions. I wonder if something like L# was
envisioned during the development of LINQ, it's such a good fit.
> BTW, Have you seen my LSharp in the Cloud video? -
> http://www.robblackwell.org.uk/?p=152 I recently managed to get LSharp
> working in Windows Azure, with a publicly accessible REPL. LSharp
> continues to throw up new and fun things for me too!
>
I hadn't seen the video, thanks for the link. I like the 'probing'
that you did right off the bat. (: The .NET security model, especially
concepts like application domains and per-assembly permissions make it
easy for MS to secure something like Azure.
Keep up the good work,
-Harold
AlamedaMike
just showed up at the Clojure google group:
http://groups.google.com/group/clojure/browse_thread/thread/54571c9b8f625dba
On Feb 16, 8:27 am, Harold Hausman <hhaus...@gmail.com> wrote:
Harold Hausman
> Harold, you picked a good time to raise these questions, because this
> just showed up at the Clojure google group:
>
> http://groups.google.com/group/clojure/browse_thread/thread/54571c9b8f625dba
>
Heh, punctuated equilibrium.
Given that, I think the things I said earlier are still good. Pilfer
good ideas from Clojure as applicable, focus on the lightweight .NET
scripting niche, and let others have the glory of revolutionizing
concurrent programming. (:
-Harold
AlamedaMike
1) I love that LSharp is so simple and straightforward. I'd love it to
bits if it could handle events. So I'd like to see it continue in that
vein.
2) On the other hand, I'm desperate to see a common Lisp-class
language get some traction on both the JVM and the CLR. Clojure is a
great language and the clear front runner. So part of me would love to
see all efforts consolidated on making that happen. If it does, we
have a decent chance of getting a great language with significant
commonality on both platforms.
Of course, I'm not the one doing the work, so it's easy for me to say.
But if you added your skills to the ClojureCLR effort it would
probably make for a powerful combo, though.
My 2 centavos.