The compiler as service(s)

I know of the ensime server.

Also, http://tryscala.com has an undocumented API to collect pieces of code remotely and run them, content assist etc. is that kind of what this is about?

Thanks,
Razvan

On 2011-10-29, at 5:14 PM, Olivier Lefevre wrote:

> At the suggestion of Joseph Suereth (who seems to be the unofficial list
> maintainer) I am creating a new thread so the old one, "tainted" as it
> is by the ugly exchange that started it, can be abandoned. It is suggested
> that anyone who has something of interest to say about Roslyn uses this
> new thread (or start his own!) instead.
>
> To recap: the Visual Studio group at Microsoft has just released under the
> Roslyn moniker (http://msdn.com/roslyn/) a complete rewrite of the C# and VB#
> compiler whereby the compiler is exposed as a set of service APIs instead
> of the black box we all know. This isn't a product and may never become one
> but it seems incredibly useful. The Scala compiler team has been moving in
> the same direction, to ease the burden on IDE writers, and I was wondering
> how the two efforts compare.
>

I would *love* to see a detailed comparison.  I think Scala's Compiler API is not 'exposed' as much as it is 'divined'.   That is to say, things aren't locked down so that we can still fix bugs, so no formal API has been constructed but many articles and videos have been made covering the details.  
I hope to see Scala offer more in the way of API exposure such that compiler plugins become more and more viable as time goes on.  The existing compiler plugins that are out there are already impressive, but I want to see the community flourish.
- Josh

On Sat, Oct 29, 2011 at 6:47 PM, Razvan Cojocaru <pub@razie.com> wrote:

I know of the ensime server.

Also, http://tryscala.com has an undocumented API to collect pieces of code remotely and run them, content assist etc. is that kind of what this is about?

Thanks,
Razvan

On 2011-10-29, at 5:14 PM, Olivier Lefevre <lefevrol@yahoo.com> wrote:

> At the suggestion of Joseph Suereth (who seems to be the unofficial list
> maintainer) I am creating a new thread so the old one, "tainted" as it
> is by the ugly exchange that started it, can be abandoned. It is suggested
> that anyone who has something of interest to say about Roslyn uses this
> new thread (or start his own!) instead.
>
> To recap: the Visual Studio group at Microsoft has just released under the
> Roslyn moniker (http://msdn.com/roslyn/) a complete rewrite of the C# and VB#
> compiler whereby the compiler is exposed as a set of service APIs instead
> of the black box we all know. This isn't a product and may never become one
> but it seems incredibly useful. The Scala compiler team has been moving in
> the same direction, to ease the burden on IDE writers, and I was wondering
> how the two efforts compare.
>
> -- O.L.
>

Probably shortsighted and veering off topic but thinking out loud…
I've been considering occasionally how Scala's advanced (relative to popular languages) features deter enterprise adoption and IMO founded but there are other threads about that. (Scala's still my favourite and I watch trending languages.)
But I wonder whether a few features could be isolated as a plugin for a kind of Scala "lite" that's fully compatible with Scala "full" (inasmuch as Scala without continuations is compatible with them but not vice versa)?
Back on topic…
The compiler API is relatively documented…how would you foresee its exposure?

Ah, scaladoc != documentation (although it brings you very far along the way).
When I mean exposed, I mean exposed *and* maintained like a public API (binary compatible releases for say 2.8.x series).
Right now it's pretty impressive what you can do with Scala's plugin features.   I'm curious how roslyn works with typing and parsing.  That's currently a limitation in Scala that makes plugins somewhat more limited (compared to being able to do *anything*).


On Sat, Oct 29, 2011 at 10:03 PM, Toland <toland@dnalot.com> wrote:

Probably shortsighted and veering off topic but thinking out loud…
I've been considering occasionally how Scala's advanced (relative to popular languages) features deter enterprise adoption and IMO founded but there are other threads about that. (Scala's still my favourite and I watch trending languages.)
But I wonder whether a few features could be isolated as a plugin for a kind of Scala "lite" that's fully compatible with Scala "full" (inasmuch as Scala without continuations is compatible with them but not vice versa)?
Back on topic…
The compiler API is relatively documented…how would you foresee its exposure?

Yes, but how stable is that compiler API? Which parts of it are for internal use only and which parts are guaranteed to remain available across a (large-ish) number of compiler versions? I can appreciate that we don’t want to lock down the compiler internals too early for fear of getting it wrong. However, as a plug-in author it would be great to know just which parts of the API documented in the link you provide are intended to be fixed and public and which parts are “hands off” and for internal reference only.

 

Or maybe that information does exist and I’m not aware of it?

 

It would also be cool if one could use part of the compiler without dragging in all of it. For example if I wanted to just make some kind of analysis tool I might want to use the parser and symbol table management facilities of the compiler, but I don’t need the code generator and optimizer stuff. Perhaps the compiler should be provided, as an option, as a collection of jar files rather than just one big jar file.

 

Peter

 

From: scala-tools@googlegroups.com [mailto:scala-tools@googlegroups.com] On Behalf Of Toland
Sent: Saturday, October 29, 2011 22:04
To: scala-tools@googlegroups.com
Subject: Re: [scala-tools] The compiler as service(s)

 

Probably shortsighted and veering off topic but thinking out loud…

 

I've been considering occasionally how Scala's advanced (relative to popular languages) features deter enterprise adoption and IMO founded but there are other threads about that. (Scala's still my favourite and I watch trending languages.)

 

But I wonder whether a few features could be isolated as a plugin for a kind of Scala "lite" that's fully compatible with Scala "full" (inasmuch as Scala without continuations is compatible with them but not vice versa)?

 

Back on topic…

 

The compiler API is relatively documented…how would you foresee its exposure?