Re: Scala coding guidelines needed? NOT formatting style!

Mats Henricson-2 wrote:
> 
> Erik Engbrecht wrote:
>> If you go back to my original post, I was agreeing with Tony and Paul
>> that there shouldn't be some sort of "official" style guide linked off
>> of the main Scala website.  I would also expect a style guide to be more
>> than a collection of "don't do that"'s, and even if it was just that, I
>> think if it reached any depth there would be some strong differences of
>> opinion.  That's why I don't think it should be official.
> 
> I think this issue could be solved by having two levels of coding
> guidelines;
> 
> * Rules, which we could all agree with, and
> * Recommendations, which are more a matter of style, or areas
>   where there isn't agreement within the community, or where there
>   are well known exceptions
> 
> IMNSHO, this is the only way to get an official, i.e. respected by
> all, coding guideline.
> 
> If coding guidelines are codified in one (or two) statement each
> (with accompanying examples and text), instead of vague but well
> meaning texts, then it is also so much more simple to know what
> exactly the guideline says, and whether people agree with it or
> not.
> 
> Mats
> 

Possible bug in typechecker

For a fortnight I have been dogged by compiler typecheck errors in
code that I think is correct. I have narrowed down a small test case,
which I believe should typecheck, that illustrates the problem.

Either (a) would someone please explain why this isnt typesafe (and
ideally how to correct it), or (b) should I report this in trac?

trait Dimension {
	type ContainerType <: Container[X] forSome {type X <: Dimension}
}
object D1 extends Dimension {
	type ContainerType = Container[D1.type]
}
class Container[D <: Dimension] {
	def op(c: Container[D])
}
abstract class Context[Dim <: Dimension] {
	val c1: Dim#ContainerType
	val c2: Dim#ContainerType
	
/*
[error]  found   : Dim#ContainerType
[error]  required: Container[X] where type X <: Dimension
[error]         def test() = c1.op(c2)
[error]                            ^
*/
	def test() = c1.op(c2)
}

Re: Scala vs. X10

Re: Scala vs. X10

Now that the discussion is on X10 versus Scala: Fortress is also a language
one can compare with (if it has not been discussed earlier). I notice
in particular that Fortress has special syntax for sets, lists and
maps. I can see that Scala's library syntax for sets, lists and maps
makes these concepts simple. However, has it been considered to have
special syntax for these data structures?

I would like in this context to point to VDM, a formal specification
language that very early on (early 70ties) had special syntax for
sets, lists and maps, and contained as a subset an ML-like imperative
+ functional programming language (plus pre/post conditions and
quantifiers):

  http://en.wikipedia.org/wiki/Vienna_Development_Method
  http://www.vienna.cc/e/evdm.htm

Klaus

Re: Scala vs. X10

Re: Scala vs. X10

Re: Scala coding guidelines needed? NOT formatting style!

jonathan mawson wrote:
> That sounds sane to me. Surely there are guidelines that everyone must agree
> with? "Use val rather than var whenever possible." "Don't extend Application
> when performance matters" "Understand that Range uses lazy evaluation - and
> that it is contagious" (Although that one is about to be obsolete.) 
> 
> It isn't a question of "rules" as much as the knowledge that gives you a
> real feel for a language and how to use it safely and efficiently. It's a
> list of Why's rather than of Do's and Don'ts that is needed.

I think "why's" are too vague. Simply because they can't be used
at code reviews. Also, they can't be used for automatic code
inspections, performed by computers. Example:

   Understand that Range uses lazy evaluation - and that
   it is contagious

What is a computer to do with such a rule or recommendation?
It can't possibly know if the author of the code understands
ranges or not. And arguing about this at a manual code review
is dangerous; "You simply don't understand ranges", "Yes I do,
but in this case the laziness don't apply".

Therefore I think do's and don'ts are better, and in this
particular case I would start with something like this:

   Only use ranges when... "something"

If you can't replace "something" with well written text, then
this isn't well understood enough, or well agreed upon enough,
to become a rule or a rec.

My suggestion is to craft rules and recommendations only for
cases that

1. are important - it is better to have five recs too few than
   one rec too many, since petty nitpicking undermines the
   authority of a coding standard
2. are common - really weird corner cases will bite some people,
   but only so rarely that it is not worth the time to bother
   everyone with them
3. are specific - vague well meaning text makes noone happy

Mats

Re: Scala vs. X10

Nightly build logs page nonfunctional

Re: Possible bug in typechecker

Ben,

> abstract class Context[Dim <: Dimension] {
> 	val c1: Dim#ContainerType
> 	val c2: Dim#ContainerType

I think the problem is that the existential X refers (expands to) to different
types for c1 and c2.

Michael