develooper Front page | perl.perl6.internals.api.parser | Postings from December 2000

Re: Now, to try again...

Thread Previous | Thread Next
David Grove
December 18, 2000 10:51
Re: Now, to try again...
Message ID:

Sam Tregar <> wrote:

 > On Mon, 18 Dec 2000, David Grove wrote:


 > > _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.

No no. I just think we've redefined the "little languages" as everests
rather than molehills. That scares me.

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 the
moment. A bit of stolen grammar, perhaps, but not support for the
languages outside of a pure perl context. We have a bit of ground to
recover. I've mixed feelings whether this effort can help or harm that. It
depends on marketing, of course. That's probably something that I just
have to work through, since I know we want that.

I think that it would be a nice thing to have, too, if we could use one
interpreter for multiple languages. One library in another language's
context. But like you say, that's out of context. But that's in context,
because that's what it sounds like we're reaching for: the ability to
parse anything to perl, whether it actually translates or not, using
methods that seem out of scope. We also want to produce the output of run
| binary | bytecode, meaning python in, .class (java) out.

I think this _should_ be a simple thing, or as recently suggested a simple
set of things. We don't appear to be going in that direction. I have long
since seen the "little languages" as altering Perl's syntax. Parsing C
into Perl or Perl source trees doesn't compute into that and it's just
blowing my mind.

Maybe it is simple. If it is, no problem. I do hope that we are able to
provide a simple interface to the end user for being able to use the
feature, however. Whatever effort we have to do to provide _them_ with
this simplicity is merited. It's the complexity of their work I'm
concerned about, not mine/ours.

Ideally, we're doing nothing more than mapping one to 'nother lexeme set.
If the user can do that simply, I'm happy (and would like to branch into
actually getting that started). Otherwise, if the user can't easily use
this feature, we haven't planned well.

 > > I have to be cynical about this. Of what benefit is this to the Perl
 > > community and language?
 > Yeesh.  You'd think we were proposing a serious piece of work here!  Of
 > what benefit to the Perl community is your staunch oposition to
 > an API that most of us want?

That's out of context for my concerns.

Let me be a little clearer and calmer: I am _already_ working on something
that could provide and receive mutual benefit from this tiny tidbit, so,
to me, it's serious. It's also serious because it's somewhere I _can_
participate effectively. I'm concerned because we've gone from altering
how perl sees Perl, to how perl interprets the entirety of the C language.
I'd like very much to participate in working on this specific tiny tidbit,
but we seem to be at two extremes (meeting in the middle in a few posts)
of complexity and goal. In order to understand how I can participate, I'm
looking for sensible methods of achieving the goals, and sensible goals to
achieve. Parsing C-laced-perl seems sensible. Parsing C does not. I mean,
if one wanted to go that far, more power to him. Do we have the ability to
do the simple things before we try to do the unseemly? I mean, can we aim
for the first and arrive at the latter?

As I've expressed, this is an area that I have intense interest, because
of my own work. In order for me to do my own work, and by extension to
assist in this piece of the puzzle in Perl 6, I have to find clear and
sensible goals and methods of reaching those goals. So, yes, it's
important to me.

On the other hand, you have made an interesting point... I didn't think of
it before. Using a c/python/java library within Perl code to come up with
cross-language-ability... I like that.

 > Is it just that you lack the imagination to see the potential benefit
 > here?

I do see the benefits, but it's almost utopian. I feel like we're trying
to eat an entire cow at once raw rather than a bite of juicy filet mignon
smotherd in mushrooms.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About