This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: Re: A modest proposal

9 replies
David Flemström
Joined: 2009-08-10,
User offline. Last seen 42 years 45 weeks ago.
How far should this be pushed, though? Should the following be acceptable?
protected {
  var {
    x = 3
    y = 2
  }

  val {
    z = 3
    lazy {
      w = compute("input")
    }
  }
}
Personally, I visually parse this code as if the curly braces create a new scope, so this syntax doesn't make much sense to me. The idea is good, however, but not the implementation.

On Fri, Apr 23, 2010 at 9:06 PM, Doug Tangren <d [dot] tangren [at] gmail [dot] com> wrote:
There might be an argument there for refactoring that into its own object or class there if you are grouping an area of specialized behavior into a section of a single class.
-Doug Tangren
http://lessis.me


On Fri, Apr 23, 2010 at 3:03 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:
I like to group related things together.  For example, I may have a public method with several protected/private methods that support it.


Kevin Wright
Joined: 2009-06-09,
User offline. Last seen 49 weeks 3 days ago.
Re: Re: Re: A modest proposal
I must say, I actually kind of like this!
It's not the first time this week that the concept of blocks-without-scope have been invoked either, in a parallel discussion we've been discussing early vs late initialization of variables within constructor blocks, and a proposal was given:
class X {  earlyInit {    ...  }  ...  lateInit {    ...  }}
The idea being that all the "early" stuff for every class in a hierarchy happens first, then all the "regular" stuff, then all the "late" stuff.

How about we combine the two proposals, make "early" and "late" into keywords, and additionally introduce a dedicated annotation for scopeless blocks?  I'd like to propose [ and ] as delimiters, given that Scala perceives arrays as functional mappings from indices to values and therefore doesn't inherit the square-bracket-array-access notation from java.
So...
protected [
  var [
    x = 3
    y = 2
  ]

  val [
    z = 3
    lazy [
      w = compute("input")
    ]
  ]
]

The beauty is that this could be extended to ANY modifier or annotation, but it's still completely optional.
On the other hand, I imagine it would be a right pain in the proverbial for anyone working on IDEs - sorry Miles!

p.s: I think that I just invented a new word, the spellchecker really doesn't like "scopeless"




On 23 April 2010 20:12, David Flemström <david [dot] flemstrom [at] gmail [dot] com> wrote:
How far should this be pushed, though? Should the following be acceptable?
protected {
  var {
    x = 3
    y = 2
  }

  val {
    z = 3
    lazy {
      w = compute("input")
    }
  }
}
Personally, I visually parse this code as if the curly braces create a new scope, so this syntax doesn't make much sense to me. The idea is good, however, but not the implementation.

On Fri, Apr 23, 2010 at 9:06 PM, Doug Tangren <d [dot] tangren [at] gmail [dot] com> wrote:
There might be an argument there for refactoring that into its own object or class there if you are grouping an area of specialized behavior into a section of a single class.
-Doug Tangren
http://lessis.me


On Fri, Apr 23, 2010 at 3:03 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:
I like to group related things together.  For example, I may have a public method with several protected/private methods that support it.





--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Kevin Wright
Joined: 2009-06-09,
User offline. Last seen 49 weeks 3 days ago.
Re: Re: Re: A modest proposal
I must say, I actually kind of like this!
It's not the first time this week that the concept of blocks-without-scope have been invoked either, in a parallel discussion we've been discussing early vs late initialization of variables within constructor blocks, and a proposal was given:
class X {  earlyInit {    ...  }  ...  lateInit {    ...  }}
The idea being that all the "early" stuff for every class in a hierarchy happens first, then all the "regular" stuff, then all the "late" stuff.

How about we combine the two proposals, make "early" and "late" into keywords, and additionally introduce a dedicated annotation for scopeless blocks?  I'd like to propose [ and ] as delimiters, given that Scala perceives arrays as functional mappings from indices to values and therefore doesn't inherit the square-bracket-array-access notation from java.
So...
protected [
  var [
    x = 3
    y = 2
  ]

  val [
    z = 3
    lazy [
      w = compute("input")
    ]
  ]
]

The beauty is that this could be extended to ANY modifier or annotation, but it's still completely optional.
On the other hand, I imagine it would be a right pain in the proverbial for anyone working on IDEs - sorry Miles!

p.s: I think that I just invented a new word, the spellchecker really doesn't like "scopeless"




On 23 April 2010 20:12, David Flemström <david [dot] flemstrom [at] gmail [dot] com> wrote:
How far should this be pushed, though? Should the following be acceptable?
protected {
  var {
    x = 3
    y = 2
  }

  val {
    z = 3
    lazy {
      w = compute("input")
    }
  }
}
Personally, I visually parse this code as if the curly braces create a new scope, so this syntax doesn't make much sense to me. The idea is good, however, but not the implementation.

