gmane.comp.lang.scala

Interview: Scala creator Martin Odersky - The H Half Hour

Simon Ochsenreither — 2012-05-25T12:24:30

Nice interview: 
http://www.h-online.com/open/features/Scala-creator-Martin-Odersky-The-H-Half-Hour-1582445.html

RE: Re: Scope of Scala's implicit class conversion

Ryan Hendrickson — 2012-05-24T15:42:01

'Typed as if' != 'evaluated as if'. It seems to me that the language in 6.4 that you point out is just talking about how typing should proceed for e.x, but e.x can't be typed if x is not a member of the type of e. So the 7.3 rules translate the expression into one that can be typed, and then v(e).x is typed as if it were { val y = v(e); y.x } per the 6.4 rules. I'm not terribly confident I'm not missing some implication of the rest of the spec, though.






(please forgive me my corporate legal disclaimer)

----------------------------------------

This message is intended exclusively for the individual(s) or entity to
which it is addressed. It may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. 
If you are not the named addressee, you are not authorized to read, 
print, retain, copy or disseminate this message or any part of it. 
If you have received this message in error, please notify the sender 
immediately by e-mail and delete all copies

Re: Re: Scope of Scala's implicit class conversion

Som Snytt — 2012-05-24T08:18:27

It's way past midnight here, so no good can come of this, but by 6.4
Designators:

For other expressions e, e.x is typed as if it was { val y = e; y.x }, for

Immediately, this has consequences for how the prefix is typed:

The expected type of a designator’s prefix is always undefined.

But that would also imply that the e in 7.3 is y from 6.4, and goes to the
OP's intuition that the prefix should be evaluated before y is wrapped in a
thunk for the implicit conversion v(y) for v(y).x  where v(=>Y).

On Wed, May 23, 2012 at 4:26 PM, Ryan Hendrickson <
Ryan.Hendrickson< at >bwater.com> wrote:

RE: Re: Scope of Scala's implicit class conversion

Ryan Hendrickson — 2012-05-23T23:26:27

Ah, forgive me. In that case, the language you're looking for is in Section 7.3, in the list of the three situations in which views are applied:

2. In a selection e.m with e of type T , if the selector does not denote a member
of T. In this case, a view v is searched which is applicable to e and whose result
contains a member named m. The search proceeds as in the case of implicit
parameters, where the implicit scope is the one of T. If such a view is found,
the selection e.m is converted to v(e).m.

So the compiler can only generate something that is semantically equivalent to v(e).m, and as you've demonstrated, when by-name parameters are involved

  val x = e
  v(x).m

is not semantically equivalent to v(e).m.







(please forgive me my corporate legal disclaimer)

----------------------------------------

This message is intended exclusively for the individual(s) or entity to
which it is addressed. It may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt

Re: Scope of Scala's implicit class conversion

ron — 2012-05-23T23:20:51

I understand what happens, and also by-name parameters, but it is
still not clear why does the compiler choose to apply the implicit
conversion to the whole expression (putting it wholly into the by-name
param), versus generating code to evaluate the result of the
expression and putting only the result into the conversion. Maybe this
is something trivial, but still it would be nice if someone could
point it out exactly.

BR,
Robin

On máj. 24, 01:02, Ryan Hendrickson <Ryan.Hendrick...< at >bwater.com>
wrote:

RE: Scope of Scala's implicit class conversion

Ryan Hendrickson — 2012-05-23T23:02:00

You don't have a largest/smallest problem here; in fact, what you describe is *almost* equivalent to what the compiler is doing. The exact equivalent would be:

  toXXX((new A).a.b).xxx

Because your toXXX method takes a by-name parameter (and the XXX constructor does as well), Scala never needs to invoke the body of the thing being converted in order to yield the result 42. If you took away the '=>' in toXXX or the XXX constructor, you'd see the aa/bb side effects again. You can find out more by Googling 'scala by-name parameters'.





(please forgive me my corporate legal disclaimer)

----------------------------------------

This message is intended exclusively for the individual(s) or entity to
which it is addressed. It may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. 
If you are not the named addressee, you are not authorized to read, 
print, retain, copy or disseminate this message or any part of it. 
If you have received this messa

Scope of Scala's implicit class conversion

ron — 2012-05-23T22:35:08

Hello List,

