type confusion :-(

Maybe it has something to do with "A <: X[A]", which implies a
recursive kind of relationship.

On Thu, Jun 3, 2010 at 3:49 PM, Andreas Flierl wrote:
> Hi there,
>
> I am probably confusing myself but I don't understand why the following does not compile:
>
> trait X[A <: X[A]]
> trait Y[A <: X[A]]
> class Z extends X[Z] with Y[Z]
>
> class PimpedX[A <: X[A]](wrapped: A) {
>  def foo = "bar"
> }
>
> def pimpx[A <: X[A]](wrapped: A) = new PimpedX(wrapped)
>
> class Strange[A <: X[A]](v: X[A] with Y[A]) {
>  def woot = pimpx(v).foo
> }
>
>
> The error message is pretty clear:
>
> 10: error: inferred type arguments [X[A] with Y[A]] do not conform to method pimpx's type parameter bounds [A <: X[A]]
>         def woot = pimpx(v).foo
>                    ^
>
> But why is that so? An X[A] with Y[A] surely "is a" X[A], no?
>
> Thanks for any insight.
> Andreas

On Thu, Jun 03, 2010 at 09:49:17PM +0200, Andreas Flierl wrote:
> trait X[A <: X[A]]
> trait Y[A <: X[A]]
>
> class Strange[A <: X[A]](v: X[A] with Y[A]) {
> def woot = pimpx(v).foo
> }

Since A <: X[A], v must be X[X[A]] with Y[X[A]].

> But why is that so? An X[A] with Y[A] surely "is a" X[A], no?

But an X[X[A]] with Y[X[A]] isn't an X[A].

Maybe you meant this:

class Strange[A <: X[A] with Y[A]](v: A) {
def woot = pimpx(v).foo
}

First of all, thanks for looking at this. :)

> On Thu, Jun 03, 2010 at 09:49:17PM +0200, Andreas Flierl wrote:
>> trait X[A <: X[A]]
>> trait Y[A <: X[A]]
>>
>> class Strange[A <: X[A]](v: X[A] with Y[A]) {
>> def woot = pimpx(v).foo
>> }
>
> Since A <: X[A], v must be X[X[A]] with Y[X[A]].
hmm, yeah... ok... this is scary

since I can pass any Z in.. Z must apply there
so if the actual parameter for v is a Z... what is A?
As far as my understanding goes (which obviously not very far), the inferred type for A would be Z. But probably not, because if it were Z, it would work.

>> But why is that so? An X[A] with Y[A] surely "is a" X[A], no?
>
> But an X[X[A]] with Y[X[A]] isn't an X[A].

I would understand that if the A's were the "same". But are they not something different?

... maybe I've written to many A's
let me write the pimpx method with a B (just to confuse myself less) :)

def pimpx[B <: X[B]](wrapped: B) = new PimpedX(wrapped)

it should be possible to put a X[X[A]] with Y[X[A]] in there, shouldn't it?
Since B would be X[A] in that case?

> Maybe you meant this:
>
> class Strange[A <: X[A] with Y[A]](v: A) {
> def woot = pimpx(v).foo
> }

