This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: Modules?

5 replies
BobLondon
Joined: 2011-11-03,
User offline. Last seen 42 years 45 weeks ago.

> ----- Original Message -----
> From: Miles Sabin
> On Thu, Nov 3, 2011 at 10:54 AM, BobLondon wrote:
> Scala objects and path dependent types encode ML-style modules,

Seems like a different kind of module to what I'm thinking of. This looks like just a way to structure code.

I'm thinking of versioned deployable artifacts. Plus mechanisms like Ruby gems or I guess Maven/OSGi/Jigsaw in Java. A mechanism to declare the dependencies of code.

Bob

Guillaume Yziquel
Joined: 2011-11-03,
User offline. Last seen 42 years 45 weeks ago.
Re: Modules?

Le Thursday 03 Nov 2011 à 07:28:22 (-0400), Bob London a écrit :
> > ----- Original Message -----
> > From: Miles Sabin
> > On Thu, Nov 3, 2011 at 10:54 AM, BobLondon wrote:
> > Scala objects and path dependent types encode ML-style modules,
>
> Seems like a different kind of module to what I'm thinking of. This looks like just a way to structure code.
>
> I'm thinking of versioned deployable artifacts. Plus mechanisms like Ruby gems or I guess Maven/OSGi/Jigsaw in Java. A mechanism to declare the dependencies of code.
>
> Bob

Well, in OCaml, "versioned deployable artifacts" and "mechanisms to
declare the dependencies of code" can be done by using first-class
modules (not only a way to structure code, but also a runtime value
analog to a C struct). You'd dynamically load a module satisfying a
given module signature, and you'd pass the module around in your code as
a first-class runtime value. Some kind of "plugin".

This is not really a problem with ML-style modules, except that it
indeed was intended more as a way to structure code as opposed to any
kind of OSGi replacement.

Now, I do not see why you wouldn't be able to use the OSGi Java
machinery from Scala itself.

marius
Joined: 2008-08-31,
User offline. Last seen 3 years 19 weeks ago.
Re: Modules?
That's really beyond a language scope. These are really libraries more or less "standard". I believe one can use OSGi in Scala ... although OSGi sucks big time. Any .jar can impersonate a (hot)-deploy-able module with a bit of classloaders help. So what is your expectation from Scala language really ?

Marius

On Thu, Nov 3, 2011 at 1:28 PM, Bob London <boblondon [at] mail [dot] com> wrote:
> ----- Original Message -----
> From: Miles Sabin
> On Thu, Nov 3, 2011 at 10:54 AM, BobLondon <boblondon [at] mail [dot] com> wrote:
> Scala objects and path dependent types encode ML-style modules,

Seems like a different kind of module to what I'm thinking of. This looks like just a way to structure code.

I'm thinking of versioned deployable artifacts. Plus mechanisms like Ruby gems or I guess Maven/OSGi/Jigsaw in Java. A mechanism to declare the dependencies of code.

Bob

paulbutcher
Joined: 2010-03-08,
User offline. Last seen 10 weeks 5 days ago.
Re: Modules?

On 3 Nov 2011, at 11:28, Bob London wrote:
>> ----- Original Message -----
>> From: Miles Sabin
>> On Thu, Nov 3, 2011 at 10:54 AM, BobLondon wrote:
>> Scala objects and path dependent types encode ML-style modules,
>
> Seems like a different kind of module to what I'm thinking of. This looks like just a way to structure code.
>
> I'm thinking of versioned deployable artifacts. Plus mechanisms like Ruby gems or I guess Maven/OSGi/Jigsaw in Java. A mechanism to declare the dependencies of code.

Most Scala libraries use Maven or Ivy (which interoperate pretty well). Sbt provides particularly good support for Ivy. Is there anything that Maven/Ivy don't give you that you think would justify a Scala-specific solution?

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul [at] paulbutcher [dot] com
AIM: paulrabutcher
Skype: paulrabutcher

BobLondon
Joined: 2011-11-03,
User offline. Last seen 42 years 45 weeks ago.
Re: Modules?

> ----- Original Message -----
> From: Marius Danciu
> That's really beyond a language scope. These are really libraries more or
> less "standard". I believe one can use OSGi in Scala ... although OSGi
> sucks big time. Any .jar can impersonate a (hot)-deploy-able module with a
> bit of classloaders help. So what is your expectation from Scala language
> really ?

Its just a sense that classes/objects are too low level a unit to be thinking in terms of. And Maven/OSGi type solutions feel like tacking the extra data on after the fact rather than building it in the base unit you produce day-to-day. Why should packaging and deployment be something separate to development? Why not compile modules rather than classes?

All, thanks for the other links, which are useful.

Bob

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Modules?


On Thu, Nov 3, 2011 at 9:39 AM, Bob London <boblondon [at] mail [dot] com> wrote:
> ----- Original Message -----
> From: Marius Danciu
> That's really beyond a language scope. These are really libraries more or
> less "standard". I believe one can use OSGi in Scala ... although OSGi
> sucks big time. Any .jar can impersonate a (hot)-deploy-able module with a
> bit of classloaders help. So what is your expectation from Scala language
> really ?

Its just a sense that classes/objects are too low level a unit to be thinking in terms of. And Maven/OSGi type solutions feel like tacking the extra data on after the fact rather than building it in the base unit you produce day-to-day. Why should packaging and deployment be something separate to development? Why not compile modules rather than classes?

All, thanks for the other links, which are useful.

Bob

It's not separate from development, but that doesn't mean it's part of the language per se. I believe the Typesafe Stack includes sbt. I really think sbt is what you want. Also, there's a project somewhere that lets you put sbt dependencies directly in a scala script.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland