Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread Dan Sugalski
At 11:21 PM 10/12/00 -0400, John Porter wrote: >Jarkko Hietaniemi wrote: > > On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote: > > > > > > I don't think it's that big a deal. Easy enough to wrap in a macro. > > > > I thought (hoped) that the plan was the avoid the cpp like the plague >

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread John Porter
Jarkko Hietaniemi wrote: > On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote: > > > > I don't think it's that big a deal. Easy enough to wrap in a macro. > > I thought (hoped) that the plan was the avoid the cpp like the plague > and cancer it is. Well, yes, definitely; but we're j

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread Jarkko Hietaniemi
On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote: > Dan Sugalski wrote: > > > > Well, damn. And I mean that sincerely. :( > > I don't think it's that big a deal. Easy enough to wrap in a macro. I thought (hoped) that the plan was the avoid the cpp like the plague and cancer it is.

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread John Porter
Dan Sugalski wrote: > > Well, damn. And I mean that sincerely. :( I don't think it's that big a deal. Easy enough to wrap in a macro. -- John Porter

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread Dan Sugalski
At 12:07 AM 10/13/00 +0100, Simon Cozens wrote: >On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote: > > Can't. ISO C requires that all variadic functions take at least one named > > parameter. The best you can do is something like (void *, ...). Well, damn. And I mean that sincerely.

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread Simon Cozens
On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote: > Can't. ISO C requires that all variadic functions take at least one named > parameter. The best you can do is something like (void *, ...). Argh. Can't we just use a stack? I like stacks. Stacks make sense. -- ..you could spend *

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread Russ Allbery
Dan Sugalski <[EMAIL PROTECTED]> writes: > C's vararg handling sucks in many sublime and profound ways. It does, > though, work. If we declare in advance that all C-visible perl functions > have an official parameter list of (...), then we can make it work. The > calling program would just fetch

Re: RFC 334 (v1) Ahhhh.. i get it

2000-10-12 Thread Dave Storrs
Heh. In my youth, we said "Thanks a million." I see that inflation has now turned that into "Thanks a million and twenty four thousand." :> On 12 Oct 2000, John van V wrote: > > $thanks -> (1000K)

Re: A tentative list of vtable functions

2000-10-12 Thread ye, wei
Hildo Biersma wrote: > Fisher Mark wrote: > > > > > One C++ problem I just found out is memory management. It seems > > > that it's impossible to 'new' an object from an specified memory block. > > > So it's impossible to put free'd objects in memory pool and re-allocate > > > them next time. >

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread Dan Sugalski
At 08:57 PM 10/12/00 +0100, Simon Cozens wrote: >On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote: > > Doing this also means someone writing an app with an embedded perl > > interpreter can call into perl code the same way as they call into any C > > library. > >Of course, the problem

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread Simon Cozens
On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote: > Doing this also means someone writing an app with an embedded perl > interpreter can call into perl code the same way as they call into any C > library. Of course, the problem comes that we can't have anonymous functions in C. That

Re: RFC 334 (v1) Ahhhh.. i get it

2000-10-12 Thread John van V
$thanks -> (1000K)

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread Dan Sugalski
At 07:48 PM 10/12/00 +, John van V wrote: > * It also means we can write bits of perl in Perl, and similarly not > have >to care about this fact. > >Granted, some developers are thick as a brick... >If you are writing perl in Perl, then, presumably, you would know this. But pe

Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions

2000-10-12 Thread Dan Sugalski
At 06:30 PM 10/10/00 -0400, John Porter wrote: >Dan Sugalski wrote: > > > > Perl functions that are called from outside will have to have some sort of > > interpreter attached to 'em. I can see either a default interpreter, or > the > > one they were compiled into being valid as a choice. > > > >

Re: RFC 334 (v1) I'm {STILL} trying to understand this...

2000-10-12 Thread John van V
* It also means we can write bits of perl in Perl, and similarly not have to care about this fact. Granted, some developers are thick as a brick... If you are writing perl in Perl, then, presumably, you would know this. Excatly where is the added value, or is it purely for entertai

Re: RFC 334 (v1) I'm really trying to understand this...

2000-10-12 Thread Simon Cozens
On Thu, Oct 12, 2000 at 07:10:30PM -, John van V wrote: > If you get the chance, I would really grateful if you could translate the > abstract into lay terms, just confused by the concept of "low level perl" > * We want

Re: RFC 334 (v1) I'm really trying to understand this...

2000-10-12 Thread John van V
If you get the chance, I would really grateful if you could translate the abstract into lay terms, just confused by the concept of "low level perl" Why??, perl is my only (byte) compiled language...