On Sep 30, 2007, at 2:30 AM, Charles Oliver Nutter wrote:
> JRuby's main compiler is complete, so I'm starting to kick around
> ideas for a second compiler.
>
> The goal of the second compiler would be to produce normal-looking
> Java classes that are actually just Ruby code underneath.
> Constructing them in the normal Java way would invoke initialize;
> calling methods in the normal Java way would dynamically call the
> associated method.
>
> I talk about it in the second half of this post:
>
> http://headius.blogspot.com/2007/09/...-complete.html
>
> Now before anyone cries foul, this is not about adding static
> typing to Ruby; it's about finding a way to specify what types
> should be inserted into the generated Java class to make things
> easy on the Java side, while avoiding incompatible changes to JRuby.
>
> Since so many of you have a better perception of beauty in DSL-like
> syntaxes than I do, I figured you might have a good suggestion.
>
> The first version I proposed on the blog would be a simple map in
> the class body of the form
>
> {<return type> => [<arg type 1>, <arg type 2> ...]}
>
> as in
>
> {String => [Integer, Array]}
> def mymethod(i, a) ...
>
> which would appear to Java code as
>
> public String mymethod(Integer i, List a) { ...
>
> or perhaps
>
> public String mymethod(int i, List a) { ...
>
> But I know it's not particularly pretty. So here's the requirements:
>
> - provide a way to specify the types of an immediately-following
> method definition; this is only going to be a compiler hint, so it
> doesn't have to (and perhaps should avoid) having any side-effects.
> - have no lasting side-effects when run nomally. The above code
> would just produce a hash that gets immediately thrown away if run
> in e.g. Matz's Ruby.
> - not require any syntactic or library changes to Ruby, so the same
> code can run unmodified on any implementation.
>
> Ideas?
>
my thoughts are that this will lead to other enhancements - compiler
hints - so why not invent some sort of unifying syntax up front as
other compilers have. for instance
pragma :mymethod do |m|
m[String, Array] => String
m[Integer, Array] => Integer
end
so this is specifying two signatures for a polymorphic method. of
course you'd have a shortcut
signature :mymethod, [String, Array] => Integer
extending the building method class for this is very appealing
Method(:mymethod).pragma do
map [String, Array] => String,
[Integer, Array] => Integer
end
where to block above is defined thusly
class Method
def pragma &block
(( @pragma ||= Pragma.new self )).configure &block
end
class Pragma
def initialize method
@method = method
@signatures = []
@dsl = DSL.new self
end
class DSL
def initialize pragma
@pragma = pragma
end
def configure &block
instance_eval &block
end
def map sig = {}
sig.each do |argv, returned|
@pragma.signatures << [argv, returned]
end
end
end
end
end
i like the idea of sticking it into Method and pulling the DSL out in
it's own namespace for the instance_eval lets you have a really
powerful syntax. for instance this can work:
Method(:mymethod).pragma do
map variardic => void
end
simply by
class Module
class Pragma
class DSL
( VARIARDIC = Object.new ).freeze
( VOID = Object.new ).freeze
def variardic() VARIARDIC end
def void() VOID end
end
end
end
it's unrelated, but you might one or two idea from this:
http://codeforpeople.com/lib/ruby/pa...s-0.3.0/README
it's bit rotted a bit, but at one time i put a bit of thought into
what the various types of ruby arglists could be and how to manage
that compactly.
keep up the good work on jruby.
cheers.
a @
http://drawohara.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
Similar Threads