Yeah, meanwhile I found exactly that solution.
Sadly, I still don't understand why the other approach didn't work. :-(

Please pardon my ignorance.

Andreas

> def pimpx[B <: X[B]](wrapped: B) = new PimpedX(wrapped)
>
> it should be possible to put a X[X[A]] with Y[X[A]] in there, shouldn't it?
> Since B would be X[A] in that case?

argl, silly me

if B were X[A] then "wrapped" would have to be of type X[A]
which would mean that X[X[A]] with Y[X[A]] would have to be of type X[A]
which it is not

hi,

it seems that the way i try to use a class alters the way the scala
system does/not detect/report errors. frustrating. admittedly i really
don't know what-the-eff i'm doing when it comes to scala, i'm just a
gadfly so i'll happily take clues as to what neophyte mistake i'm
making (i mean besides the colliding reference that scalac nicely
reports but scala repl doesn't).
thank you!

Scala compiler version 2.8.1.final -- Copyright 2002-2010, LAMP/EPFL

(a)
import scala.xml._
import scala.io._
class Sink // as in Kitchen.
{
def loadFile( filePath : String ) =
{
Source.fromFile( filePath )
}
}

(b)
scala
scala> :load LoadXML.scala
Loading LoadXML.scala...
import scala.xml._
import scala.io._
defined class Sink
scala> new Sink().loadFile( "foo" );
:13: error: value loadFile is not a member of Sink
new Sink().loadFile( "foo" );

vs. (c)
scalac LoadXML.scala
LoadXML.scala:8: error: reference to Source is ambiguous;
it is imported twice in the same scope by
import scala.io._
and import scala.xml._
Source.fromFile( filePath )
^
one error found

the plot thicks:

(a) seemingly no matter what i do in scala with :load, it never works,
even after fixing the error that scalac identified. scala never sees
the method i've defined inside the class.

(b) but if i use scalac and then scala -cp ., then it does work.

wth?!

On Thu, Jan 13, 2011 at 10:29 AM, Alex Boisvert wrote:
> class Sink {  // notice the curly brace at the end of the line

my reaction (a): noooooooooooooooo! it burrrnnnssss!!!

my reaction (b): thank you for the clue. :)

sincerely.

On Thu, Jan 13, 2011 at 10:13 AM, Raoul Duke <raould@gmail.com> wrote:

hi,

it seems that the way i try to use a class alters the way the scala
system does/not detect/report errors. frustrating. admittedly i really
don't know what-the-eff i'm doing when it comes to scala, i'm just a
gadfly so i'll happily take clues as to what neophyte mistake i'm
making (i mean besides the colliding reference that scalac nicely
reports but scala repl doesn't).
thank you!


Scala compiler version 2.8.1.final -- Copyright 2002-2010, LAMP/EPFL

(a)
import scala.xml._
import scala.io._
class Sink // as in Kitchen.
{
 def loadFile( filePath : String ) =
   {
     Source.fromFile( filePath )
   }
}

The issue is that the REPL is more "line-oriented" than scalac and therefore considers "class Sink" separate from the block following it.
One way to make it work is to write:
class Sink {  // notice the curly brace at the end of the line  def loadFile(filePath: String) = { ...} }
alex

And to be more explicit, your original formatting defined an essentially
empty class "Sink," followed by a block, in which a lone method
"loadFile" is defined. Definitions don't have a meaningful result, so
the block yields nothing. If you teak it like so, you'll see that the
method is returned as a promoted function instance:
import scala.xml._

import scala.io._
class Sink // as in Kitchen.
{
def loadFile( filePath : String ) =
{
Source.fromFile( filePath )
}
loadFile _
}

-chris

On 1/13/11 1:36 PM, Raoul Duke wrote:
> On Thu, Jan 13, 2011 at 10:29 AM, Alex Boisvert wrote:
>> class Sink { // notice the curly brace at the end of the line
> my reaction (a): noooooooooooooooo! it burrrnnnssss!!!
>
> my reaction (b): thank you for the clue. :)
>
> sincerely.
>

On Thu, Jan 13, 2011 at 10:56 AM, Chris Lewis wrote:
> And to be more explicit, your original formatting defined an essentially
> empty class "Sink," followed by a block, in which a lone method "loadFile"
> is defined.

when you say to be more explicit, you mean to be more explicit about
how the syntax is interpreted stunningly differently between the repl
and the compiler, right? since it all works just fine for me via the
compiler.

just checking.

On Thu, Jan 13, 2011 at 11:26:03AM -0800, Raoul Duke wrote:
> when you say to be more explicit, you mean to be more explicit about
> how the syntax is interpreted stunningly differently between the repl
> and the compiler, right?

It should be somewhat less than stunning if you have a passing
familiarity with how the language is parsed. There are numerous
situations where how something is parsed depends on the next line.
Lacking the ability to read your mind about what you might type next,
the repl has to assume a valid line is the line.

Console println
"bob"

If it can see everything, that's Console.println("bob"). But
Console.println() is a valid parse given only the first two tokens, and
that is what you will get.

Also, for this reason among others I strongly discourage people from any
curly brace style which divorces the opening brace from the identifier.

// bad
class Foo
{

// good
class Foo {

It is no longer merely a matter of style preference; you make your and
everyone else's life harder with the former.

On Thu, Jan 13, 2011 at 11:40 AM, Paul Phillips wrote:
> Lacking the ability to read your mind about what you might type next,
> the repl has to assume a valid line is the line.

er, so the fact that i'm using :load means there is no way for the
repl to, you know, look at the whole file? at once? and figure out
gosh not what i might type next, but what i did in fact type? already?
in the past? like the compiler does? so i can't actually have a file
that works in the compiler and works in the repl via :load unless i
use a formatting style i don't enjoy? that's worth a billion euro, i'm
sure.

(yes, yes, i'm being a big fat jerk. but for a good cause: usability.)

sincerely.

I was augmenting the previous response by being more explicit about what
was happening. Yes, there are deltas in how the repl handles whitespace.
I can't personally say that's stunning, at least, not in comparison with
other languages providing compilers and repls.

On 1/13/11 2:26 PM, Raoul Duke wrote:
> On Thu, Jan 13, 2011 at 10:56 AM, Chris Lewis wrote:
>> And to be more explicit, your original formatting defined an essentially
>> empty class "Sink," followed by a block, in which a lone method "loadFile"
>> is defined.
> when you say to be more explicit, you mean to be more explicit about
> how the syntax is interpreted stunningly differently between the repl
> and the compiler, right? since it all works just fine for me via the
> compiler.
>
> just checking.
>

The point Paul was making is that even if the compiler has access to all
source lines, there may be different ways to interpret them.

Console println
"bob"

could mean `Console.println("bob")` or `Console.println(); "bob"`.
Given such an ambiguity, the compiler settles on the latter
interpretation. "Usability" may suffer when the latter interpretation
makes more sense to you, but it is just as likely to suffer if it chose
the former.

The compiler might be able to eke out some special cases (e.g. if "bob",
a provably non-side-effecting expression, is just discarded, it was
probably meant as an argument to println), but these would make both the
implementation and the spec more complicated, as well as making it more
difficult for programmers to understand and predict what the compiler
will do, with relatively little benefit.

On 01/13/2011 11:45 AM, Raoul Duke wrote:
> On Thu, Jan 13, 2011 at 11:40 AM, Paul Phillips wrote:
>> Lacking the ability to read your mind about what you might type next,
>> the repl has to assume a valid line is the line.
>
> er, so the fact that i'm using :load means there is no way for the
> repl to, you know, look at the whole file? at once? and figure out
> gosh not what i might type next, but what i did in fact type? already?
> in the past? like the compiler does? so i can't actually have a file
> that works in the compiler and works in the repl via :load unless i
> use a formatting style i don't enjoy? that's worth a billion euro, i'm
> sure.
>
> (yes, yes, i'm being a big fat jerk. but for a good cause: usability.)
>
> sincerely.
>
> .
>

On Thu, Jan 13, 2011 at 11:45:51AM -0800, Raoul Duke wrote:
> (yes, yes, i'm being a big fat jerk. but for a good cause: usability.)

There is a simple fact about humans: if you behave like a "big fat jerk"
it will make me less inclined to do whatever it is you want. So if you
believe you are serving the cause of usability, then you must also
believe your own ideas would impair it. In which case, deftly played.

(As a side note, the bad behavior of some people actually has no
influence on my time allocation or technical decisions. Maybe it'd be
better if it did, but I guess people who think this is how you do things
aren't likely to be deterred by a few failures.)

On Thu, Jan 13, 2011 at 12:10 PM, Aaron Novstrup
wrote:
> The point Paul was making is that even if the compiler has access to all
> source lines, there may be different ways to interpret them.

ok, i can see that.

as for me, the point i'm making is that the repl :load behaves
differently than the compiler, and i don't think it should. (i were
King of the REPLs that i would require the REPL to use something much
more like the same syntax as the compiler, and assume that input is
miltiline until enter is pressed twice or some such. but that's just
me.)

sincerely.

On 01/13/2011 01:31 PM, Raoul Duke wrote:
> as for me, the point i'm making is that the repl :load behaves
> differently than the compiler, and i don't think it should. (i were
> King of the REPLs that i would require the REPL to use something much
> more like the same syntax as the compiler, and assume that input is
> miltiline until enter is pressed twice or some such. but that's just
> me.)

This would be nice as an optional feature and would facilitate some
other common patterns (like implementing both a class and its companion
object). Currently, pressing enter twice has another meaning, so I think
it would have to be optional to avoid confusing existing users.

Unfortunately, I think you just ticked off the actual King of the REPL.

On Thu, Jan 13, 2011 at 1:44 PM, Aaron Novstrup
wrote:
> This would be nice as an optional feature and would facilitate some
> other common patterns (like implementing both a class and its companion
> object). Currently, pressing enter twice has another meaning, so I think
> it would have to be optional to avoid confusing existing users.

sure, what's done is done and shouldn't be changed willy-nilly. more
thought and study and trial and error would need to be done based on
what i'm getting at before considering making changes. still, i think
the current situation is significantly painful, enough that i think it
would be better to man up to the usability problem and flip the switch
& change it to something better in some not-too-far-off future release
of scala.

sincerely.

On Thu, Jan 13, 2011 at 12:10 PM, Aaron Novstrup <anovstrup@stottlerhenke.com> wrote:

The point Paul was making is that even if the compiler has access to all
source lines, there may be different ways to interpret them.

Console println
"bob"

could mean `Console.println("bob")` or `Console.println(); "bob"`.
Given such an ambiguity, the compiler settles on the latter
interpretation.

Ah, but no, it doesn't:

scala> object x {
     |        def y {
     |        Console println
     |        "bob"
     |        }
     | }
defined module x

scala> x.y
bob

scala>

The applicable syntax rule is "A single new line token is accepted
... after an infix operator, if the first token on the next line can start an expression"

You need *two* new lines to get "the latter interpretation":

scala> object x {
     |        def y {
     |        Console println
     |
     |        "bob"
     |        }
     | }
defined module x

scala> x.y


scala>

"Usability" may suffer when the latter interpretation
makes more sense to you, but it is just as likely to suffer if it chose
the former.

I think you have misunderstood Raoul's point, which is that, while it is understandable the REPL interprets it differently from the compiler because it's interactive, :load is *not* interactive so it ought to interpret it
the way the compiler does.

-- Jim
 

The compiler might be able to eke out some special cases (e.g. if "bob",
a provably non-side-effecting expression, is just discarded, it was
probably meant as an argument to println), but these would make both the
implementation and the spec more complicated, as well as making it more
difficult for programmers to understand and predict what the compiler
will do, with relatively little benefit.

 

On 01/13/2011 11:45 AM, Raoul Duke wrote:
> On Thu, Jan 13, 2011 at 11:40 AM, Paul Phillips <paulp@improving.org> wrote:
>> Lacking the ability to read your mind about what you might type next,
>> the repl has to assume a valid line is the line.
>
> er, so the fact that i'm using :load means there is no way for the
> repl to, you know, look at the whole file? at once? and figure out
> gosh not what i might type next, but what i did in fact type? already?
> in the past? like the compiler does? so i can't actually have a file
> that works in the compiler and works in the repl via :load unless i
> use a formatting style i don't enjoy? that's worth a billion euro, i'm
> sure.
>
> (yes, yes, i'm being a big fat jerk. but for a good cause: usability.)
>
> sincerely.
>
> .
>

On Thu, Jan 13, 2011 at 1:31 PM, Raoul Duke <raould@gmail.com> wrote:

On Thu, Jan 13, 2011 at 12:10 PM, Aaron Novstrup
<anovstrup@stottlerhenke.com> wrote:
> The point Paul was making is that even if the compiler has access to all
> source lines, there may be different ways to interpret them.

ok, i can see that.

as for me, the point i'm making is that the repl :load behaves
differently than the compiler, and i don't think it should. (i were
King of the REPLs that i would require the REPL to use something much
more like the same syntax as the compiler, and assume that input is
miltiline until enter is pressed twice or some such. but that's just
me.)

sincerely.

It seems to me that would make the usability of the REPL suffer ... a lot; we would need to enter nearly twice as many newlines as we do now.

[The longer paragraph is not directed at you Aaron.]

On Thu, Jan 13, 2011 at 01:44:32PM -0800, Aaron Novstrup wrote:
> This would be nice as an optional feature and would facilitate some
> other common patterns (like implementing both a class and its
> companion object).

That's why it's an open ticket. For a long time.

https://lampsvn.epfl.ch/trac/scala/ticket/321

Hard to fix everything at once. People should try reading every open
ticket once in a while. It's doable: I've done it several times. These
discussions, such as they are, always involve failure to recognize the
scope I'm trying to cover. If people aren't even willing to research
what tickets exist on a subject before giving usability lessons the
words will have little relevance. We deal with complicated,
interlocking structures with lots of moving parts. What is "obvious" or
"easy" in isolation is rarely so with the full context. But even the
genuinely obvious and easy ones compete for attention amongst a very
crowded field.

On Thu, Jan 13, 2011 at 2:39 PM, Paul Phillips wrote:
> That's why it's an open ticket.  For a long time.
>  https://lampsvn.epfl.ch/trac/scala/ticket/321

i think there are several issues being conflated here.

(1) that ticket doesn't point out that :load doesn't have to be tied
to the one-line-at-a-time-at-the-prompt style. so the ticket doesn't
help with my original concern, it just reinforces the point that
whoever is working on repl :load doesn't "get" the lack of usability
of :load at all. which doesn't, as far as i know, interact in any way
what-so-ever with anything else in the universe let alone scala
because if :load were fixed to work like the compiler then it wouldn't
break anything that works with it now, and it would - gosh - actually
start working for things any newbie who hasn't been waterboarded by
scala would want it to work for.

(2) yes, the question of how to fix the
one-line-at-a-time-at-the-prompt-style is probably a bigger more hairy
one. but i think it is a worthy subject matter wrt usability. and the
ticket doesn't really say anything about this or what any related
wider concerns are. it just says "that is the way things are now so go
poke a stick in your eye and like it." oh boy that sure sounds like a
product i want to adopt whole-heartedly.

(3) when you take on the job of being the czar of something, you
should take on the job of listening to the whiners when they have a
point. /their/ job in life is to get a tool that works and get on with
their product, not to read every gosh-darned open ticket; that is the
job of the maintainers.

(4) at the very least if :load isn't ever going to be fixed to not be
so painfully apparently obstructive to progress, the blankety-blank
repl could spit out a note that "gosh i don't actually support the
same syntax that the compiler does, haha" so that people aren't just
completely freaking freaked out by the inconsistent behaviour across
tools.

sincerely.
$0.01 and ever decreasing, apparently.

On Thu, Jan 13, 2011 at 2:39 PM, Paul Phillips <paulp@improving.org> wrote:

[The longer paragraph is not directed at you Aaron.]

On Thu, Jan 13, 2011 at 01:44:32PM -0800, Aaron Novstrup wrote:
> This would be nice as an optional feature and would facilitate some
> other common patterns (like implementing both a class and its
> companion object).

That's why it's an open ticket.  For a long time.

 https://lampsvn.epfl.ch/trac/scala/ticket/321

Hard to fix everything at once.  People should try reading every open
ticket once in a while.  It's doable: I've done it several times.  These
discussions, such as they are, always involve failure to recognize the
scope I'm trying to cover.  If people aren't even willing to research
what tickets exist on a subject before giving usability lessons the
words will have little relevance.  We deal with complicated,
interlocking structures with lots of moving parts.  What is "obvious" or
"easy" in isolation is rarely so with the full context.  But even the
genuinely obvious and easy ones compete for attention amongst a very
crowded field.

I for one greatly appreciate the scope you are trying to cover and what you have covered. At the same time, this is scala-*user*, and there is no way that people posting here are going to know what you know, and it's an extraordinary expectation that they will have read all the open tickets. It really isn't true that these discussions fail to recognize the scope you are trying to cover, because they aren't *about* that -- people ask questions and make suggestions based on their own limited perspective; they may not even know that you exist or what you do. And as the use of Scala grows, that will be more and more true.

In any case, saying that there's already a ticket for that and it's low priority or involves a ton of complicated work and you're swamped with more pressing issues is always a good response that I think most people can appreciate. But it doesn't mean, and shouldn't mean, that they won't come back and ask for yet more pie-in-the-sky changes for which there are already open tickets.

-- Jim

On Thu, Jan 13, 2011 at 3:02 PM, Jim Balter wrote:
> In any case, saying that there's already a ticket for that and it's low
> priority or involves a ton of complicated work and you're swamped with more
> pressing issues is always a good response that I think most people can
> appreciate.

well... depending on how that response is delivered... :-) (pot.
kettle. black. here. yes.)

makes me think that the oss world needs a site where issues can have
cash bounties associated with them. so if something bugs me a lot, i
can make the ticket and include a description of the solution i want,
and then say "and i'll pay ten bucks to whoever fixes it". and then
other people can pile more $ on if they care as well.

the good thing is that it would not have to lead to the projects being
controlled entirely by the people with the most cash, since the
maintainers would still be the final arbiters of what patches get
taken in or not.

but it would perhaps give another avenue to getting things done?

sincerely.

On 2011-01-13 3:53 PM, "Raoul Duke" <raould@gmail.com> wrote:
>
> i think there are several issues being conflated here.

You forgot #5: Your sense of good coding style is... uhm... needs work. You think it looks better that way? Really? Next thing you'll be saying is it looks better with semi-colons at the end of each line (oh, wait, I see one of those too!)

On Thu, Jan 13, 2011 at 3:19 PM, Derek Williams <derek@nebvin.ca> wrote:

On 2011-01-13 3:53 PM, "Raoul Duke" <raould@gmail.com> wrote:
>
> i think there are several issues being conflated here.

You forgot #5: Your sense of good coding style is... uhm... needs work. You think it looks better that way? Really? Next thing you'll be saying is it looks better with semi-colons at the end of each line (oh, wait, I see one of those too!)

That's like saying that one's sense of good taste needs work if they prefer chocolate to vanilla, or v.v. Or telling people they have poor judgment if they use [vi or emacs -- whichever one you don't]. All Raoul said is "a formatting style i don't enjoy" -- do you really have some argument, from principles of software design, that he *should* enjoy it?

-- Jim

On Thu, Jan 13, 2011 at 3:19 PM, Derek Williams wrote:
> You forgot #5: Your sense of good coding style is... uhm... needs work. You
> think it looks better that way? Really? Next thing you'll be saying is it
> looks better with semi-colons at the end of each line (oh, wait, I see one
> of those too!)

yeah, i can't deny that! i'm craaaaazy (in a bad way)!

(i don't really want semicolons, but it is a hard habit to shake just
yet. and don't get me started on how last i heard semicolon inference
in scala was actually somewhat fraught with unfun edge-cases, which
scares me.)

but at any rate, i think that any computer system that makes me bend
to its will when it comes to where the curly brackets go is just plain
sad. the machines are supposed to be flexible enough to bend to /our/
will.

sincerely.

On 2011-01-13 4:35 PM, "Jim Balter" <Jim@balter.name> wrote:
>
> Or telling people they have poor judgment if they use [vi or emacs -- whichever one you don't].

If he uses vi I'm really gonna lose it!

On Thu, Jan 13, 2011 at 3:32 PM, Raoul Duke <raould@gmail.com> wrote:

On Thu, Jan 13, 2011 at 3:19 PM, Derek Williams <derek@nebvin.ca> wrote:
> You forgot #5: Your sense of good coding style is... uhm... needs work. You
> think it looks better that way? Really? Next thing you'll be saying is it
> looks better with semi-colons at the end of each line (oh, wait, I see one
> of those too!)

yeah, i can't deny that! i'm craaaaazy (in a bad way)!

(i don't really want semicolons, but it is a hard habit to shake just
yet. and don't get me started on how last i heard semicolon inference
in scala was actually somewhat fraught with unfun edge-cases, which
scares me.)

The rules are pretty simple and usually do the right thing.

but at any rate, i think that any computer system that makes me bend
to its will when it comes to where the curly brackets go is just plain
sad. the machines are supposed to be flexible enough to bend to /our/
will.

sincerely.

 
By that criterion, every computer system is just plain sad, as they all have syntactic and semantic rules that we must obey. Scala actually provides tremendous flexibility compared to most other languages, including, ahem ... making semicolons optional.

On Thu, Jan 13, 2011 at 3:41 PM, Derek Williams wrote:
>> Or telling people they have poor judgment if they use [vi or emacs --
>> whichever one you don't].
> If he uses vi I'm really gonna lose it!

eclipse, then emacs, in roughly that order :-)

dark chocolate over milk. (a position i used to vehemently hold the
other way 'round, but i guess i'm getting long in the tooth.)

toilet paper should roll down, not up.

chew with mouth closed.

red wine over white, for the most part.

cookies and cream is god's own perfect ice cream flavour.

'true faith' >> 'bizarre love triangle'.

stick over automatic.

almost anything over any form of windows.

functional before imperative.

etc.

sincerely.

On Thu, Jan 13, 2011 at 3:53 PM, Jim Balter wrote:
> The rules are pretty simple and usually do the right thing.
> By that criterion, every computer system is just plain sad, as they all have
> syntactic and semantic rules that we must obey. Scala actually provides
> tremendous flexibility compared to most other languages, including, ahem ...
> making semicolons optional.

i'm happy if it does, believe me.

tho, i'm not happy if it is doggedly pathetically pedantic about curly
brackets. *which the compiler part of it isn't* thank goodness.

sincerely.

Raoul,
You may be happy to know that an improved Eclipse REPL is in the works which would allow binding two different keystroke combinations for "this is multiline, don't parse until I'm done," and "parse away!".  For instance, you could bind shift+enter for the first one (corresponding to a hard break but not a new paragraph in many rich text editors) and enter for the second. 
I'm not sure if this addresses your issue, however, since you are talking about :load, which would behave the same in such an enhanced REPL.
Donna
On Thu, Jan 13, 2011 at 10:31 PM, Raoul Duke <raould@gmail.com> wrote:

as for me, the point i'm making is that the repl :load behaves
differently than the compiler, and i don't think it should. (i were
King of the REPLs that i would require the REPL to use something much
more like the same syntax as the compiler, and assume that input is
miltiline until enter is pressed twice or some such. but that's just
me.)

sincerely.

If I can vote of one future feature, it would be "up arrow" recalling previous expression history. I am a bad typist, and I am plagued with typos that cause me to type expressions all over again in the Eclipse REPL. The command-line REPL has the expression recall, and I can really feel the difference.
Brian Maso

Sent from my iPhone
On Jan 14, 2011, at 1:49 AM, Donna Malayeri <lindydonna@gmail.com> wrote:

Raoul,
You may be happy to know that an improved Eclipse REPL is in the works which would allow binding two different keystroke combinations for "this is multiline, don't parse until I'm done," and "parse away!".  For instance, you could bind shift+enter for the first one (corresponding to a hard break but not a new paragraph in many rich text editors) and enter for the second. 
I'm not sure if this addresses your issue, however, since you are talking about :load, which would behave the same in such an enhanced REPL.
Donna
On Thu, Jan 13, 2011 at 10:31 PM, Raoul Duke < (raould [at] gmail [dot] com> wrote:

as for me, the point i'm making is that the repl :load behaves
differently than the compiler, and i don't think it should. (i were
King of the REPLs that i would require the REPL to use something much
more like the same syntax as the compiler, and assume that input is
miltiline until enter is pressed twice or some such. but that's just
me.)

sincerely.

Interestingly, pasting the Console-println-bob example in the REPL via paulp's great Ctrl-V feature, causes it to be evaluated as by the compiler.
scala> Console println "bob"bob

On Thu, Jan 13, 2011 at 6:02 PM, Jim Balter <Jim@balter.name> wrote:

On Thu, Jan 13, 2011 at 2:39 PM, Paul Phillips <paulp@improving.org> wrote:

[The longer paragraph is not directed at you Aaron.]

On Thu, Jan 13, 2011 at 01:44:32PM -0800, Aaron Novstrup wrote:
> This would be nice as an optional feature and would facilitate some
> other common patterns (like implementing both a class and its
> companion object).

That's why it's an open ticket.  For a long time.

 https://lampsvn.epfl.ch/trac/scala/ticket/321

Hard to fix everything at once.  People should try reading every open
ticket once in a while.  It's doable: I've done it several times.  These
discussions, such as they are, always involve failure to recognize the
scope I'm trying to cover.  If people aren't even willing to research
what tickets exist on a subject before giving usability lessons the
words will have little relevance.  We deal with complicated,
interlocking structures with lots of moving parts.  What is "obvious" or
"easy" in isolation is rarely so with the full context.  But even the
genuinely obvious and easy ones compete for attention amongst a very
crowded field.

I for one greatly appreciate the scope you are trying to cover and what you have covered. At the same time, this is scala-*user*, and there is no way that people posting here are going to know what you know, and it's an extraordinary expectation that they will have read all the open tickets. It really isn't true that these discussions fail to recognize the scope you are trying to cover, because they aren't *about* that -- people ask questions and make suggestions based on their own limited perspective; they may not even know that you exist or what you do. And as the use of Scala grows, that will be more and more true.

In any case, saying that there's already a ticket for that and it's low priority or involves a ton of complicated work and you're swamped with more pressing issues is always a good response that I think most people can appreciate. But it doesn't mean, and shouldn't mean, that they won't come back and ask for yet more pie-in-the-sky changes for which there are already open tickets.

-- Jim

Interesting indeed. I think CTRL-V is provided by jline. I didn't know scala would process the statement like this. jline doesn't handle well editing content containing a newline but with that said, I think there is potential to correct jline to handle cursor and edit when newlines are part of the content. Once that's done I think we could bind CTRL-J to send a newline to the jline buffer without sending it to scala, and that would be a workaround to edit multi-line scala statements in the REPL.
--Jean-Laurent
From: Naftoli Gugenheim <naftoligug@gmail.com>

Interestingly, pasting the Console-println-bob example in the REPL via paulp's great Ctrl-V feature, causes it to be evaluated as by the compiler.
scala> Console println "bob"bob

You can, and that too is in the works. :)  I agree with you that command history is really important.
Donna

On Fri, Jan 14, 2011 at 7:11 PM, Brian Maso <brian@blumenfeld-maso.com> wrote:

If I can vote of one future feature, it would be "up arrow" recalling previous expression history. I am a bad typist, and I am plagued with typos that cause me to type expressions all over again in the Eclipse REPL. The command-line REPL has the expression recall, and I can really feel the difference.
Brian Maso