Re: Generating Perl 6 source with Perl
Simon Cozens wrote: > Larry has guaranteed that Perl 6 will be built "out of the same source tree" > as Perl 5. Whatever that means... i.e. not much. > This is a major win for us in two areas. Firstly, we can reuse the > information determined by Perl 5's Configure process to help make Perl 6 > portable: for instance, I expect we'll still be using the [UI](8|16|32|V) > typedefs to guarantee integer sizes. Yeuch. So now we have to maintain two interdependent hairballs. Is that really progress? > Secondly and more importantly, it guarantees that we've got a copy of Perl on > hand before Perl 6 is built. This allows us to reduce the level of > preprocessor muddling by effectively generating the C source to Perl 6 from > templates and preprocessing. For instance, I expect to see a little macro > language develop for specifying vtable methods, which, when preprocessed, > would also generate the vtables and their corresponding enums. I'd also like > to see Perl choose whether or not a function should invoke the native C > library's implementation or define its own. > > What do people think? I think macro languages suck, whether they are the C macro preprocessor, or some fancy dohickey that we knock together. I think that having to have perl5 around to build perl6 also sucks. For example, in our case we build perl5 every night with the rest of Solaris. It already takes too long. Adding a build of perl5 just to build perl6 - well, forget it. Alan Burlison
Re: Generating Perl 6 source with Perl
On Sat, Feb 17, 2001 at 12:22:44PM +, Nicholas Clark wrote: > > Very, very, very rough example so you get the idea: > [reassuring example] Here's a slightly less rough example. Pipe the following code to the attached Perl program, and look at the output on stdout, and in vtable.h: CLASS=sviv METHOD=new if (pmc) (pmc->vtbl->destroy)(pmc); else pmc = (PMC)malloc(sizeof(PMC)); pmc->vtbl = &sviv_vtable; pmc->private_data = (IV*)malloc(sizeof(IV*)); return pmc; -- "Even had to open up the case and gaze upon the hallowed peace that graced the helpdesk that day." -- Megahal (trained on asr), 1998-11-06 vtable.pl
Re: Generating Perl 6 source with Perl
On Fri, Feb 16, 2001 at 09:30:50PM +, Simon Cozens wrote: > On Fri, Feb 16, 2001 at 04:00:05PM -0500, Sam Tregar wrote: > > I think he meant that using a symbolic debugger is hard, not that it > > wouldn't work. After all, when GDB is tell you that: > >(*fooz).blazt[10].mark[0]->set(fungle(10)); > > Is causing a seg fault and all you wrote was: > >$fooz->set(10); > > You've got to get pretty smart to figure out what's going south. Yes, that's what I meant. Why didn't I actually write out the explanation? (that was why I said "mix well" rather than "mix" (at all)) Having C source full of macros (or FORTRAN source with somme custom preprocessing, thinking about a previous job) and a symbolic debugger saying "it went SEGV here: FROB(BNARFL(3)); " without actually seeing the clean language source is not easy to follow. For example, as BNARFL is a macro, you can't ask the debugger to call BNARFL(3) and see what you get back. > Oh, I see what you mean. Yeah, my use of the word "macro" was misleading > there. I'm thinking more of "template". Cool. More like XS, by which I mean XS makes a C file, and the C file is there for you to read while debugging, rather than just the XS file. [but this isn't a great example as it's chock full o' pre-processor macros, which are the sort of thing that then makes symbolic debugging hard] > Very, very, very rough example so you get the idea: [reassuring example] > The real benefit would be that the Perl program would know about all the > methods and be able to automatically construct the vtable definitions and > the relevant enum's, and that all the system-specific crap wouldn't show up in > the generated C files, so they'd actually be *easier* to handle. Cool. I'd been failing to understand that the intent was to make human readable C files (as opposed to obfuscation for cpp) Nicholas Clark
Re: Generating Perl 6 source with Perl
At 09:30 PM 2/16/2001 +, Simon Cozens wrote: >The real benefit would be that the Perl program would know about all the >methods and be able to automatically construct the vtable definitions and >the relevant enum's, and that all the system-specific crap wouldn't show >up in the generated C files, so they'd actually be *easier* to handle. Except... The big problem is that we can't generate the C without perl, and we can't run perl without the C. I expect we'll end up distributing the pre-generated C with the source kits and rebuilding them as needed, the same way we do now with the files that embed.pl generates. We could, I suppose, do this with microperl, but it seems like one more step that could go wrong when you build perl. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Generating Perl 6 source with Perl
On Fri, 16 Feb 2001, Simon Cozens wrote: > Larry has guaranteed that Perl 6 will be built "out of the same source tree" > as Perl 5. This is a major win for us in two areas. Firstly, we can reuse the > information determined by Perl 5's Configure process to help make Perl 6 > portable: > Secondly and more importantly, it guarantees that we've got a copy of Perl on > hand before Perl 6 is built. Hmm. I thought that was more of a transitional idea, not a permanent state of affairs. That is, perl5 re-used a lot of perl4 stuff while still in development; perl6 can probably profitably do the same. However, eventually, perl4 stuff went away (or got absorbed outright). The same should ultimately happen to perl5 stuff, or else we're stuck forever maintaining both perl5 *and* perl6. Still, it indeed may be a very good way to get things going and allow us to postpone worrying about Configure's replacement. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Generating Perl 6 source with Perl
On Fri, Feb 16, 2001 at 04:00:05PM -0500, Sam Tregar wrote:
> I think he meant that using a symbolic debugger is hard, not that it
> wouldn't work. After all, when GDB is tell you that:
>(*fooz).blazt[10].mark[0]->set(fungle(10));
> Is causing a seg fault and all you wrote was:
>$fooz->set(10);
> You've got to get pretty smart to figure out what's going south.
Oh, I see what you mean. Yeah, my use of the word "macro" was misleading
there. I'm thinking more of "template".
Very, very, very rough example so you get the idea:
vtable.spec could have something like
void add normal_method # Where normal_method means a, b, and a key.
IV left = a->get_int();
IV right = b->get_int();
/* handle overflows */
a->set_int(left + right);
#if ($Config{memcpy}... || some Perl expression...)
memcpy(foo, bar);
#else
my_memcpy(foo,bar);
#endif
producing
void add (PMC* a, PMC* b, void* key) {
IV left = a->get_int();
IV right = b->get_int();
/* handle overflows */
a->set_int(left + right);
memcpy(foo,bar);
}
which is not so bad to handle in a symbolic debugger.
The real benefit would be that the Perl program would know about all the
methods and be able to automatically construct the vtable definitions and
the relevant enum's, and that all the system-specific crap wouldn't show up in
the generated C files, so they'd actually be *easier* to handle.
Simon
--
Pretty, smart, sane:Pick two.
- Ron Echeverri
Re: Generating Perl 6 source with Perl
On Fri, 16 Feb 2001, Simon Cozens wrote: > On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote: > > macro languages and symbolic debuggers don't mix well. > > Generated output would be Real Life C. I'm thinking something along the lines > of > perl vtable.pl < vtable.spec > vtable.c > which would work just fine with symbolic debuggers. I think he meant that using a symbolic debugger is hard, not that it wouldn't work. After all, when GDB is tell you that: (*fooz).blazt[10].mark[0]->set(fungle(10)); Is causing a seg fault and all you wrote was: $fooz->set(10); You've got to get pretty smart to figure out what's going south. -sam
Re: Generating Perl 6 source with Perl
On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote: > macro languages and symbolic debuggers don't mix well. Generated output would be Real Life C. I'm thinking something along the lines of perl vtable.pl < vtable.spec > vtable.c which would work just fine with symbolic debuggers. -- It's all fun and games until someone loses an eye. Then it's a sport!
Re: Generating Perl 6 source with Perl
On Fri, Feb 16, 2001 at 07:55:10PM +, Simon Cozens wrote: > Secondly and more importantly, it guarantees that we've got a copy of Perl on > hand before Perl 6 is built. This allows us to reduce the level of > preprocessor muddling by effectively generating the C source to Perl 6 from > templates and preprocessing. For instance, I expect to see a little macro > language develop for specifying vtable methods, which, when preprocessed, > would also generate the vtables and their corresponding enums. I'd also like > to see Perl choose whether or not a function should invoke the native C > library's implementation or define its own. > > What do people think? macro languages and symbolic debuggers don't mix well. We should be mindful of this if we're going to be writing a lot of bugs^Wcode in a macro language. However, I like the idea of making the bootstrap process more of a "microperl followed by configure probing written as a perl script" rather than "complex shell scripts followed by miniperl and a few Makefile.PLs", which is one of the possibilities having perl5 around would offer. Nicholas Clark
Re: Generating Perl 6 source with Perl
On Friday 16 February 2001 14:55, Simon Cozens wrote: > Secondly and more importantly, it guarantees that we've got a copy of Perl on > hand before Perl 6 is built. This allows us to reduce the level of > preprocessor muddling by effectively generating the C source to Perl 6 from > templates and preprocessing. For instance, I expect to see a little macro > language develop for specifying vtable methods, which, when preprocessed, > would also generate the vtables and their corresponding enums. I'd also like > to see Perl choose whether or not a function should invoke the native C > library's implementation or define its own. > > What do people think? One of the early ideas proposed by a couple of people is that perl be written in whatever language the XS replacement will be, for solidifying the interface, making it bootstrappable, etc. Even with Inline, now, there still needs to be some heavy interface - but there would still be some consistency. -- Bryan C. Warnock [EMAIL PROTECTED]
Generating Perl 6 source with Perl
Larry has guaranteed that Perl 6 will be built "out of the same source tree" as Perl 5. This is a major win for us in two areas. Firstly, we can reuse the information determined by Perl 5's Configure process to help make Perl 6 portable: for instance, I expect we'll still be using the [UI](8|16|32|V) typedefs to guarantee integer sizes. Secondly and more importantly, it guarantees that we've got a copy of Perl on hand before Perl 6 is built. This allows us to reduce the level of preprocessor muddling by effectively generating the C source to Perl 6 from templates and preprocessing. For instance, I expect to see a little macro language develop for specifying vtable methods, which, when preprocessed, would also generate the vtables and their corresponding enums. I'd also like to see Perl choose whether or not a function should invoke the native C library's implementation or define its own. What do people think? -- Gu sa-sur bi nu-ha-za sila-a KU. -- Sumerian saying
