Redline: Smalltalk in 'small talks' ...

26 views
Skip to first unread message

jamesl

unread,
Dec 11, 2010, 9:57:41 PM12/11/10
to JVM Languages
A 'series' of posts on implementing a language on top of the JVM has
been started:
http://blog.redline.st/2010/12/12/redline-smalltalk-in-%E2%80%9Csmall-talks%E2%80%9D/

I hope it is of interest to people on this list.

Rgs, James.

Rémi Forax

unread,
Dec 12, 2010, 7:40:12 AM12/12/10
to jvm-la...@googlegroups.com

Very interesting.

I don't know if you had taken a look to JSR 292
(the package java.dyn of the upcoming jdk7),
if it's not the case you should because it
really simplifies the implementation of a runtime
of a dynamic language.

> Rgs, James.
>

cheers,
R�mi

Robert Fischer

unread,
Dec 12, 2010, 9:08:06 AM12/12/10
to jvm-la...@googlegroups.com
For the record, JSR292 also simplifies the implementation of a
statically-typed functional language.

let f = { bar:String, baz:String -> ... }
let a = f("foo")
let b = f("bar")
let c = b("baz")

That's now just a bunch of very optimizable MethodHandle mangling.

~~ Robert.

> Rémi
>
> --
> You received this message because you are subscribed to the Google Groups
> "JVM Languages" group.
> To post to this group, send email to jvm-la...@googlegroups.com.
> To unsubscribe from this group, send email to
> jvm-language...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/jvm-languages?hl=en.
>
>

John Rose

unread,
Dec 15, 2010, 5:07:53 AM12/15/10
to jvm-la...@googlegroups.com
Thanks, Robert.

I just posted on "Scheme in One Class":

http://blogs.sun.com/jrose/entry/scheme_in_one_class

The idea is to demonstrate how JSR 292 simplifies a toy interpreter.

-- John

jamesl

unread,
Dec 15, 2010, 1:10:43 PM12/15/10
to JVM Languages
Thank you for the reference. When is JSR292 going to be released?

I'm wary of including this and requiring all users of Redline to move
to
the newest JVM, but I personally cant wait for JSR292.

On Dec 12, 11:40 pm, Rémi Forax <fo...@univ-mlv.fr> wrote:
> On 12/12/2010 03:57 AM, jamesl wrote:
>
> > A 'series' of posts on implementing a language on top of the JVM has
> > been started:
> >http://blog.redline.st/2010/12/12/redline-smalltalk-in-%E2%80%9Csmall...

John Rose

unread,
Dec 15, 2010, 3:14:54 PM12/15/10
to jvm-la...@googlegroups.com
On Dec 15, 2010, at 10:10 AM, jamesl wrote:

> Thank you for the reference. When is JSR292 going to be released?

JDK 7. The EG is finalizing the API for public review. A preview is always available here:

http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/

(For something as complex as this, there needs to be continual review and timely commenting. If a prospective user has comments on the API as it stands now, now is the time to figure them out and express them.)

> I'm wary of including this and requiring all users of Redline to move to
> the newest JVM, but I personally cant wait for JSR292.

Me too!

-- John

Per Bothner

unread,
Dec 15, 2010, 3:33:08 PM12/15/10
to jvm-la...@googlegroups.com
[private]

On 12/15/2010 02:07 AM, John Rose wrote:
> I just posted on "Scheme in One Class":
>
> http://blogs.sun.com/jrose/entry/scheme_in_one_class

"Getting at such APIs, randomly and interactively, has been impossible
before JSR 292, at least without statically or dynamically spinning
bytecoded adapters."

Or using reflection. And one might argue that JSR 292 is to some extent
basically "improved and optimizable reflection".

I think most JVM-based languages with a REPL have long been able
to "get at such APIs, randomly and interactively". So I think this
sentence is a bit confusing about exactly what is new.

#|kawa:12|# (define f (java.io.File "Makefile"))
#|kawa:13|# (define p (java.io.FileReader f))
/dev/stdin:13:11: warning - more than one possibly applicable method
'<init>' in java.io.FileReader
candidate: java.io.FileReader
java.io.FileReader.<init>(java.io.FileDescriptor)
candidate: java.io.FileReader java.io.FileReader.<init>(java.io.File)
candidate: java.io.FileReader java.io.FileReader.<init>(java.lang.String)
#|kawa:15|# (set! p (java.io.BufferedReader p))
#|kawa:16|# (write (p:readLine))
/dev/stdin:16:8: warning - no known slot 'readLine' in java.lang.Object
"# Makefile.in generated by automake 1.11.1 from Makefile.am."

The warnings are probably overly conservative (they indicate the compiler
can't determine the specific method at compile-time, so has to use
reflection), but that's a different discussion. They can be turned off
by adding type specifiers:

#|kawa:3|# (define f ::java.io.File (java.io.File "Makefile"))
#|kawa:4|# (define p ::java.io.BufferedReader (java.io.BufferedReader
(java.io.FileReader f)))
#|kawa:5|# (write (p:readLine))
"# Makefile.in generated by automake 1.11.1 from Makefile.am."

(The type specifiers are not needed when evaluating a file, because
then the compiler can know that the variables aren't re-assigned to.)
--
--Per Bothner
p...@bothner.com http://per.bothner.com/

Robert Fischer

unread,
Dec 15, 2010, 3:39:49 PM12/15/10
to jvm-la...@googlegroups.com
Yeah, the cooler part of JSR292 is the ability to muck with the parameter lists conveniently—the MethodHandles class.  Well, that and the ability for the runtime to optimize the calls.

~~ Robert.


--

Per Bothner

unread,
Dec 15, 2010, 3:47:01 PM12/15/10
to jvm-la...@googlegroups.com
Oops, I guess my message wasn't private as intended ...
Luckily it could just as well have been public anyway!

On 12/15/2010 12:39 PM, Robert Fischer wrote:
> Yeah, the cooler part of JSR292 is the ability to muck with the

> parameter lists conveniently�the MethodHandles class. Well, that and


> the ability for the runtime to optimize the calls.
>
> ~~ Robert.
>
> On 15 December 2010 15:33, Per Bothner <p...@bothner.com

> <mailto:p...@bothner.com>> wrote:
>
> [private]

John Rose

unread,
Dec 15, 2010, 5:54:59 PM12/15/10
to jvm-la...@googlegroups.com
On Dec 15, 2010, at 12:33 PM, Per Bothner wrote:

"Getting at such APIs, randomly and interactively, has been impossible
before JSR 292, at least without statically or dynamically spinning bytecoded adapters."

Or using reflection.  And one might argue that JSR 292 is to some extent
basically "improved and optimizable reflection".

It's a fair point, and Mark Evenson (ABCL) has also made it in the blog comments.   I have updated the blog entry.  Thanks!

-- John
Reply all
Reply to author
Forward
0 new messages