David Barri | 29 Aug 00:10 2015
Picon

Re: pre-SIP proposal discussion: Partial type inference, and named type arguments

 - Scala would become a null safe language
 - There would be an alternative to Option that does not require
boxing, which in turn would make lots of operations faster.

Woah, that's a pretty neat idea. Is this something planned for Dotty?

On 28 August 2015 at 23:22, Jon Pretty <jon.pretty <at> propensive.com> wrote:
Hi Simon,

I think the point here is not that it would encourage people to use nulls, but would handle them in an acceptably-concise way everywhere they exist that we can't do anything about them, e.g. Java APIs.

Complementing this would be a new global assertion that non-? types like `String` and `List[Int]` could never be null (assigning `null` to them would be an error), and this would be an extremely valuable enhancement. `T` would coerce to `T?` for all `T`, but not the other way round, unless you import or define a "dangerous" implicit, presumably. We could have that implicit emit a warning, if we wanted.

So, for example, the signature of `System.getProperty` would become `def getProperty(key: String?): String?`, and that `?` would serve as a constant reminder that we need to explicitly handle these `null`s, probably with something like the `Option(...)`, or perhaps some more concise convenience methods.

So, would this *encourage* people to use nulls? The default for any type you write down would be not to support `null`s, so I don't see why people would voluntarily add a `?` to a type just to make it more inconvenient to use.

But it probably *would* encourage the use of nulls instead of `Option`s. So, is that a problem, now that our type system encapsulates that nullability well? We've just got a typesafe, boxing-free `Option`!

If this is the direction it's going, that gets a big +1 from me.

Cheers,
Jon



--
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.
Jon Pretty | 28 Aug 15:25 2015

Fwd: pre-SIP proposal discussion: Partial type inference, and named type arguments

Hi Simon,

I think the point here is not that it would encourage people to use nulls, but would handle them in an acceptably-concise way everywhere they exist that we can't do anything about them, e.g. Java APIs.

Complementing this would be a new global assertion that non-? types like `String` and `List[Int]` could never be null (assigning `null` to them would be an error), and this would be an extremely valuable enhancement. `T` would coerce to `T?` for all `T`, but not the other way round, unless you import or define a "dangerous" implicit, presumably. We could have that implicit emit a warning, if we wanted.

So, for example, the signature of `System.getProperty` would become `def getProperty(key: String?): String?`, and that `?` would serve as a constant reminder that we need to explicitly handle these `null`s, probably with something like the `Option(...)`, or perhaps some more concise convenience methods.

So, would this *encourage* people to use nulls? The default for any type you write down would be not to support `null`s, so I don't see why people would voluntarily add a `?` to a type just to make it more inconvenient to use.

But it probably *would* encourage the use of nulls instead of `Option`s. So, is that a problem, now that our type system encapsulates that nullability well? We've just got a typesafe, boxing-free `Option`!

If this is the direction it's going, that gets a big +1 from me.

Cheers,
Jon

--
Jon Pretty
Propensive Ltd
<at> propensive

--
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.
Janek Bogucki | 21 Aug 22:29 2015
Picon

Proposed removal of <at> author and <at> version

Hi,

The tracking of source file authors and versions should be left to the VCS. This leads me to propose the removal of <at> author and <at> version tags,

For example,

Stack.scala

* <at> author Matthias Zenger
* <at> version 1.0, 10/07/2003

This file has over 10 authors and edits as recently as 2013 so the tags are misleading.
Best Regards,Janek

--
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.
Naftoli Gugenheim | 21 Aug 05:55 2015
Picon

Re: pre-SIP proposal discussion: Partial type inference, and named type arguments

Another proposal of Paul's was based on something like currying, so you could have a function that lets you write f[Int][String](x) out just f[Int](x). I think the simple way of implementing it was nested apply's without parentheses, like def apply[A] = { def apply[B](x: B) = null }

This would allow for the same shortcutting, without (a) overloading _ more, or (b) giving an identifier like ? special meaning to the compiler.


On Thu, Aug 20, 2015, 10:54 PM Jason Zaugg <jzaugg <at> gmail.com> wrote:
On Thu, Aug 20, 2015 at 8:54 PM Ahmad Salim Al-Sibahi <asal.thegeek <at> gmail.com> wrote:

Therefore, it might be nice if possible to partially apply (either using _ or named arguments) type signature and let Scala take care of the rest.
In the first example, one should then be able to write right[String, _](0) or right[A = String](0) , and for the second example one could write nums.flatMap[String \/ Int, _] or nums.flatMap[String \/ Int, Set[_]] or nums.flatMap[B = String \/ Int].
I believe that this will strike a better balance than having to write everything explicitly, when Scalas automatic inference fails or produces the wrong result.

