headers
Sven Eric Panitz | 1 Apr 2006 18:31

verify error? and non-strict parameter notation

Hello all.
After some months I eventually found time to play a bit around
with scala again. Two things I came across today:

1)
Unfortunately, when running one of my scala programs I get a verify error:

java.lang.VerifyError: (class: name/panitz/ki/InformedSlide$$anonfun$0,
method: apply signature: (I)V) Illegal use of nonvirtual function call

I wonder if this could possibly be due to a compiler error (or maybe
I did something stupid)? I checked the
bug data base, but could not find any similar reports.
Does this look like something known, or shoud I try to prepare a proper
bug report?

2)
When I did some scala programming last year, it was possible to mark  
parameters
as non strict by way of the keyword def.
A function definition like:
   def cond(a:Boolean,def x:Int,def y:Int)= if (a) x else y
was possible. This seems no longer to be valid scala, however I did not
find any mentioning about this in the change logs. Is there a new way to
have non-strict function parameters apart from defining them as function:
   def cond(a:Boolean,x:()=>Int,y:()=>Int)= if (a) x() else y()

Sven Eric

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
martin odersky | 1 Apr 2006 18:53
Picon
Picon
Favicon

Re: verify error? and non-strict parameter notation

Sven Eric Panitz wrote:
> Hello all.
> After some months I eventually found time to play a bit around
> with scala again. Two things I came across today:
>
> 1)
> Unfortunately, when running one of my scala programs I get a verify 
> error:
>
> java.lang.VerifyError: (class: name/panitz/ki/InformedSlide$$anonfun$0,
> method: apply signature: (I)V) Illegal use of nonvirtual function call
>
This looks like a bug. Can you file a bug report, or send us the program 
so that we can look at it?
> I wonder if this could possibly be due to a compiler error (or maybe
> I did something stupid)? I checked the
> bug data base, but could not find any similar reports.
> Does this look like something known, or shoud I try to prepare a proper
> bug report?
>
> 2)
> When I did some scala programming last year, it was possible to mark  
> parameters
> as non strict by way of the keyword def.
> A function definition like:
>   def cond(a:Boolean,def x:Int,def y:Int)= if (a) x else y
> was possible. This seems no longer to be valid scala, however I did not
> find any mentioning about this in the change logs. Is there a new way to
> have non-strict function parameters apart from defining them as function:
>   def cond(a:Boolean,x:()=>Int,y:()=>Int)= if (a) x() else y()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Judson, Ross | 2 Apr 2006 01:59
Favicon

sbazgui

...provides a simple GUI to some of sbaz's functionality (thanks to Lex
for a clean library -- I did not have a single problem while putting
sbazgui together.

sbaz install sbazgui

...will give you 0.1, and make it exceptionally convenient for you to
stay up to date.  Note that I have only tested on XP so far; I'll have
to get some Linux installed and see what happens -- it should be OK, as
it is quite "vanilla".  Note that sbazgui looks particularly good if you
have the Substance Look and Feel installed as a Java extension.  

Start it with "sbazgui", and ignore the ugly console junk that will be
gone by 0.2 ;)  The first time you run you'll be asked to find your sbaz
directory (mine is d:\scala-2.1.0); that value is stored with Java's
preferences facility.

sbazgui always retrieves the latest package list on startup, shows you
what you have installed, and where you can update.  It can install
individual packages, update them, or upgrade all (corresponding to sbaz
commands).  The gui clears away some of the version information so you
can see what you have, and what the latest version is.

sbazgui took about six hours (including sbaz packaging) to write in
Sean's Eclipse environment, and a good part of that was spent on trying
various forms of Scala syntax to handle common GUI issues.  All in all,
it's going to be depressing the next time I write GUI code in
Java...I've got premonitions of irritation already.  ;)

Once you get the feel of the language _and the type system_, Scala's "it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ittay Dror | 2 Apr 2006 06:39

question about syntax

Hi,

I've been reading about Scala and I'm finding it is very interesting. However, I'm confused by the syntax of functions:

- 'def v: int = 1' defines a function that returns an int (right?), but the signature (for accepting it in
other functions) is () => int. why then not define 'def v: () => int = 1'? that way, it is compatible with
defining a variable 'var v: int = 1'

- 'def v(x: int)(y: int): int = ...' defines a function that accepts an int and returns a function that
accepts an int and returns an int. why then not use the syntax 'def v(x: int) : int => int = ...', or 'def v: int
=> (int => int) = ...'

- constructors: how can a class have more than one constructor?

Thanx,
Ittay

--

-- 
===================================
Ittay Dror 
openQRM Team Leader, 
R&D, Qlusters Inc.
ittayd <at> qlusters.com
+972-3-6081994 Fax: +972-3-6081841

http://www.openQRM.org
- Keeps your Data-Center Up and Running
Permalink | Reply | 1 comment |
headers
Lex Spoon | 2 Apr 2006 14:03
Picon
Favicon

Re: question about syntax

Ittay Dror <ittayd <at> qlusters.com> writes:
> I've been reading about Scala and I'm finding it is very interesting. However, I'm confused by the syntax
of functions:
> 
> - 'def v: int = 1' defines a function that returns an int (right?),
> but the signature (for accepting it in other functions) is () =>
> int. why then not define 'def v: () => int = 1'? that way, it is
> compatible with defining a variable 'var v: int = 1'
> 
> - 'def v(x: int)(y: int): int = ...' defines a function that accepts
> an int and returns a function that accepts an int and returns an
> int. why then not use the syntax 'def v(x: int) : int => int = ...',
> or 'def v: int => (int => int) = ...'

A def always gives you a type Left=>Right for some Left and Right.  So
with:

  def v: int = 1

Right is obviously int.  Left, in this case, is the empty argument
list () .

For your def v example, you could in fact write it out longer.

  def v(x: int)(y: int): int = ...  /* original */
  def v(x: int): int=>int = y:int => ...   /* modified */

Notice that the first one has a (y: int) before the equals sign
while the second one has "y:int =>" after the equals sign.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Debasish Ghosh | 2 Apr 2006 10:28
Picon
Favicon
Gravatar

Mixins in Scala

Hi -

I have been trying to spread the good word about Scala to the computing
fraternity in general and our organization in particular. I have started posting
blog entries about Scala in my personal blog. The last post which I made
discusses mixins and traits of Scala wrt class composition and compares this
Scala feature with similar features of C++, Java and Ruby. I myself am not an
expert in Scala, but I have been trying to dig deep and make my hands dirty with
the various innards of the language. I really like what I see and I believe
Scala has the potential to make it as the language of the future.

I would request you all to have a look at my posts about scala in my blog. The
blog url is http://debasishg.blogspot.com. Chcekc out entries with category
"scala". The post about mixins is at
http://debasishg.blogspot.com/2006/04/scala-compose-classes-with-mixins.html.
Will appreciate any feedback, comments and criticisms on the subject.

Cheers.
- DG
Permalink | Reply | 0 comments |
headers
Alan Lawrence | 2 Apr 2006 23:14
Picon
Picon
Favicon

Irrefutable patterns??

Hi,

Today I tried compiling the following:

package bugtest2;

object Test2 {
     def foo(iter : Iterable[Tuple2[String,int]]) =
         for (val Tuple2(s,i) <- iter)
             System.out.println(s);
}

My understanding was that Tuple2(s,i) would be an irrefutable pattern  
here (i.e. for type Tuple2[String,int], an element of an Iterable 
[Tuple2[String,int]]), by section 8.1 of the scala language reference  
(page 81) point 3: the pattern p is a constructor pattern Tuple2 
(s,i), the type Tuple2[String,int] is an instance of class Tuple2,  
the primary constructor of type Tuple2[String,int] has argument types  
(String,int), and patterns s and i are irrefutable for types String  
and int by being variable patterns (point 1). However, trying to  
compile it I get the following error:

Test2.scala:5 error: value filter is not a member of scala.Iterable 
[scala.Tuple2[java.lang.String,scala.Int]]
         for (val Tuple2(s,i) <- iter)
              ^

which indicates that the compiler is using the translation of page  
62: "every generator 'val p <- e', where p is not irrefutable for the  
type of e, is replaced by 'val p <- e.filter { case p => true; case _
(Continue reading)

Permalink | Reply | 2 comments |
headers
Burak Emir | 2 Apr 2006 23:38
Picon
Picon
Favicon

Re: Irrefutable patterns??

Hello Alan,

Good catch. The pattern is sure enough an irrefutable pattern. 
Unfortunately, translation of for-comprehension happens already in the 
parser, so the compiler doesn't actually know anything about types yet. 
And since we do probably not  optimize away the filter method  (that 
would be impossible to specify -- what if the user writer x.filter 
(true) but the class of x does not have a member called filter?), you 
end up with "erroneous code".

If you're curious what your trees look like after parsing, try 
"-print:parse". Note that after parsing there is no such thing as a 
for-comprehension left.

The best workaround for now is of course to put the match inside the 
body. It looks like we have to search for a new translation of 
for-comprehensions, or leave them untouched until after typechecking (my 
preference). It's quite strange that we did not run into this before.

cheers,
Burak

Alan Lawrence wrote:

> Hi,
>
> Today I tried compiling the following:
>
> package bugtest2;
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
martin odersky | 2 Apr 2006 23:57
Picon
Picon
Favicon

Re: Irrefutable patterns??

Burak Emir wrote:
> Hello Alan,
>
> Good catch. The pattern is sure enough an irrefutable pattern. 
> Unfortunately, translation of for-comprehension happens already in the 
> parser, so the compiler doesn't actually know anything about types 
> yet. And since we do probably not  optimize away the filter method  
> (that would be impossible to specify -- what if the user writer 
> x.filter (true) but the class of x does not have a member called 
> filter?), you end up with "erroneous code".
>
I also think this is a bug. What happens is that the parser maps this to 
a filter method, which would then be
optimized away by the type checker. Note that only the type checker, not 
the parser can detect that Tuple2 is irrefutable. The problem is that 
between these two points in time the type checker will complain about a 
missing `filter' method. The best solution for this would be to expand 
for-comprehensions only after type checking.

 -- Martin
Permalink | Reply | 0 comments |
headers
Christian Plesner Hansen | 3 Apr 2006 14:27

Pattern matching

Hi,
I've written a critical comment about Scala's pattern matching mechanism
(http://blog.quenta.org/2006/03/match.html) which in essence says that I think
way too many restrictions are put on case classes and their class hierarchies. 
If anyone on this list feels like discussing this I would be very interested to
hear wheter you think it makes sense or if it's a load of dingo's kidneys.

-- Christian
Permalink | Reply | 0 comments |

Gmane