Re: [Cardinal-dev] Questions, ideas and thoughts

[Dan Sugalski]

At 8:44 PM +0200 5/15/02, Erik Bågfors wrote:
> The whole point of running languages on another VM/interpreter than the
> default one is to be able to do some cool inter-language-stuff.
>
> So writing my really really small basic-like language I started to think
> how I could call ruby or perl-code from it and quickly realized that it
> needed to understand objects in some way. This can be done very easy and
> without putting objects into the language itself like the following

I'm glad you're doing this--this is the sort of thing we need to work
out now, rather than in a few months. That would Be Bad. :)

I think I can answer some of your questions, and I think we need to
come up with some answers to the rest.


> # Ruby code
> class TestClass
>         def initialize(string)
>                 @string = string
>         end
>         def a(string)
>                 puts "Initialized with " + @string
>                 puts "Called a with " + string
>         end
> end
>
> # Called from ruby code
> test = TestClass.new("test")
> test.a("more test")                           # This would output
>                                         # Initialized with test
>                                         # Called with more test
>
> # My basic-code could look like this
> TEST = TestClass_new("test")
> TestClass_a(TEST, "more test")               # which would give it a
> gtk+-like syntax.
>
> That should work shouldn't it?

Looks like it, yep. Assuming you're using _ to split parts of the
namespace in BASIC. (Unless you want to invent an OO extension to
BASIC, in which case you can't imagine how much I don't want to know
about it. :)


> So.. in that way we should be able to solve the
> none-oo-language-using-objects-problem.

Yup. Prototypes will help as well in some cases, and there's always
the potential for a generic method call function, along the lines of
what Objective-C uses. (call_method(object, method, param1...paramX))
> This needs some kind of naming
> convention for how classes/object/methods should be named.

Nope. Parrot places no limitations on, nor requirements on, names for
things. That's a language issue. (Granted, writing your code with
only Tengwar characters will make it difficult to use elsewhere, but
that's not Parrot's problem)

> How are
> classes and objects defined in parrot and parrot assembly??

Classes, as far as parrot is concerned, are a pretty simple thing.
There's a namespace with the same name as the class with some
meta-information attached to it (author ID, version, and a few other
things), a potential mapping to a global name (for cases where you've
got multiple versions of the same class) and that's about it.

There may be a newclass opcode to set things up, but I'm not sure
about that yet.

> what about this code in ruby?
> def four_times
>         yeild
>         yeild
>         yeild
>         yeild
> end
>
> How would I call this code from my minibasic? or from perl?? or from
> scheme? Is that even possible? rubys block are wonderfull and I'd like
> to use them alot :)

As far as parrot's concerned, that's just a sub that takes a code
reference as a parameter. From perl you'd call it like:

   $foo->four_times(\&some_sub, @list_o_parameters);

I don't speak Scheme-ese, but I expect defs would be involved somehow.

The low-level prototype would be an optional leading code reference,
and then parameters. There's a slot in the calling convention for it,
I think.


> Another example is that in ruby all classes need to start with a capital
> character.  That means that a class written in another language that
> doesn't have this restriction is either a) unusable or b) usable if we
> rename it somehow of c) usable if we change ruby.  What would we do
> here?

Probably B or C. Possibly D. Parrot itself doesn't care--it's case
sensitive, but doesn't put any meaning to case, since that's really
not something it should. That'd really be Matz's call on how to
handle it.

> One change I think we will have to do is true and false-values.  In ruby
> only "nil" and "false" evaluates as false in if/while/for/.... If I use
> something from perl that is false I think it must evaluate as false in
> ruby also.  This will be quite easy to do since parrot kinda solves this
> for us, but it will feel wierd when 0 can be false again (if it's not a
> Ruby 0 :) )

Truth and falsehood will be properties placed on values, so you can
have a value of 37 that's still false. There's a get_boolean entry to
the PMC's vtable, so you can define truth and falsehood on a
per-class basis.

> Another question is regarding types in the languages.  For example
>
> # Perl-code
> sub hello  { "1234" }
> sub hello2 { 1234 }
>
> $h = hello;
> $h2 = hello2;
> print "number equal\n" if $h == $h2;
> print "string equal\n" if $h eq $h2;
> # End code
>
> This code will produce the output
> number equal
> string equal
>
> because hello and hello2 both outputs a scalar, which in perl is both
> string and numbers.

Right. Perhaps the easiest thing to do is treat the output of
non-native-language functions/methods/whatevers as overloaded, as
that's what they are.

> This would require some kind of magic conversion within parrot.  Of
> course this also get's very interesting because you'll get strings back
> from mathematical functions.

At the moment I'm considering some sort of automatic thunking layer

> The other way is also interesting.  Calling ruby from perl. For example
> without the magical conversion I talk about above:
>
> # Ruby code
> def constant_number
>         0
> end
>
> # perl code
> print "true" if (constant_number);
>
> Will ALWAYS print true since RubyIntegers are always true, even the
> number 0.  That will really confuse the perl-guys.

They can cope. :) Perl 6 will make truth and falsehood potentially
independent of a variable's numeric or string value, so that's not
something completely foreign.

> How do we call functions from ruby? In ruby (as all real oo-languages)
> there is really no such thing as functions, only methods.  Do we just
> throw the functions as methods into the Kernel class?  That seams
> logical since that's kindof what ruby does if you define a method
> without saying what class it should belong to.

How do you call functions in ruby now? If, for example, someone does
a wrapper around a C library that's not OO?

> Also, where do I find good info on how functions/methods are supposed to
> work in parrot.  The examples on parrotcode.org shows some basic ideas
> but there are lot's of things missing and I know there has been talk
> about this lately in perl6-internals but I don't know what the final
> word was.

I committed the calling conventions PDD--check in docs/pdd for
details. It's not enough yet, but we're getting there. The global
namespace code just went in, so subs and methods will follow soon.
--
                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
address@hidden                         have teddy bears and even
                                      teddy bears get drunk