carlok | 30 Jun 18:35 2015
Picon

Would support for [non-erased] Higher-Kinded types in [future version] of CLR suffice for full scala support ?

Hi everyone,

(*ducks* don't hit me, i tried googling for [recent/relevant] talk about "google://scala&clr&higher-kinded", and found nothing)

I'd be truly happy to have Scala on .NET (wet dream: supported by VS & Resharper).

I know that support was dropped because of CLR not being particularly friendly to Scala (noticed rumors that maybe Microsoft dropping financial support is a part of the decision).

But there is talk - now that CLR is also open-sourced - about merits of supporting [non-erased] HKT's in future. CLR also supports (now maybe even correctly ;-) tail call elimination (no trampolining hell, oh yeah ;-).

Even though C# 6.0 is almost pleasant, i still miss Scala very much (and still dislike JVM a bunch ;-) . Also, .NET is so much easier if you have to support some deep dark corners of the MS stack (x_x) ...

What would be needed for CLR to make "native" (not IKVM) .NET Scala implementation "a breeze" ? Perhaps the CLR crowd could be "pushed to implement it all", if incentivised by visions of Scala heaven ;-)

Thanks,

  carlok.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Oleg Ilyenko | 26 Jun 23:12 2015
Picon

`try`/`finally` equivalent for `scala.concurrent.Future`

Hi,

I have a question (and possibly suggestion) about `scala.concurrent.Future`. I noticed that it does not contain an equivalent of `try`/`finally`. One could argue, that `andThen` fulfills this role, but unfortunately it takes a `Try[T] => U` function as an argument instead of `Try[T] => Future[U]`, which I need in most of the cases.

Let me explain my use-case. When I working with async/non-blocking API, most of the operations return `Future`, as one would normally expect. This also includes lifecycle methods, like `close` or `shutdown`. Often I have a situation, where I allocate some resources and would like to make some cleanup when `Future` is completed with either success or failure:

class Resource {
  def read(): Future[String] = ???
  def close(): Future[Unit] = ???
}

def readResource(): Future[String] = {
  val resource = new Resource

  resource.read().andFinally(_ => resource.close())
}

I find it to be pretty common pattern (I also seen and used it in `Future` implementation of other languages). At the moment I use this naive implementation of it:

