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 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 can do
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 play
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:
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 could
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
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 supposed to
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 define in
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 is the API
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 just
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 define in
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 some hooks
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 parser that
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
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++ istream, IO
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 source
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, but
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 if
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
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) when it's
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
23 matches
Mail list logo
