Michael G Schwern wrote:
> On Sun, Dec 17, 2000 at 12:11:01PM +1100, Jeremy Howard wrote:
> > Something to be careful of--it's easy to create a circular reference
when
> > using method pointers. As a result, neither the referrer nor referee
objects
> > are ever destroyed.
> >
> > When using method
On Sun, Dec 17, 2000 at 01:20:07AM +, Nicholas Clark wrote:
> I'm assuming we're all sort of thinking that input is certainly
> [good stuff]
>
> I don't think you can do that with eval in perl5, can you?
> If not, it represents something new the parser will have to be able to
> communicate wi
On Sun, Dec 17, 2000 at 12:43:15PM +, Simon Cozens wrote:
> On Sun, Dec 17, 2000 at 01:20:07AM +, Nicholas Clark wrote:
> > I'm assuming we're all sort of thinking that input is certainly
> > [good stuff]
Thanks, but you were supposed to tell me what I'd missed :-)
> > I don't think you
On Sat, 16 Dec 2000, David Grove wrote:
> Because what is the parser/lexer/tokenizer parsing? Perl? Pythonic?
> Javanese? All of them? Thinking of just the parser as a single entity
> seems to me to be headed into trouble unless we can define in advance what
> type of role these dialects will pla
On Sun, Dec 17, 2000 at 09:45:30AM -0500, Andy Dougherty wrote:
> (yet-to-be-written perl-lex)
Wolfgang Laun may take issue with that adjective.
--
The trouble with computers is that they do what you tell them, not what
you want.
-- D. Cohen
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Something I though of:
> If you're trying to write an interactive perl inputer - either a perl shell
> or just the command prompt on the debugger it would be useful if you
> could tell the parser that the chunk of source you're giving it may be
> incomp
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Everyone is quiet.
Give us a chance. ;)
> I'm assuming we're all sort of thinking that input is certainly
> (I will have failed to mention some things)
> * human readable programming language source (perl5, perl6, whatever else)
> * bytecode (which c
On Sun, 17 Dec 2000, Andy Dougherty wrote:
> Now matter how we slice it, it's going to be very hard for the first
> person to twist perl6 to parse something that is both complex and very
> different from Perl6. And I'm unconvinced that this difficulty ought to
> hold up the entire process. It w
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 17, 2000 at 12:43:15PM +, Simon Cozens wrote:
> > On Sun, Dec 17, 2000 at 01:20:07AM +, Nicholas Clark wrote:
> > > I'm assuming we're all sort of thinking that input is certainly
> > > [good stuff]
>
> Thanks, but you were su
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Sat, 16 Dec 2000, David Grove wrote:
>
> > Because what is the parser/lexer/tokenizer parsing? Perl? Pythonic?
> > Javanese? All of them? Thinking of just the parser as a single entity
> > seems to me to be headed into trouble unless we can def
At 11:13 AM 12/16/00 -0600, Jarkko Hietaniemi wrote:
>On Fri, Dec 15, 2000 at 03:10:16PM -0500, Dan Sugalski wrote:
> > At 11:18 AM 12/15/00 -0600, Jarkko Hietaniemi wrote:
> > >On Fri, Dec 15, 2000 at 12:13:01PM +, Simon Cozens wrote:
> > > > IMHO, the first thing we need to design and code i
On Sun, 17 Dec 2000, David Grove wrote:
> That sounds too complex for what seems like a more simple solution. When
> you say "turn simple 'languages' into perl", that's what Dan's told me is
> my source filter. Actually, it's a bit more than a source filter. The goal
> would be to turn the creole
Sam Tregar <[EMAIL PROTECTED]> wrote:
> I imagine that each supported language will likely have its own
prefered
> parsing strategy. Some will be perfectly lex-yacc-able. Some will be
> more like Perl than that and would benefit from some hooks into Perl's
> existing parser. I think we jus
At 09:45 AM 12/17/00 -0500, Andy Dougherty wrote:
>On Sat, 16 Dec 2000, David Grove wrote:
>
> > Because what is the parser/lexer/tokenizer parsing? Perl? Pythonic?
> > Javanese? All of them? Thinking of just the parser as a single entity
> > seems to me to be headed into trouble unless we can def
At 02:08 PM 12/16/00 +, David Grove wrote:
>Ok, _from_ the books on the reading list, I'm seeing no precedent for a
>parser/lexer/tokenizer that uses multiple input "languages". Yes I know
>that GCC does F77/ASM/C/C++ but I'm not sure those completely relate.
>Simon (?) brought up the problem
At 01:22 PM 12/17/00 +, David Grove wrote:
>Sam Tregar <[EMAIL PROTECTED]> wrote:
>
> > I imagine that each supported language will likely have its own
>prefered
> > parsing strategy. Some will be perfectly lex-yacc-able. Some will be
> > more like Perl than that and would benefit from so
At 12:41 PM 12/17/00 -0500, Bradley M. Kuhn wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> > Something I though of:
> > If you're trying to write an interactive perl inputer - either a perl shell
> > or just the command prompt on the debugger it would be useful if you
> > could tell the par
At 11:58 AM 12/17/00 +, David Grove wrote:
>As the maker of such an editor, I wouldn't mind getting any help from perl
>that can be gotten in this area. It's not really the rules that are
>gotchas, but the exceptions to the rules. The elements that you mentioned
>(strings and regexen) are extr
At 12:43 PM 12/17/00 -0500, Bradley M. Kuhn wrote:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > and the above can come from
> > * memory (C's zero terminated strings, blocks with lengths, other things
> >native to other languages
> > * files (by filename, file/socket handle, C FILE*, C++ i
At 12:17 PM 12/17/00 +, David Grove wrote:
>Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > Another route to keep 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.
>
>
At 02:24 PM 12/17/00 -0500, Sam Tregar wrote:
>On Sun, 17 Dec 2000, David Grove wrote:
>
> > That sounds too complex for what seems like a more simple solution. When
> > you say "turn simple 'languages' into perl", that's what Dan's told me is
> > my source filter. Actually, it's a bit more than a
On Sun, 17 Dec 2000, Dan Sugalski wrote:
> For my part, at least, I've been thinking of something either LISP-ish
> or very simple parameter setting/checking (like stuff in, say, your
> average .rc file with a little control flow thrown in) when it's
> brought up. Occasionally things FORTHish, b
Andy Dougherty writes:
> Now matter how we slice it, it's going to be very hard for the first
> person to twist perl6 to parse something that is both complex and very
> different from Perl6. And I'm unconvinced that this difficulty ought to
> hold up the entire process. It would be quite ironic
Nicholas Clark writes:
> Would it be sane to get the parser to return suitable information on the
> source to let a syntax analyser (such as a highlighting editor) know that
> character positions 5123 to 5146 are a qq() string (So it can change the
> font or the colour or whatever)
I think the pr
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Sun, 17 Dec 2000, Dan Sugalski wrote:
>
> > For my part, at least, I've been thinking of something either
LISP-ish
> > or very simple parameter setting/checking (like stuff in, say, your
> > average .rc file with a little control flow thrown in) wh
On Sun, 17 Dec 2000, David Grove wrote:
> Ok, my C's rather rusty, but are we interested in parsing that?
Yes. I've heard people talk about a C frontend. Will it ever see the
light? I don't know. Does it matter? I don't think so.
> Is Perl going to provide API to access pointers through so
26 matches
Mail list logo
