Re: Backtracking through the source
On Thu, 30 Nov 2000, Bryan C. Warnock wrote: > You don't want the compiler design to be a 'hands-on experiment' for us > inexperienced folk? That's not elitist, that's pragmatic. > > You don't want this to be a learning experience - (corrections, observations, > answers) - to the same? *That's* elitist. Fair enough to a point, but please let's not overburden the experienced folk by also _expecting_ them to always supply "corrections, observations, and answers". -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Now, to try again...
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 in the language, and at what point > they merge into a single entity and how. 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 perl6 never gets off the ground because we can't figure out how to make 'use Java;' easy. "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. > Or, perhaps a more direct question. Has anyone given any thought about how > this multiple-input-style thingy is going to work? Can work? Should work? That's a good question. 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. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Now, to try again...
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 incongruent with your first paragraph. Could you > elaborate a bit? You had expressed concern about redundancy if each parser had to re-implement a whole slew of stuff: p> a prefilter of some sort, or multiple parsers (or worse, multiple p> "parser/lexer/tokenizer single-entity parts"... meaning redundant p> duplication of extra effort over and over again repeatedly). I was just trying to say that for many small tasks, I would guess that most of the default actions would not need to be overridden, and hence there would not, in practice, be all that much redundancy. > > Another route to keep in mind is spending effort working on and with > > things such as perl-byacc > 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 and outputs perl code. It just may not be what folks first think of as a "source filter" in the sense of using the Filter:: modules. For some problems, it's certainly too complex. For others it might not be. Not all problems need be shoe-horned into the same solution box. That's all I'm trying to say. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Now, to try again...
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 simple parameter setting/checking (like stuff in, say, your average > .rc file with a little control flow thrown in) when it's brought up. That's typically what I think of, too. When perl6.0 is released, it would be nice if it were reasonably easy to write the appropriate modules (or whatever) and use such little languages fairly easily. 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*. In between, there is a continuous spectrum of possibilities, and it may sometimes be appropriate to call on other tools to help out. But I don't think this should affect perl6-internals-api-parser very much. If the parser is sufficiently clever to parse something as complex as Perl, then it can probably be coerced into parsing something much simpler. So let's get on with the Perl6 parser. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Now, to try again...
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 problem. This is a nearly ubiquitously desired objective
> (writing the modules or whatever they are), but I have the fear that
> actually writing one will be so undaunting that it will be a seldom-used
> feature, or one that will be as often avoided as complex perl OOP (beyond
> the basics), provided only by the highest levels of perl mastery.
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
create it, and I don't see it as worthwhile to expend a disproportionate
amount of effort in that direction.
In another message, you write ...
> I also admit that I would, on a purely personal-bias level, prefer not
> to
> cast too much support in the direction of Python, Java, C#, or ASP at
which also seems to aruge for not working too too hard to make it easy to
write the Pythonish module.
I think one or both of us is confused.
> I don't
> see these little languages as Perl features, but as programmer features,
I don't see Python or Java as a "little language". Perhaps that's the
source of the confusion. I see a whole spectrum of "languages" one might
want to feed to perl6. Easy ones ("little languages") should be easy.
Hard ones (e.g. Tcl, Python) should be possible. In-between-ones should
be in between.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
