Re: licensing issues
This was the subject of a list and an RFC. I'd hope not to see what we worked hard to come up with not go to waste, guys and gals. We came up with a "least of all evils" solution, I think, and I feel very strongly that not protecting Perl from outright theft, especially using very iffy licenses alone, is a huge mistake, and has already harmed the Perl language and communities of more than one operating system both in numbers (advocacy issue) and in financial damage. Respectfully, as with the other issues, let's please give Larry his time at bat with the RFC as it stands rather than second guessing ourselves again redundantly after the fact. p Jarkko Hietaniemi [EMAIL PROTECTED] wrote: Could you explain why do you think going more GPL would be a good thing for Perl? What things it would change compared with the current scheme? What problems it would solve? Do you not think it would create new ones? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
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...
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
Re: Backtracking through the source
Simon Cozens [EMAIL PROTECTED] wrote: 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 people... This would *honestly* be my preference; I think it would be far easier to write and understand than anything else. So long as it's nicely re-entrant we should be fine. 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 basically where I've been talking about a "creole processor", which would in these terms be a pre-preprocessor, I imagine. This was also my original source of confusion, since I thought that this was the primary goal of the "pre-processor". What I've worked on is something that takes in "creoles" or modes of perl or "little-language stuff" and turns it into pure perl before actual interpretation. I think it's simpler and may make more sense to turn it into perl than to have each creole spit out syntax trees. It's the difference between a bunch of little anthill add-ons versus a bunch of big everest add-ons, whether compiled in or linked, whether perl or api. David Grove [EMAIL PROTECTED]
Re: Guidelines for internals proposals and documentation
Dan Sugalski [EMAIL PROTECTED] wrote: At 10:19 AM 11/17/00 -0800, Ken Fox wrote: However, I don't want to see early (premature) adoption of fundamental pieces like the VM or parser. It makes sense to me to explore many possible designs and pick and choose between them. Also, if we can keep external API design separate from internal design I think we'll have more wiggle room to experiment. (That's one of the big problems with perl 5 right now.) That's one of the reasons I'd like to work on the APIs first. I realize that doing even that will have an effect on the design of the pieces behind the APIs, but we have to startsomewhere. But.. but... but... we don't even have a design spec. I mean, we don't even know for sure what Perl 6 is going to look like for certain, inside or outside. Wouldn't we have to know the outside before we try to put the insides together? Is there any action on the api lists that I'm not seeing? If not, I'd say we've got the cart before the horse.
Re: Guidelines for internals proposals and documentation
Nat and I argued parts of this (I think this is included) at some length. Actually, I think I drove him crazy getting specifics out of this. Adam Turoff [EMAIL PROTECTED] wrote: On Tue, Nov 14, 2000 at 05:59:40PM -0500, Dan Sugalski wrote: 6) Only a WG chair, pumpking, or one of the principals (i.e. Me, Nat, or Larry, or our replacements) can mark a PDD as developing, standard, or superceded. This doesn't sound right. I'm still waiting to find out whether a group will be submitting a) a single PDD, b) multiple PDD's, or c) multiple PDD's merged into a single PDD. case pdd a) this makes sense as stated, I think b) this makes no sense submitters would control their own PDD's except only leader could stamp accepted c) submitters would control their own PDD's except only leader could stamp PDD accepted and only leader could stamp master PDD anything esac Okay, my bash is a bit off, but you get the idea. If anyone is interested, I think that within groups, b or c sounds like a logical approach to solving the problems at hand, since each person would likely have a very very very specific problem area in mind. Method a sounds a bit like a ... hmmm ... cluster-Muck, with everybody trying to come up with bits and pieces of the same document rather than coming up with ideas that end up in a single (or multiple) PDD to be submitted even higher outside the working group. I'm thinking project management terms here. All PDDs (like RFCs) need to start with 'Status: Developing' by default. Since statuses like 'Standard', 'Rejected', etc. have Real Meaning (tm), there should be some review in place (by a WGC, principal, etc.). Statuses like 'Withdrawn' and 'Superceded' should be accepted from PDD authors/teams. FWIU, "Developing" would be after an initial proposal, and means it wasn't tossed out at the first mention of it. It makes sense that it's a status of its own. The RFC process accidentally required single-authorship for all RFCs. We should allow RFCs to be maintained by a group of collaborating authors (without forcing them to start a mailing list first). Any of these authors should be able to make updates and update the status as appropriate (e.g. Developing, Withdrawn, Superceded). I think this is similar to what I'm suggesting with my a-b-c's above. I do agree that single-authorship would be a management problem. But then, multiple management could cause tangenting, but (according to EFNet #perl) there's nothing wrong with discussing winnie the pooh from time to time when burnout sets in. ;-)) Maybe sub PDD's (SPDDs) can be conceived of as "discussion", but I think that perhaps in groups with big jobs, actual proposals about how minutiae might be accompilshed could help set ideas in stone more than just discussion, then discussion could have its proper place. If SPDD's are used, it would be the responsibility of a team leader to collect the ideas and come up with a main one that everyone needed to agree on, which should be a simple diplomatic process and less overall work for the team leader himself, and more thoughtful (full of thoughtoutedness) effort from the team members. This is a community process. I'm uncomfortable leaving such decisions to such a small number of people. How about nominating/electing a core team that will be responsible for the API design, whereby a vote of 3/10 is needed to reject a PDD and a vote of 5/10 is needed to accept a PDD? (The numbers 3, 5 and 10 are arbitrary, and used to demonstrate that this doesn't need to degenerate into review by committee.) This is where Nat and I, I think, had a hurdle, and is the reason for my reponse to this email. The concern that was expressed was the development of the interests of a small group overriding the interests of the whole, the creation of another perl-elite caste, etc. Nate, correct me if I have it wrong PLEASE... It is, within a single group, the responsibility of the team leader to moderate discussion and lead the team to a unanymous decision. Within the team, the leader could be removed by majority appeal, but otherwise has authority in that area, and could not override the group. With the groups as a collective, general election of a core team was shot down (I proposed that), and I'm agreeing to the reasons for it... it's potentially caste-building (that wasn't the reason, but I have my own reason too). Since one team would not be familiar with issues within another group, it would be a tremendous thing to ask of a "core team" to decide on all PDD's including both their own and ones they aren't directly working with. All in all, I think Dan's doing a good job making this make sense. I'm just curious about the inner workings of a group.
