Weblogs Forum - Pimp my Library

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Pimp my Library

32 replies on 3 pages. Most recent reply: Aug 17, 2012 3:35 AM by Ugo Matrangolo

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 32 replies on 3 pages [ « | 1 2 3 | » ]

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Pimp my Library

Posted: Oct 13, 2006 7:58 AM

I also would recommend extreme caution in using that feature. People complain about dynamic typing and then go ahead and use implicit conversions. That is like filtering the mosquito and eating the camel. In 90% of the dynamic typing errors at least I get a “type foo does not understand message bar” message that makes it easy to find the error. With implicit conversions I can get all kind of logical errors without ever getting any hint at what is wrong.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Pimp my Library

Posted: Oct 23, 2006 7:58 AM

Just in case this might interest someone. Implicit parameters, conversions, overloading, inheritance, etc... aren't the only non-intrusive ways to extend libraries a posteriori. Standard ML (http://en.wikipedia.org/wiki/Standard_ML), for example, has a nice module system, lexical scoping, and immutable bindings that make it possible to extend libraries. This can be even done without compromising existing code that uses the (original non-extended) library (although it is easier to do it with language extensions specifically designed for that like the ML Basis System: http://mlton.org/MLBasis). Here is a small project of mine that extends the Standard ML Basis library (http://www.standardml.org/Basis/) without actually modifying the source code of said library:

http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/extended-basis/unstable/

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Pimp my Library

Posted: Oct 23, 2006 2:11 PM

I am puzzled because Scala's object system subsumes SML's module system (more precisly, the generative facet of it). Yet implicits are in my mind quite orthogonal to this, much more akin to Haskell's type classes. What aspect of the module system did you have in mind as an alternative to implicits?

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Pimp my Library

Posted: Oct 24, 2006 1:42 AM

Sorry, I guess I wasn't clear enough. I wasn't suggesting modules as a replacement to implicits or type classes. I was responding mainly to this statement in your original post:

"There's a fundamental difference between your own code and libraries of other people: You can change or extend your own code, but if you want to use some other libraries you have to take them as they are."

What I'm saying is that SML's features (particularly when combined with something like SML/NJ's CM or MLton's/MLKit's ML Basis System) make it possible to safely extend libraries made by others. The "Extended Basis Library" does just that (it also uses the ML Basis System, but the only thing that can not be really done within SML'97 is the hiding of some auxiliary module definitions (particularly functors)).

The way I see it, SML is a simple language. Complex or unsafe language features aren't needed to extend libraries.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Pimp my Library

Posted: Oct 24, 2006 2:58 AM

> Sorry, I guess I wasn't clear enough. I wasn't suggesting
> modules as a replacement to implicits or type classes. I
> was responding mainly to this statement in your original
> post:
>
> "There's a fundamental difference between your own code
> and libraries of other people: You can change or extend
> your own code, but if you want to use some other libraries
> you have to take them as they are."
>
> What I'm saying is that SML's features (particularly when
> combined with something like SML/NJ's CM or
> MLton's/MLKit's ML Basis System) make it possible to
> safely extend libraries made by others. The "Extended
> Basis Library" does just that (it also uses the ML Basis
> System, but the only thing that can not be really done
> within SML'97 is the hiding of some auxiliary module
> definitions (particularly functors)).
>
My statement was too strong. Sure, a decent module system like ML's will allow you to extend modules with new functionality (the same goes for a standard object system). But there are things you can't do. For instance if your base library produces values of type X you can't make it retroactively produce values of some tupe X' which is richer than X, without changing its code (unless the library has forseen the extension using factory methods, but that's another story).

> The way I see it, SML is a simple language. Complex or
> unsafe language features aren't needed to extend libraries.

Well, I think implicits are neither complex nor unsafe.
Bob Harper, one of the designers of the SML module system, seems to agree. He proposes to change the module system in order to allow it to simulate Haskell's type classes. The proposal is very close to Scala's implicits.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Pimp my Library

Posted: Oct 24, 2006 4:32 AM

> But there are things you can't do. For instance if your base library
> produces values of type X you can't make it retroactively produce values
> of some tupe X' which is richer than X, without changing its code (unless
> the library has forseen the extension using factory methods, but that's
> another story).