implicit class FutureExtras[T](val f: Future[T]) extends AnyVal {
  def andFinally(fn: Try[T] => Future[_])(implicit ec: ExecutionContext): Future[T] = {
    f.flatMap(value => fn(Success(value)) map (_ => value))
        .recoverWith {case error => fn(Failure(error)) map (_ => throw error)}
  }

So the semantics of `andFinally` is very similar to `andThen`. The difference is that it waits for the `Future` returned by `fn` before propagating the actual value down the chain. Do you think this is a suitable solution for the use-case i described, or do I miss something? If the solution is good, do you think it makes sense to include `andFinally` in the `Future` trait itself?

I also noticed, that most of the `Future` methods take a `PartialFunction` instead of `Function1` as an argument. Sometimes it is inconvenient since it forces me to use pattern-matching. So I wondered what is the reasoning behind this?

Best regards,
Oleg

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Eran Medan | 25 Jun 00:10 2015
Picon

SIP proposal - support _ in numeric literals

Hi scala-debate!

Following a positive comment by Martin in r/scala, regarding adding _ seperator to numeric literals, (he said he is ok with this as an SIP) I'd like to ask your feedback / moral support as well 

The request is to support _ in number literals to allow writing more readable numeric constants (e.g. 1_000_000 instead of 1000000). This exists in Java 8, Rust and perhaps in other languages. 
The Java specification is to simply ignore any underscore chars inside a number literal, (e.g. as long as the first and last in a literal are digits all _ sequences in between are ignored) 

Since Scala always was ok with supporting basic Java expressions, it's not a new language feature as much as just keeping up with a very cosmetic and low risk readability feature. 
My questions 
  1. Can I go ahead and create an SIP for it? (even though I'm a "newbie" to contribution to scala and scalac in particular) 
  2. Should I also include other Java8 literal changes (e.g. binary literal)? or should this be a different SIP?
  3. Should I also implement it or rather have someone who comitted to Scala's compiler before pick it up (it's probably a small change) 
  4. Anything I need to know that is not covered here? http://www.scala-lang.org/contribute/hacker-guide.html 
  5. Is there a formal language definition syntax for Scala that I also need to update if I make this change?
Here is my naive implementation outline (I didn't test it or even try to compile it yet, just to ask if this is the right location and approach)
I'm sure it's much more complex than that, but well, I have to start from somewhere, right? (and the best way to get the right answer in the internet is not to ask, but to post the wrong answer :))

The only "complexity" is to handle this case 1_000_000_ (which personally I think should be ok, but the Java specification doesn't allow it, so we should follow)

Should the implementation be here? (just a guess: https://github.com/scala/scala/blob/2.12.x/src/compiler/scala/tools/nsc/ast/parser/Scanners.scala#L979) 

protected def getNumber(): Unit = { // consume digits of a radix
def consumeDigits(radix: Int): Unit = { var lastIsUnderscore = false;
while (digit2int(ch, radix) >= 0 || ch == '_') { if(ch != '_') {

putChar(ch) lastIsUnderscore = false; } else { lastIsUnderscore = true; }
nextChar()
} if(lastIsUnderscore) { //TODO: howdo I throw an error if the last char in the number sequence is an _? } }

How far is it from what needs to be actually done? Also if by accident it's actually doing what it should do, can you help me find a more elegant way to implement it? Or is it readable enough?
(again, didn't compile / test yet, just getting initial feedback, never commited to Scala before... )

Should I go ahead and continue? or should I stay away from the compiler? :)

Thanks!
Eran

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Esdras Souto Costa | 29 Apr 17:38 2015
Picon

Variadic Template (Generic Varargs) in Scala

does scala writers intends to implement the Variadic Template in Scala?
In this way, you eliminate 22 Tuple classes (Tuple2, Tuple3, ..., Tuple22)
and other classes that has same problem like Function classes (Function0, ...)

I think it's a little ugly to see

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lukas Wegmann | 20 Apr 11:57 2015
Picon

Disable Conversion to Unit

Hi,

I recently spent hours to track a bug due to the automatic conversion to Unit.

Finally, the issue boiled down to a swallowed exception because a Try[Unit] has been converted to Unit:

def f(i: Int): Try[Unit] = Try{ throw new ArrayIndexOutOfBoundsException }

def g(): Unit = f(42) // will never throw, but f(42).get would

I'm now wondering if one could also get along without the automatic conversion to Unit? I think this behavior is a bit off from the general convention in Scala of making destructive operations explicit. E.g. converting a Float to an Int.

What do you think? Would a compiler flag that disables this conversion make sense or is there some invaluable benefit I've missed?


Lukas

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Eric Kolotyluk | 25 Mar 02:16 2015
Picon

Wacky Fantasies in Documentation

I was trying to get something working by reading the ScalaDoc. The 
documentation was actually quite good by Scala standards, complete with 
examples even. Unfortunately, there were some errors in the example code 
that took me a while to figure out. Then I started to have this fantasy...

I wonder if it would be possible to define example code in scaladoc 
comments such that when you generated your documentation at build time 
in scaladoc, it would run the example code like a unit test, and fail 
the build if the example code did not compile and execute.

One of my colleagues started buying into my fantasy and even suggested 
that the scaladoc comments link to actual unit tests. Often studying 
unit tests can be the best example of understanding a library or 
framework. Indeed, I have seen a number of projects in GitHub that refer 
you to the unit tests for examples of how to use the API or framework. 
Of course this would imply that you would actually want to write good 
scaladoc comments for your unit tests too. OMG - now I am speaking 
heresy. What if the unit test framework actually help generate 
meaningful documentation to explain what what going on?

My experience with documentation has been that it is often hard to test 
documentation, to test that it is actually correct. What if we could 
help improve documentation by using automated methods to test it, or at 
least a part of it, such as examples.

Cheers, Eric

--

-- 
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Justin Pihony | 18 Mar 20:16 2015
Picon

Opinion requested for ScalaDocs change

All,
    I first posted this on the internals group, and then the users group, and was suggested to post it here. If you have any input in a more searchable scaladoc, then please put your two cents in :)

    The current state of scaladocs does not allow for easy searchability between companion objects. This issue was created to help the problem by combining the companion pages. The thought is that it will help discovery by allowing an easier Ctrl+F. I am asking for a consensus of opinions on how this should be accomplished. If you go to this link, you will see the current state of the propositions. 

The constant across all changes is the structure of the member definition.
The part that is in question revolves around the top level documentation; whether it should be combined or not. If so, what is the best way of combining:


Please review and let me know what you think is the best solution.

Thanks,
Justin

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rich Oliver | 16 Mar 16:11 2015
Picon

Is Object-Orientated Programming misnamed?

Would it be more accurate to call Object-Orientated Programming Subject-Orientated programming?

The so called objects are in fact dynamic subjects. This is both their power and their danger. A so called object can do anything it wants when you call a method on it: print out helpful feedback, log information, launch a nuclear missile, or upload your personal data to a Server.. This is why Java strings are finalised, because if you could override methods on strings it would create huge security holes. On the JVM its ints, floats doubles etc that are the true objects, passive dumb objects that rely on external function calls to do anything with. The same with classic C data. Again just dumb objects. Surely its C that should be classifed as an object orientated language?

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
MichaelZ | 16 Mar 01:47 2015
Picon

why "Hi:%.1G".format(0.0) does not work? Puzzled.

why "Hi:%.1G".format(0.0) does not work? Puzzled.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Som Snytt | 14 Mar 23:28 2015
Picon

GSOC diversion


I can't believe it's almost summer!

If I can find a mentor, I would like to tackle the first project idea, dealing with project organization and aggregation in Scala:

http://scala-lang.org/gsoc/2015.html#project_titles_go_here_with_h3_headings

Since naming is the hardest problem in computer science, I realize that a single summer of coding is not sufficient to achieve a robust implementation.

Probably actually coming up with titles is out of scope.

But given a source of random words, such as a dictionary or an EPFL student, it should be possible to generate corresponding headings.

If I can formalize it in a paper, which Scala conference should I present at? I have a travel budget of about 3/4 of a tank of gas.

I propose that as proof-of-concept, the tool should emit JSON output, and the conversion to h3's can be tackled by the community using Scala.js.

BTW, at first I thought Scala.js was the user group for the isle of Jersey, but that would be Scala.je. To avoid such problems in future, I hope to add a lint filter to the project title tool.

One solution would be to mangle names, such as "scala$backend$javascript". The mangling would be completely invisible to the user. Does the community have any experience with that?

I can't wait to start coding in Scala, so I will likely go ahead without a mentor.

I am confident I can complete the project in 1/3 the lines it would have taken me in Java.

Summertime, and the coding is easy.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Radek Slupik | 10 Mar 22:32 2015
Picon

Making ScalaDoc show preconditions and postconditions.

Currently calls to require and ensuring merely turn into assertions. Would it be reasonable to make ScalaDoc put these in the documentation as well?

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gmane