headers
Raoul Duke | 1 Aug 2005 06:29
Picon

Re: read-eval-print loop?

On 7/22/05, Burak Emir <Burak.Emir <at> epfl.ch> wrote:
> It's not very actively maintained, has some bugs, but definitely works.

Hi Burak, Thanks for the info. I gave it a try while attemping to
figure out how currying works in Scala and the first thing I typed
caused it to die :-) Please see the excerpt below.

I haven't found it in any of the docs: what is the syntax for
currying? I attempted to do something long the lines of:
def foo(x:int, y:int):int = {x+y;}
foo(7); // hoping to get a method object back, but the compiler tells
me wrong number of arguments.

many thanks for your time!

 version: 1.4.0.0
 type :? to get a list of all interpreter commands

> def fn(x:int, y:int) :int = {x+y;}

Exception in thread "main" java.lang.AbstractMethodError: updateFlagsAndPos
	at scala.tools.scalac.typechecker.Analyzer.updateFlagsAndPos(Analyzer.scala(Compiled
Code))
	at scala.tools.scalac.typechecker.Analyzer$class.updateFlagsAndPos(Analyzer.scala(Compiled
Code))
	at scala.tools.scalac.typechecker.Analyzer$class.typeSymbolOrNone(Analyzer.scala(Inlined
Compiled Code))
	at scala.tools.scalac.typechecker.Analyzer$class.classSymbol(Analyzer.scala(Inlined
Compiled Code))
	at scala.tools.scalac.typechecker.Analyzer$class.enterSym(Analyzer.scala(Compiled
(Continue reading)

Permalink | Reply | 5 comments |
headers
Nikolay Mihaylov | 1 Aug 2005 11:28
Picon
Picon
Favicon

Re: read-eval-print loop?

Hi there

On Sun, 2005-07-31 at 21:29 -0700, Raoul Duke wrote:
> I haven't found it in any of the docs: what is the syntax for
> currying? I attempted to do something long the lines of:
> def foo(x:int, y:int):int = {x+y;}
> foo(7); // hoping to get a method object back, but the compiler tells
> me wrong number of arguments.

Scala only permits partial application if that is expressed in the
definition of a function. The way to do this is to supply multiple
parameter lists. In your particular case you have to write:

def foo(x: Int)(y: Int): Int = x + y;

Then, foo(7) will be a value of type Int => Int. If you want to fully
apply it you write foo(7)(42).

Nikolay
Permalink | Reply | 4 comments |
headers
Nikolay Mihaylov | 1 Aug 2005 11:51
Picon
Picon
Favicon

Re: tuples and n-ary functions

Hi Steve

On Sun, 2005-07-31 at 17:17 -0500, Stephen Harris wrote:
> Say I have a function
>      val f = (a:Int,b:Int) => a + b
> 
> Is it possible to store a single value that f can be applied to (in  
> other words a tuple value of its arguments)?
> It seems to me that we should be able to pass a pair to f like so:
> 
>      val t = Tuple2(1,2)
>      f(t)  // fails : "wrong number of arguments"
> 
> 
> It would be even more nice if we could write that tuple as just  
> "(1,2)" :)
> 
> Is there a reason preventing this sort of thing?

While unable to argue on the type-theoretic side of your question I can
argue from implementation point of view. Method arguments are
implemented in the usual JVM way. They are explicit and each one is
assigned a slot. Now, a tuple is just an instance of one of the TupleN
familly of classes. Consequently, it is a single value. It will be quite
a performance hit to have all methods with just one argument of the
corresponding tuple type because we'll have to construct tuples for each
method call. A better alternative is for the compiler to allow the
application of a function to a proper tuple and generate the code to
unwrap the tupple to the arguments expected by the method. It doesn't
seem hard to implement but it also has to be typechecked (and lets not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Sackman | 1 Aug 2005 14:24
Picon

Re: implementing Java interfaces that require primitives

On Fri, Jul 29, 2005 at 06:54:03PM +0200, St?phane Micheloud wrote:
> First write a Java file "Comparator.java" declaring
> the same interface as "java.util.Comparator", e.g.
<snip>
> Let's now test it :-)
> 
> class MyComparator with /*java.*/util.Comparator {
>   def compare(o1: Any, o2: Any): Int = 0;
>   override def equals(obj: Any): Boolean = false;
> }
> 
> object main with Application {
>   val x = new MyComparator;
>   ()
> }
> 
> Finally you can just remove the comment around the
> "java." prefix. Thats's it !

Ahh yes, I was getting extends and with wrong. Thanks for your help.

It's a shame that Scala can't do autoboxing of primitives for Java's
sake as in Java 1.5. Would be nice if you could just write true and
allow scala to work out that it really can convert from a scala.Boolean
to a java.lang.Boolean if necessary. Writing java.lang.Boolean.TRUE
repeatedly gets a little boring... ;-)

Thanks for your help,

Matthew
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jamie Webb | 1 Aug 2005 15:30

Re: tuples and n-ary functions

On Sun, Jul 31, 2005 at 05:17:06PM -0500, Stephen Harris wrote:
> Say I have a function
>     val f = (a:Int,b:Int) => a + b
> 
> Is it possible to store a single value that f can be applied to (in  
> other words a tuple value of its arguments)?
> It seems to me that we should be able to pass a pair to f like so:
> 
>     val t = Tuple2(1,2)
>     f(t)  // fails : "wrong number of arguments"

As Nikolay said, there are practical reasons not to use tuples as the
main way to pass multiple arguments, but I see no reason why this
couldn't be provided /in addition/, simply by adding an applyToTuple
method to each of the FunctionN traits.

It would be in some ways nicer to add an overloaded apply method and
get the regular application syntax, but that introduces possible
overload conflicts with methods that are declared to accept tuples.

Ooh... could we have an AnyFunction trait that has an abstract
definition of applyToTuple, such that

    FunctionN[..., R] <: AnyFunction[TupleN[...], R]

Then we could write code that would operate on functions with any
number of parameters.

> It would be even more nice if we could write that tuple as just  
> "(1,2)" :)
(Continue reading)

Permalink | Reply | 0 comments |
headers
burak.emir | 2 Aug 2005 16:05
Picon
Picon
Favicon

"curryable" Re: read-eval-print loop?


> If, as you suggest, functions are implicitly curryable (hey, look, I
> just coined a new word), the partial application bar(1) will be

hardly a new word... :-) http://www.google.ie/search?hl=en&q=curryable&meta=

what about schoenfinkelable, that one seems still available (fresh!)

cheers,
buraq
Permalink | Reply | 0 comments |
headers
Martin Odersky | 2 Aug 2005 14:57
Picon
Picon
Favicon

Re: implementing Java interfaces that require primitives


> It's a shame that Scala can't do autoboxing of primitives for Java's
> sake as in Java 1.5. Would be nice if you could just write true and
> allow scala to work out that it really can convert from a scala.Boolean
> to a java.lang.Boolean if necessary. Writing java.lang.Boolean.TRUE
> repeatedly gets a little boring... ;-)
> 
This one is easy: Just define a view from primitive types to Java's
boxed types. I.e. like:

  def view(x: boolean): java.lang.Boolean = 
    if (x) java.lang.Boolean.TRUE else java.lang.Boolean.FALSE

We should have thought about it and have put these views into
Predef.scala, so that they are accessible to everyone. (Probably we'll
do that for the next release). At the moment, you can still define and import
these views yourself.

Hope this helps

 -- Martin
Permalink | Reply | 0 comments |
headers
Nikolay Mihaylov | 2 Aug 2005 15:29
Picon
Picon
Favicon

Re: read-eval-print loop?

Hi Raoul

On Mon, 2005-08-01 at 10:40 -0700, Raoul Duke wrote:
> It makes me wonder: why is currying done this way?

I think overloading has a role to play here. If you have

  def foo(x: Int) = x + 1;
  def foo(x: Int, y: Int) = x + y;

how do you say what foo(1) means? Ok, we can settle for the more
specific one, but that means you can never partially apply foo(Int,
Int).

Obviously, in similar cases the Scala currying syntax doesn't help much
because for

  def foo(x: Int) = x + 1;
  def foo(x: Int)(y: Int) = x + y;

every application of foo is ambiguous. But consider the following
example:

  def bar(x: Int, y: Int)(s: String) = (x + y).toString() + s;
  def bar(x: Int)(s1: String, s2: String) = s1 + x + s2;;

If, as you suggest, functions are implicitly curryable (hey, look, I
just coined a new word), the partial application bar(1) will be
ambiguous, whereas with the Scala syntax it refers to the second
definition.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Raoul Duke | 1 Aug 2005 19:40
Picon

Re: read-eval-print loop?

> def foo(x: Int)(y: Int): Int = x + y;
> Then, foo(7) will be a value of type Int => Int. If you want to fully
> apply it you write foo(7)(42).

hi Nikolay,

Thank you for the information, I will give it a try! And, many thanks
to everybody working on Scala, it is very interesting, and to you all
who are kindly posting helpful information to the list.

It makes me wonder: why is currying done this way? I'm guessing that
Scala is attempting to make it known that currying is expensive, and
so doesn't want to let it happen anywhere. If that is the case, then
since I am attempting to write a video game, I should avoid currying!

(If currying is not expensive, or even if it is, I wonder if the
compiler could generate N versions of a function where one is the
totally un-curried, and the rest are the progressively curried ones.
There might be the possibility of stripping out the unused curried
versions during some final stage of an application build process?)

(If currying does become more, shall I say, prevalent and usable, I
think it would be interesting to support named currying so any subset
of the function arguments could be curried a la o'caml.)

many thanks,
sincerely.
Permalink | Reply | 3 comments |
headers
robert kuzelj | 2 Aug 2005 20:37
Picon

how to cast?

hi,

yes this is really the question!
or better if not to cast what to do then?

given the following class

class ByteBuffer() extends Serializable
{
  private var buffer_ : Array[Byte] = null;

  def this(_buffer: Array[Byte]) =
  {
    this();
    buffer_ = _buffer;
  }

  def this(_buffer: String) = this(_buffer.getBytes());
  def this(_buffer: StringBuffer) = this(_buffer.toString());
}

and this example code

var buffer = new
ByteBuffer(someJavaObj.thatReturnsAStringButIsDeclaredAsAnObj());

the following compiler error is yield.

scala-a.scala:192: overloaded constructor ByteBuffer of type
()testpack.ByteBuffer <and> (scala.Array[scala.Byte])testpack.ByteBuffer
(Continue reading)

Permalink | Reply | 6 comments |

Gmane