Depends on what you mean. In SML, assuming you a have module whose signature defines an abstract type X, you can indeed rebind the module with an augmented module that has a richer definition of type X. If you have multiple modules sharing the same abstract types, you can rebind all of them. Of course, such rebinding does not change the meaning of code that refers to the original module.

> > The way I see it, SML is a simple language. Complex or
> > unsafe language features aren't needed to extend libraries.

Perhaps my wording was a bit too strong here.

> Well, I think implicits are neither complex nor unsafe.

Admittedly I don't know Scala (aside from skimming a few papers on it), but I think that combining implicit conversions and mutation is a great way to shoot yourself in the foot. Time will tell.

> Bob Harper, one of the designers of the SML module system, seems to
> agree. He proposes to change the module system in order to allow it to
> simulate Haskell's type classes. The proposal is very close to Scala's
> implicits.

I'm aware of the work. I'm personally not too enthusiastic about it. I think that there are far more important extensions (e.g. higher-order functors, higher-rank polymorphism, polymorphic recursion, ...) that should be considered/added to SML before anything like implicits or type classes that add an additional level of magic to the language. It is a good thing that the behaviour of SML programs can be explained without preprocessing or translating the program to some elaborated from (well, almost). Adding type classes destroys that property (you then need something like the dictionary translation).

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Pimp my Library

Posted: Oct 24, 2006 10:10 AM

> > But there are things you can't do. For instance if your
> base library
> > produces values of type X you can't make it
> retroactively produce values
> > of some tupe X' which is richer than X, without changing
> its code (unless
> > the library has forseen the extension using factory
> methods, but that's
> > another story).
>
> Depends on what you mean. In SML, assuming you a have
> module whose signature defines an abstract type X, you can
> indeed rebind the module with an augmented module that has
> a richer definition of type X. If you have multiple
> modules sharing the same abstract types, you can rebind
> all of them. Of course, such rebinding does not change
> the meaning of code that refers to the original module.
>
True (and the same holds for abstract type members of classes in Scala). But an abstract type is just the type-level analogue of a factory method -- both enable planned extensibility. The SML base library is very well designed in that respect, that's why it is so extensible.

Many other libraries are designed with less forethought, so you have to use them as they are. My post was about what to do for them. I absolutely agree that implicits are not
a panacea; when extensions are planned beforehand, type/method abstraction is usually preferable.

Jay Sachs

Posts: 30
Nickname: jaysachs
Registered: Jul, 2005

Re: Pimp my Library

Posted: Oct 26, 2006 7:52 AM

> I am puzzled because Scala's object system subsumes SML's
> module system (more precisly, the generative facet of it).
> Yet implicits are in my mind quite orthogonal to this,
> much more akin to Haskell's type classes. What aspect of
> the module system did you have in mind as an alternative
> to implicits?

I may be wrong, but I thought Haskell does not have ad-hoc overloading, while Scala does. In particular, I'm under the impression that Haskell doesn't have to "find the best fit among potentially ambiguous functions" that Scala does.

Or does the same danger exist in Haskell? (Forgive any and all abuses of Haskell that follow).For example, if I have a type T which "implements" a class C, but does not "implement" D, is it possible for me to "import" something which will "adapt" C to D, and thus T will "implement" D? And by doing so, this could change which function "someFun" in

someFun t

is actually invoked? Does Haskell do anything with potential name collisions besides spit out an ambiguity error?

All this is not to say that "just because Haskell does it, it must be good to do". There is much to emulate in Haskell, but it's not all gold.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: Pimp my Library

