Re: Set vs. Assign..?
Benjamin Goldberg <[EMAIL PROTECTED]> wrote: > I would suggest the opnames/categories "mutate," "alias," and "create." IMHO, we could leave PASM syntax as it is and create opcode aliases inside the assembler ... > I believe that the most in^H^H logical shorthand spellings of these > opcodes would be ":=", "=", and "<==", for alias, mutate, and create, > respectively. But what I really want to have is these in the PIR code (except for the "create" one, which is: $P0 = new PerlInt With an underlying create op, that does assign a value too, it could then be $P0 = new PerlInt (42) or something. leo
Re: We *need* this op! :-)
On Thu, Aug 07, 2003 at 12:57:11PM -0400, Gordon Henriksen wrote: > This is really a language feature; you should add it to the hq9+ > implementation. Sadly, this was not considered when hq9+ was developed, so it's not actually part of the language. Maybe someone should develop and extended version - hq9+42 dha -- David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/ however, if people don't like Perl, they don't have to use it. they can stay at the office solving their problems while the Perl Mongers go out and drink. ;)- brian d foy in c.l.p.misc
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
Re: [perl #23025] [PATCH] env.t doesn't test the env ops on solaris (and others)
Lars Balker Rasmussen (via RT) <[EMAIL PROTECTED]> writes:
> # New Ticket Created by Lars Balker Rasmussen
> # Please include the string: [perl #23025]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=23025 >
>
>
> There's no reason to test for the presence of setenv/unsetenv in libc
> - these functions are emulated if not present.
>
> However, now the 4th test fails on Solaris (and most likely other OS's
> witout setenv/unsetenv). This is because the test relies on a key
> disappearing from %ENV when it's been unsetenv'ed - this doesn't
> happen when using putenv("key=") as the current unsetenv emulation.
>
> I'm not sure what's the best portable way to handle this is.
We'll postpone deciding on this one until later - I've attached a
patch to env.t that tests the env-implementation on all platforms, and
doesn't fail on Solaris.
? env.diff
Index: t/pmc/env.t
===
RCS file: /cvs/public/parrot/t/pmc/env.t,v
retrieving revision 1.4
diff -u -a -u -r1.4 env.t
--- t/pmc/env.t 23 Jul 2003 18:18:56 - 1.4
+++ t/pmc/env.t 8 Aug 2003 15:42:06 -
@@ -1,10 +1,9 @@
#! perl -w
-use Parrot::Test tests => 4;
+use Parrot::Test tests => 5;
use Test::More;
use Parrot::Config;
-SKIP: {
-skip("no setenv", 3) unless $PConfig{"setenv"};
+
$ENV{"PARROT_TMP"} = "riding a ponie";
output_like(<<'CODE', <--
Lars Balker Rasmussen Consult::Perl
Re: We *need* this op! :-)
On Fri, Aug 08, 2003 at 12:33:03PM +0100, Nicholas Clark wrote: > On Fri, Aug 08, 2003 at 02:20:46AM -0400, David H. Adler wrote: > > On Thu, Aug 07, 2003 at 12:57:11PM -0400, Gordon Henriksen wrote: > > > This is really a language feature; you should add it to the hq9+ > > > implementation. > > > > Sadly, this was not considered when hq9+ was developed, so it's not > > actually part of the language. Maybe someone should develop and > > extended version - hq9+42 > > No, hq9*6, surely? Well, that loses the all-important increment op. How about hq9+(6*9) ? > (if everyone is still in the dark about six by nine see > http://whatis.techtarget.com/definition/0,,sid9_gci211501,00.html > ) Frankly, I always thought that Arthur's explanation was more convincing than the base 13 argument... dha -- David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/ "We are the Borg. You will be assimilated! Nah, only kidding. We're just the Sontarans. Care to take part in some 'medical research'?"
Re: #define name collisions -- yet another small project
At 10:01 PM +0300 8/8/03, Vladimir Lipskiy wrote: > At 9:21 PM +0300 8/8/03, Vladimir Lipskiy wrote: > > So, the project. Someone needs to go through the configure procedure >> and the headers and throw a PARROT_ prefix in front of all the HAS_ >> defines we define, so we can avoid this problem. > >Some defines have the HAVE_ prefix. Should those be also prefixed? If they're being set in our configure stuff, yes. If we add PARROT_ to HAVE_, we will end up with the PARROT_HAVE_ prefix, what IMHO is harsh. It might be alot better if we firstly had changed HAVE_ for HAS_. What do you think? It is grammatically obnoxious, isn't it? PARROT_HAS_STDIO_H is fine, so if you want to make that change everywhere, go for it. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
