Q/comment re: [ANN] Beta version of Scala 2

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Q/comment re: [ANN] Beta version of Scala 2

Raoul Duke
it is very exciting to see Scala 2 since it tells the world that scala
development is still very alive and well! congratulations on all your
hard work. i see ever more mention of scala on sites like
lambdatheultimate, so that's terrific.

these comments comes after the horses have left the barn, as they say:

A) "In these cases it suffices to enclose the multi-line expression in
parentheses to suppress
the generation of a newline token" ...I think parentheses are getting
to be too overloaded - i'd suggest having using the standard (if
somewhat ugly?) backslash standard a la python etc.

B) some day, i wish you could replace "val" and "var" with words that
differ by more than a single letter for
readability/usability/maintainability. :-)

of course, these comments are of infinitesimal importance in light of
all scala has to offer and continues to accrue!

sincerely.
Reply | Threaded
Open this post in threaded view
|

Re: Q/comment re: [ANN] Beta version of Scala 2

Lex Spoon
Hey Raoul!  Thanks for the thoughts.


> A) "In these cases it suffices to enclose the multi-line expression in
> parentheses to suppress
> the generation of a newline token" ...I think parentheses are getting
> to be too overloaded - i'd suggest having using the standard (if
> somewhat ugly?) backslash standard a la python etc.

I find escapes to be fidgity.  It is easy to get them wrong and thus
cause the compiler to go spew lots of confusing error messages.  It is
easy, for example, to accidentally add a space after the backslash.

Plus, as you say, they look kinda ugly!

Parentheses are not being overloaded in this use.  They are already
used to group an expression together, and that's what they are being
used for when they prevent a line-end from being considered a newline.

Plus, parentheses plus indentation is nice to read, IMHO...  Maybe
I'll change my mind after more experience, but I like it so far.


FWIW, my favorite tweak in this area would be if there was a warning
for incorrect indentation.  That is, this should generate a warning:

        val foo = bar
                + baz

If someone really meant for "+ baz" to be a command by itself, then
they should indent like this:

        val foo = bar
        + baz



> B) some day, i wish you could replace "val" and "var" with words that
> differ by more than a single letter for
> readability/usability/maintainability. :-)

True.  Arguably, they *are* similar concepts, if I wanted to be
stubborn.  :)

What alternative would work well, though?  Maybe "val" and
"mutable val"?  Ick, "mutable val" looks oxymoronic.  Maybe "var" and
"mutable var"?  Or perhaps, given the existence of legacy code using
"var" already, it could be "bind" and "rebindable bind" ??




-Lex


Reply | Threaded
Open this post in threaded view
|

Re: Q/comment re: [ANN] Beta version of Scala 2

Clive Jevons-2
... just a thought on the last point:
const
and
var
?
C

On 14 Jan 2006, at 13:42, Lex Spoon wrote:

> Hey Raoul!  Thanks for the thoughts.
>
>
>> A) "In these cases it suffices to enclose the multi-line  
>> expression in
>> parentheses to suppress
>> the generation of a newline token" ...I think parentheses are getting
>> to be too overloaded - i'd suggest having using the standard (if
>> somewhat ugly?) backslash standard a la python etc.
>
> I find escapes to be fidgity.  It is easy to get them wrong and thus
> cause the compiler to go spew lots of confusing error messages.  It is
> easy, for example, to accidentally add a space after the backslash.
>
> Plus, as you say, they look kinda ugly!
>
> Parentheses are not being overloaded in this use.  They are already
> used to group an expression together, and that's what they are being
> used for when they prevent a line-end from being considered a newline.
>
> Plus, parentheses plus indentation is nice to read, IMHO...  Maybe
> I'll change my mind after more experience, but I like it so far.
>
>
> FWIW, my favorite tweak in this area would be if there was a warning
> for incorrect indentation.  That is, this should generate a warning:
>
>         val foo = bar
>                 + baz
>
> If someone really meant for "+ baz" to be a command by itself, then
> they should indent like this:
>
>         val foo = bar
>         + baz
>
>
>
>> B) some day, i wish you could replace "val" and "var" with words that
>> differ by more than a single letter for
>> readability/usability/maintainability. :-)
>
> True.  Arguably, they *are* similar concepts, if I wanted to be
> stubborn.  :)
>
> What alternative would work well, though?  Maybe "val" and
> "mutable val"?  Ick, "mutable val" looks oxymoronic.  Maybe "var" and
> "mutable var"?  Or perhaps, given the existence of legacy code using
> "var" already, it could be "bind" and "rebindable bind" ??
>
>
>
>
> -Lex
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Q/comment re: [ANN] Beta version of Scala 2

Martin Odersky
In reply to this post by Raoul Duke
Thanks for you comment, Raoul:

> A) "In these cases it suffices to enclose the multi-line expression in
> parentheses to suppress
> the generation of a newline token" ...I think parentheses are getting
> to be too overloaded - i'd suggest having using the standard (if
> somewhat ugly?) backslash standard a la python etc.
>
Like Lex, I think that escapes are problematic by themselves. Moreover,
backslash is already used prominently in the XML libraries.

I have thought of another refinement to ``semicolon inference'', which
makes adding parentheses unnecessary in many more cases. The idea is
that when an expression ends in an operator we do not assume a following
newline to be a statement separator.

