Incrementally parsing with SAX

let's say i have two methods:

def a (b : => String) = {
val tmp = b
c(b)
}

def c (b: => String) = b

will tmp be a string, or a () => String? will c return a String, or a
function returning a string?

On Sat, May 29, 2010 at 1:50 PM, HamsterofDeath <h-star@gmx.de> wrote:

let's say i have two methods:

def a (b : => String) = {
  val tmp = b
  c(b)
}

def c (b: => String) = b

will tmp be a string, or a () => String? will c return a String, or a
function returning a string?

tmp is a String
c is a String

b: => String will evaluate every time it appears where a string could be used _except_ if it would then have to be repackaged into a function.

You can check where the calls happen by looking at the bytecode (javap -c ClassName) or by running a test like this that prints something in when evaluated:

 object Test {
  object CountString {
    var inA = false
    var inC = false
    var n = 0
    def s = {
      n += 1
      println(n + " " + inA + " " + inC)
      inA = false
      inC = false
      n.toString
    }
  }
  def c (b: => String) = { CountString.inC = true; b }
  def a (b : => String) = {
    CountString.inA = true
    val tmp = b
    CountString.inA = true
    c(b)
  }
}

In this particular case, we get

scala> Test.c( Test.CountString.s )
1 false true
res0: String = 1

scala> Test.a( Test.CountString.s )
2 true false
3 true true
res1: String = 3

showing that we performed the evaluation _after_ entering c (hence the second boolean prints "true"), and that it evaluates on val tmp = b (thus 2 has inA==true), and evaluates again on c(b) but only once inside both a and c (i.e. a doesn't evaluate it and then pass the value to c).

  --Rex

On Saturday May 29 2010, HamsterofDeath wrote:
> let's say i have two methods:
>
> def a (b : => String) = {
> val tmp = b
> c(b)
> }
>
> def c (b: => String) = b
>
> will tmp be a string, or a () => String? will c return a String, or a
> function returning a string?

For the 87th time, by-name parameters are not functions! They're values
whose actual parameter expression is evaluated every time the formal
parameter's value is used in the method that defines the by-name
parameter.

RRS

On Sat, May 29, 2010 at 2:50 PM, Randall R Schulz <rschulz@sonic.net> wrote:

For the 87th time, by-name parameters are not functions! They're values
whose actual parameter expression is evaluated every time the formal
parameter's value is used in the method that defines the by-name
parameter.

...except that they're implemented as functions (Function0, to be precise).

  --Rex
 

i'm pretty sure my debugger showed them as classes, just like the usual
closures. you probably mean that they are not functions "by concept" but
behave like a "method call" instead of a "value access"

sorry for not listening the first 85 times. you're right on the 86th one ;)

Randall R Schulz schrieb:
> On Saturday May 29 2010, HamsterofDeath wrote:
>
>> let's say i have two methods:
>>
>> def a (b : => String) = {
>> val tmp = b
>> c(b)
>> }
>>
>> def c (b: => String) = b
>>
>> will tmp be a string, or a () => String? will c return a String, or a
>> function returning a string?
>>
>
> For the 87th time, by-name parameters are not functions! They're values
> whose actual parameter expression is evaluated every time the formal
> parameter's value is used in the method that defines the by-name
> parameter.
>
>
> RRS
>
>

On Saturday May 29 2010, Rex Kerr wrote:
> On Sat, May 29, 2010 at 2:50 PM, Randall R Schulz wrote:
> > For the 87th time, by-name parameters are not functions! They're
> > values whose actual parameter expression is evaluated every time
> > the formal parameter's value is used in the method that defines the
> > by-name parameter.
>
> ...except that they're implemented as functions (Function0, to be
> precise).

Everything is implemented as something else on a lower level. Stick to
the concepts. By-name parameters are not overtly invoked or applied the
way methods or functions are. They're simply used, triggering
evaluation(s) of the expression given as an actual parameter.

> --Rex

Randall Schulz

On Sat, May 29, 2010 at 3:20 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Saturday May 29 2010, Rex Kerr wrote:
> On Sat, May 29, 2010 at 2:50 PM, Randall R Schulz wrote:
> > For the 87th time, by-name parameters are not functions! They're
> > values whose actual parameter expression is evaluated every time
> > the formal parameter's value is used in the method that defines the
> > by-name parameter.
>
> ...except that they're implemented as functions (Function0, to be
> precise).

