On Wed, Jan 17, 2001 at 11:03:05AM -0200, Branden wrote:
> I work with Perl and I also work with Tcl, and one thing I actually like
> about Tcl is that it's interactive like a shell, i.e. it gives you a prompt,
> where you type commands in and, if you type a whole command by the end of
> the line,
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
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
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 <[EM
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
>
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 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 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
On Fri, Dec 01, 2000 at 08:42:57PM -0500, Bradley M. Kuhn wrote:
> I believe that to do a true port to the JVM (e.g., supporting
> eval($STRING)), we'll need to implement a bootstrapping parser for the
> parser code in Java.
Uhm, and then in every other language we port it to. Are you *sure* that
On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote:
> I categorically do *NOT* want perl6-internals to turn into a basic course in
> compiler design, purely for the benefit of those who know nothing at all about
> what they're trying to achieve. I'd like Perl 6 to b
On Thu, Nov 30, 2000 at 05:07:32AM +, David Grove wrote:
> >From my understanding, "API" is the set of functions internal to Perl and
> PerlXS that allow C to access Perl internal structures, functions, etc.,
> for the purpose (or effect) of "writing" "Perl" in "C" (SvPV(whatsis)).
Uhm, no. A
On Thu, Nov 30, 2000 at 03:30:28AM +, David Grove wrote:
> For this, I'd probably look for it to be writable either in perl or in api
You keep using that word. I do not think it means what you think it means.
--
Pray to God, but keep rowing to shore.
-- Russian Proverb
On Wed, Nov 29, 2000 at 02:57:23PM -0500, Dan Sugalski wrote:
> My only worry is, how do we reconcile this with the idea of
> >Perl having an easily modifiable grammar and being a good environment for
> >little-language stuff?
>
> That's a good question, and it depends on what Larry's thinking o
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 up with a rather
> odd mutant beast. Hopefully one that's understandable by reasonably sane
> p
On Wed, Nov 29, 2000 at 09:51:07AM -0800, Dave Storrs wrote:
> I have a feeling this is a stupid question, but I have to ask anyway.
> Do we really need to pass in a PerlInterp pointer?
Yes. Threads. There's a reason for all the PERL_EXPLICIT_CONTEXT anxiety.
--
Old Japanese proverb:
T
On Tue, Nov 28, 2000 at 06:58:57PM +, Tom Hughes wrote:
> I didn't say that having infinite lookahead was better than allowing
> backtracking. I simply said that the two were equivalent and that any
> problem that can be solved by one can be solved by the other.
Fair enough.
> That's quite a
On Mon, Nov 27, 2000 at 11:49:30PM +, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Is there any reasonable case where we would need to backtrack over
> > successfully parsed source and redo the parsing? I'm not talking about the
On Wed, Nov 22, 2000 at 12:45:50PM +0100, Bart Lateur wrote:
> Heh. In short: are there
> any more *practical* "how do I build my own compiler" books, that people
> can wholeheartedly recommend?
"Modern Compiler Design in C" (or "... in ML" if you so desire) by Appel.
Bit weird in places - excel
On Tue, Nov 21, 2000 at 10:37:23AM +, David Grove wrote:
> I'm not sure that it's possible to do this, or disirable. If Larry wants
> Perl to use different modes, creoles, or ways of interpreting or
> understanding the "perl" language, then we have to let the parser have a
> bit more informati
On Tue, Nov 21, 2000 at 07:36:11AM -0500, David Grove wrote:
> > 1) The API presented to the rest of the world. This is likely one call,
>
> These are almost two separate things entirely. (I don't get the "one call"
> thing. What do you mean?)
A parser does, essentially, one single thing: it ta
On Wed, Nov 15, 2000 at 03:29:24AM +, David Grove wrote:
> If this should be a PDD, I'll be happy to propose it that way, but I will
> need some slight help in the specific implementation of the C code that
> does it.
I may have misunderstood the purpose of this group, but it's *API*, which
m
21 matches
Mail list logo
