- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Why isn't mixing Context Bounds and regular Implicit Params allowed?
Mon, 2010-09-06, 12:35
Ive noticed that its not allowed to have both Context Bounds and
regular Implicit Params defined for the same method. Is this simply a
policy decision or is there some structural reason I can't see?
//silly example
scala> def method[T: ClassManifest](implicit p: String) {}
:1: error: cannot have both implicit parameters and context bounds `: .
..' on type parameters
If its a policy decision, I personally find it obstructs how I want to
write Scala code, because it violates the orthogonality of independent
params to the same method.
I'm writing code that uses Numeric and ClassManifest context bounds on
most methods (for Numeric abstraction plus the option to instantiate
Arrays). These two implicit params are an ever-present background
noise thru my API, hence its nice to use the compact ContextBound
notation consistently.
But, whenever I occasionally need to pass another implicit param (with
2 type-params, so cannot be Context-Bounded), for some reason, I'm
suddenly forced to unpack my Numeric and ClassManifest bounds, even
though they are unrelated. Thats what I mean by orthogonality
violation.
I appreciate that there's a degree of beginner vs advanced trade-off
here (eg beginner might be confused by simultaneous Context Bounds and
regular Implicit Params), but IMO keeping orthogonal concerns
unentangled is more important.
-Ben
Mon, 2010-09-06, 16:17
#2
Re: Why isn't mixing Context Bounds and regular Implicit Params
On Mon, Sep 06, 2010 at 09:35:46PM +1000, Ben Hutchison wrote:
> Ive noticed that its not allowed to have both Context Bounds and
> regular Implicit Params defined for the same method. Is this simply a
> policy decision or is there some structural reason I can't see?
I would guess the reason was simplicity of implementation, and would
further guess it will be relaxed at some point.
Mon, 2010-09-06, 19:37
#3
Re: Why isn't mixing Context Bounds and regular Implicit Params
It also seems that using context bounds or implicit views necessitates that the type inferences work as expected. When you have to pass one of those implicit parameters in yourself, you have to pass them all in the order defined in the type parameter list, or rely on the compilers auto-naming scheme for if you only want to specify one of them. This can get frustrating...
On Sep 6, 2010 11:16 AM, "Paul Phillips" <paulp@improving.org> wrote:On Mon, Sep 06, 2010 at 09:35:46PM +1000, Ben Hutchison wrote:
I would guess the reason was simplicity of implementation, and would
> Ive noticed that its not allowed to...
further guess it will be relaxed at some point.
--
Paul Phillips | These are the climbs that apply men's soles.
Stickler |
Empiricist |
all hip pupils! |----------* http://www.improving.org/paulp/ *----------
Mon, 2010-09-06, 19:57
#4
Re: Why isn't mixing Context Bounds and regular Implicit Params
I guess one possible solution would be to allow multiple implicit parameter lists.
Then you have to supply all of the first list, or all of the first two lists, or all of the first three lists, etc.
I wouldn't like to hazard a guess as to how difficult it might be to add such a feature though...
On 6 September 2010 19:28, Josh Suereth <joshua.suereth@gmail.com> wrote:
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Then you have to supply all of the first list, or all of the first two lists, or all of the first three lists, etc.
I wouldn't like to hazard a guess as to how difficult it might be to add such a feature though...
On 6 September 2010 19:28, Josh Suereth <joshua.suereth@gmail.com> wrote:
It also seems that using context bounds or implicit views necessitates that the type inferences work as expected. When you have to pass one of those implicit parameters in yourself, you have to pass them all in the order defined in the type parameter list, or rely on the compilers auto-naming scheme for if you only want to specify one of them. This can get frustrating...
On Sep 6, 2010 11:16 AM, "Paul Phillips" <paulp@improving.org> wrote:
On Mon, Sep 06, 2010 at 09:35:46PM +1000, Ben Hutchison wrote:
> Ive noticed that its not allowed to...I would guess the reason was simplicity of implementation, and would
further guess it will be relaxed at some point.
--
Paul Phillips | These are the climbs that apply men's soles.
Stickler |
Empiricist |
all hip pupils! |----------* http://www.improving.org/paulp/ *----------
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Mon, 2010-09-06, 21:47
#5
Re: Why isn't mixing Context Bounds and regular Implicit Params
On Mon, Sep 6, 2010 at 8:43 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
I guess one possible solution would be to allow multiple implicit parameter lists.I think this is a desirable feature. I've encountered the need for them in my experiments with implicits and type-level computation. Full support for functional dependencies (which are kind of the precursor to open type functions) would require these as well.
Then you have to supply all of the first list, or all of the first two lists, or all of the first three lists, etc.
I wouldn't like to hazard a guess as to how difficult it might be to add such a feature though...you're welcome to find out :-)
it's not very high on my list, but might make it in at some point in 2.9/3.0
cheersadriaan
Mon, 2010-09-06, 23:07
#6
Re: Why isn't mixing Context Bounds and regular Implicit Params
On 6 September 2010 21:41, Adriaan Moors <adriaan.moors@epfl.ch> wrote:
On Mon, Sep 6, 2010 at 8:43 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
I guess one possible solution would be to allow multiple implicit parameter lists.I think this is a desirable feature. I've encountered the need for them in my experiments with implicits and type-level computation. Full support for functional dependencies (which are kind of the precursor to open type functions) would require these as well.
Then you have to supply all of the first list, or all of the first two lists, or all of the first three lists, etc.I wouldn't like to hazard a guess as to how difficult it might be to add such a feature though...you're welcome to find out :-)
It's tempting, but I have this terrible habit of over-committing myself, and I've already set aside some time to play with Tiark's scala-virtualized branch :)
it's not very high on my list, but might make it in at some point in 2.9/3.0
cheersadriaan
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
On Monday September 6 2010, Ben Hutchison wrote:
> Ive noticed that its not allowed to have both Context Bounds and
> regular Implicit Params defined for the same method. Is this simply a
> policy decision or is there some structural reason I can't see?
>
> //silly example
> scala> def method[T: ClassManifest](implicit p: String) {}
> :1: error: cannot have both implicit parameters and context
> bounds `: . ..' on type parameters
Since the context bound notation is just syntactic sugar for an implicit
parameter, you can still do what you want:
def m[T](implicit p: String, mt: Manifest[T]) { ... }
> ...
>
> -Ben
Randall Schulz