On Tue, Jan 02, 2001 at 06:22:31PM -0800, Steve Fink wrote:
> Just in looking at your example, it seems like some complex replacements
> would be a bit of a pain to generate. It would be nice to have a
> specification for those opcode replacements. Like, say, perl code. How
> hard would it be to d
That is way cool.
Though I'm not sure that all of the constructs of another language are
going to be that easy to map into perl opcodes. Arithmetic, sure. But
perl opcodes aren't exactly a universal intermediate language.
Just in looking at your example, it seems like some complex replacements
w
On Mon, Dec 18, 2000 at 10:12:35AM -0500, Andy Dougherty wrote:
> The issues of 'use Python' or 'use Pythonish' are a quite different issue.
> I don't think anyone believes it ought to be easy to *write* the Pythonish
> module. But it ought to be *possible*.
Incidentally, it's possible in Perl 5
I'm wondering if we should explicitly break out the languages that
comprise perl today. That'd be at least toplevel perl, regular
expressions, and pack. Maybe tr// and the second half of s/// are
sufficiently different too. If nothing else, it would highlight the
problems in switching languages mi
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Dec 2000, David Grove wrote:
>
> >
> > Andy Dougherty <[EMAIL PROTECTED]> wrote:
> >
> I think you misunderstand. I think it should be very easy to *use* a
> hypothetical Pythonish module. I don't expect it will be very easy to
> c
On Mon, 18 Dec 2000, David Grove wrote:
>
> Andy Dougherty <[EMAIL PROTECTED]> wrote:
>
> > The issues of 'use Python' or 'use Pythonish' are a quite different
> issue.
> > I don't think anyone believes it ought to be easy to *write* the
> Pythonish
> > module.
>
> I do.
> That's the probl
Sam Tregar <[EMAIL PROTECTED]> writes:
>
>It comes down to what is meant by "little language". When I hear that
>term I immediately think Scheme and TCL. They both have a small core and
>extremely regular syntax. I can imagine writing a smallish parser that
>spits out Perl bytecode for either.
Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
>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 t
David Grove <[EMAIL PROTECTED]> writes:
>
>Because what is the parser/lexer/tokenizer parsing? Perl? Pythonic?
>Javanese?
It is entierly possible to use one parser/lexer "engine" for multiple
languages - for example a yacc/byacc/bison LALR(1) parser is a simple
state machine - all the language
On Sun, 17 Dec 2000, Simon Cozens wrote:
> This is the fourth time I've sent this mail to perl6-internals-api-parser,
I've seen it on the list at least twice.
> but it doesn't seem to be arriving. None of my other mail is affected, and
> perl5-porters is, for once, behaving itself; why this lis
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:29 PM 12/18/00 +, David Grove wrote:
>
> >Sam Tregar <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, 18 Dec 2000, David Grove wrote:
> > >
> >
> >[snip]
> >
> > > > _Perl_ _within_ _a_ _Perl_ _context_ _and_ _for_ _Perl_
_purposes_,
At 06:05 PM 12/18/00 +, Nicholas Clark wrote:
>On Mon, Dec 18, 2000 at 11:30:09AM +, David Grove wrote:
> >
> > Bart Lateur <[EMAIL PROTECTED]> wrote:
>
> > > But, the gist of this post is: we don't want to loose the usefulness of
> > > the syntax highlighter, as soon as there is one syn
At 12:29 PM 12/18/00 +, David Grove wrote:
>Sam Tregar <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 18 Dec 2000, David Grove wrote:
> >
>
>[snip]
>
> > > _Perl_ _within_ _a_ _Perl_ _context_ _and_ _for_ _Perl_ _purposes_,
> >
> > Feeling a little hostile to the rest of the programming world?
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Dec 2000, David Grove wrote:
>
[snip]
> > _Perl_ _within_ _a_ _Perl_ _context_ _and_ _for_ _Perl_ _purposes_,
>
> Feeling a little hostile to the rest of the programming world? You're
> sounding almost nationalistic! We're not at war.
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 18, 2000 at 11:30:09AM +, David Grove wrote:
> >
> > Bart Lateur <[EMAIL PROTECTED]> wrote:
>
> > > But, the gist of this post is: we don't want to loose the
usefulness
> of
> > > the syntax highlighter, as soon as there is one
On Mon, Dec 18, 2000 at 11:30:09AM +, David Grove wrote:
>
> Bart Lateur <[EMAIL PROTECTED]> wrote:
> > But, the gist of this post is: we don't want to loose the usefulness of
> > the syntax highlighter, as soon as there is one syntax error in the
> > script, because this will be the norm
On Mon, 18 Dec 2000, David Grove wrote:
> For the full language spec, I don't think it's attainable, and honestly
> don't see the reason for it within the context of Perl.
I've got a simple reason for it - I think it's going to be part of the
Perl6 spec. Do I have any proof? Nope. We'll know
Bart Lateur <[EMAIL PROTECTED]> wrote:
> On Sun, 17 Dec 2000 14:11:50 -0700 (MST), Nathan Torkington wrote:
>
> >I think the problems with this that were raised in the past are:
> > * parsing partial source
> > * does this mean that the parser has to reparse the whole sourcefile
> > ever
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> The issues of 'use Python' or 'use Pythonish' are a quite different
issue.
> I don't think anyone believes it ought to be easy to *write* the
Pythonish
> module.
I do.
That's the problem. This is a nearly ubiquitously desired objective
(writing th
Andy Dougherty <[EMAIL PROTECTED]> 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.
>
> Correct. perl-byacc is a source filter. It takes in yacc source an
Another point re: the parsing process. I think it should be possible
for any of the steps or extensions to be defined as C code or as Perl
code. We're already shooting to have C subs isomorphic with Perl subs
so this shouldn't be a problem, just something to keep in mind.
Nat
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> I'm assuming that for performance reasons a parser-beast written in C would
NC> have code to do this conditionally compiled (like the -DDEBUGGING stuff)
NC> so that serious production perl wouldn't have the slowdown, but the perl
NC> yo
Sam Tregar <[EMAIL PROTECTED]> wrote:
> 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.
Sorr
On Sun, 17 Dec 2000, Dan Sugalski wrote:
> At 02:24 PM 12/17/00 -0500, Sam Tregar wrote:
> >It comes down to what is meant by "little language". When I hear that
> >term I immediately think Scheme and TCL.
> For my part, at least, I've been thinking of something either LISP-ish or
> very si
On Sun, 17 Dec 2000 14:11:50 -0700 (MST), Nathan Torkington wrote:
>I think the problems with this that were raised in the past are:
> * parsing partial source
> * does this mean that the parser has to reparse the whole sourcefile
> every time you type a character?
Hold it. I don't think that
On Sun, 17 Dec 2000, David Grove wrote:
> > "Little languages", on the other hand, are a somewhat different matter.
> > They will presumably be not-so-complex and hence won't require such
> deep
> > hooks, and some redundancy there won't be such a big problem.
>
> I'm not sure how this is inc
Sam Tregar <[EMAIL PROTECTED]> wrote:
> possible, right? Are you saying you don't think we should make it
> possible for someone to write a C parser for Perl?
For the full language spec, I don't think it's attainable, and honestly
don't see the reason for it within the context of Perl. It do
On Sun, Dec 17, 2000 at 02:11:50PM -0700, Nathan Torkington wrote:
> 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() str
This is the fourth time I've sent this mail to perl6-internals-api-parser,
but it doesn't seem to be arriving. None of my other mail is affected, and
perl5-porters is, for once, behaving itself; why this list in particular?
- Forwarded message from Simon Cozens <[EMAIL PROTECTED]> -
Dam
Damn this is annoying. Is it perl.org that's dropping mail or me?
- Forwarded message from Simon Cozens <[EMAIL PROTECTED]> -
On Sat, Dec 16, 2000 at 08:09:23PM +, David Grove wrote:
> Thinking of just the parser as a single entity seems to me to be headed into
> trouble unless we can
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
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
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
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
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
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 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 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
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 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 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 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
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
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
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
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
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:
> 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
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
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
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 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 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
Simon Cozens <[EMAIL PROTECTED]> wrote:
> > Simon (?) brought up the problem that we might end up with a
monolithic
> > beastie
>
> I don't recall saying anything about it being a problem. :)
Ok, it scared somebody. That much I remember.
> > Reading what you say, "parser/lexer/tokenizer"
On Sat, Dec 16, 2000 at 02:27:24AM -0500, Dan Sugalski wrote:
> Okay, it's time to try again, and this time I think it's best to skip the
> specifics of parameters and suchlike things.
>
> How do we want the parser/lexer/tokenizer piece to work, and what sorts of
> hooks do we want to provide t
On Sat, Dec 16, 2000 at 02:08:37PM +, 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.
That does relate
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> (Keeping in mind the input is source, and
> the output is a syntax tree)
Will you be my hero?
Or
Your clarity is sincerely appreciated.
Ok, _from_ the books on the reading list, I'm seeing no precedent for a
parser/lexer/tokenizer that uses multipl
58 matches
Mail list logo
