[anonymoushn]

This, and your replies below, read like trolling written by someone who hasn't used the features he is claiming are unnecessary. They repeatedly fail to address the point: you actually can't begin in Scala with no notion of lightweight threads, coroutines, or continuations, and simply make a library that does one of those things.

  "The style one can program in and the style it is implemented isn't connected the way you think it is."

The above might be alluding to techniques for pretending to have these language features when one does not. You can write CPS manually, and you might even be able to make a machine apply the CPS transformation automatically to your procedural code. Neither of these things sound particularly fun, compared to the alternative of writing procedural code and then debugging the code that you've actually written. It's little help that you have to return every once in a while to avoid a StackOverflow due to the language's embarrassing lack of TCO.

Edit: Apparently if you use Squawk you can have green threads. Can you have OS threads as well?

[anonymoushn]

In consideration to anyone who actually tries to read all this, I was wrong. Scala really does have continuations. You won't learn about this by reading Martin Odersky's book on the language (even though the book is for Scala 2.8, the version in which delimited continuations were introduced), but googling around for delimited continuations, shift, and reset will result in a fair mix of useful notes and completely inscrutable notes.

This whole sort of back and forth exchange of escalating condescension is not rare on the internet, but I was surprised that dino wouldn't actually tell anyone why we were wrong. Generally I've found this quote http://bash.org/?152037 to be more or less true; asserting that a system is incapable of things it is capable of is met with people pointing out how to make it do those things. In this particular instance the response from dino involved much more effort than a simple lmgtfy link while accomplishing dramatically less in the promotion of his faith, or even the promotion of any sort of knowledge at all.

This feature is a little obscure, and one could easily spend a great deal of time writing Scala professionally without ever passing "-P:continuations:enable" to anything. I believe that one would be missing out.

[happy_dino]

> due to the language's embarrassing lack of TCO

TCO is a runtime property, not a language property.

Anyway, you have clearly not been doing your research and its not my job to do it for you.

Bye.

[anonymoushn]

This comment is hilarious. I guess I can now spend the rest of my life searching for the super-performant yet somehow extremely obscure JVM implementation with OS threads, green threads, and TCO.

Edit: I am still seeking the legendary JVM implementation with TCO. I guess the argument is something like, oh well at some point in the future some JVM could conceivably have that feature, therefor it is wrong to say that Scala does not have it! Rather than writing code that assumes Scala is a complete joke of a functional language, one could simply write the code the natural way, verify that it compiles, and then wait until a JVM with TCO exists, so that it will stop crashing! In the mean time, one can enjoy the entertainment provided by Scala's inability to compile shift in an if statement without an else clause. Truly I am writing code exactly as I would if(it_was_synchronous) else { cpsunit }.

I feel as though you told me reset and shift, although you did not. So thanks for that!

[happy_dino]

> I am still seeking the legendary JVM implementation with TCO.

  scala> :paste
  // Entering paste mode (ctrl-D to finish)

  object TCO extends App {
    def stackSize = Thread.currentThread.getStackTrace.length
    def printStackSizeMessageOutside() =
      println(s"$stackSize stackframes outside of the mutually recursive calls")
    def printStackSizeMessageInside() =
      println(s"$stackSize stackframes inside the mutually recursive calls")

    def mutuallyRecursiveAdd1(a: Long, b: Long): Long =
      if (b == 0) {
        printStackSizeMessageInside()
        a
      } else
        mutuallyRecursiveAdd2(a+1, b-1)
  
    def mutuallyRecursiveAdd2(a: Long, b: Long): Long =
      if (b == 0) {
        printStackSizeMessageInside()
        a
      } else
        mutuallyRecursiveAdd1(a+1, b-1)
  
    printStackSizeMessageOutside()
    mutuallyRecursiveAdd1(23, 10000000)
  }

  // Exiting paste mode, now interpreting.

  defined object TCO

  scala> TCO main null
  We have 29 stackframes outside of the mutually recursive calls
  We have 30 stackframes inside the mutually recursive calls

[anonymoushn]

Sweet, where do I download it/which obscure flag to I pass to enable it?

  27 stackframes outside of the mutually recursive calls
  java.lang.StackOverflowError
	at TCO$.mutuallyRecursiveAdd2(<console>:22)

Oddly, your Thread.currentThread.getStackTrace.length seems to return strings like "We have 30". Mine is returning an Int over here.

[happy_dino]

Ah right. I refactored the messages a bit and didn't completely update the post to mirror that.

[anonymoushn]

I am still very interested in learning about the runtime you are using :)

After a significant amount of effort (googling for stuff about scala, JVMs, and TCO mostly gets hits with people complaining about their code not working) I discovered something called Avian, which I can try out soon. I still think it is a bit weird to spend time engaging with a stranger who wants to know something very simple, but to expect the stranger to dig around for it for a few hours instead of telling him.