but if there's someone with both interest and expertise...)
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
he compilation/execution bits, which
could potentially call into the parser again...)
Dan
------"it's like this"---
Dan Sugalski even
gt;
>I don't think so. In a compiler I don't believe that the intermediate step
>is there, and I've never seen any compiler accept multiple input semantics
>and multiple output (meaning binary, bytecode, java, c#))
Pretty much everyone's compiler does this at this point. G
ll be a syntax tree
>
>I think I said that.
More or less. Perl will probably have two different intermediate
representations, the parsed syntax tree and bytecode. The parser only spits
out the syntax tree.
Dan
---
At 10:18 AM 11/21/00 -0800, Benjamin Stuhl wrote:
>--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 10:37 AM 11/21/00 +, David Grove wrote:
> > >Thanks for the clarifications, Simon.
> > >
> > >Simon Cozens <[EMAIL PROTECTED]> wrote:
>
At 12:46 PM 11/21/00 +, David Grove wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > At 10:37 AM 11/21/00 +, David Grove wrote:
> > >Thanks for the clarifications, Simon.
> > >
> > >Simon Cozens <[EMAIL PROTECTED]> wrote:
&g
At 01:04 PM 11/21/00 +, David Grove wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > At 07:36 AM 11/21/00 -0500, David Grove wrote:
> > >However, one thing is seriously lacking in this theory... if the
>parser is
> > >perl, how does the perl pa
At 11:45 PM 11/21/00 +, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > At 10:18 AM 11/21/00 -0800, Benjamin Stuhl wrote:
> >
> > >Well, it would (IMHO) make more sense to have
&g
At 11:51 PM 11/21/00 -0600, Jarkko Hietaniemi wrote:
>On Tue, Nov 21, 2000 at 09:39:16PM -0500, Dan Sugalski wrote:
> > At 11:45 PM 11/21/00 +, Tom Hughes wrote:
> > >In message <[EMAIL PROTECTED]>
> > > Dan Sugalski <[EMAIL PROTECTED]> wr
At 01:50 PM 11/22/00 -0500, Chaim Frenkel wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> At 07:36 AM 11/21/00 -0500, David Grove wrote:
> >> However, one thing is seriously lacking in this theory... if the parser is
>
r extensions.
Also, check the bibliography that got posted to perl6-meta--the advanced
compiler book I put on the list is one I rather like.
Dan
--"it's like this"---
Dan Sugalski
mon problem with regex parsers.
Probably the easiest thing is to implement some sort of file-tied scalar or
something that can provide bytes to the regex engine until it stops asking
for them. Some magic or other, though, will get us what we need.
At 12:11 PM 11/22/00 -0800, Steve Fink wrote:
>Dan Sugalski wrote:
> >
> > You're not wrong, but I don't think this is a huge problem. Lots of systems
> > do it like this at the moment--GCC comes to mind as a first one, but there
> > are lots of others. Gr
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
s just isn't a reasonable criticism of regex parsers since
>normal parsers do it all the time anyway!
It's certainly a reasonable criticism of parsers in general, and a good one
to keep in mind with regex based parsers. It's easier to overdo it with a
bad regex than it is
;re pasting a half-zillion regexes together.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
xpressions run over text and ultimately fail, but
rather cases where we need to chuck out part of what we have and restart?
Dan
--"it's like this"---
Dan Sugalski even
At 04:50 PM 11/27/00 -0500, Kurt D. Starsinic wrote:
>On Mon, Nov 27, 2000 at 04:41:34PM -0500, Dan Sugalski wrote:
> > Okay, here's a question for those of you with more experience at parsers
> > than I have. (Which would be about everyone)
> >
> > Is there an
is passed back to the function
whose pointer we got as parameter two.
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL
At 09:48 AM 11/28/00 -0800, Steve Fink wrote:
>Dan Sugalski wrote:
> >
> >int perl6_parse(PerlInterp *interp,
> >void *source,
> >int flags,
> >void *extra_pointer);
>
>Given that other thin
similar things you might need to remember.
Well, we do have the syntax tree, and can make whatever notes we want in
the stash of the interpreter we're dealing with. Maybe an "intederminate"
on the foo slot or something.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 07:03 PM 11/28/00 +, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > The third parameter is the flags parameter, and it's optional. If omitted
> > or set to PERL_CHAR_SOURCE, the second param
At 09:10 AM 11/28/00 -1000, Tim Jenness wrote:
>On Mon, 27 Nov 2000, Dan Sugalski wrote:
>
> > ---
> >
> >int perl6_parse(PerlInterp *interp,
> >void *source,
> >int flags,
> >
ways is that one being violated? (I can think of a couple
personally... :)
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 03:15 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
>On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> > At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> > >On Tue, Nov 28, 2000 at 07:03:49PM +, Tom Hughes wrote:
> > > > Applying the maxim th
At 09:05 PM 11/28/00 +, Nicholas Clark wrote:
>On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
> > > > is treated as if it points to a stream of bytes, where the first
> four are
>
not, since that would place the burden of knowing too
much about the guts of perl on whoever's using it. I don't want to do that.
Dan
------"it's like this"---
Dan Sugalski
At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 07:03 PM 11/28/00 +, Tom Hughes wrote:
> >>In message <[EMAIL PROTECTED]>
> >> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >>
>
around so that it didn't need to be re-created later.
Yup, we do. We'd call this (or something like it) when doing the whole
eval/do/require/use thing, so we may well be parsing into an existing
interpreter.
>On Mon, 27 Nov 2000, Dan Sugalski wrote:
>
> >
d for before the comment sequence. (Unless we
want to do some sort of probabalistic thing, or turn the whole parser into
a big neural net or something...)
Dan
------"it's like this"---
At 02:49 PM 11/29/00 +, Nicholas Clark wrote:
>On Wed, Nov 29, 2000 at 09:38:44AM -0500, Dan Sugalski wrote:
> > At 10:42 AM 11/29/00 +, Nick Ing-Simmons wrote:
>
> > >FILE * is not a good idea. PerlIO * is fine.
> >
> > The problem with that is we'
e anywhere
near as separate as we'd like. I think we're going to end up with a rather
odd mutant beast. Hopefully one that's understandable by reasonably sane
people...
Dan
--"it'
At 07:07 PM 11/29/00 +, Simon Cozens wrote:
>On Wed, Nov 29, 2000 at 02:02:31PM -0500, Dan Sugalski wrote:
> > I'm really thinking that the lexer, parser, and tokenizer can't be
> anywhere
> > near as separate as we'd like. I think we're going to end
dual. It might be that it's
not worth going insane making it configurable if we can handle 90% of the
cases with source filtering that have some hooks into the parser so they
can pass in hints and suchlike things.
Dan
At 07:29 AM 11/30/00 -0800, Dave Storrs wrote:
>On Wed, 29 Nov 2000, Dan Sugalski wrote:
>
> > At 09:51 AM 11/29/00 -0800, Dave Storrs wrote:
> > >I have a feeling this is a stupid question, but I have to ask anyway.
> > >
> > >Do we really need t
;.
Huh? You're not talking about using this union around, say, the IV slot in
a scalar, I hope...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PRO
sign, interpreter design,
whatever) it's best to get up to speed first.
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL
At 10:54 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>On Thu, Nov 30, 2000 at 11:23:11AM -0500, Dan Sugalski wrote:
> > At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> > >On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > > > On a related
you can't contribute. (This is the generic rather than
specific 'you' here) A good working knowledge of, say, the properties of
complex numbers is as important as knowledge of the guts when building the
complex number class.
Or, to use the building analogy, you don't
he building. A more appropriate analogy is
one where you walk into the architect's conference room and start
commenting on and fiddling with the design of the building. While the sign
says "Open Meeting", the expectation is that you're competent in the areas
That probably didn't talk you down, did it? :-/
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 06:28 PM 12/2/00 -0500, Bradley M. Kuhn wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > It's more than just the parser. You've got the bytecode compiler and
> > possibly the optimizer as well, and they're probably going to be all, or
> > mos
At 02:17 PM 12/13/00 +, Nicholas Clark wrote:
>On Wed, Nov 29, 2000 at 03:33:16PM -0500, Dan Sugalski wrote:
> > Good integration with source filters may well solve a large chunk of our
> > little language problem. They're a pain and a half to write now but if we
> &
At 02:36 PM 12/13/00 +, Nicholas Clark wrote:
>Ah. Digest system tells me some messages for me bounced.
>
> > From: Damien Neil <[EMAIL PROTECTED]>
> > On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote:
> > >int perl6_parse(PerlInterp *inte
I don't want us to get too hung up about all this--if it turns out that
providing a general-purpose extended language parser just doesn't come
easily, then we can put it off for perl 6.2 or later. As long as it's
spec'd out, we can add it in when we get time.
in mind is spending effort working on and with
>things such as perl-byacc (and maybe even the yet-to-be-written perl-lex)
>that help turn simple "languages" into perl.
That sounds rather keen, and I'm all for it. Maybe we can roll it into the
core di
ser will get you.
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
of parser extensions. Both have their places, and both
are targets. (And both may well exist lexically, so the parser may stop
parsing itself in mid-stream and start jamming source down a source filter
for a while and eating the filter's output)
Dan
--
xtension of files. (Since they'd probably come
in via a PerlIO stream tied to a host function somehow)
Dan
------"it's like this"---
Dan Sugalski
>What? I don't think anyone expects writing a new frontend for Perl 6 to
>be an easy job but "a programming nightmare"? "Beyond common sense"? I'm
>not suggesting they program it in StoryServer!
Gah! That's an evil thought. (Keep it up and you'l
sugar, not become a
>full-featured compiler/interpreter for those other languages.
That's not the impression I got. If we can read in real Python source,
that's keen by me.
Dan
--"it's like t
statement and eval the statement, only do it
with a scopeless eval, so things like lexical variables wouldn't
immediately disappear.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
urce trees doesn't compute into that and it's just
>blowing my mind.
>
>Maybe it is simple. If it is, no problem.
I think at the moment you just have to take it on faith that it'll work.
(And it will) Perhaps once things come into clearer f
x highlighting, I was thinking of an editor
>written in C with embedded perl. Such as emacs or vi.
Yup. The parser should have some mechanism to parse pieces of code, so the
editor can pass in small chunks for analysis.
Dan
--
ource, and the output is a syntax tree)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
executing it.
I'd personally like to provide a scopeless string eval, and the second
issue's a SMOP. (Though involving the parser on the fly would make it easier)
Dan
------"it's like this"---
56 matches
Mail list logo
