Re: multiple languages clarification - newbie
- Original Message -
From: Richard Jolly [EMAIL PROTECTED]
Date: Wednesday, September 8, 2004 6:02 pm
Subject: multiple languages clarification - newbie
Hi,
newbie
Can someone provide clarification on what mixing languages will
look
like in practice, or point me to where its explained?
I think you mean mixed language libraries/modules
rather than mixed languages (to mix languages, you'd
need to do a multi-arg eval like in Dan's example).
Using another language's module, however, would not
pay attention to the other language's syntax at all.
You would Cuse the module in your code, and
then interface with it just as if it were written in
the language that you were writing in (and not in the
language that the module was written in).
So this:
#!/usr/bin/perl6
use __Python::sys;# whatever syntax
sys.stdout.write( 'hi there');# perl6 syntax matches python
syntax
here, I think
would become this: (Apologies, I don't know Python,
well, at all, so I'll state what assumptions I make)
#!/usr/bin/perl6
use __Python::sys;
# I'm assuming that C$stdout is some sort of
# global object in the Csys namespace.
$*sys::stdout.write('hi there');
And this:
#!/usr/bin/ponie
use __Python::sys;
use __Python::string;
my $hi = __Python::string-upper( 'hi' )
sys-stdout-write( $hi ); # HI
my $upper_func = __Python::string-upper # does this call the
# function with no args
(perlish)
# or return it (pythonish)
#!/usr/bin/ponie
use __Python::sys;
use __Python::string;
use UNIVERSAL qw(can);
# here I'm assuming that C$string is a global
# object in the C__Python namespace.
my $hi = $__Python::string-upper('hi') # Hi;
my $hi_func1 = \__Python::string::upper;
my $hi_func2 = can($__Python::string,'upper');
The idea is that after compilition, everything is
just PMCs and PIR, and so everything (hopefully)
plays nice together.
- Joe
Re: multiple languages clarification - newbie
- Original Message -
From: mAsterdam [EMAIL PROTECTED]
Date: Wednesday, September 8, 2004 8:31 pm
Subject: Re: multiple languages clarification - newbie
Joseph Ryan wrote:
Can someone provide clarification on what mixing languages will
look like in practice, or point me to where its explained?
delurk Warning. This is perl 7 and a half:
#!/usr/bin/perl -w
use prolog;
prolog: # prolog tells us:
needs_support_of(Db, Da):-
designer(A, Da),
designer(B, Db),
needs(A, B).
designer(perl, larry).
designer(parrot, dan).
needs(perl, parrot).
prolog. ;# or some other end-quote
for needs_support_of {
print; # prints 1st in the signature of the unification,
# predicate, 2nd .. nth in the signature of the
# match (for one member of the result).
}
__END__
/delurk
You could do that in Perl6 (or any Parrot based language) as:
eval
needs_support_of(Db, Da):-
designer(A, Da),
designer(B, Db),
needs(A, B).
designer(perl, larry).
designer(parrot, dan).
needs(perl, parrot).
, prolog;
for needs_support_of() {
print; # prints 1st in the signature of the unification,
# predicate, 2nd .. nth in the signature of the
# match (for one member of the result).
}
Assuming, of course, that there exists a prolog-parrot compiler.
You could even have your syntax if you use a macro:
macro prolog is parsed(/
\: ([
[^p]+ ::
| !before ^^prolog\.\s*$$ p
]+)
/) {
eval($_, prolog);
}
- Joe
Re: multiple languages clarification - newbie
- Original Message -
From: JOSEPH RYAN [EMAIL PROTECTED]
Date: Wednesday, September 8, 2004 8:58 pm
Subject: Re: multiple languages clarification - newbie
macro prolog is parsed(/
\: ([
[^p]+ ::
| !before ^^prolog\.\s*$$ p
]+)
/) {
eval($_, prolog);
}
Woops, actually, that would need to be:
macro prolog is parsed(m:w/
\: ([
[^p]+ ::
| !before ^^prolog \. ;$$ p
]+)
prolog \. ;
/) {
eval($_, prolog);
}
But, this is perl6-language stuff anyways. (:
- Joe
Re: P6C: Parser Weirdness
Steve Fink wrote:
Neither of those seems right to me. The first keys off of the position
of the binary, which could be anywhere with respect to the library
module you're in; the second is relative to whatever the current
directory is while you're running the script. I would think that
something like
use File::Basename qw(dirname);
use lib dirname($INC{P6C/Parser.pm})./../../../../lib;
(untested and probably not quite the right path) would be better. Or
perhaps it should be ripped out entirely, and any script using
P6C::Parser should be required to set the lib path correctly? It
partly depends on whether we want to ensure that P6C::Parser
preferentially uses the Parse::RecDescent from parrot/lib rather than
a system-provided one. Which probably is not the case?
The Parse::RecDescent in parrot/lib is a hacked version that removes
a bunch of stuff (tracing code, iirc) from the outputted grammer so
that it runs many orders faster than the regular version. Or, to
put it another way, it increases P6C's runspeed from infuriating
to slow :)
- Joe
Re: Ladies and gentlemen, I give you... objects!
Larry Wall wrote: On Fri, Feb 27, 2004 at 09:08:31AM -0500, Dan Sugalski wrote: : Nope. If a language wants to provide get/set methods for class : attributes it needs to create those methods at compilation time. For Perl 6 it's a single method that might be lvaluable depending on the declaration of the attribute. Right, but the compiler should be able to figure that out and emit the proper code. - Joe
Re: OO inheritance in a hacker style
Luke Palmer wrote: Austin Hastings writes: Hmm. The text and examples so far have been about methods and this seems to be about multi-methods. Correct me if I'm wrong ... You're wrong. Consider my example, where via single inheritance we reach a layered list of methods, each of which replaces the previous one in the namespace (parent.method superseded by child.method). This is not multi-dispatch -- the class of the object being dispatched determines the method -- but I want to modify the dispatch chain so that some upstream class' method is ignored. It's surely possible by modifying that class's DISPATCH. Whether it should actually be in the language is up for debate. I'd say that if you need to do this with any frequency whatsoever, you're not thinking about roles right. A good example might be in order... :-) Well, what if the two classes you want to inherit from weren't designed with roles in mind? For instance, there might be two CPAN modules that each have a dozen methods that you want to inherit, but they each have 1 that overlap whose conflict you want to easily resolve. Besides, the user is not thinking about XXX right sounds like we need to give a ++ to the pythonometer ;) - Joe
Re: How does perl handle HLL Ceval?
[EMAIL PROTECTED] wrote: The subject says it all. As parrot is designed to be targetted by many langauges, how will it handle 'eval' opcodes for those different languages? Shell out to a seperate process? As far as Perl6 (which will be written in Perl6) goes, an easy solution is to design the compiler so that compilition to imcc can be done with a generalized function call, and then link in the perl6 compiler as a module. Eval can then just be a simple wrapper around that, something like: .pcc_sub _eval non_prototyped .param String code_to_eval .param PerlHash options .pcc_begin prototyped .arg code_to_eval .arg options .pcc_call _compile_perl6_code .local string IMCC .result IMCC .pcc_end .local Sub _current_eval .local PerlUndef result compile _current_eval, IMCC, IMCC invokecc _current_eval restore result .pcc_begin_return .return result .pcc_end_return .end Something similar could be done with a C-based compiler and NCI. - Joe
Re: Proposal: parrot-compilers list
Pete Lomax wrote: On Mon, 17 Nov 2003 11:35:51 -0800, Sterling Hughes [EMAIL PROTECTED] wrote: I think this would be a *very* cool thing. What he said. Ditto. - Joe
Re: P5 B backend for languages/perl6 - quasi-announcement
Sean O'Rourke wrote: [EMAIL PROTECTED] (Scott Walters) writes: I have work-related reason to add a B backend for Perl 5 to the perl6 compiler. I'm looking at creating an assembler for Perl 5's B bytecode along the lines of IMCC, and creating patches against languages/perl6/IMCC.pm and languages/perl6/IMCC/* to conditionally, using some sort of phrasebook, generate assembly for either Parrot or B. This would involve some nontrivial refactoring, since both are unashamedly machine-dependent, and freely emit blocks of assembly directly from the AST walk. Unless B assembly is a lot like parrot assembly, simply replacing (or factoring out) these chunks might not be the best way. Of course, I've never used B assembly, so discount this impression appropriately. Everything up to IMCC* (i.e. parsing, tree munging, and context (wannabe typing)) should be fine, though. I actually started to do some refactoring last night of languages/perl6 (I've decided to put my languages/java on hold until the class-metadata stuff is finalized.) What kind of refactoring would you suggest? Should we have some sort of generic bytecode generation package? - Joe
Re: [PS] obsolete files
Leopold Toetsch wrote: Here is a list of files that I consider to be unused: Hmmm... obsolete... unused... sounds a lot like languages/perl6 :-P - Joe
Re: Class metadata for PIR/assembly files
Dan Sugalski wrote: Here's the scoop: Metadata for classes is simple. In PIR/assembly, they're noted with .things: .class Foo .is bar .is baz .does some_thing .member x .member y .member z .ssalc Unless someone tells me that ssalc is horribly obscene in some relatively common language, and we may still if the translation amuses me sufficiently. Keywords are simple for the metadata. .class starts the declaration, has a single parameter the name. Class declarations end with .ssalc. Each .is defines a parent class, each .does defines an interface the class supports, and each .member defines a PMC member slot that each object. If a class is defined in the bytecode, it gets instantiated when the bytecode is created. (It's a constant class, though like any other class is mutable at runtime so it's not that constant) There is no difference between a class created with metadata and one created by executable code piecemeal. Classes, when instantiated, have a backing namespace that's identical to the class name. We will be adding version metadata to the classes, but that's going to be deferred. It's OK for the code that handles PIR and assembly to ignore this for the moment, at least until the metadata segment is better defined. Which will be soon, though I'd rather someone else do the bytecode modification as it's been a long time since I've had my hand in there. This would be a good time to comment on the metadata, as I'm about to go finish defining the ops to create classes dynamically and actually finish the fscking object.c. code to do it. Will there be a way to specify which methods belong to the class in the metadata? Or will Method namespaces just have to match class names so that a lookup can be done? -Joe
:: doesn't work inside an identifier.
According to the CVS log for /languages/imcc/imcc.l, :: is now allowed inside an identifier name. However, when I try to create an example like: .sub foo::bar end .end It gives the error: error:imcc:parse error, unexpected LABEL, expecting IDENTIFIER Is this a bug, or am I misunderstanding something? - Joe
Re: Namespace'd subs in IMCC?
Leopold Toetsch wrote: Joseph Ryan [EMAIL PROTECTED] wrote: From what I understand from the IMCC documentation, the .namespace macro prepends the namespace name plus :: to all names within it. It's for variables only, currently. I figured that this would be handy in distinguishing which class a method belongs to without causing name clashes. For instance: .namespace foo .sub bar would create a method bar in the class foo, for a full name of foo::bar. I'm not outerly sure, if imcc should even have such a functionality. Or at least, if there is one, it should be configurable. The name mangling is HLL dependent and there may be no general scheme to do it right for all kind of symbols. However, this doesn't seem to work. Is this a bug, or should I be doing something else for this type of problem? It's not layed out what it should really do. I'm towards removing this directive and let the HLL compiler deal with it. Well, in that case, would it be possible to allow : as a valid character for use in symbol names? -Joe
Namespace'd subs in IMCC?
From what I understand from the IMCC documentation, the .namespace macro prepends the namespace name plus :: to all names within it. I figured that this would be handy in distinguishing which class a method belongs to without causing name clashes. For instance: .namespace foo .sub bar end .end .endnamespace foo would create a method bar in the class foo, for a full name of foo::bar. However, this doesn't seem to work. Is this a bug, or should I be doing something else for this type of problem? Thanks, - Joe
Re: Is there any way to dynamically add a method to a class?
Dan Sugalski wrote: On Mon, 25 Aug 2003, Joseph Ryan wrote: So, I know how to use find_method to get a method from an object; but is there any way to dynamically add a method to a class? Basically, I want to do something like this: newclass P2, Foo new P1, P2 addr I0, _Foo::somemethod setmethod P1, somemethod, I0 findmethod P0, P1, somemethod invoke So, how do I do it? :) What's supposed to happen is that each class has a backing namespace, and methods all live in that namespace. Generally objects, no matter what their HLL class, will be PMCs that have subclassed (at the parrot level) ParrotObject. Anyway, for a perl/python/ruby object of class Foo, to add a new method you'd just add a new sub/method name/PMC binding to the Foo namespace. I'm a bit lost here; what does that mean? How do I do it? Does .sub _Foo::somemethod print Foo-ey goodness. .end add somemethod to the Foo namespace? Or would it have to be: .sub Foo::somemethod print Foo-ey goodness. .end Thanks for the reply, - Joe
Is there any way to dynamically add a method to a class?
So, I know how to use find_method to get a method from an object; but is there any way to dynamically add a method to a class? Basically, I want to do something like this: newclass P2, Foo new P1, P2 addr I0, _Foo::somemethod setmethod P1, somemethod, I0 findmethod P0, P1, somemethod invoke So, how do I do it? :) The only way I could figure out that might work was to make my own pmc class that held an alias to the class pmc itself as a property, and then treat the class itself as hash; however that seems extremely hackish, as well as pretty slow, as it would take an extra lookup to find the method. Any tips would be greatly appreciated. - Joe
Re: generic code generator? [was: subroutines and python status]
Michal Wallace wrote:
On Sun, 3 Aug 2003, K Stol wrote:
What do you think? Want to try squishing pirate/python
and pirate/lua together? :)
Yeah, I like the idea. Let's try this out.
Well, I finished reading your report[1] and
posted some of my (rather unorganized) thoughts
up at [2]
It does seem like there are some snags getting
languages to talk to each other, even with the
calling conventions, but even so, I'm even more
convinced now that a generic, overridable
code-generator is the way to go.
It seems to me that if we want to maximize the
number of languages using it, the generic
compiler shouldn't depend on anything but
C and parrot... But until we get it working,
I'd like to stick to a dynamic language like
python/perl/lua/scheme. And, well, my code's
already in python... :) [though I'd actually
love to try out some lua 5]
What I'm picturing is a template system for
specifying chunks of IMCC. Something like this:
ast generic:
on @while(test, body):
% while= gensym(while)
% endwhile = gensym(endwhile)
% test = gensym($I)
{while}:
{test} = @expr
unless {test} goto {endwhile}
@body
{endwhile}:
on @if(test, elif*, else?):
...
ast python(generic):
on @while(test, body, else?):
...
Okay, I don't have a good syntax in mind yet,
the point is it's a template language and you
can subclass/override/extend the template.
Maybe there's no syntax and it just uses
cleanly coded classes in some oo language.
Or perl6 with it's grammars and rules. I
don't know.
I think that trying to define a new syntax for a new meta-language is a bad
idea. The goal of a GCG (Generic Code Generator) should be to
allieviate the
compiler writers of the responsiblity of generating code. Forcing them to
generate different code doesn't help solve the problem. (-:
However, at the risk of sounding lame, what if the GCG syntax was
instead some
sort of standard meta-language structure like YAML or XML? As in, the
syntax
wouldn't be a syntax at all, but just a dump of the AST with
standardized node
names. I think this would have a number of benefits:
1.) Instead of forcing the compiler writer to generate code, the
compiler writer
would only have to transform the parse tree into a structure that is
name-consistant with the GCG's standard, and then use any of a number of
existing libraries to dump the tree as YAML/XML.
2.) Since there are more YAML/XML parsers than I can count implemented in
nearly modern useful language I can think of, the GCG could be generated in
any language without causing a stall on starting on the generic code
generation
part of the project. (you know, the important part)
3.) It would be possible to handle language-specific nodes by defining some
sort of raw node whose value could be raw imcc code.
Anyways, just a few thoughts. A tool like this would be *very* useful,
I think. Good luck. (-:
- Joe
JVM-PIR translator (was: Re: subroutines and python status)
Leopold Toetsch wrote: Luke Palmer [EMAIL PROTECTED] wrote: You mind submitting a patch to put this in the languages/pirate I'd appreciate that very much. Pie-thon, here we come ... Speaking of adding new projects to languages, I have a partially complete JVM-PIR translator done. It's complete, with the exception of: 1: The two threading ops arent translated 2: I need to translate the core libraries. I'm hoping GNU Classpath will be of some help here. 3: I'm missing some runtime exceptions, which I just havent gotten around to yet. Other than that, its pretty complete. However, the code it generates isn't quite runnable. Pasm seems to be missing a few instructions, specifically add_method and add_attribute instructions. So, I just made them up. As you can imagine, this causes a few errors :) That means that beyond trivial cases, the code is mostly untested. So, would anyone want this in the tree? Or should I wait until it is better tested and documented? You take a look at it at: http://jryan.perlmonk.org/images/jirate.tar.gz Let me know what you think. - Joe
Re: approaching python
Benjamin Goldberg wrote:
K Stol wrote:
The register stuff, I presume, is register allocation and the like? When
targeting IMCC, you can use an infinite amount of registers. Just keep a
counter in the code generator, each time a new register is needed, just
increment the counter and add a ${S|N|I|P} in front of it (example:
$P1). IMCC does register allocation and spilling.
So this is not really difficult.
Nono, the problem isn't that python uses *more* registers than
whatever, but rather, that it doesn't use registers at all. Instead,
it uses a stack. So, for example, python's add instruction might get
translated into the following pir or pasm code:
restore P0
restore P1
clone P0, P0
add P0, P1
save P0
Needless to say, this is not efficient, due to how slow parrot's push
and pop operations are.
Well, thats because you're trying to make a register machine act like a
stack machine. It would be more efficient to translate add as:
$P2 = $P0 + $P1
That is to say, map stack positions to registers by simulating the
stack while walking each op during translation time, rather than
during runtime. So, in this case, the code that translates the add
instruction might look something like:
translate_add_op {
pop variable1 off of simulated stack
pop variable2 off of simulated stack
create new temp pmc
push new temp_pmc onto simulated stack
print temp_pmc's name
print =
print variable1's name
print +
print variable2's name
}
So, after this code, our simulated stack is depleted by two items
(the operands), and then replenished by one (the result); this
makes it act exactly like the real stack, except that we are
manipulating the registers rather than the values.
Hmm... If imcc is smart enough, (or perhaps I should say, when the flow
control is simple/clear enough) it should be able to see when a value is
pushed onto the stack, and later popped off, when there are enough
registers free that we could have stored it in a spare register instead
of on the stack. That is, a sort of register *un*spilling.
Doesn't IMCC already do this?
- Joe
