- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
A change in the way the interpreter displays views.
Mon, 2010-04-05, 17:15
Hi Paul,
I was thinking that views should not display their elements because this means forcing the view. I'd rather want them to print similarly to unevaluated Streams, which also print Stream(x, y, z, ?). I changed the toString method in TraversableView#Transform to print something like TraversableViewXYZ(...). (with the ... being there literally). However, the interpreter will still happily print all elements of a view. Can you point me to the place where things get printed? What kind of magic is applied here?
Cheers
-- Martin
I was thinking that views should not display their elements because this means forcing the view. I'd rather want them to print similarly to unevaluated Streams, which also print Stream(x, y, z, ?). I changed the toString method in TraversableView#Transform to print something like TraversableViewXYZ(...). (with the ... being there literally). However, the interpreter will still happily print all elements of a view. Can you point me to the place where things get printed? What kind of magic is applied here?
Cheers
-- Martin
Mon, 2010-04-05, 18:17
#2
Re: A change in the way the interpreter displays views.
On Mon, Apr 5, 2010 at 6:51 PM, Paul Phillips <paulp@improving.org> wrote:
On Mon, Apr 05, 2010 at 06:15:49PM +0200, martin odersky wrote:That's good to know! Looking at this:
> I was thinking that views should not display their elements because
> this means forcing the view. I'd rather want them to print similarly
> to unevaluated Streams, which also print Stream(x, y, z, ?). I changed
> the toString method in TraversableView#Transform to print something
> like TraversableViewXYZ(...). (with the ... being there literally).
> However, the interpreter will still happily print all elements of a
> view. Can you point me to the place where things get printed? What
> kind of magic is applied here?
The accumulation of magical bits eventually led me to centralize it.
It's ScalaRunTime.stringOf.
case x: Traversable[_] =>
// Some subclasses of AbstractFile implement Iterable, then throw an
// exception if you call iterator. What a world.
// And they can't be infinite either.
if (x.getClass.getName startsWith "scala.tools.nsc.io") x.toString
else (x map inner) mkString (x.stringPrefix + "(", ", ", ")")
Do we need this? Can't we make Traversables use toString in all cases?
Cheers
-- Martin
Mon, 2010-04-05, 18:27
#3
Re: A change in the way the interpreter displays views.
On Mon, Apr 05, 2010 at 06:59:12PM +0200, martin odersky wrote:
> Do we need this? Can't we make Traversables use toString in all cases?
No, the whole reason it came about is for this:
scala> List(Array(1))
res0: List[Array[Int]] = List(Array(1))
Without the special casing that is List([I@1f7dff15)
Mon, 2010-04-05, 18:57
#4
Re: A change in the way the interpreter displays views.
On Mon, Apr 5, 2010 at 7:12 PM, Paul Phillips <paulp@improving.org> wrote:
On Mon, Apr 05, 2010 at 06:59:12PM +0200, martin odersky wrote:I understand now, thanks! Then all I need to do is exclude Views from this logic and we should be done.
> Do we need this? Can't we make Traversables use toString in all cases?
No, the whole reason it came about is for this:
scala> List(Array(1))
res0: List[Array[Int]] = List(Array(1))
Without the special casing that is List([I@1f7dff15)
Cheers
-- Martin
--
Paul Phillips | Simplicity and elegance are unpopular because
Moral Alien | they require hard work and discipline to achieve
Empiricist | and education to be appreciated.
i'll ship a pulp | -- Dijkstra
Mon, 2010-04-05, 19:27
#5
Re: A change in the way the interpreter displays views.
On Mon, Apr 05, 2010 at 07:47:52PM +0200, martin odersky wrote:
> I understand now, thanks! Then all I need to do is exclude Views from
> this logic and we should be done.
Technically that is true, but it seems like there's an abstraction in
here somewhere. I mean
if (x.getClass.getName startsWith "scala.tools.nsc.io")
makes me as ill as anyone else. I'm not sure what it would be called,
but some kind of method like...
def isTraversableCasually: Boolean
(I'm joking in name but not in concept) which would default to true but
could be overridden by:
* Infinite sequences
* Views which don't like being forced
* Iterators (were it defined on TraversableOnce)
* Iterables which throw exceptions on iterator (not a design I'm real
fond of, but it was like that when I got here)
* NodeSeqs which extend Node[Seq] (see previous comment)
...
Mon, 2010-04-05, 20:37
#6
Re: A change in the way the interpreter displays views.
On Mon, Apr 5, 2010 at 8:23 PM, Paul Phillips <paulp@improving.org> wrote:
On Mon, Apr 05, 2010 at 07:47:52PM +0200, martin odersky wrote:Yes, I was thinking the same thing. But then thought it would be better to turn this around. Have a method troStringShowElements which is by default false and is overridden by the standard collection implementations. Fewer surprises that way. Users should expect toString to be used for printing normally.
> I understand now, thanks! Then all I need to do is exclude Views from
> this logic and we should be done.
Technically that is true, but it seems like there's an abstraction in
here somewhere. I mean
if (x.getClass.getName startsWith "scala.tools.nsc.io")
makes me as ill as anyone else. I'm not sure what it would be called,
but some kind of method like...
def isTraversableCasually: Boolean
(I'm joking in name but not in concept) which would default to true but
could be overridden by:
* Infinite sequences
* Views which don't like being forced
* Iterators (were it defined on TraversableOnce)
* Iterables which throw exceptions on iterator (not a design I'm real
fond of, but it was like that when I got here)
* NodeSeqs which extend Node[Seq] (see previous comment)
...
Cheers
-- Martin
--
Paul Phillips | Those who can make you believe absurdities
Moral Alien | can make you commit atrocities.
Empiricist | -- Voltaire
pp: i haul pills |----------* http://www.improving.org/paulp/ *----------
Mon, 2010-04-05, 21:07
#7
Re: A change in the way the interpreter displays views.
On Mon, Apr 05, 2010 at 09:30:09PM +0200, martin odersky wrote:
> Yes, I was thinking the same thing. But then thought it would be
> better to turn this around. Have a method troStringShowElements which
> is by default false and is overridden by the standard collection
> implementations. Fewer surprises that way. Users should expect
> toString to be used for printing normally.
The annoying case which cannot be covered this way and leaves us still
having to through something like stringOf is null. But it still sounds
pretty good, one null special case won't kill anyone.
Mon, 2010-04-05, 21:57
#8
Re: Re: A change in the way the interpreter displays views.
On Mon, Apr 5, 2010 at 10:01 PM, Paul Phillips <paulp@improving.org> wrote:
On Mon, Apr 05, 2010 at 09:30:09PM +0200, martin odersky wrote:No, I mean leave stringOf, but simplify the logic to test for toStringShowElements. Actually, that should probably be renamed to
> Yes, I was thinking the same thing. But then thought it would be
> better to turn this around. Have a method troStringShowElements which
> is by default false and is overridden by the standard collection
> implementations. Fewer surprises that way. Users should expect
> toString to be used for printing normally.
The annoying case which cannot be covered this way and leaves us still
having to through something like stringOf is null. But it still sounds
pretty good, one null special case won't kill anyone.
toStringShowsElements.
Cheers
-- Martin
On Mon, Apr 05, 2010 at 06:15:49PM +0200, martin odersky wrote:
> I was thinking that views should not display their elements because
> this means forcing the view. I'd rather want them to print similarly
> to unevaluated Streams, which also print Stream(x, y, z, ?). I changed
> the toString method in TraversableView#Transform to print something
> like TraversableViewXYZ(...). (with the ... being there literally).
> However, the interpreter will still happily print all elements of a
> view. Can you point me to the place where things get printed? What
> kind of magic is applied here?
The accumulation of magical bits eventually led me to centralize it.
It's ScalaRunTime.stringOf.