Re: Summary...tell me where I'm worng...
At 11:52 AM 8/2/00 -0600, Nathan Torkington wrote:
>Graham Barr writes:
> > Why would the fuzzy regex not be done this way ?
>
>I have some small objections:
>
>I think one regexp syntax with potentially wildly variable
>interpretations is a dangerous thing. If we want fuzzy
>regexp matching, either put it into the core's re engine
>or make it a module that doesn't use =~ and qr//.
Not qr, but =~'s OK. Nothing wrong with:
$re_thing = Some::Other::RE::Engine("ads7*&$$34/*@#^");
$foo =~ /$re_thing/;
>My big objection to a dynamically loadable core is my
>experience (admittedly limited) with GNOME and Mozilla.
>They're big Big BIG ... fat Fat FAT ... pigs Pigs PIGS.
>I see the plethora of componentized libraries as part of
>the problem. I fear Perl becoming a big fat pig too.
Perl will be snappy, if I have to build and test the thing on the
VaxStation II/GPX I've got at home. (At 1/3 VUP, it can be described many
ways, but "fast" is not one of 'em)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Summary...tell me where I'm worng...
Graham Barr writes:
> Why would the fuzzy regex not be done this way ?
I have some small objections:
I think one regexp syntax with potentially wildly variable
interpretations is a dangerous thing. If we want fuzzy
regexp matching, either put it into the core's re engine
or make it a module that doesn't use =~ and qr//.
I also think that lexically scoped RE engines are useless.
You want the engine scoped to the pattern, so you can mix
and match fuzzy with traditional (e.g., search engine has
box for pattern and buttons for regular RE or fuzzy, and
all you need to do is say:)
$pattern = param("pattern");
if (param("fuzzy")) {
$re = qr/$pattern/f;
} else {
$re = qr/$pattern/;
}
# ...
while () {
print if /$re/;
}
My big objection to a dynamically loadable core is my
experience (admittedly limited) with GNOME and Mozilla.
They're big Big BIG ... fat Fat FAT ... pigs Pigs PIGS.
I see the plethora of componentized libraries as part of
the problem. I fear Perl becoming a big fat pig too.
Nat
Re: Summary...tell me where I'm worng...
Tim Bunce wrote: > > How does "use My::New:Regex;" differ from "use Foo::Bar;"? > > If a module is written to require "more crap that someone would have to > install" then that's the way it's been written. That fact that that crap > includes a new regex module is no different from that crap including > any other kind of 'not part of the core library' module. > > ... > I disagree. Perl isn't about standing in the way of anything. 'Fraid I have to agree with Tim on this one. -- John Porter
Re: Summary...tell me where I'm worng...
On Wed, Aug 02, 2000 at 12:33:05AM -0600, Nathan Torkington wrote: > Tim Bunce writes: > > If people *want* to say "use My::New:Regex;" and have that install a > > new regex implementation for that lexical scope then we should allow > > that. > > I don't hear a good reason for why we'd want this. Why would the fuzzy regex not be done this way ? > All I can see is > that it would lead to yet more crap that someone would have to install > in order to use a module. > > > I doubt we'll see multiple regex engines but should shouldn't presume to > > stand in the way of making it possible. > > Au contraire. Some things we should stand in the way of. I suspect > that this is one. I am not sure I have an opinion either way on that, yet. But if you think of it as "matching" instead of regex then I am sure people could think up many uses. I suppose the question is "do they need the regex syntax ?" (ie =~,$1,$2 etc) or could they just use a functional interface from a module. Graham.
Re: Summary...tell me where I'm worng...
On Wed, Aug 02, 2000 at 12:33:05AM -0600, Nathan Torkington wrote: > > > If people *want* to say "use My::New:Regex;" and have that install a > > new regex implementation for that lexical scope then we should allow > > that. > > I don't hear a good reason for why we'd want this. All I can see is > that it would lead to yet more crap that someone would have to install > in order to use a module. How does "use My::New:Regex;" differ from "use Foo::Bar;"? If a module is written to require "more crap that someone would have to install" then that's the way it's been written. That fact that that crap includes a new regex module is no different from that crap including any other kind of 'not part of the core library' module. > > I doubt we'll see multiple regex engines but should shouldn't presume to > > stand in the way of making it possible. > > Au contraire. Some things we should stand in the way of. I suspect > that this is one. I disagree. Perl isn't about standing in the way of anything. Tim.
Re: Summary...tell me where I'm worng...
Tim Bunce writes: > > >The word "pluggable" gives me the willies. I feel like things like > > >REs should have one blessed implementation and set of capabilities. > > The key point here is *one blessed implementation*. (nat as nat) When I said that, I was keeping in mind that we might have multiple implementations when we're building a Perl to release, or preparing a new version of Perl. But I fear Joe Random User being able to install their own regexp engine. That way lies madness, surely. > If people *want* to say "use My::New:Regex;" and have that install a > new regex implementation for that lexical scope then we should allow > that. I don't hear a good reason for why we'd want this. All I can see is that it would lead to yet more crap that someone would have to install in order to use a module. > I doubt we'll see multiple regex engines but should shouldn't presume to > stand in the way of making it possible. Au contraire. Some things we should stand in the way of. I suspect that this is one. Nat
Re: Summary...tell me where I'm worng...
On Tue, Aug 01, 2000 at 05:23:27PM +0200, Dominic Dunlop wrote: > At 15:19 +0100 2000-08-01, Tim Bunce wrote: > > >RegEx (internals?) > > > >Yes, Yes, Yes. > > I could argue for regex being language too: > If the language group is > going to give each of perl's reserved words (and much else besides) > the third degree so as to decide whether it should stay in the core, > be cast into outer darkness, or end up somewhere in between, then I'd > say that the same should be done for the language supported by the > regex engine. Yes. Yes. Yes. Tim.
Re: Summary...tell me where I'm worng...
On Tue, Aug 01, 2000 at 01:28:09PM -0400, Dan Sugalski wrote: > At 11:01 AM 8/1/00 -0600, Nathan Torkington wrote: > >The word "pluggable" gives me the willies. I feel like things like > >REs should have one blessed implementation and set of capabilities. The key point here is *one blessed implementation*. If people *want* to say "use My::New:Regex;" and have that install a new regex implementation for that lexical scope then we should allow that. I don't see it even being a major technical challenge (assuming a vtable interface for major subsystems like the regex library, there are other ways of course). I doubt we'll see multiple regex engines but should shouldn't presume to stand in the way of making it possible. Tim.
Re: Summary...tell me where I'm worng...
At 11:01 -0600 2000-08-01, Nathan Torkington wrote: >Dominic Dunlop writes: >> Pluggable regex engines would make supporting (say) core and optional >> regex language features easier. > >(Nat qua Nat speaking) > >The word "pluggable" gives me the willies. I feel like things like >REs should have one blessed implementation and set of capabilities. ... >If nobody else will, I will RFC this architecture concept: unity. Fair enough. Some of the language folks may see this as party-pooping, but fair enough. The rest of what I said about the regex language still stands, though. -- Dominic Dunlop
RE: Summary...tell me where I'm worng...
>Perl's regex syntax in not poorly documented (IMHO, of couse). Some of the new stuff is. (Poorly documented, that is.) >MRE made me feel like a ghod (after I read chapter 7 for the third time ;) Some of the new stuff's not in MRE, which is, I suppose, partly why Jeffrey Friedl's working on a new edition (and trawling up a rich haul of bugs in the process -- see the p5p list). Of course, documentation in MRE II would lay that particular complaint of mine to rest (six feet deep in a in a lead-lined casket). -- Dominic Dunlop
Re: Summary...tell me where I'm worng...
At 11:01 AM 8/1/00 -0600, Nathan Torkington wrote: >The word "pluggable" gives me the willies. I feel like things like >REs should have one blessed implementation and set of capabilities. I >don't want to have four modules in my program, each of which requires >a different RE engine. I very much agree here. I've no problem if someone wants to do Weird Things with regex objects so the wacky regex engine's completely encapsulated. (And thus guaranteed to be around, otherwise you couldn't get the Odd Object in the first place) Given the pain involved in writing a regex engine this would keep the numbers down quite low. (Perhaps to two--the normal one and the fuzzy engine) >I also don't think that Perl should become a Big Fat Pig[tm] like >GNOME, where you need a half-zillion different shared libraries, each >of which comes from a different source, just to run a program. Absolutely, positively, yes! Perl should require exactly two things: A functioning C compiler and a functioning build environment. (Which may, if we write a make-ish thing in perl, consist of a bootstrapping compile script in the native script language) If folks want to use libwhatever they can darned well use it in an *optional* module. Building GDBM.pm with perl if you've got GDBM at build time's fine. Requiring GDBM to build perl in the first place definitely isn't. I think it's time to go update the job description and get some RFCs out. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Summary...tell me where I'm worng...
Dominic Dunlop writes: > Pluggable regex engines would make supporting (say) core and optional > regex language features easier. (Nat qua Nat speaking) The word "pluggable" gives me the willies. I feel like things like REs should have one blessed implementation and set of capabilities. I don't want to have four modules in my program, each of which requires a different RE engine. I also don't think that Perl should become a Big Fat Pig[tm] like GNOME, where you need a half-zillion different shared libraries, each of which comes from a different source, just to run a program. If nobody else will, I will RFC this architecture concept: unity. We want unity of language design, I think we should shoot for unity of implementation. That's not to say that we shouldn't design things modularly, but encouraging diverging released implementations of the modules seems like it would only lead to chaos. Nat
RE: Summary...tell me where I'm worng...
-Original Message- From: Dominic Dunlop [mailto:[EMAIL PROTECTED]] previously difficult or impossible (or merely verbose). But it's also more or less poorly documented, more or less poorly understood, more or less well-used, and more or less poorly tested. (Indeed, some of it's still marked as experimental.) Perl's regex syntax in not poorly documented (IMHO, of couse). MRE made me feel like a ghod (after I read chapter 7 for the third time ;) -Corwin
Re: Summary...tell me where I'm worng...
At 15:19 +0100 2000-08-01, Tim Bunce wrote: > >RegEx (internals?) > >Yes, Yes, Yes. I could argue for regex being language too: it's a little language, and it's got very crufty of late. Yes, it's sexy cruft which can be justified because it allows one to do neat things which were previously difficult or impossible (or merely verbose). But it's also more or less poorly documented, more or less poorly understood, more or less well-used, and more or less poorly tested. (Indeed, some of it's still marked as experimental.) If the language group is going to give each of perl's reserved words (and much else besides) the third degree so as to decide whether it should stay in the core, be cast into outer darkness, or end up somewhere in between, then I'd say that the same should be done for the language supported by the regex engine. Once the language group has decided what are the required and optional features of the regex language, then the internals folks can start working out how to make it fly (or tell the language folks it won't). Pluggable regex engines would make supporting (say) core and optional regex language features easier. Want me to write this up as an RFC? -- Dominic Dunlop
Re: Summary...tell me where I'm worng...
On Tue, Aug 01, 2000 at 07:03:42AM -0400, Grant M. wrote: > Just trying to catch up. This is where I understand the discussion > stands: > INTERNALS(?) > modular language: >Scanner/Symbol Table/Parser/Executor Internals. >Standard Functions separate from core (moving to language?) Some of each. >Modules Separate from everything (definitely language) Yes. > Strict(er) DataTypes: >Automatic Type Conversion(?) (internal or language?) >Native Size Allocation (Internal or language?) Language for now. > Items still under general discussion: >Formats (probably language if it stays) >Garbage Collection (internals?) >RegEx (internals?) Yes, Yes, Yes. >localtime() (arrays start at 0 or 1) (language) Yes. >Backward compatibility in general (who knows) Script Backward compatibility = language. XS Backward compatibility = here (later) if someone volunteers to write the code to make old XS code work with the new APIs. > If someone could just tell me where these discussions go > (as many aren't really defined yet) I would be grateful. Also, I'd say "if in doubt then it's not for perl6-internals, at least not for now". I'd also say there's not much point at the moment in discussing details of implementing features that we're not pretty sure will be in the language. I think there's _lot's_ of valuable work we can do here we can do here prior to the language being firmed up. If we start getting into details of other things we won't make progress on the basics, like vtable interfaces for SV and libraries, analysis of GC implementations etc. We need to be pretty sure of most of those kind of issues by the time the language gets firmed up. Tim.