Posted: Oct 28, 2006 1:34 AM

> I may be wrong, but I thought Haskell does not have ad-hoc
> overloading, while Scala does. In particular, I'm under
> the impression that Haskell doesn't have to "find the best
> fit among potentially ambiguous functions" that Scala
> does.
>
True. Haskell has other magical things, though, such as default cases for instances.

> Or does the same danger exist in Haskell? (Forgive any and
> all abuses of Haskell that follow).For example, if I have
> a type T which "implements" a class C, but does not
> "implement" D, is it possible for me to "import" something
> which will "adapt" C to D, and thus T will "implement" D?
> And by doing so, this could change which function
> "someFun" in
>
> someFun t
>
> is actually invoked?

Yep, you can certainly do that in Haskell. Even without the import. An instance definition *somewhere* in your program will suffice. (I don't like this behavior; that's why Scala has the visibility rule for applicable implicits).

> Does Haskell do anything with
> potential name collisions besides spit out an ambiguity
> error?
>
Here I am not sure.

> All this is not to say that "just because Haskell does it,
> it must be good to do". There is much to emulate in
> Haskell, but it's not all gold.

Right, but what would Haskell be without type classes?

Cheers

-- Martin

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: This was a bad idea in C++

Posted: Oct 28, 2006 5:58 PM

> C++ allows things that are not only problematic from a
> maintenance perspective, it also allow things that are
> dangerous and, frankly, unnecessary.

I have long thought that there should be a library switch in c++ and this should be enforceable at a level where an engineering manager can dictate it is off for their application development ;-)

The much-denigrated conversion and operator-overloading features in C++ are fantastic when you are writing core libraries and adding new types, creating a DSL (Domain-Specific Language).

D H

Posts: 13
Nickname: dug
Registered: Jul, 2003

Re: Pimp my Library

Posted: Jan 1, 2007 7:23 AM

I like implicit conversions, too. It's been in the CLR (.NET/Mono) for a long time. I added support for it in boo.
It would be nice if it were in the jvm, too, just for convenience.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Did agents disappear?

Posted: Jan 30, 2007 9:34 AM

Hey, what happened to agent-based programming in Scala? I can't seem to find mention of it now.

Eelco Hillenius

Posts: 37
Nickname: ehillenius
Registered: Mar, 2006

Re: Pimp my Library

Posted: Dec 13, 2007 4:48 PM

A nice example of how this functionality can be used to retrofit 'old' (Java) libraries is described here: http://technically.us/code/x/the-awesomeness-of-scala-is-implicit

Chris McIntosh

Posts: 4
Nickname: machershel
Registered: Feb, 2008

Re: Pimp my Library

Posted: Feb 13, 2008 11:45 PM

I've recently begun evaluating Scala for a project. I have the Eclipse plugin (using Compiler Plug-in 2.6.9.RC412860). I also have Scalac version 2.7.0-RC1.

On the statement:
implicit def enrichArray[T](x: Array[T]) = new RichArray[T]
both compilers present an error message.

From the 2.6.9 compiler:
Illegal cyclic reference involving method enrichArray

From the 2.7.0 compiler:
error: recursive method enrichArray needs result type

Interestingly, no one else has reported it in the comments. I'm ready to don my dunce cap... but, please, I'd like to get outta the corner and back on-track... can someone help me understand what I'm missing?

Chris McIntosh

Posts: 4
Nickname: machershel
Registered: Feb, 2008

Re: Pimp my Library

Posted: Feb 13, 2008 11:53 PM

Ok... found the mistake... just reporting for others who may be as sleepy as I at the time...

the statement (as presented in the article) omits the parameter to the RichArray constructor:

implicit def enrichArray[T](xs: Array[T]) = new RichArray[T]

should be:
implicit def enrichArray[T](xs: Array[T]) = new RichArray[T](xs)

Flat View: This topic has 32 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic