Java array class is not kawa Class?

[Yaroslav Kavenchuk-3]

#|kawa:21|# (define a (integer[] 1 2 3 4 5))
#|kawa:22|# a
[1 2 3 4 5]
#|kawa:23|# a:Class
class [Lgnu.math.IntNum;
#|kawa:24|# (a:Class:toString)
Invalid parameter, was: gnu.bytecode.ArrayType cannot be cast to
gnu.bytecode.ClassType
java.lang.ClassCastException: gnu.bytecode.ArrayType cannot be cast to
gnu.bytecode.ClassType
        at
gnu.kawa.functions.GetNamedPart.getNamedPart(GetNamedPart.java:290)
        at gnu.kawa.functions.GetNamedPart.apply2(GetNamedPart.java:245)
        at atInteractiveLevel$23.run(stdin:24)
        at gnu.expr.ModuleExp.evalModule(ModuleExp.java:302)
        at kawa.Shell.run(Shell.java:275)
        at kawa.Shell.run(Shell.java:186)
        at kawa.Shell.run(Shell.java:167)
        at kawa.repl.main(repl.java:870)
#|kawa:26|# a:Class:ComponentType
Invalid parameter, was: gnu.bytecode.ArrayType cannot be cast to
gnu.bytecode.ClassType
java.lang.ClassCastException: gnu.bytecode.ArrayType cannot be cast to
gnu.bytecode.ClassType
        at
gnu.kawa.functions.GetNamedPart.getNamedPart(GetNamedPart.java:290)
...

How to work with ArrayType? How get class of array element?

Thanks!

--
WBR, Yaroslav Kavenchuk.

[Jim White]

Yaroslav Kavenchuk wrote:

> ...
>
> How to work with ArrayType? How get class of array element?

ArrayType derives from ObjectType.

Array types are not classes, as you noticed, because that is just the
Java object model.

ArrayType.getComponentType() gets the Type of the elements.

Also the gnu.bytecode package is not particularly about Kawa The
Language so much as an API to the Java VM bytecode format.

If you're gonna dig around in such low-level stuff, it's probably a good
idea to look at the Kawa source for such details.

I've been lurking with interest on your efforts as I'm also working with
OpenOffice, but I decided to integrate Groovy rather than Kawa.
Although it's still pretty crude, you might want to check it out.

http://www.ifcx.org/

Jim

[Yaroslav Kavenchuk-3]

2008/3/1, Jim White wrote:
>  > How to work with ArrayType? How get class of array element?
...
>
>  ArrayType.getComponentType() gets the Type of the elements.
...
>
>  If you're gonna dig around in such low-level stuff, it's probably a good
>  idea to look at the Kawa source for such details.

I do not find how get ArrayType from array :(

#|kawa:6|# (instance? (integer[] 1 2):class gnu.bytecode.ArrayType)
false

I was looking bad?

>  I've been lurking with interest on your efforts as I'm also working with
>  OpenOffice, but I decided to integrate Groovy rather than Kawa.
>  Although it's still pretty crude, you might want to check it out.
>
>  http://www.ifcx.org/

I saw your project, and tried to use it.

Why did you choose Groovy rather than Kawa or Clojure?

Thanks for your answer!

--
WBR, Yaroslav Kavenchuk.

[Jim White]

Yaroslav Kavenchuk wrote:

> 2008/3/1, Jim White wrote:
>
>> > How to work with ArrayType? How get class of array element?
> ...
>
>> ArrayType.getComponentType() gets the Type of the elements.
> ...
>
>> If you're gonna dig around in such low-level stuff, it's probably a good
>> idea to look at the Kawa source for such details.
>
> I do not find how get ArrayType from array :(

Me either.

AFAIK it is just used internally by the Kawa compiler to generate JVM
bytecode.

If you want to do reflective stuff, then all I can suggest is using the
the standard Java methods (java.lang.Class, java.reflect.*, etc.).

Per wrote some explanation of Kawa's inner workings a long while ago.
They may be helpful to you.

http://www.gnu.org/software/kawa/index.html#Top

http://www.gnu.org/software/kawa/internals/index.html

http://per.bothner.com/papers/index.html

> #|kawa:6|# (instance? (integer[] 1 2):class gnu.bytecode.ArrayType)
> false
>
> I was looking bad?

Your example makes me have to update my Kawa to SVN, but that's not such
a bad thing...

So I fiddled around and suggest this:

#|kawa:9|# (java.lang.Class:isArray (integer[] 1 2):class)
true
#|kawa:10|# (java.lang.Class:getComponentType (integer[] 1 2):class)
class gnu.math.IntNum

Dealing with primitive types is a bit fussier:

#|kawa:24|# (instance? (java.lang.Class:getComponentType (int[] 1
2):class) <java.lang.Class>)
true
#|kawa:25|# (java.lang.Class:getComponentType (int[] 1 2):class)
int
#|kawa:26|# (instance? (java.lang.Class:getComponentType (int[] 1
2):class) <java.lang.Class>)
true
#|kawa:27|# (java.lang.Class:isPrimitive
(java.lang.Class:getComponentType (int[] 1 2):class))
true
#|kawa:29|# (eq? (java.lang.Class:getComponentType (int[] 1 2):class)
java.lang.Integer:TYPE)
#t

AFAIK, the only way to figure out which particular primitive type is
used is to compare against the various java.lang.*:TYPE constants.
Notice that those constants refer to the corresponding primitive for the
boxed type.

I see that some methods return 'true' and some '#t'.  I know that must
have something to do with which type is actually returned by the
methods, although I'm not sure why two Kawa methods ('eq?' and
'instance?') should have different results.

>> I've been lurking with interest on your efforts as I'm also working with
>> OpenOffice, but I decided to integrate Groovy rather than Kawa.
>> Although it's still pretty crude, you might want to check it out.
>>
>> http://www.ifcx.org/
>
> I saw your project, and tried to use it.

Did it work?

If have trouble and/or success please do let me know on the IFCX forum.

http://sourceforge.net/forum/forum.php?forum_id=708126

> Why did you choose Groovy rather than Kawa or Clojure?

Groovy has very compact syntax for doing things with Java classes and
collections and I think it is the best of the currently hot "scripting"
languages (JRuby, Jython, and Groovy) for people who already know Java.

Groovy also has the "category" mechanism which enables adding API to
existing classes which can be used to make the OpenOffice UNO API more
palatable.

Since I've been a Lisper for about 30 years now I've come to accept that
folks are never gonna get excited about a language with TMDRP (Too Many
Damned Right Parenthesis).  While resurrecting UCI MLISP or porting
Dylan to Kawa are both interesting possibilities, I'm more interested in
applications of such things these days.

My plans for IFCX Wings include supporting any programming language,
starting with those that work on the JVM, and I have a hacked up version
that shows both Groovy and Scheme (Kawa) in the same document.

Jim

[Yaroslav Kavenchuk-3]

2008/3/1, Jim White wrote:

>  So I fiddled around and suggest this:
>
>  #|kawa:9|# (java.lang.Class:isArray (integer[] 1 2):class)
>  true
>  #|kawa:10|# (java.lang.Class:getComponentType (integer[] 1 2):class)
>  class gnu.math.IntNum
>
>  Dealing with primitive types is a bit fussier:
>
>  #|kawa:24|# (instance? (java.lang.Class:getComponentType (int[] 1
>  2):class) <java.lang.Class>)
>  true
>  #|kawa:25|# (java.lang.Class:getComponentType (int[] 1 2):class)
>  int
>  #|kawa:26|# (instance? (java.lang.Class:getComponentType (int[] 1
>  2):class) <java.lang.Class>)
>  true
>  #|kawa:27|# (java.lang.Class:isPrimitive
>  (java.lang.Class:getComponentType (int[] 1 2):class))
>  true
>  #|kawa:29|# (eq? (java.lang.Class:getComponentType (int[] 1 2):class)
>  java.lang.Integer:TYPE)
>  #t

Oops, I not guessed use the 'native' methods:

#|kawa:24|# (*:getMethods java.lang.Class)
...
public native java.lang.Class java.lang.Class.getComponentType()
...

as static. Many-many thansk!

> Did it work?

Yes! But... very slowly. Especially startup (initialization).

>  If have trouble and/or success please do let me know on the IFCX forum.
>

I wrote: http://sourceforge.net/forum/message.php?msg_id=4573444   :)

>  > Why did you choose Groovy rather than Kawa or Clojure?
>
>
> Groovy has very compact syntax for doing things with Java classes and
>  collections and I think it is the best of the currently hot "scripting"
>  languages (JRuby, Jython, and Groovy) for people who already know Java.

What you think about JavaFX?

>  Since I've been a Lisper for about 30 years now I've come to accept that
>  folks are never gonna get excited about a language with TMDRP (Too Many
>  Damned Right Parenthesis).  While resurrecting UCI MLISP or porting
>  Dylan to Kawa are both interesting possibilities, I'm more interested in
>  applications of such things these days.

I very glad to hear it :)

>  My plans for IFCX Wings include supporting any programming language,
>  starting with those that work on the JVM, and I have a hacked up version
>  that shows both Groovy and Scheme (Kawa) in the same document.

Good luck!

--
WBR, Yaroslav Kavenchuk.

[Per Bothner]

The problem is that core Java "reflection" is poorly designed.
When I need to work with an object that represents a Java class,
it can come from (at least) 3 different sources:

(1) A compiler needs to deal with a class as seen in the source
code.  For example, when Kawa sees a define-simple-class it
creates a data structure representing the various Scheme
properties (a ClassExp), which it thens translates into a
lower-level data structure representing fields and methods
(a ClassType).

(2) A class file contains another representation of a class.

(3) The JVM creates a java.lang.Class object, which is used
by both the JVM and reflection.

The life-cycle is from (1) to (2) to (3).  The gnu.bytecode
API is designed to be useful for all 3 purposes:  You can
create a gnu.bytecode.ClassType using reflection (i.e. from
a java.lang.Class); from reading a .class file; or the
compiler can construct one as needed from source code.

So when you ask "how do you get ArrayType from array",
I could answer your question:
   Type.make(array.getClass())

But the real question is: Why do you want it?  What
are you planning on doing with the ArrayType?

 > I see that some methods return 'true' and some '#t'.  I know that
 > must have something to do with which type is actually returned by the
 > methods, although I'm not sure why two Kawa methods ('eq?' and
 > 'instance?') should have different results.

Actually, it's bug in output formatting (printing).  If you do:

   (define r (....))

and then print r, you'll find that #t/#f is printed.

Re-doing output formatting to avoid this anomaly is on the
list of things to fix before the 1.10 release.
--
        --Per Bothner
per@...   http://per.bothner.com/

[Per Bothner]

Jim White wrote:
> Groovy has very compact syntax for doing things with Java classes and
> collections

Actually, Kawa's is pretty darn compact, too:

#|kawa:1|# (define v (vector 3 4 5 6))
#|kawa:2|# (set! (v 3) (v 2))
#|kawa:3|# v
#(3 4 5 5)
#|kawa:4|# v:size
4
|kawa:5|# v:class
class gnu.lists.FVector
#|kawa:9|# (set! a (integer[] 9 8 7 6))
#|kawa:10|# (set! (a 1) (a 0))
#|kawa:11|# a
[9 9 7 6]
#|kawa:14|# (java.lang.Math:cos 3.4)
-0.9667981925794611
--
        --Per Bothner
per@...   http://per.bothner.com/

[Jim White]

Yaroslav Kavenchuk wrote:

> 2008/3/1, Jim White wrote:
>
>> So I fiddled around and suggest this:
>>
>> #|kawa:9|# (java.lang.Class:isArray (integer[] 1 2):class)
>> true
>> #|kawa:10|# (java.lang.Class:getComponentType (integer[] 1 2):class)
>> class gnu.math.IntNum
>>
>> Dealing with primitive types is a bit fussier:
>>
>> #|kawa:24|# (instance? (java.lang.Class:getComponentType (int[] 1
>> 2):class) <java.lang.Class>)
>> true
>> #|kawa:25|# (java.lang.Class:getComponentType (int[] 1 2):class)
>> int
>> #|kawa:26|# (instance? (java.lang.Class:getComponentType (int[] 1
>> 2):class) <java.lang.Class>)
>> true
>> #|kawa:27|# (java.lang.Class:isPrimitive
>> (java.lang.Class:getComponentType (int[] 1 2):class))
>> true
>> #|kawa:29|# (eq? (java.lang.Class:getComponentType (int[] 1 2):class)
>> java.lang.Integer:TYPE)
>> #t
>
>
> Oops, I not guessed use the 'native' methods:
>
> #|kawa:24|# (*:getMethods java.lang.Class)
> ...
> public native java.lang.Class java.lang.Class.getComponentType()
> ...
>
> as static. Many-many thansk!
>
>>Did it work?
>
> Yes! But... very slowly. Especially startup (initialization).

Yeah, the first thing evaluated has to load Groovy and compile the Wings
macro.  Also prior to 0.4 (available by doing "Update" in the
"Tools:Extensions..." dialog if you've installed 0.3) the compiled
macros weren't cached.  And of course OpenOffice uses a lot of resources.

But once initialized, GroovyForOpenOffice performance just depends on
your JVM.

>> If have trouble and/or success please do let me know on the IFCX forum.
>
> I wrote: http://sourceforge.net/forum/message.php?msg_id=4573444   :)

Ah yes!

>...
> What you think about JavaFX?

No reason to live.  ;-)

It does have static typing with type inference so performance is good,
but it has funky syntax and so is not better than Jython or JRuby and
for folks who like those features there is Scala.  It does have a nifty
binding mechanism, but other languages will be getting that too (there's
a JSR for it).  The only people likely to buy in to JavaFX are the Java
ME cell phone licensees.

I am pleased to see that Sun has recognized that Java needs to work as
well as Flash if it is going to win back a bit of the web browser/rich
client territory (which initially was given completely and freely to
Java by Netscape, but then bungled by McNealy and Sun marketroids).

But the best thing about JavaFX is that it caused Sun to hire Per!  :-)

Jim

[Jim White]

Per Bothner wrote:

> Jim White wrote:
>
>> Groovy has very compact syntax for doing things with Java classes and
>> collections
>
> Actually, Kawa's is pretty darn compact, too:

As you well know, I'm a long time Lisper and Kawa supporter, but
S-expression notation is just not gonna get most folks excited.  But of
course there's no accounting for taste since many seem to love it when
you more than double up the amount of notation and use XML rather than
S-expressions.  Although folks do seem to be getting tired of verbosity.

> #|kawa:1|# (define v (vector 3 4 5 6))
> #|kawa:2|# (set! (v 3) (v 2))
> #|kawa:3|# v
> #(3 4 5 5)
> #|kawa:4|# v:size
> 4
> |kawa:5|# v:class
> class gnu.lists.FVector
> #|kawa:9|# (set! a (integer[] 9 8 7 6))
> #|kawa:10|# (set! (a 1) (a 0))
> #|kawa:11|# a
> [9 9 7 6]
> #|kawa:14|# (java.lang.Math:cos 3.4)
> -0.9667981925794611

The Groovy version of that:

groovy:000> v = [3, 4, 5, 6]
===> [3, 4, 5, 6]
groovy:000> v[3] = v[2]
===> 5
groovy:000> v
===> [3, 4, 5, 5]
groovy:000> v.size()
===> 4
groovy:000> v.class
===> class java.util.ArrayList
groovy:000> a = (9..6) as int[]
===> [I@c17f5a
groovy:000> a[1] = a[0]
===> 9

Notice in the construction of a I used the fact that ranges are lists,
and since we've been discussing arrays I showed it using a primitive
type for the components.

As you see the default display for arrays doesn't show them as lists
(they might be rather large after all and Groovy doesn't have much
support for pretty printing).  But you can say:

groovy:000> a as List
===> [9, 9, 7, 6]

A sublist:

groovy:000> a[2..1]
===> [7, 9]

And what I don't show here is Groovy's notion of Truth and Iterable are
weakly typed and support many convenient default conversions.  That can
make for very terse code.  Plus there is autoproxying and adapters for
closures and other cool hacks to eliminate much of the fiddly glue code
folks have to write to overcome strong typing.

So for folks familiar with Java, Groovy syntax is a lot more
comprehensible, and most importantly, for language features that are in
common between Java and Groovy the syntax is the same (in fact most Java
source is acceptable Groovy).  That isn't true for LISP family, Ruby,
Python, JavaFX, etc.

I would rather have a language with well-developed semantics like
Scheme, but as my preference for Groovy over Scala shows, for my current
applications it turns out yet again that worse is better.

Jim

[Per Bothner]

Jim White wrote:
> As you well know, I'm a long time Lisper and Kawa supporter, but
> S-expression notation is just not gonna get most folks excited.

I have mixed feelings about S-expressions, myself.  I like having an
extensible syntax and no reserved identifiers.  Otherwise, I'd like to
make parentheses optional except for grouping.  (If you start Kawa
with the --q2 switch, you get an experimental hybrid line-oriented
syntax, but it's too incomplete/inconsistent for real use.)

One way in which Kawa is more compact than Groovy is in property acesses
and "beans".  From http://groovy.codehaus.org/Groovy+Beans

Groovy:
         Customer customer = new Customer();
         customer.setId(1);
         customer.setName("Gromit");
         customer.setDob(new Date());

         println("Hello " + customer.getName());

Kawa:

(define customer (Customer id: 1 name: "Gromit" dob: (Date)))
(format "Hello %s%~" customer:name)


Class definition:

(define-class Customer ()
   (id :: <integer>)
   (name :: <string>)
   (dob :: <java.util.Date>))

However, I agree that Groovy seems a nice enough language, with
some nice ideas.
--
        --Per Bothner
per@...   http://per.bothner.com/

[Jim White]

Per Bothner wrote:

> Jim White wrote:
>
>> As you well know, I'm a long time Lisper and Kawa supporter, but
>> S-expression notation is just not gonna get most folks excited.
>
> I have mixed feelings about S-expressions, myself.  I like having an
> extensible syntax and no reserved identifiers.  Otherwise, I'd like to
> make parentheses optional except for grouping.  (If you start Kawa
> with the --q2 switch, you get an experimental hybrid line-oriented
> syntax, but it's too incomplete/inconsistent for real use.)
> ...

While I was at UCI back in the heyday of the PDP-10, Jim Meehan put the
finishing touches on the UCI version of MLISP which delivered on
McCarthy's original idea for an m-notation that was well-specified wrt.
s-expressions and  the inverse transformations were unique (so that
roundtripping resulted in the original form).

It would be nice to resurrect that code (and it's manual) if a
machine-readable copy could be found.  I've done some cursory looking
and no luck.

I am planning to create yet another language, although it's intention is
to integrate other languages rather than being something to try and get
folks to code for itself.  The basic idea is a LISP-in-RDF, or GRASP if
you will (graph processing).

One of the handy things already available for RDF is a variety of nice
encodings like N3 and Turtle.

http://www.w3.org/DesignIssues/Notation3.html

http://www.dajobe.org/2004/01/turtle/#sec-examples

http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/#ntriples

Also this idea has already been implemented as Adenine as part of the
Haystack project, although I don't know yet whether I'll be able to
build on that directly or not.

http://groups.csail.mit.edu/haystack/developers/adenine.html

http://haystack.lcs.mit.edu/papers/sow2002-adenine.pdf

Jim