Please help me clarify the following (carbon copied from Stackoverflow
http://stackoverflow.com/questions/10727508/scope-of-scalas-implicit-class-conversion#comment13936013_10727508):

Scala seems to apply the implicit class conversion on the largest
possible expression, as in the following example:

----repl----
scala> class B { def b = { println("bb"); true } }
scala> class A { def a = { println("aa"); new B } }
scala> (new A).a.b
aa
bb
res16: Boolean = true

scala> class XXX(b: => Boolean) { def xxx = 42 }
scala> implicit def toXXX(b: => Boolean) = new XXX(b)
scala> (new A).a.b.xxx
res18: Int = 42
----repl----

Which part of the specification addresses this behavior? What prevents
the compiler from converting into val x = (new A).a.b; toXXX(x).xxx ?

Thank you,
Robin

Re: What Differentiates Gosu From Other Languages?

Dave — 2012-05-23T21:21:31


On 23 mei, 20:51, Bill Burdick <bill.burd...< at >gmail.com> wrote:

It's still there, only renamed
http://gosu-lang.org/compare.html

Re: Re: What Differentiates Gosu From Other Languages?

Bill Burdick — 2012-05-23T18:51:35

After looking at the (removed) language comparison chart (
http://web.archive.org/web/20110726124437/http://gosu-lang.org/comparison.shtml),
it seems, to me, like Gosu is similar to Xtend:
http://www.eclipse.org/xtend/  The only problem I have with the current
Xtend version is that closures aren't compatible with SAMs, so you can't
use them with FJ's Function objects, for instance.  I made a patch to help
with that and some of the Xtend maintainers helped with some other issues
involving closures (with casts and such), so that they work "like they
should" in MY Xtend codebase, but it looks like the three changes I use
won't actually be integrated until RC1 (and the integration keeps getting
bumped farther down the line).


Bill


On Wed, May 23, 2012 at 12:58 PM, Dave <dave.mahabiersing< at >hotmail.com>wrote:

Re: What Differentiates Gosu From Other Languages?

Dave — 2012-05-23T17:58:21

http://stackoverflow.com/questions/4975428/whats-the-essential-similarities-and-differences-between-scala-and-gosu-relate

On 23 mei, 19:38, Simon Ochsenreither
<simon.ochsenreit...< at >googlemail.com> wrote:

Re: What Differentiates Gosu From Other Languages?

Simon Ochsenreither — 2012-05-23T17:38:15



Yes, I'm not sure, but it might even predate the F# stuff.

Interesting that they have given up on the Eclipse IDE support, though. 

Independently of the language, Gosu/F#/Scala, I think it really boils down 
to having not just a few, but a lot of type providers.

Looking at the myriad of query/sql/collection APIs out there in the Scala 
ecosystem I really hope that SLICK and type providers are a good value 
proposition for them, so that stuff gets more consistent.

I guess Scala will have few more problems due to not only wanting to have a 
more general system (macros instead of special compiler interfaces), but 
also wanting to support the traditional collection API names and 
integrating it into for comprehensions will be hard.

F# has an interesting approach ... they basically split their collection 
operations between the part that generates SQL and the part which operates 
on the resulting collection.

Re: What Differentiates Gosu From Other Languages?

Erik Post — 2012-05-23T15:41:19


This article seems a bit more to the point:

http://guidewiredevelopment.wordpress.com/2010/11/18/gosus-secret-sauce-the-open-type-system/

 Their 'open type system' sounds like type providers to me, as I understand 
them from http://scalamacros.org/usecases/type-providers.html. Sounds 
pretty cool. Seeing 'driver.DriversLicenses = new 
ArrayList<DriversLicense>()' was less of a herald of awesomeness.

Cheers,
Erik

Re: What Differentiates Gosu From Other Languages?

Tony Morris — 2012-05-23T12:25:20

Well, Scala is pretty complex after all. You should see the flatMap
function! Well, where do I start? Sheesh, I am so overwhelmed right now.
How complex indeed.

On 23/05/12 21:49, Mark Hammons wrote:

Re: What Differentiates Gosu From Other Languages?

Mark Hammons — 2012-05-23T11:49:28

Yeah, this language seems like a winner. I really wish scala developers
dealt with non-complicated things like classloader deadlocks instead of the
dreaded foldLeft and map functions.

On Wed, May 23, 2012 at 1:36 PM, Robert Kirkpatrick <robert< at >eridan.net>wrote:

Re: What Differentiates Gosu From Other Languages?

Robert Kirkpatrick — 2012-05-23T11:36:41

Yes indeed - just as an example:
"we flirt with deadlock every time our special loader does its job"

At least the author plays transparency!

Le 23/05/2012 13:10, Simon Ochsenreither a écrit :

Re: What Differentiates Gosu From Other Languages?

Simon Ochsenreither — 2012-05-23T11:10:34

This is pretty scary: 
http://guidewiredevelopment.wordpress.com/2012/05/09/gosus-inconceivable-non-classloader-take-1/

Re: What Differentiates Gosu From Other Languages?

Robert Kirkpatrick — 2012-05-23T11:07:56

Quite terrible about Scala indeed.
Nevertheless interesting about an "IDE-oriented" language, showing where the Scala competition lies.

Robert.

Le 23/05/2012 12:22, Mark Hammons a écrit :

Re: Scala - a Roadmap

Philippe Lhoste — 2012-05-23T10:56:46

That's what is nice with tabs: just change a setting, and you have indentation fitting 
your preferences, from 1 to 8 (or more!) units, without even changing the source code.


You won't see mixed spaces and tabs in my sources, they are pure tabs, and I am happy with 
this... I am OK with space-only indentation, that's what we use at work (with three 
spaces...), but I still find them less convenient.
Both ways are OK, as long as they are consistently use, the real evil is indeed in mixing 
spaces and tabs.


Sigh, yes, it is nightmarish, I admit it. But don't put the blame on tabs, put the blame 
on lack of tools to enforce any policy they could have chosen. Hey, you can open a file 
with 3 spaces indentation, have your editor remaining in default 4 spaces (if that's your 
default) and introduce inconsistent indentation in the file without noticing. In general, 
not in the same function (might be too visible) but perhaps in a new function, a new 
class, etc.

To please everybody, you can make the compiler

Re: What Differentiates Gosu From Other Languages?

Mark Hammons — 2012-05-23T10:22:57

I don't understand most programmers' aversion to functional languages.
Yeah,  it's tough to do at first, but so is every othdr paradigm. This
article is pretty terrible if you ask me.
On 2012 5 23 12:02, "Simon Ochsenreither" <
simon.ochsenreither< at >googlemail.com> wrote:

What Differentiates Gosu From Other Languages?

Simon Ochsenreither — 2012-05-23T10:02:29

Interesting read, also references Scala: 
http://guidewiredevelopment.wordpress.com/2012/02/27/what-differentiates-gosu-from-other-languages/

Re: Should a self-referential val/var declaration really compile?

Jon Van Caneghem — 2012-05-23T00:11:51

Ah Snap, Jesper!  You just got gaftered.
http://gafter.blogspot.com/2006/11/reified-generics-for-java.html?showComment=1203883620000#c8374851026588442066