Everything is implemented as something else on a lower level. Stick to
the concepts. By-name parameters are not overtly invoked or applied the
way methods or functions are. They're simply used, triggering
evaluation(s) of the expression given as an actual parameter.

The concept is "This works exactly like a passable method that you evaluate every time."  Which is exactly the concept of a function, except the syntax is slightly more convenient in most cases.  The syntax to declare the type even says, in effect, "This is a function with no parameter lists."

By-name parameters are functions behind the scenes (and not very far behind the scenes!), and they are functions conceptually, except with slightly different syntax.  They may have had a conceptual history that was distinct from functions in some way, and they may have a name that doesn't use the word "function", but if one knows what a function is, there is very little extra to learn to know what a by-name parameter is in Scala (and that is all syntax, AFAICT).

If someone wants to keep the differences straight in their head by calling them "not functions, by-name parameters" that is understandable to me.  But if they want to keep them straight by calling them "eagerly evaluated zero-parameter-list functions a.k.a. by-name parameters", that is understandable too.

Maybe if you can share the history of the concept--and how it differs from the concept of function--you can show why it is advantageous to use the "not a function" meme.
 
  --Rex

the difference would be, i assume, that you cannot pass the
by-name-parameter around. it gets evaluated if you try, except you pass
it to another method which takes a by-name-parameter. storing the
by-name-parameter in a reference is not possible. (still assuming here).
you cannot add it to a map, assign it to a val and so on

Rex Kerr schrieb:
> On Sat, May 29, 2010 at 3:20 PM, Randall R Schulz > wrote:
>
> On Saturday May 29 2010, Rex Kerr wrote:
> > On Sat, May 29, 2010 at 2:50 PM, Randall R Schulz wrote:
> > > For the 87th time, by-name parameters are not functions! They're
> > > values whose actual parameter expression is evaluated every time
> > > the formal parameter's value is used in the method that
> defines the
> > > by-name parameter.
> >
> > ...except that they're implemented as functions (Function0, to be
> > precise).
>
> Everything is implemented as something else on a lower level. Stick to
> the concepts. By-name parameters are not overtly invoked or
> applied the
> way methods or functions are. They're simply used, triggering
> evaluation(s) of the expression given as an actual parameter.
>
>
> The concept is "This works exactly like a passable method that you
> evaluate every time." Which is exactly the concept of a function,
> except the syntax is slightly more convenient in most cases. The
> syntax to declare the type even says, in effect, "This is a function
> with no parameter lists."
>
> By-name parameters are functions behind the scenes (and not very far
> behind the scenes!), and they are functions conceptually, except with
> slightly different syntax. They may have had a conceptual history
> that was distinct from functions in some way, and they may have a name
> that doesn't use the word "function", but if one knows what a function
> is, there is very little extra to learn to know what a by-name
> parameter is in Scala (and that is all syntax, AFAICT).
>
> If someone wants to keep the differences straight in their head by
> calling them "not functions, by-name parameters" that is
> understandable to me. But if they want to keep them straight by
> calling them "eagerly evaluated zero-parameter-list functions a.k.a.
> by-name parameters", that is understandable too.
>
> Maybe if you can share the history of the concept--and how it differs
> from the concept of function--you can show why it is advantageous to
> use the "not a function" meme.
>
> --Rex
>

On Saturday May 29 2010, Rex Kerr wrote:
> On Sat, May 29, 2010 at 3:20 PM, Randall R Schulz wrote:
> > ...
>
> Maybe if you can share the history of the concept--and how it differs
> from the concept of function--you can show why it is advantageous to
> use the "not a function" meme.

The history is not hidden, if you care to look into it. It's very old.

The reason not to think of them as functions is the simple fact that
_they are not functions_!

To think about the concept of the by-name parameter in terms of a
particular implementation is simply to mix up your role as the user of
a language with that of its implementor.

The other misconception around Scala by-name parameters is that they're
lazy values. Surely you don't promote thinking of them in that
erroneous manner, do you?

I don't really get why one has to defend not thinking of a thing as some
other thing. Surely you can see that HamsterOfDeath's question
originates in just the kind of misunderstanding you're promoting?

> --Rex

Randall Schulz

NIO uses byte buffers, and as such is always buffered.

On Sat, May 29, 2010 at 11:52 AM, Kai Meder <stuff@kai.meder.info> wrote:

Hello,