On Fri, Apr 23, 2010 at 9:06 PM, Doug Tangren <d [dot] tangren [at] gmail [dot] com> wrote:
There might be an argument there for refactoring that into its own object or class there if you are grouping an area of specialized behavior into a section of a single class.
-Doug Tangren
http://lessis.me


On Fri, Apr 23, 2010 at 3:03 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:
I like to group related things together.  For example, I may have a public method with several protected/private methods that support it.





--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

David Flemström
Joined: 2009-08-10,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: A modest proposal
On Fri, Apr 23, 2010 at 9:44 PM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:
So...
protected [
  var [
    x = 3
    y = 2
  ]

  val [
    z = 3
    lazy [
      w = compute("input")

    ]
  ]
]
Overloading type parameter lists is a Bad Idea™ from a parsers perspective. Basic parentheses would make more sense in my opinion.Also, I could see this being useful for keywords or annotations, but shouldn't it be possible to generalize? Scala is scalable, after all, so how do we allow for libraries to add their own "grouping brace functions"? Is this how macros could be introduced?
I think that this feature shouldn't be rushed; something that seems to be a brilliant idea might turn out to be disastrous in the end. As I've said before: we don't want Scala to become another Perl.
On the other hand, I imagine it would be a right pain in the proverbial for anyone working on IDEs - sorry Miles!
I don't think so, actually, from having studied the code.
David Flemström
Joined: 2009-08-10,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: A modest proposal
On Fri, Apr 23, 2010 at 9:44 PM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:
So...
protected [
  var [
    x = 3
    y = 2
  ]

  val [
    z = 3
    lazy [
      w = compute("input")

    ]
  ]
]
Overloading type parameter lists is a Bad Idea™ from a parsers perspective. Basic parentheses would make more sense in my opinion.Also, I could see this being useful for keywords or annotations, but shouldn't it be possible to generalize? Scala is scalable, after all, so how do we allow for libraries to add their own "grouping brace functions"? Is this how macros could be introduced?
I think that this feature shouldn't be rushed; something that seems to be a brilliant idea might turn out to be disastrous in the end. As I've said before: we don't want Scala to become another Perl.
On the other hand, I imagine it would be a right pain in the proverbial for anyone working on IDEs - sorry Miles!
I don't think so, actually, from having studied the code.
dimensia
Joined: 2010-04-15,
User offline. Last seen 2 weeks 4 days ago.
Re: Re: Re: A modest proposal
I think C++'s style would be less cluttered:
class Foo {   var publicX = 1   var publicY = 2
private:
  var privateX = 1   var privateY = 1 }
The proposed syntax listed here introduces too much nesting in my opinion.
It doesn't scale to var and vals but those are already reduced to a scant three characters and I think they're needed anyway to keep parsing sane?  I could be wrong.
On Fri, Apr 23, 2010 at 3:25 PM, David Flemström <david [dot] flemstrom [at] gmail [dot] com> wrote:
On Fri, Apr 23, 2010 at 9:44 PM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:
So...
protected [
  var [
    x = 3
    y = 2
  ]

  val [
    z = 3
    lazy [
      w = compute("input")


    ]
  ]
]
Overloading type parameter lists is a Bad Idea™ from a parsers perspective. Basic parentheses would make more sense in my opinion.Also, I could see this being useful for keywords or annotations, but shouldn't it be possible to generalize? Scala is scalable, after all, so how do we allow for libraries to add their own "grouping brace functions"? Is this how macros could be introduced?
I think that this feature shouldn't be rushed; something that seems to be a brilliant idea might turn out to be disastrous in the end. As I've said before: we don't want Scala to become another Perl.
On the other hand, I imagine it would be a right pain in the proverbial for anyone working on IDEs - sorry Miles!
I don't think so, actually, from having studied the code.

Alex Cruise
Joined: 2008-12-17,
User offline. Last seen 2 years 26 weeks ago.
Re: Re: Re: A modest proposal
Trimmed scala@ off the CC list...

On 10-04-23 12:12 PM, David Flemström wrote:
j2q2894b2d81004231212ycccec403q218a70d213a20ace [at] mail [dot] gmail [dot] com" type="cite">How far should this be pushed, though? Should the following be acceptable?
protected {
  var {
    x = 3
    y = 2
  }

  val {
    z = 3
    lazy {
      w = compute("input")
    }
  }
}
Personally, I visually parse this code as if the curly braces create a new scope, so this syntax doesn't make much sense to me. The idea is good, however, but not the implementation.

I'd strongly prefer to keep val, var and def right beside the names.   I agree that scopeless blocks are a bit jarring, and I don't particularly care much about the syntax, I've just had a few files recently with an awful lot of private members and exactly one public member.

I wouldn't mind the C++ syntax, there's certainly no conflict with any existing label syntax.  One problem that occurs to me is that, since "public" is *not* a reserved word in Scala, there'd be an asymmetry in the visibility blocks:

// implicitly public
def foo

private {
  def bar
}

protected[pkg] {
  def bar
}

-0xe1a
Kevin Wright
Joined: 2009-06-09,
User offline. Last seen 49 weeks 3 days ago.
Re: Re: Re: A modest proposal
yikes! I didn't think about type parameters, you're right that it's a risky choice to overload.
It's true as well that braces imply scoping, so they're sadly also risky.  I still think that we're onto something here with scopeless blocks that can be used for any keyword or annotation though, and it's especially frustrating if notation is going to be the only sticking point.
The C++ syntax is surprisingly appropriate.  It's clean, and already has some precedent in the way packages are handled.  But for completeness I feel that a good longhand syntax is also needed, just maybe not the one I first suggested. :)

On 23 April 2010 21:25, David Flemström <david [dot] flemstrom [at] gmail [dot] com> wrote:
On Fri, Apr 23, 2010 at 9:44 PM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:
So...
protected [
  var [
    x = 3
    y = 2
  ]

  val [
    z = 3
    lazy [
      w = compute("input")


    ]
  ]
]
Overloading type parameter lists is a Bad Idea™ from a parsers perspective. Basic parentheses would make more sense in my opinion.Also, I could see this being useful for keywords or annotations, but shouldn't it be possible to generalize? Scala is scalable, after all, so how do we allow for libraries to add their own "grouping brace functions"? Is this how macros could be introduced?
I think that this feature shouldn't be rushed; something that seems to be a brilliant idea might turn out to be disastrous in the end. As I've said before: we don't want Scala to become another Perl.
On the other hand, I imagine it would be a right pain in the proverbial for anyone working on IDEs - sorry Miles!
I don't think so, actually, from having studied the code.



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Kevin Wright
Joined: 2009-06-09,
User offline. Last seen 49 weeks 3 days ago.
Re: Re: Re: A modest proposal
yikes! I didn't think about type parameters, you're right that it's a risky choice to overload.
It's true as well that braces imply scoping, so they're sadly also risky.  I still think that we're onto something here with scopeless blocks that can be used for any keyword or annotation though, and it's especially frustrating if notation is going to be the only sticking point.
The C++ syntax is surprisingly appropriate.  It's clean, and already has some precedent in the way packages are handled.  But for completeness I feel that a good longhand syntax is also needed, just maybe not the one I first suggested. :)

On 23 April 2010 21:25, David Flemström <david [dot] flemstrom [at] gmail [dot] com> wrote:
On Fri, Apr 23, 2010 at 9:44 PM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:
So...
protected [
  var [
    x = 3
    y = 2
  ]

  val [
    z = 3
    lazy [
      w = compute("input")


    ]
  ]
]
Overloading type parameter lists is a Bad Idea™ from a parsers perspective. Basic parentheses would make more sense in my opinion.Also, I could see this being useful for keywords or annotations, but shouldn't it be possible to generalize? Scala is scalable, after all, so how do we allow for libraries to add their own "grouping brace functions"? Is this how macros could be introduced?
I think that this feature shouldn't be rushed; something that seems to be a brilliant idea might turn out to be disastrous in the end. As I've said before: we don't want Scala to become another Perl.
On the other hand, I imagine it would be a right pain in the proverbial for anyone working on IDEs - sorry Miles!
I don't think so, actually, from having studied the code.



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] googlemail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: Re: Re: A modest proposal
(To Debate only):

If it is decided that one wants this--and I am not entirely convinced that repetition is a bad thing in this case, since that pits logical organization against lexical organization--then I would suggest a syntax motivated by block strings.

token {{{
  statementA
  statementB
  statementC
}}}

is treated equivalently to

  token statementA
  token statementB
  token statementC

and thus one could have

private {{{
  var x = 0
  val y = "Fish"
}}}

but also

private var {{{
  x = 0
  z = Some("Fish")
}}}

However, the whole idea strikes me as too macro-like; it suggests to me that it would be done instead of think about the problem in a more modular way that would, in the long run, be superior in most instances.

  --Rex

P.S. There is some appeal to
  whatever.add( {{{ a; b; c; d }}} )
as a shorthand to automatically turn single-argument side-effecting methods into multi-argument ones.


On Fri, Apr 23, 2010 at 7:18 PM, Kevin Wright <kev [dot] lee [dot] wright [at] googlemail [dot] com> wrote:
yikes! I didn't think about type parameters, you're right that it's a risky choice to overload.
It's true as well that braces imply scoping, so they're sadly also risky.  I still think that we're onto something here with scopeless blocks that can be used for any keyword or annotation though, and it's especially frustrating if notation is going to be the only sticking point.
The C++ syntax is surprisingly appropriate.  It's clean, and already has some precedent in the way packages are handled.  But for completeness I feel that a good longhand syntax is also needed, just maybe not the one I first suggested. :)

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland