On Wed, Sep 20, 2000 at 01:52:47PM +0100, Nick Ing-Simmons wrote:
> Tom Hughes <[EMAIL PROTECTED]> writes:
> >
> >What I'd like to see us avoid is the current situation where trying
> >to examine the value of an SV in the debugger is all but impossible
> >for anybody other than a minor god.
>
> W
Tom Hughes <[EMAIL PROTECTED]> writes:
>
>What I'd like to see us avoid is the current situation where trying
>to examine the value of an SV in the debugger is all but impossible
>for anybody other than a minor god.
What is so hard about:
gdb> call Perl_sv_dump(sv)
???
>
>Tom
--
Nick Ing-Sim
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:57 PM 9/18/00 +0100, Tom Hughes wrote:
>
> >Doesn't this run a significant danger of leading us straight back
> >into the perl5 problem of making debugging of the source code more
> >or less impossible?
>
> N
[Please forgive me for chiming in late on this thread; I just got a chance
to catch up on mailing list traffic.]
> > On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > > That's fine for the VM and the support libraries, but I'd *really* like
> > > to see the parser/front-end in Perl. T
At 04:57 PM 9/18/00 +0100, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > As for the language we implement perl in (and thus ultimately need to
> > translate to the compiler-target language), I'm thinking of something like
> > Chip's PIL
At 06:58 PM 9/15/00 +0100, Simon Cozens wrote:
>On Fri, Sep 15, 2000 at 12:53:29PM -0400, Dan Sugalski wrote:
> > The only reason I can see nice winning over fast is if nice brings in
> whole
> > new concepts to the language. (Like, say, matrix ops or Damian's
> currying > > stuff)
>
>Well, taki
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> As for the language we implement perl in (and thus ultimately need to
> translate to the compiler-target language), I'm thinking of something like
> Chip's PIL. (Or PIL itself--I've not actually seen it)
Is there
Dan Sugalski wrote:
> 1) How fast is the C (or whatever) code it emits likely to be?
The perl-in-perl interpreter would not be a deliverable. Speed would
not be its goal. It would be a reference implementation that would be
easier to break and repair. An internals tutorial, if you will.
So
On Fri, Sep 15, 2000 at 12:53:29PM -0400, Dan Sugalski wrote:
> The only reason I can see nice winning over fast is if nice brings in whole
> new concepts to the language. (Like, say, matrix ops or Damian's currying stuf)
Well, taking the idea of writing the parser in Perl, let's have a look
at
On Fri, 15 Sep 2000, Dan Sugalski wrote:
> Doing core work in perl also has startup issues--either we need to parse
> perl code every time perl starts, write the optree stuff to be
> position-independent, compile perl down to native code, or embed and
> process bytecode every time we start.
I
At 10:07 PM 9/13/00 -0600, Nathan Torkington wrote:
>Ken Fox writes:
> > The dogfood theory? One of the design goals for Perl is to make text
> > munging easy. Parsing falls into that category and therefore we should
> > use it, i.e. eat our own dogfood.
>
>How about this. During design, we try t
At 03:06 PM 9/14/00 +0100, Simon Cozens wrote:
>On Thu, Sep 14, 2000 at 02:40:31PM +0100, Piers Cawley wrote:
> > > Are there any better reasons than "It would be nice?"
> >
> > Can there *be* a better reason than "It would be nice"? Seriously,
> > niceness is a damned fine goal.
>
>No, it isn't.
At 02:40 PM 9/14/00 +0100, Piers Cawley wrote:
>Simon Cozens <[EMAIL PROTECTED]> writes:
>
> > On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > > That's fine for the VM and the support libraries, but I'd *really*
> > > like to see the parser/front-end in Perl. There are dozens of RFCs
> > On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > > That's fine for the VM and the support libraries, but I'd *really*
> > > like to see the parser/front-end in Perl. There are dozens of RFCs
> > > that require some non-trivial extensions to the parser. It would
> > > be nice to cod
On Thu, Sep 14, 2000 at 02:40:31PM +0100, Piers Cawley wrote:
> > Are there any better reasons than "It would be nice?"
>
> Can there *be* a better reason than "It would be nice"? Seriously,
> niceness is a damned fine goal.
No, it isn't. Practical wins over nice any day. Fast probably wins over
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > That's fine for the VM and the support libraries, but I'd *really*
> > like to see the parser/front-end in Perl. There are dozens of RFCs
> > that require some non-trivial extensions to the par
Ken Fox writes:
> The dogfood theory? One of the design goals for Perl is to make text
> munging easy. Parsing falls into that category and therefore we should
> use it, i.e. eat our own dogfood.
How about this. During design, we try to make the parser a module
with an interface designed so that
At 09:50 PM 9/12/00 +0100, Simon Cozens wrote:
>On Tue, Sep 12, 2000 at 04:55:02PM -0400, Dan Sugalski wrote:
> > > Are there any better reasons than "It would be nice?"
> > It'd make things easier? (I'd rather write a parser in perl than C...)
>
>You're going to have to do it some time, for boots
Simon Cozens wrote:
> On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > That's fine for the VM and the support libraries, but I'd *really* like
> > to see the parser/front-end in Perl. There are dozens of RFCs that require
> > some non-trivial extensions to the parser. It would be nice
On Mon, Sep 11, 2000 at 05:02:13PM -0400, Dan Sugalski wrote:
> If you're essentially adding stack primitives to C, sure. If you're talking
> about a whole new language it's still an issue.
OK, I think I've got my brains in order now. I *think*. This is probably still
going to be a little fuzzy.
On Tue, Sep 12, 2000 at 04:55:02PM -0400, Dan Sugalski wrote:
> > Are there any better reasons than "It would be nice?"
> It'd make things easier? (I'd rather write a parser in perl than C...)
You're going to have to do it some time, for bootstrapping. And now you need
an interpreter on hand at t
On Tue, 12 Sep 2000, Simon Cozens wrote:
> On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > That's fine for the VM and the support libraries, but I'd *really* like
> > to see the parser/front-end in Perl. There are dozens of RFCs that require
> > some non-trivial extensions to the par
On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> That's fine for the VM and the support libraries, but I'd *really* like
> to see the parser/front-end in Perl. There are dozens of RFCs that require
> some non-trivial extensions to the parser. It would be nice to code these
> in Perl
Are
Dan Sugalski wrote:
> As for the language we implement perl in (and thus ultimately need to
> translate to the compiler-target language), I'm thinking of something like
> Chip's PIL.
That's fine for the VM and the support libraries, but I'd *really* like
to see the parser/front-end in Perl. There
At 09:26 PM 9/11/00 +0100, Simon Cozens wrote:
>On Mon, Sep 11, 2000 at 04:01:53PM -0400, Dan Sugalski wrote:
> > Are you thinking of something along the lines of FORTH or PostScript? Or
> > something else?
>
>Something else. Forth and PostScript are languages which are implemented
>through stacks
On Mon, Sep 11, 2000 at 01:09:41PM -0400, [EMAIL PROTECTED] wrote:
> Currently I'm thinking C for the target compiler just because of its
> ubiquity.
I don't think it matters much. Any language similar to C (or C itself)
is fine. The ticklish part is garbage collection, exceptions, and
the for
On Mon, Sep 11, 2000 at 04:01:53PM -0400, Dan Sugalski wrote:
> Are you thinking of something along the lines of FORTH or PostScript? Or
> something else?
Something else. Forth and PostScript are languages which are implemented
through stacks; I'm talking about a language designed for manipulati
At 08:19 PM 9/11/00 +0100, Simon Cozens wrote:
>On Mon, Sep 11, 2000 at 02:39:14PM -0400, Dan Sugalski wrote:
> > At 01:23 PM 9/11/00 -0500, David L. Nicol wrote:
> > >Dan Sugalski wrote:
> > >
> > > > If anyone's got any arguments in a particular direction, now would
> be the
> > > > time. Once
On Mon, Sep 11, 2000 at 02:39:14PM -0400, Dan Sugalski wrote:
> At 01:23 PM 9/11/00 -0500, David L. Nicol wrote:
> >Dan Sugalski wrote:
> >
> > > If anyone's got any arguments in a particular direction, now would be the
> > > time. Once we're done wrangling, we'll start in on the features we need
At 01:23 PM 9/11/00 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
>
> > If anyone's got any arguments in a particular direction, now would be the
> > time. Once we're done wrangling, we'll start in on the features we need to
> > write into the PIL translator, and get implementation of that sta
Dan Sugalski wrote:
> If anyone's got any arguments in a particular direction, now would be the
> time. Once we're done wrangling, we'll start in on the features we need to
> write into the PIL translator, and get implementation of that started.
>
> Dan
31 matches
Mail list logo