I connect to hosts via NIO and want to parse the resulting XML.
I get chunks of data (NIO) which I want to feed into a SAX-Parser. Is
there a way *not* buffering the data-chunks and feeding them at-once
into SAX? What would be an efficient way?

Thanks, Kai

On Sat, May 29, 2010 at 4:21 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Saturday May 29 2010, Rex Kerr wrote:
> On Sat, May 29, 2010 at 3:20 PM, Randall R Schulz wrote:
> > ...
>
> Maybe if you can share the history of the concept--and how it differs
> from the concept of function--you can show why it is advantageous to
> use the "not a function" meme.

The history is not hidden, if you care to look into it. It's very old.

The reason not to think of them as functions is the simple fact that
_they are not functions_!

A true pass-by-name construct is not a function; in Scala you would have to provide an apply/update pair in the general case, or a pair (f: => T , Option[T => Unit])--at least in Algol you could assign to a pass-by-name construct.

But in Scala you can't assign to a by-name parameter.

And thus by-name parameters are not conceptually distinct, in Scala, from functions, in any practical sense.

Or at least you haven't explained why, aside from saying "Because that's what they are!"
 

The other misconception around Scala by-name parameters is that they're
lazy values. Surely you don't promote thinking of them in that
erroneous manner, do you?

No, because they're not lazy values (i.e. are only evaluated once the first time they're needed, and then that value is stored and returned on every subsequent call).  They don't act like lazy values.

They _do_ act like zero-parameter-list functions (except they are hard to store and pass).
 

I don't really get why one has to defend not thinking of a thing as some
other thing. Surely you can see that HamsterOfDeath's question
originates in just the kind of misunderstanding you're promoting?

Possibly.  But it might also originate in looking at the output of a debugger, exception handling, source code, or Scala syntax.

  --Rex

You can convert it to a regular function by appending _. If you need
to do this, you can then pass it around like any other function
object:

scala> def test(str: => String) = str _
test: (str: => String)() => String

On Sat, May 29, 2010 at 10:21 PM, HamsterofDeath wrote:
> the difference would be, i assume, that you cannot pass the
> by-name-parameter around. it gets evaluated if you try, except you pass
> it to another method which takes a by-name-parameter. storing the
> by-name-parameter in a reference is not possible. (still assuming here).
> you cannot add it to a map, assign it to a val and so on
>
> Rex Kerr schrieb:
>> On Sat, May 29, 2010 at 3:20 PM, Randall R Schulz > > wrote:
>>
>>     On Saturday May 29 2010, Rex Kerr wrote:
>>     > On Sat, May 29, 2010 at 2:50 PM, Randall R Schulz wrote:
>>     > > For the 87th time, by-name parameters are not functions! They're
>>     > > values whose actual parameter expression is evaluated every time
>>     > > the formal parameter's value is used in the method that
>>     defines the
>>     > > by-name parameter.
>>     >
>>     > ...except that they're implemented as functions (Function0, to be
>>     > precise).
>>
>>     Everything is implemented as something else on a lower level. Stick to
>>     the concepts. By-name parameters are not overtly invoked or
>>     applied the
>>     way methods or functions are. They're simply used, triggering
>>     evaluation(s) of the expression given as an actual parameter.
>>
>>
>> The concept is "This works exactly like a passable method that you
>> evaluate every time."  Which is exactly the concept of a function,
>> except the syntax is slightly more convenient in most cases.  The
>> syntax to declare the type even says, in effect, "This is a function
>> with no parameter lists."
>>
>> By-name parameters are functions behind the scenes (and not very far
>> behind the scenes!), and they are functions conceptually, except with
>> slightly different syntax.  They may have had a conceptual history
>> that was distinct from functions in some way, and they may have a name
>> that doesn't use the word "function", but if one knows what a function
>> is, there is very little extra to learn to know what a by-name
>> parameter is in Scala (and that is all syntax, AFAICT).
>>
>> If someone wants to keep the differences straight in their head by
>> calling them "not functions, by-name parameters" that is
>> understandable to me.  But if they want to keep them straight by
>> calling them "eagerly evaluated zero-parameter-list functions a.k.a.
>> by-name parameters", that is understandable too.
>>
>> Maybe if you can share the history of the concept--and how it differs
>> from the concept of function--you can show why it is advantageous to
>> use the "not a function" meme.
>>
>>   --Rex
>>
>
>

I mean buffering in the sense of "collecting the whole data".
Of course every data-chunk is made avaiable thru NIO-ByteBuffers.

I'm looking for a way to feed a Sax-Parser incrementally with
Array[Byte] or ByteBuffer, each being a chunk of data read via NIO.

Any advice?
Thanks, Kai

On 29.05.2010 22:58, Nils Kilden-Pedersen wrote:
> NIO uses byte buffers, and as such is always buffered.
>
> On Sat, May 29, 2010 at 11:52 AM, Kai Meder > wrote:
>
> Hello,
>
> I connect to hosts via NIO and want to parse the resulting XML.
> I get chunks of data (NIO) which I want to feed into a SAX-Parser. Is
> there a way *not* buffering the data-chunks and feeding them at-once
> into SAX? What would be an efficient way?
>
> Thanks, Kai
>
>

They don't capture the whole block,  just the resulting expression. Its a fundamental difference and saying they behave the same leads to misunderstanding and inevitable confusion.

On May 30, 2010 12:20 AM, "Rex Kerr" <ichoran@gmail.com> wrote:

On Sat, May 29, 2010 at 4:21 PM, Randall R Schulz <rschulz@sonic.net> wrote: > > On Saturday May 29 ...

A true pass-by-name construct is not a function; in Scala you would have to provide an apply/update pair in the general case, or a pair (f: => T , Option[T => Unit])--at least in Algol you could assign to a pass-by-name construct.

But in Scala you can't assign to a by-name parameter.

And thus by-name parameters are not conceptually distinct, in Scala, from functions, in any practical sense.

Or at least you haven't explained why, aside from saying "Because that's what they are!"
 

> > The other misconception around Scala by-name parameters is that they're > lazy values. Surely y...

No, because they're not lazy values (i.e. are only evaluated once the first time they're needed, and then that value is stored and returned on every subsequent call).  They don't act like lazy values.

They _do_ act like zero-parameter-list functions (except they are hard to store and pass).
 

> > I don't really get why one has to defend not thinking of a thing as some > other thing. Surely ...

Possibly.  But it might also originate in looking at the output of a debugger, exception handling, source code, or Scala syntax.

  --Rex

On Sun, May 30, 2010 at 1:27 PM, Chris Twiner <chris.twiner@gmail.com> wrote:

They don't capture the whole block,  just the resulting expression. Its a fundamental difference and saying they behave the same leads to misunderstanding and inevitable confusion.

Can you provide example code that illustrates the difference in behavior between by-name parameters and zero-parameter functions?  Apparently I am misunderstanding something.

  --Rex

I thought I had an example, but this simple comparison indicates the same behavior to me:

scala> def byName(f: => String) = {
    | println(f);
    | println("foo");
    | println(f);
    |
    | }
byName: (=> String)Unit


scala> def noArg(f: () => String) = {
    | println(f());
    | println("foo");
    | println(f());
    | }
noArg: (() => String)Unit


scala> byName({ println("CALLED!"); "bar"})
CALLED!
bar
foo
CALLED!
bar


scala> noArg(() => {println("CALLED!"); "bar"})
CALLED!
bar
foo
CALLED!
bar

So, I stored the parameter in a local var and the behavior does change to illustrate the difference:
scala> def byNameWithVar(f: => String) = {      | var g = f     | println(g);     | println("foo");      | println(g);     | }byNameWithVar: (=> String)Unit
scala> byNameWithVar({ println("CALLED!"); "bar"}) CALLED!barfoo bar
scala> def noArgWithVar(f: () => String) = {      | var g = f     | println(g())     | println("foo")      | println(g())     | }noArgWithVar: (() => String)Unit
scala> noArgWithVar(() => {println("CALLED!"); "bar"}) CALLED!barfoo CALLED!bar
I was surprised that the first example above results in identical behavior, but it could be I don't totally understand the semantics of by-name parameters.  It would seem that a by-name parameter is evaluated every time it's value is needed.
Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com




On Sun, May 30, 2010 at 2:09 PM, Rex Kerr <ichoran@gmail.com> wrote:
> On Sun, May 30, 2010 at 1:27 PM, Chris Twiner <chris.twiner@gmail.com>
> wrote:
>>
>> They don't capture the whole block,  just the resulting expression. Its a
>> fundamental difference and saying they behave the same leads to
>> misunderstanding and inevitable confusion.
>
> Can you provide example code that illustrates the difference in behavior
> between by-name parameters and zero-parameter functions?  Apparently I am
> misunderstanding something.
>
>   --Rex
>
>

This makes perfect sense In the case of the function, g becomes equal to the function.  so g is simply an alias for f For the by-name param, g becomes equal to the result of evaluating f

On 30 May 2010 22:31, David Copeland <davec@naildrivin5.com> wrote:

I thought I had an example, but this simple comparison indicates the same behavior to me:

scala> def byName(f: => String) = {
    | println(f);
    | println("foo");
    | println(f);
    |
    | }
byName: (=> String)Unit


scala> def noArg(f: () => String) = {
    | println(f());
    | println("foo");
    | println(f());
    | }
noArg: (() => String)Unit


scala> byName({ println("CALLED!"); "bar"})
CALLED!
bar
foo
CALLED!
bar


scala> noArg(() => {println("CALLED!"); "bar"})
CALLED!
bar
foo
CALLED!
bar

So, I stored the parameter in a local var and the behavior does change to illustrate the difference:
scala> def byNameWithVar(f: => String) = {      | var g = f     | println(g);     | println("foo");      | println(g);     | }byNameWithVar: (=> String)Unit
scala> byNameWithVar({ println("CALLED!"); "bar"}) CALLED!barfoo bar
scala> def noArgWithVar(f: () => String) = {      | var g = f     | println(g())     | println("foo")      | println(g())     | }noArgWithVar: (() => String)Unit
scala> noArgWithVar(() => {println("CALLED!"); "bar"}) CALLED!barfoo CALLED!bar
I was surprised that the first example above results in identical behavior, but it could be I don't totally understand the semantics of by-name parameters.  It would seem that a by-name parameter is evaluated every time it's value is needed.
Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com




On Sun, May 30, 2010 at 2:09 PM, Rex Kerr <ichoran@gmail.com> wrote:
> On Sun, May 30, 2010 at 1:27 PM, Chris Twiner <chris.twiner@gmail.com>
> wrote:
>>
>> They don't capture the whole block,  just the resulting expression. Its a
>> fundamental difference and saying they behave the same leads to
>> misunderstanding and inevitable confusion.
>
> Can you provide example code that illustrates the difference in behavior
> between by-name parameters and zero-parameter functions?  Apparently I am
> misunderstanding something.
>
>   --Rex
>
>

--
Kevin Wright

mail/google talk: kev.lee.wright@gmail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

as far as i understand, this:

scala> def byNameWithVar(f: => String) = {
| var g = f
| println(g);
| println("foo");
| println(g);
| }

is equal to

scala> def noArgWithVar(f: () => String) = {
| var g = f()
| println(g)
| println("foo")
| println(g)
| }

David Copeland schrieb:
> I thought I had an example, but this simple comparison indicates the
> same behavior to me:
>
> scala> def byName(f: => String) = {
> | println(f);
> | println("foo");
> | println(f);
> |
> | }
> byName: (=> String)Unit
>
>
> scala> def noArg(f: () => String) = {
> | println(f());
> | println("foo");
> | println(f());
> | }
> noArg: (() => String)Unit
>
>
> scala> byName({ println("CALLED!"); "bar"})
> CALLED!
> bar
> foo
> CALLED!
> bar
>
>
> scala> noArg(() => {println("CALLED!"); "bar"})
> CALLED!
> bar
> foo
> CALLED!
> bar
>
> So, I stored the parameter in a local var and the behavior does change
> to illustrate the difference:
>
> scala> def byNameWithVar(f: => String) = {
> | var g = f
> | println(g);
> | println("foo");
> | println(g);
> | }
> byNameWithVar: (=> String)Unit
>
> scala> byNameWithVar({ println("CALLED!"); "bar"})
> CALLED!
> bar
> foo
> bar
>
> scala> def noArgWithVar(f: () => String) = {
> | var g = f
> | println(g())
> | println("foo")
> | println(g())
> | }
> noArgWithVar: (() => String)Unit
>
> scala> noArgWithVar(() => {println("CALLED!"); "bar"})
> CALLED!
> bar
> foo
> CALLED!
> bar
>
> I was surprised that the first example above results in identical
> behavior, but it could be I don't totally understand the semantics of
> by-name parameters. It would seem that a by-name parameter is
> evaluated every time it's value is needed.
>
> Dave
>
> ---
> My Blog: http://www.naildrivin5.com/blog
> Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
> Fork me on Github: http://davetron5000.github.com
>
>
>
>
> On Sun, May 30, 2010 at 2:09 PM, Rex Kerr > wrote:
> > On Sun, May 30, 2010 at 1:27 PM, Chris Twiner
> >
> > wrote:
> >>
> >> They don't capture the whole block, just the resulting expression.
> Its a
> >> fundamental difference and saying they behave the same leads to
> >> misunderstanding and inevitable confusion.
> >
> > Can you provide example code that illustrates the difference in behavior
> > between by-name parameters and zero-parameter functions? Apparently
> I am
> > misunderstanding something.
> >
> > --Rex
> >
> >
>

Although I think this is the only instance in Scala that a function (not a method) has a number of parameter lists other than 1.

On Sat, May 29, 2010 at 6:19 PM, Rex Kerr <ichoran@gmail.com> wrote:

On Sat, May 29, 2010 at 4:21 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Saturday May 29 2010, Rex Kerr wrote:
> On Sat, May 29, 2010 at 3:20 PM, Randall R Schulz wrote:
> > ...
>
> Maybe if you can share the history of the concept--and how it differs
> from the concept of function--you can show why it is advantageous to
> use the "not a function" meme.

The history is not hidden, if you care to look into it. It's very old.

The reason not to think of them as functions is the simple fact that
_they are not functions_!

A true pass-by-name construct is not a function; in Scala you would have to provide an apply/update pair in the general case, or a pair (f: => T , Option[T => Unit])--at least in Algol you could assign to a pass-by-name construct.

But in Scala you can't assign to a by-name parameter.

And thus by-name parameters are not conceptually distinct, in Scala, from functions, in any practical sense.

Or at least you haven't explained why, aside from saying "Because that's what they are!"
 

The other misconception around Scala by-name parameters is that they're
lazy values. Surely you don't promote thinking of them in that
erroneous manner, do you?

No, because they're not lazy values (i.e. are only evaluated once the first time they're needed, and then that value is stored and returned on every subsequent call).  They don't act like lazy values.

They _do_ act like zero-parameter-list functions (except they are hard to store and pass).
 

I don't really get why one has to defend not thinking of a thing as some
other thing. Surely you can see that HamsterOfDeath's question
originates in just the kind of misunderstanding you're promoting?

Possibly.  But it might also originate in looking at the output of a debugger, exception handling, source code, or Scala syntax.

  --Rex

On Thursday June 3 2010, Naftoli Gugenheim wrote:
> Although I think this is the only instance in Scala that a function
> (not a method) has a number of parameter lists other than 1.

Welcome to Scala version 2.8.0.RC3 (Java HotSpot(TM) Client VM, Java 1.6.0_20).
Type in expressions to have them evaluated.
Type :help for more information.

scala> def m2al(ints: Int*)(strs: String*): Int = ints.length + strs.length
m2al: (ints: Int*)(strs: String*)Int

scala> val m2al_f = m2al _
m2al_f: (Int*) => (String*) => Int =

scala> def m3al(bools: Boolean*)(ints: Int*)(strs: String*): Int = bools.length + ints.length + strs.length
m3al: (bools: Boolean*)(ints: Int*)(strs: String*)Int

scala> val m3al_f = m3al _
m3al_f: (Boolean*) => (Int*) => (String*) => Int =

And so on.

Randall Schulz

I'm assuming you're talking about the vals, not the defs, which are methods. But I'm not sure why you didn't write:
scala> (i: Int) => ((s: String) => s + i) res0: (Int) => (String) => java.lang.String = <function>
Which seems to indicate that it's really just a function returning a function.


On Thu, Jun 3, 2010 at 8:10 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Thursday June 3 2010, Naftoli Gugenheim wrote:
> Although I think this is the only instance in Scala that a function
> (not a method) has a number of parameter lists other than 1.

Welcome to Scala version 2.8.0.RC3 (Java HotSpot(TM) Client VM, Java 1.6.0_20).
Type in expressions to have them evaluated.
Type :help for more information.

scala> def m2al(ints: Int*)(strs: String*): Int = ints.length + strs.length
m2al: (ints: Int*)(strs: String*)Int

scala> val m2al_f = m2al _
m2al_f: (Int*) => (String*) => Int = <function1>

scala> def m3al(bools: Boolean*)(ints: Int*)(strs: String*): Int = bools.length + ints.length + strs.length
m3al: (bools: Boolean*)(ints: Int*)(strs: String*)Int

scala> val m3al_f = m3al _
m3al_f: (Boolean*) => (Int*) => (String*) => Int = <function1>


And so on.


Randall Schulz