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
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
A parser that can handle partial programs (was Re: Now, to try again...)
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
incomplete.
I really like this idea, although I am unsure of how we might implement it.
I don't recall any of the compiler texts I have read over the years talking
about formal methods for writing such a "partial programs are acceptable"
parser.
Lisp-like languages handle this, but s-expressions are so trivial to parse
that it's no help to simply "follow" their example.
Perhaps, since we are doing recursive decent, we could have a user-definable
error function. If all possible errors have well-defined types, the caller
could define an error function that informs rather than croaks and could
prompt like this:
foo$ print "Hello world RET
foo (unclosed double-quote)$
Inside, this would be something like (sorry for writing in pseudo-Perl,
instead of pseudo-C):
$PROMPT = "foo$";
$interp = new Perl::Language::Interpeter();
$done = 0;
my $handleError = sub ($) {
my($errorID) = @_;
if (! $errorID) {
$interp-Eval($parseTree); $done = 1;
}
if ($errorID == $UNCLOSED_DOUBLE_QUOTE) {
$PROMPT = "foo (unclosed double-quote)$";
}
[...]
}
while (! $done) {
print "$PROMPT ";
$string .= STDIN; chomp $string;
$parseTree = $interp-Parse($string, $handleError);
}
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Re: Now, to try again...
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 tell me what I'd missed :-)
[snip]
I had a hairier thought last night.
Lots of people (well, certainly at least me and the person who wrote
it)
use syntax highlighting editors.
The remarks I've seen in comments in several syntax highlighting modes
for
perl say that is that perl is pretty much the hardest language to
parse.
For example, the syntax highlighter I find myself using at the moment
doesn't like:
$foo = \"abc";
It thinks that \" escapes that ". Oops.
Other nice things like s###; pod, __DATA__, here docs, not needed to
escape
some otherwise "interesting" characters inside regexps all seem to be
prone
to confusion. So one gets irritated, and either spend time trying to
fix
the mode, or "fix" your perl to make the mode happy.
Neither of which is getting your real job done (or letting you use your
spare time to fix perl instead of the mode)
There's only 1 thing that really knows how to parse perl - perl :-)
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)
[snip]
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 extremely difficult to find, especially in odd
contexts like grep {/[^.]/} where there's no leading =~ or !~ and in s///
where there's not a single ending but two, each with its own rules.
I'm not sure this is a parser issue, at least not when it comes to the
internal parsing of Perl for perl's sake. However, putting in db-like
(debug module) hooks that I can grab onto somewhere in the mix might be
helpful.
Re: Now, to try again...
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 extremely difficult to find, especially in odd
contexts like grep {/[^.]/} where there's no leading =~ or !~ and in s///
where there's not a single ending but two, each with its own rules.
I'm not sure this is a parser issue, at least not when it comes to the
internal parsing of Perl for perl's sake.
Actually, it is. Making a syntax highlighting editor would be a lot easier
if it hands:
$foo = $bar + 12;
and gets back:
$fooscalar =assign $barscalar +addition
12constant;end-of-statement
or something like it.
That's sort of what the parser will get you.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Now, to try again...
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.
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 language into perl, but not necessarily by
filtering it, at least not solely. It can also map creole lexemes to perl
lexemes (within the context of a more complex more-than-filter filter).
Filter's appropriate--one thing goes in and a processed version gets spat
out. It's not unreasonable for a filter to turn source that looks like this:
(setvar foo 'green)
into
$foo = $things{green};
and have perl actually only
Either way, if a creole is used, wouldn't what parses it come before any
perl-language parsing if a scanner detects that it's going to be used? I
mean, it's a bit convoluted, but I'm seeing two initial processes before
the perl parser/lexer:
1. scan for creole pragmata
2. if they exist, preprocess
3. perl parser/lexer... etc
Must a creole parser/lexer be invented that outputs a source tree, or
could it be as simple as translating to a common form (Perl 6 language
spec) and having only that common form be turned into our source tree? The
latter may make parsing slower and but would be programmer friendly, the
former would be faster but would almost certainly be a programming
nightmare... at least it would complicate things beyond common sense.
Both ways work. Emitting perl source is the domain of a source filter,
while altering the parser to eat non-perl source and emit a perl syntax
tree is the domain of parser extensions. Both have their places, and both
are targets. (And both may well exist lexically, so the parser may stop
parsing itself in mid-stream and start jamming source down a source filter
for a while and eating the filter's output)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Now, to try again...
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 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 that we might end up with a monolithic beastie, and my concern is simplicity for the (advanced) user to come up with syntax variants. Reading what you say, "parser/lexer/tokenizer" (multiple things) "part" (one thing). That's got to be a stumbling block of some kind. If we separate out the "parser" (or look at each of them individually - which might further help clarity), we have something that might be "plug and pl...", er..., "plug and code". But then, if we're using flex/bison (lexx/yacc), that doesn't sufficiently satisfy what I'm looking for in end-user usability. If joe hacker-wannabe wants to program in Java, he shouldn't have to write flex spex, mess with gobs of perlguts, or, hopefully, go outside the Perl language. I see this as leaving two options: having a perl layer above the parser, or replacing the parser with perl. If I understand the latter and our goals, this is where we're going, although I'll still voice that I think a simpler Perl abstraction on top of it all that a user can define as easily as a good non-compiled module would be highly beneficial. It would give us a single parser that we plug into. No semantics, guys, please. I'm trying to figure out how we're going to allow multiple input "languages" with a single, small parser. Maybe not a source filter so to speak, but a layer above what is normal for this collection of operations. My concern is to give users the ability to create innovation within Perl without being perl masters. p