All (constructive) feedback and ideas are welcome. If people are interested, I shall go forth and write an official SIP.

Here's one previous discussion on this topic: "another matter of syntax". I recall the topic coming up once or twice since then, might be worth trawling the archives for any other discussions. 

I think that its an interesting idea that is worth fleshing out. I’d favour use of _, or maybe Predef.?, as the signal to infer the type, rather than named type parameters, which would be a bigger change to the language.

Here’s a quick prototype of the change that shows that the impact on the typechecker might not be too large. The backticked underscore is a way to sneak a wildcard through the parser, and aren’t a serious suggestion for the user facing syntax.

scala> def test[A, B >: A]: (A, B) = ???; def x = test[Int, `_`] test: [A, B >: A]=> (A, B) x: (Int, Int) scala> val nums = Set(1,2,3) nums: scala.collection.immutable.Set[Int] = Set(1, 2, 3) scala> def right[L, R](r: R): Either[L, R] = Right(r) right: [L, R](r: R)Either[L,R] scala> def left[L, R](l: L): Either[L, R] = Left(l) left: [L, R](l: L)Either[L,R] scala> nums.foldLeft(right[String, `_`](0))( (acc, i) => left("nope")) res0: Either[String,Int] = Left(nope) scala> nums.flatMap[Either[String, Int], `_`](a => Set(right(a))) res1: scala.collection.immutable.Set[Either[String,Int]] = Set(Right(1), Right(2), Right(3))
-jason

--
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.

--
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.
Haoyi Li | 21 Aug 00:40 2015
Picon

Re: Re: Boy was I wrong: My experience with C#


> ah, but what if people are not satisfied with Scala? then they get to
take a hike? :-)

I hear alpaca farming is wonderfully scenic

On Aug 20, 2015 10:33, "Raoul Duke" <raould <at> gmail.com> wrote:
> not happy with it (for whatever reason)? Languages like Scala do exist,
> because people are not satisfied with the quality of mainstream languages.

ah, but what if people are not satisfied with Scala? then they get to
take a hike? :-)

--
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.

--
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.
Ahmad Salim Al-Sibahi | 20 Aug 12:54 2015
Picon

pre-SIP proposal discussion: Partial type inference, and named type arguments

Hi everyone <at> scala-debate,

While using Scala, I have noticed that it does not currently support partial application of type arguments when calling methods: one must either let Scala infer every argument or one must provide each individual argument oneself. This is seemingly inconvenient when calling methods which accepts multiple type arguments and Scala only fails to infer one of the arguments correctly; especially, when some of the other arguments have long type names. Another situation where this also presents an inconvenience, is when some of the type arguments are dependent on each other and providing the full type argument list thus leads to some duplication.
The following two examples illustrate the point:

import scalaz.\/._object Application extends App { val nums = Set(1,2,3) val _ = nums.foldLeft(right(0)) { (acc, i) => if (i < 0) left("negative number") // Error, found: String("negative number") required: Nothing else for (prevsum <- acc) yield (prevsum + i) } }

Where it infers the value of B (the accumulator type) in foldLeft to Nothing \/ Int, and therefore is incompatible with the string used in the provided function.
Of course, one could solve this by providing the type arguments to right explicitly i.e. [String, Int]; however, since it could infer the second argument automatically, it seems inconvenient to have to type it in explicitly (imagine having a longer type Set[Map[String, Int]] on the right hand-side and you can see especially why).

Similarly, for dependent arguments like used in flatMap, there is duplication in type signature.

import scalaz.\/.import scalaz.\/._object Application extends App { val nums = Set(1,2,3) val a = nums.flatMap[String \/ Int, Set[String \/ Int]](a => Set(right(a))) // Note required duplication of String \/ Int argument }


Therefore, it might be nice if possible to partially apply (either using _ or named arguments) type signature and let Scala take care of the rest.
In the first example, one should then be able to write right[String, _](0) or right[A = String](0) , and for the second example one could write nums.flatMap[String \/ Int, _] or nums.flatMap[String \/ Int, Set[_]] or nums.flatMap[B = String \/ Int].
I believe that this will strike a better balance than having to write everything explicitly, when Scalas automatic inference fails or produces the wrong result.

All (constructive) feedback and ideas are welcome. If people are interested, I shall go forth and write an official SIP.

Thanks in advance,

Regards,

AS



--
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.
Simon Schäfer | 17 Aug 20:26 2015
Picon

Re: Nomenclature (of) improvements



On 08/17/2015 07:30 PM, 'sreque' via scala-debate wrote:
On my very first use of string interpolation I needed to embed quotes. After ~15 minutes of Googling I resigned in frustration and created a variable q = "\"" so that I could embed quotes as $q. In my opinion, interpolation as implemented is a little broken and in need of same basic fixes to put it on par with string interpolation in other languages such as Ruby.
While it is not nice that one can't escape quotes with a backslash, it took me only ~5 seconds to google for `scala string interpolation embed quote` and it found lots of StackOverflow questions about that problem and even a ticket on the Scala tracker.

On Sunday, August 9, 2015 at 3:21:36 PM UTC-7, Martin wrote:
I would argue that the "bottom up strategy" is better than the "like X
but with exceptions" one. I can understand one can be of different
opinions here. But in the end I think our time is better spent on
other improvements. "If it ain't broke don't fix it."

 - Martin

On Sun, Aug 9, 2015 at 2:33 PM, Kevin Wright <kev.lee... <at> gmail.com> wrote:
>
> On 9 Aug 2015 22:11, "martin odersky" <martin.... <at> epfl.ch> wrote:
>>
>> On Sun, Aug 9, 2015 at 1:43 PM, Kevin Wright <kev.lee... <at> gmail.com>
>> wrote:
>> >
>> >
>> > On 9 August 2015 at 21:34, martin odersky <martin.... <at> epfl.ch>
>> > wrote:
>> >>
>> >> On Sun, Aug 9, 2015 at 12:16 PM, Rex Kerr <ich... <at> gmail.com> wrote:
>> >> > Any feature that encourages widespread use of `A::N` and `(A..N)` as
>> >> > variable names is a bad feature in my book (or at least that counts
>> >> > as a
>> >> > point against it).
>> >> >
>> >> > Backticks are slightly prettier than braces, I agree, but they have a
>> >> > huge
>> >> > advantage which is that they trivially nest.  Adding slightly
>> >> > prettiery
>> >> > syntax that does less than what we already can do isn't a very good
>> >> > use
>> >> > of
>> >> > the complexity budget.
>> >> >
>> >> I very much agree. People will use the backticks liberally, which
>> >> means that there are now two
>> >> ways to interpolate these identifiers. IMO not clear whether that's
>> >> desirable. Also, I think there are many better uses to spend our
>> >> complexity budget (supposing there's anything left in it).
>> >>
>> >>  - Martin
>> >>
>> >
>> >
>> > This versus the complexity budget for users.  Right now we have two
>> > forms of
>> > identifier... that which can be used anywhere else and the restricted
>> > form
>> > available in interpolation.
>> >
>> > Interpolation breaks the rule that "an identifier can be made valid
>> > ANYWHERE
>> > so long as you back-quote it" (e.g. unusually named identifiers, or in
>> > pattern matching)
>> > In my mind, my proposal has always been about reducing the surprise of
>> > interpolation breaking this rule, and making one part of the language
>> > conceptually easier to understand.
>> >
>> But we agree that not all identifiers can be legal in interpolation.
>> So we do have two syntactic classes of identifiers. My strategy re
>> complexity is to make the string interpolation class as simple as
>> possible. If I interprete you correctly, yours is to make the delta
>> between normal and string identifiers as small as possible. But that
>> delta is still large. Currently it means: No symbols, no backticks, no
>> dollar signs. (I would have preferred no underscores either but that
>> ship has sailed, apparently).
>>
>> - Martin
>>
>
> Absolutely, yes, closing the delta is exactly my proposal. I disagree that
> it would still leave a large delta though.
>
> The main benefit I see with backticks is their ability to make any
> identifier valid regardless of context. They're used this way in other parts
> of the language and, as such, are an intuitive mechanism to close the delta
> completely.
>
> We're already used to identifiers being context-specific, as in pattern
> matching. So this is just another place where backticks could be used as a
> context override.
>
>>
>> >
>> >>
>> >> >
>> >> >
>> >> > On Sun, Aug 9, 2015 at 3:07 AM, Kevin Wright
>> >> > <kev.lee... <at> gmail.com>
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >> SIP-11 specifies:
>> >> >>
>> >> >> '$' letter { letter | digit }
>> >> >>
>> >> >>
>> >> >> Whereas the actual behaviour...
>> >> >>
>> >> >> scala> val with_underscore = "wibble"
>> >> >> with_underscore: String = wibble
>> >> >>
>> >> >> scala> s"interpolating $with_underscore into string"
>> >> >> res0: String = interpolating wibble into string
>> >> >>
>> >> >>
>> >> >> So the cat is already out of the bag for underscores!  That leaves
>> >> >> symbolic method names, and hybrids such as unary_!
>> >> >>
>> >> >> Something like this...
>> >> >>
>> >> >> val :: = "coloncolon"
>> >> >> s":: evaluates to $`::`"
>> >> >>
>> >> >>
>> >> >> Improved handling of names containing symbols was my actually
>> >> >> original
>> >> >> motivation behind this, as in.
>> >> >>
>> >> >> val `A..N` = synTypes.mkString(", ")
>> >> >> val `A::N` = (synTypes :+ "HNil") mkString "::"
>> >> >> val `(A..N)` = if (arity == 1) "Tuple1[A]" else
>> >> >> synTypes.mkString("(",
>> >> >> ",
>> >> >> ", ")")
>> >> >>
>> >> >> s"implicit def hlistTupler${arity}[${`A..N`}] : Aux[${`A::N`},
>> >> >> ${`(A..N)`}] = ..."
>> >> >>
>> >> >>
>> >> >> which can be simplified to
>> >> >>
>> >> >> s"implicit def hlistTupler$`arity`[$`A..N`] : Aux[$`A::N`,
>> >> >> $`(A..N)`] =
>> >> >> ..."
>> >> >>
>> >> >>
>> >> >>
>> >> >> Thus avoiding the "death of a thousand braces"!
>> >> >>
>> >> >> Essentially, backticks enable ANY valid identifier to be used with
>> >> >> interpolation.
>> >> >> Just as with back-quoting an identifier in pattern matching,
>> >> >> anything
>> >> >> could be back-quoted in interpolation, whether or not it was
>> >> >> originally
>> >> >> defined with backquotes.
>> >> >> This includes symbolic names and those starting with an underscore.
>> >> >> It
>> >> >> even works on regular alphanumerics (where they make a cleaner
>> >> >> delimiter
>> >> >> than braces):
>> >> >>
>> >> >> val qual = "some"
>> >> >> s"I am $qualbody" //invalid
>> >> >> s"I am ${qual}body" //clumsy
>> >> >> s"I am $`qual`body" //with back-quotes
>> >> >>
>> >> >> --
>> >> >> 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... <at> googlegroups.com.
>> >> >> For more options, visit https://groups.google.com/d/optout.
>> >> >
>> >> >
>> >> > --
>> >> > 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... <at> googlegroups.com.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >>
>> >> --
>> >> Martin Odersky
>> >> EPFL
>> >
>> >
>> >
>> >
>> > --
>> > Kevin Wright
>> > mail: kevin.... <at> scalatechnology.com
>> > gtalk / msn : kev.lee... <at> gmail.com
>> > quora: http://www.quora.com/Kevin-Wright
>> > google+: http://gplus.to/thecoda
>> > twitter: <at> thecoda
>> > vibe / skype: kev.lee.wright
>> > steam: kev_lee_wright
>> >
>> > "My point today is that, if we wish to count lines of code, we should
>> > not
>> > regard them as "lines produced" but as "lines spent": the current
>> > conventional wisdom is so foolish as to book that count on the wrong
>> > side of
>> > the ledger" ~ Dijkstra
>> >
>> > --
>> > 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... <at> googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Martin Odersky
>> EPFL
>
> --
> 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... <at> googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Martin Odersky
EPFL
--
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.

--
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.

Thomas Adkins | 15 Aug 19:13 2015
Picon

Comparison of Scala API with Java 8 API to solve n-queen problem

Professor Odersky gives an elegant solution of the n-queen problem both in his book Programming in Scala and a very similar one in his Coursera course.  I have tried and tried to repeat these results in Java 8, without success.  First, I translated the for comprehension into its flatmap/map equivalent in Scala.  Then, I attempted to code the result using the Java 8 API.  Here is the Scala flatmap/map version of the critical part:

def search_queens(size: Int): List[List[Int]] = {

n = size

def place_queens(k: Int): List[List[Int]] = {

if (k == 0) return List(List())

else

place_queens(k-1).flatMap(

queens =>

(0 until n).filter(col =>

isSafe(col, queens)).map(col => col::queens))

}

place_queens(8)

}

How can this be coded in the Java 8 API? I don't care if you have to "cheat" and use raw types to get past the compiler's inflexibility, I just want to see if this is possible.  So far, I've spent a day and a half without success.  A common criticism of Scala is its type system's obscurity, but just look at Java 8's stream types!!


 

--
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 | 8 Aug 07:41 2015
Picon

Nomenclature (of) improvements


It looks like I must write a SIP to demonstrate that s"hello, \"$world\"" is benign syntax.

But does this syntax tweak really warrant its own SIP?

It's merely supplemental to SIP-11.

It should be designated SUP-11. It's just a SIP-SUP.

Even SIP-25 is only a corrective supplement to SID-4. It could be called SUDS-4, as it cleans up the previous effort.

One advantage of the SUP-11 nomenclature is that it reduces the burden of proof: it amends a useful feature, and needs only show that the amendment is useful and not harmful.

The intention is to avoid SIDS, a syndrome in which the proposal is put down and never resuscitated.


--
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.
Owen | 1 Aug 21:25 2015
Picon

Thoughts on member initialization order

One of the great things about Scala is the ability to share information back and forth between a trait and its implementation:

trait Super { val x: Int val y = x + 1 val z: Int } trait Sub extends Super { lazy val x = 2 val z = y * 7 }

(a silly example but you get the idea).

This is one of the things that I miss the most when I have to program in Java (you can fake it in Java but it's not pretty).

Note however that, due to member initialization order (all members of Super are initialized before all members of Sub), this requires lazy vals in Sub. There are a few disadvantages introduced whenever lazy vals are used:

  • The compiler/IDE won't catch cyclic dependencies for you, leading to a potential stack overflow (with strict vals, the IDE warns you of a forward reference).
  • Either you must take care that the lazy vals are evaluated on the correct thread, or introduce synchronization.
  • Synchronization used by the compiler for the evaluated state of the lazy val can introduce deadlocks.
  • Potentially there is a performance impact though I'm not sure if this matters in practice.
  • Some lazy vals may have needed side-effects; if you accidentally fail to evaluate them, the compiler/IDE won't catch this for you (unless they are private, which is impossible for this purpose).
  • Most important: There is no self-documentation as to what is allowed to depend on what (In the example above, `x` is not allowed to depend on `y`, but this requires a comment in explanation -- the member signatures won't make this clear).

For these reasons, there are potential benefits to being able to have 2-way information sharing between a trait and its implementation without using lazy vals. The difficult question is how to achieve that.

If you look at the example above, you will see that x, y, and z have to be written in some order. Actually, this order turns out to be inconsequential to the behavior of the code, but nevertheless you have to write them in an order.

The language could include, for backward compatibility, a new keyword ord that can annotate members:

trait Super { ord val x: Int ord val y = x + 1 ord val z: Int }

An ord val must be overridden by an ord val or by a lazy val:

trait Sub extends Super { ord val x = 2 ord val z = y * 7 }

A simple translation to current Scala can be used to implement ord in the compiler:

ord val foo: Type (abstract)

becomes
val foo: Type (abstract) foo
and

ord val foo: Type = initializer

becomes
lazy val foo: Type = initializer foo

It would be a compiler error for any of the participating traits/classes in a mixin to declare a pair of ord vals in a different order in which that pair appears in any other trait/class in the mixin. This ensures that ord val declaration order is a consistent partial ordering. The use of lazy vals for implementation ensures that this will, at runtime, automatically turn into a valid total ordering with no cycles (ie, just checking that each pair is consistent is enough, and the translation to lazy vals takes care of the rest).

It then becomes an IDE/compiler warning (not an error) to forward-reference from an ord val to another ord val, where forward-reference means any reference that is not backwards according to the partial ordering created by all traits/classes in the mixin. In other words, an initializer for an ord val x may only reference an ord val y if there is some trait/class in the mixin that declares x and declares y and y appears before x.

If trait A in the mixin declares foo as an ord val, trait B in the mixin may also declare foo as an abstract non-ord val, in which case declarations in trait B say nothing about the position of foo in the partial ordering. This allows A to use ord vals to implement a traditional interface-like trait, and it allows you to freely introduce ord vals into code that does not use ord vals. Any statement in B that happens to reference foo takes its own risk in trusting that foo has been initialized, just like in the current system.

--
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 | 27 Jul 21:19 2015
Picon

Coursera gear


I learn so much just from the i18n Coursera emails!

Where can I get the trucker's hat that reads:

Fonksiyon

or maybe

Fonksiyonlar

if it fits?

Turkish is just so urban.

--
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