I.e.

        x +
          y

would parse (x + y), not x +; y. The same works for any operator, i.e.

        xs map
          (x => x + 1)

is also seen as one expression, not two. So as long as you write
connecting operators on the end of lines, you will never have to add
parens. On the other hand, writing the operator at the beginning of the
following line would not work.

        x
        - y

would be parsed as (x; - y). The rule is easily spec'ed and implemented
by admitting an optional newline after an infix operator:

Expr ::= InfixExpr ident [NL] InfixExpr

  B) some day, i wish you could replace "val" and "var" with words that
> differ by more than a single letter for
> readability/usability/maintainability. :-)
>
I guess it depends how important mutability is for you. Many languages
do not distinguish at all between mutable and immutable variables or
fields. Scala does, but does not make a big deal of the distinction.
I kind of like the fact that val and var have the same width, so making
something (im)mutable does not change the layout of the program.

Cheers

  -- Martin
Reply | Threaded
Open this post in threaded view
|

RE: Q/comment re: [ANN] Beta version of Scala 2

Judson, Ross
In reply to this post by Raoul Duke
Excellent -- this is precisely what I ran into a couple of days ago; I
had redefined the + operator to append UI components to a parent, and
chained them like this:

 parent +
   center(panel + west(child) + east (child)) +
   south(toolbar);

Overall I feel like I _like_ having the semicolons there, to be honest
-- they clearly demarcate statements at all times.  The general trend in
languages seems to be to take them away, though, so I guess I have to
live with that.

RJ


-----Original Message-----
From: Martin Odersky [mailto:[hidden email]]
Sent: Monday, January 16, 2006 10:30 AM
To: Raoul Duke
Cc: scala
Subject: Re: Q/comment re: [ANN] Beta version of Scala 2

I.e.

        x +
          y

would parse (x + y), not x +; y. The same works for any operator, i.e.

        xs map
          (x => x + 1)

is also seen as one expression, not two. So as long as you write
connecting operators on the end of lines, you will never have to add
parens. On the other hand, writing the operator at the beginning of the
following line would not work.

        x
        - y

Reply | Threaded
Open this post in threaded view
|

Re: Q/comment re: [ANN] Beta version of Scala 2

Raoul Duke
> Overall I feel like I _like_ having the semicolons there, to be honest
> -- they clearly demarcate statements at all times.

Being an old fuddy-duddy, I guess I like semicolons as well for
similar reasons. From a perspective of learning a language, it bothers
me when there are several ways to do low-level syntax e.g.: Python's
deal where semicolons don't matter ... So I'm also a little worried
about having magic things if you end the line with an operator. I
mean, just think forward to the FAQs people will have to write and the
email questions they will have to answer about why somebody's code
doesn't work because they personally prefer to have the operator at
the start of the line, or on a line entirely on its own - I've
certainly had code where I wanted the latter.

All this kind of special casing seems quite unattractive to me.

(Here's one thing I will ask for the long term future: pretty please,
never go the route of Haskell and Python where indentation whitespace
becomes significant. I really would like to retain the ability to copy
and paste code and have my IDE know how to auto-indent it.)

sincerely $0.02 :-)
Reply | Threaded
Open this post in threaded view
|

Re: Q/comment re: [ANN] Beta version of Scala 2

Andrei Formiga
On 1/16/06, Raoul Duke <[hidden email]> wrote:
>
> (Here's one thing I will ask for the long term future: pretty please,
> never go the route of Haskell and Python where indentation whitespace
> becomes significant. I really would like to retain the ability to copy
> and paste code and have my IDE know how to auto-indent it.)
>
> sincerely $0.02 :-)
>

   Actually I find the Haskell solution very good: indentation matters
but only if the user want it. You may follow the layout rules and have
a cleaner syntax based on indentation, or you can provide semicolon
and braces to delimit blocks explicitly, without using identation.
Plus, the layout rules are simple, so it doesn't seem as if there's
some magic involved. I, for one, think that semicolons are mostly
useless nowadays, and I welcome the change, but there's a legitimate
worry over the rules and special cases and the amount of "magic"
needed to get it right.

--
[]s, Andrei Formiga
Reply | Threaded
Open this post in threaded view
|

Re: Q/comment re: [ANN] Beta version of Scala 2

Raoul Duke
(Rather than continuting to help move the Scala list into being ever
more sidetracked on what probably amount to somewhat religious issues
about newlines, semicolons, whitespace, yadda, I'd just like to say
that the core problem is that we don't have systems which magically
convert among all our personally preferred styles.)

-peace. :-)
Reply | Threaded
Open this post in threaded view
|

Re: Q/comment re: [ANN] Beta version of Scala 2

Martin Odersky
In reply to this post by Raoul Duke

> (Here's one thing I will ask for the long term future: pretty please,
> never go the route of Haskell and Python where indentation whitespace
> becomes significant. I really would like to retain the ability to copy
> and paste code and have my IDE know how to auto-indent it.)
>
>  
It's promised! I also find white-space indentation very unattractive.
The point of explicit parentheses/braces is that then the IDE can do a
good job at indentation. That's much easier on the reader and the writer
than having to put in and decode the indentation by hand, IMO.

Cheers

 -- Martin