headers
Aaron Harnly | 1 May 2008 03:12

crashing the compiler with a recursive method

...and I'm not sure where else to turn. Can anyone either:
  (a) figure out why this crashes the compiler
  (b) figure out a non-compiler-crashing way to express this
  or (c) tell me why this is a terrible idea and not what I should be  
doing at all.

---
Very brief background, which can be skipped if you'd rather just grok  
code:
1. I have a "format" type F which can be decomposed to yield an item  
(of the same type), and a remainder.

In a very simple example, a string like "a,b,c" can be decomposed to  
"a" and "b,c"; "b,c" can be decomposed to "b" and "c"; and of course  
"c" cannot be decomposed any further.

2. I have a "container" type S, which is a higher-kinded type, to  
which items can be added.

Obvious example is List; you can add "a" to Nil with "a" :: Nil to get  
List("a").

I'm trying to express a method which "pumps" the format type into an  
instance of the container type, until the first type is empty. But the  
compiler crashes when I use a recursive call decomposeIntoContainer:
---

object HigherTypeArgh
{
	trait SequenceFormat[F]
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Willigers | 1 May 2008 04:00
Picon

Re: crashing the compiler with a recursive method

Hi Aaron,

Once you have a compiler crash, you might want to keep a safe copy of 
the code that caused the compiler crash, and then try to simplify it 
while retaining the crash.

For example, the following simplification still crashes

trait SequenceFormat[F]
{
     def decomposeIntoContainer[S[_]](
         seqSoFar: S[F]
     ): S[F] = decomposeIntoContainer(
               seqSoFar
             )
}

trait SequenceContainer[S[_]]
{
}

I suspect the compiler is having trouble with the inferred type of S in 
the recursive call.

Changing the recursive call to
     decomposeIntoContainer[S](
avoids the problem (both in my cut down example and in your original code).

Let me encourage you to create a ticket for the compiler crash in Trac
http://lampsvn.epfl.ch/trac/scala
(Continue reading)

Permalink | Reply | 2 comments |
headers
Aaron Harnly | 1 May 2008 13:08

Re: crashing the compiler with a recursive method

On Apr 30, 2008, at 10:00 PM, Eric Willigers wrote:
> For example, the following simplification still crashes

Thanks, Eric. Lovely, and I'll file a ticket.
cheers,
aaron
Permalink | Reply | 1 comment |
headers
Adriaan Moors | 1 May 2008 14:04
Picon

Re: Re: crashing the compiler with a recursive method

hi,

this is a known issue (http://lampsvn.epfl.ch/trac/scala/ticket/445)

sorry that it hasn't been fixed yet :-/

adriaan

On 01 May 2008, at 13:08, Aaron Harnly wrote:

> On Apr 30, 2008, at 10:00 PM, Eric Willigers wrote:
>> For example, the following simplification still crashes
>
> Thanks, Eric. Lovely, and I'll file a ticket.
> cheers,
> aaron
>
>
Permalink | Reply | 0 comments |
headers
martin odersky | 1 May 2008 17:56
Picon
Picon
Favicon

Re: Type aliases with type members specified: Weird little beasts

On Wed, Apr 30, 2008 at 5:40 PM, Keiko Nakata
<keiko <at> kurims.kyoto-u.ac.jp> wrote:
>
>  > >  3. Type alias with type member specification
>  > >
>  > >  abstract class Bar { type X }
>  > >  type BString = Bar { type X = String }
>  > >  new BString { val get = "hey" }
>  > >
>  > >  error: class type required
>
>
> > Not sure if this is what you're looking for, but traits might help
>  > remedy the problem:
>  >
>  > abstract class Bar { type X; def get: X }
>  > trait BString extends Bar { type X = String }
>  > new BString { val get = "hey" }
>  >
>
>  But I want to understand why the former code does not work.
>
A supertype of a class must be a class type. It may be neither an
abstract type, nor a singleton type, nor a refinement type.

Cheers

 -- Martin
(Continue reading)

Permalink | Reply | 0 comments |
headers
martin odersky | 1 May 2008 18:44
Picon
Picon
Favicon

Re: Re: licensing of scala/collection/immutable/Tree.scala

On Mon, Apr 28, 2008 at 9:21 PM, Christos KK Loverdos
<loverdos <at> gmail.com> wrote:
> I think the simplest solution (apart from Martin's suggestion) is to
>  convince the respective authors to release this particular
>  implementation using the standard Scala lisence. The author of some
>  code has the absolute right to release his/her software in whatever
>  license he/she wants.
>
I got permission from Erik Stenman (the author) to do that. So
Tree.scala is now no longer specially licensed.

Cheers

 -- Martin
Permalink | Reply | 1 comment |
headers
martin odersky | 1 May 2008 18:45
Picon
Picon
Favicon

Re: Re: licensing of scala/collection/immutable/Tree.scala

On Thu, May 1, 2008 at 6:44 PM, martin odersky <martin.odersky <at> epfl.ch> wrote:
> On Mon, Apr 28, 2008 at 9:21 PM, Christos KK Loverdos
>  <loverdos <at> gmail.com> wrote:
>  > I think the simplest solution (apart from Martin's suggestion) is to
>  >  convince the respective authors to release this particular
>  >  implementation using the standard Scala lisence. The author of some
>  >  code has the absolute right to release his/her software in whatever
>  >  license he/she wants.
>  >
>  I got permission from Erik Stenman (the author) to do that. So
>  Tree.scala is now no longer specially licensed.

Indeed. That's going to be the policy from now on. Please report any
remaining issues with licenses as you see them; we'll try to get them
sorted out as well.

Cheers

 -- Martin
Permalink | Reply | 0 comments |
headers
Lauri Alanko | 1 May 2008 19:54
Picon
Picon
Favicon

Re: Type aliases with type members specified: Weird little beasts

On Sun, Apr 27, 2008 at 04:03:28PM -0400, Aaron Harnly wrote:
> Hi all,
> 
> Next in my series of random puzzles: Is there any particular reason  
> why we cannot use a type alias with type member specifications to  
> construct instances?

Because a type is not a class. Scala's object system associates all
classes with types, and I think that for almost all types T there is a
natural notion of "the simplest class whose class type conforms to T",
and in Scala's syntax class identifiers are also used to stand for the
corresponding class types. Although this is often convenient, it also
leads to confusion like yours.

I recently ranted about this in another thread:

http://article.gmane.org/gmane.comp.lang.scala.user/5262

> 1. Simple type alias
> 
> class Foo
> type F = Foo
> new F()
> 
> works fine. No objections from the compiler.

There should be, IMNSHO. I'm surprised by the behavior. Apparently
Scala currently has some hacks to overload type variables to be also
usable as class variables when the type is an alias for a class type.
This is harmful, I think, because it leads one to assume that you can
(Continue reading)

Permalink | Reply | 15 comments |
headers
Miles Sabin | 1 May 2008 20:11
Gravatar

Re: Type aliases with type members specified: Weird little beasts

On Thu, May 1, 2008 at 6:54 PM, Lauri Alanko <la <at> iki.fi> wrote:
> On Sun, Apr 27, 2008 at 04:03:28PM -0400, Aaron Harnly wrote:
>  > 3. Type alias with type member specification
>  >
>  > abstract class Bar { type X }
>  > type BString = Bar { type X = String }
>  > new BString { val get = "hey" }
>  >
>  > error: class type required
>  >
>  > Hmmm. So what exactly is going on here, and is this a necessary
>  > restriction?
>
>  The simple answer is that BString is a type, not a class, not a class
>  type. It just is conceptually not the sort of thing that can be
>  meaningfully subclassed.
>
>  If you have some proposal on what exactly the above should mean, then
>  more specific comments can be given. I can think of a couple of
>  possible translations, but all of them have their problems.

Playing devil's advocate here ...

Let's suppose the above is equivalent to,

  abstract class Bar { type X }
  type BString = Bar { type X = String }
  new BStringClass { val get = "hey" }

where BStringClass is the "simplest" class whose class type conforms
(Continue reading)

Permalink | Reply | 1 comment |
headers
martin odersky | 1 May 2008 20:02
Picon
Picon
Favicon

Re: Type aliases with type members specified: Weird little beasts

On Thu, May 1, 2008 at 7:54 PM, Lauri Alanko <la <at> iki.fi> wrote:
> On Sun, Apr 27, 2008 at 04:03:28PM -0400, Aaron Harnly wrote:
>  > Hi all,
>  >
>  > Next in my series of random puzzles: Is there any particular reason
>  > why we cannot use a type alias with type member specifications to
>  > construct instances?
>
>  Because a type is not a class. Scala's object system associates all
>  classes with types, and I think that for almost all types T there is a
>  natural notion of "the simplest class whose class type conforms to T",
>  and in Scala's syntax class identifiers are also used to stand for the
>  corresponding class types. Although this is often convenient, it also
>  leads to confusion like yours.
>
>  I recently ranted about this in another thread:
>
>  http://article.gmane.org/gmane.comp.lang.scala.user/5262
>
>
>  > 1. Simple type alias
>  >
>  > class Foo
>  > type F = Foo
>  > new F()
>  >
>  > works fine. No objections from the compiler.
>
>  There should be, IMNSHO. I'm surprised by the behavior.
(Continue reading)

Permalink | Reply | 11 comments |

Gmane