Re: Please make "last" work in "grep"
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Wed, May 02, 2001 at 08:05:29AM -0700, Larry Wall wrote:
> > Michael G Schwern writes:
> > : (grep {...} @stuff)[0] will work, but its inelegant.
> >
> > It's inelegant only because the slice doesn't know how to tell the
> > iterator it only needs one value. If it did know, you'd call it
> > elegant. :-)
>
> I'd call it Haskel!
That's "Haskell", for anyone Googling.
> I've just installed it and have been skimming the
> docs.
I eagerly anticipate a workable proposal for "monadic <>" (hopefully :-)
>
> Would be neat if: my($first) = grep {...} @list; knew to stop itself, yes.
>
> It also reminds me of mjd's mention of: my($first) = sort {...} @list;
> being O(n) if Perl were really Lazy.
But it would need a completely different algorithm. Which is not too
bad. And even
my ($first, $second, $third) = sort {...} @list;
is kind-of plausible. So we'd definitely want
((undef)x((@list+1)/2), $median) = sort {...} @list;
to apply Perl's patented MindReader(tm) technology and run a median
algorithm. Wait, that last one's probably a bit too far-fetched...
--
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.|Tel: +972-3-7658117 (Main office)`-
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: .NET
On Wed, May 02, 2001 at 04:26:27PM -0500, Jarkko Hietaniemi wrote: > You are saying that the Clippy wasn't originally and truly annoying? :-) Annoying enough to spawn vigor! http://www.red-bean.com/~joelh/vigor/ -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Q. What are "seven candles", "seven cows", and "seven heads of the beast which rises from the sea"? A: Metaphors. They are all symbolic. Which means, they are not real things. --Alex Chiu, Immortality Guy
Re: .NET
>> You can serialize/deserilize object with Storable
>>
>> $foo = new Bar
>> store_fd $foo, \*SOCKET;
>>
>> and on the other end
>>
>> $foo = retrieve_fd \*SOCKET;
>> $foo->bar;
>>
>> It will work if you have Bar module on both ends.
DS> Right, but I want it to work if you don't...
Then maybe SOAP::Lite? SOAP allows to serialize/deserialize objects
and make remote call. SOAP::Lite makes it quite transparent.
server part (which has module Bar):
use SOAP::Transport::HTTP;
SOAP::Transport::HTTP::CGI
-> dispatch_to(qw(Bar))
-> handle;
package Bar;
sub get_bar { new Bar };
sub new { ... };
sub bar { ... };
client part:
use SOAP::Lite +autodispatch =>
uri => 'http://www.host.com/Bar',
proxy => 'http://www.host.com/cgi-bin/server.pl';
my $foo = Bar->get_bar;
$foo->bar;
Another solution is module Class::Tom. I've not tried it so check it
yourself: http://search.cpan.org/doc/JDUNCAN/Class-Tom-3.02/Tom.pm.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/)|
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/) |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Minimalistic Perl 6 Language
Hey, all. This whole discussion on using . instead of -> made me think a lot about the Perl 6 language. Actually, this was the more recent of many religious wars happening on perl6-language about choosing this or that way of doing something. I remember many others like using my or using dynamic variables, using strict or no strict by default and the same with warnings, everything/nothing should be an object, etc. Well, every one of these discussions is actually very important, since the outcome of this will be the syntax of Perl, and the syntax defines much of how we feel the language. Of course we cannot judge a language by its syntax, we have to see the features and flexibility it offers (its internals), but usually the syntax is the first thing of the language we get in touch with, it's our first impression of the language, and a non-pleasant syntax can make one resist to learn a language. I really can say that because syntax made me resist to languages like Python, Ruby and Pascal, while it attracted me so much to Perl and C. Of course, when you see the language at a whole, you see the features and the flexibility it offers, what made me see how C and Java are inflexible and how Perl and Python are flexible languages. But we have to admit that syntax has a strong importance in the first contact with the language. That's why I think perl6-language should change its course. I know this can sound a bit too strong, but please consider my points: First of all. Perl 6 will be flexible in its internals. We sure can say that, because we know Perl 5 very much to know what is good about it and what is not. We know it enough to say that tying is a good thing, and so is overloading. They both provide a very good level of transparency to the language. You can access any object through variables (and we hope in Perl 6 we'll be able to access them as filehandles, regexps, strings, etc). You can access any sub as an operation, by overloading that operation to that object. Nothing can be more transparent than that. We know, however, that Perl 5 has a rather weak implementation of both tying and overloading. Tying is too slow, and is rather cumbersome on XS level. Overloading isn't even documented in XS level, and there are some operations missing, there are some flaws in it. Well, I see perl6-internals is working hard on fixing some of this flaws while also adding a never seen level of flexibility, in areas including adding new opearators to the language, adding support for multiple encodings, pluggable regexp engines, and other levels of indirection to provide maximum transparency to the language. Second point. IIRC, the parser and bytecode generator of Perl 6 are to be flexible and extendable. If I understand this correctly, it would be possible, for example, to write another parser/generator for another completely different language, for example Python or Java, and make it generate bytecode for the Perl interpreter, that would use the powerful flexibility of Perl's guts. Also, if I understand correctly the flexibility and extendability of Perl 6's parser and generator, I would say it would be possible to make changes and additions to the syntax it implements by dealing with a well-defined and very clear API. For example, I would expect to be possible in Perl 6 to add a brand new operator to the language by only defining some sub, object, or whatever that defines the behaviour of the operator, and then registering the operator using an exported function of the parser, but -- this is important -- without needing to know of any internal details about the parser except for its exported API. Also, I would expect to be possible to change the default scope of variables just by adding some hooks to the parser and to the bytecode generator. Also, here I expect to learn only about the exported API of the parser and the exported API of the generator. I really don't care if they are implemented with a descending tree or with a bottom-up approache or in a xyyzy bar way, I would expect to have a clean API that would allow me to add hooks to them independently of their implementation. And I would also expect, that I could change `.' to be the operator that accesses methods in objects, like `$obj.method(@params)', instead of using `->'. Also, I could change `~' to do concatenation, and change many other operators to do whatever I want with them, all by using the exported APIs of the parser/generator. I would also expect to be able to change the language to accept variables without [$@%], and although this would probably mean deep changes in the languages, yes, I would expect to do this without having to write a new parser, but only by using the API of the parser/generator. And my last expectation (if I'm not expecting too much...) is that all these changes would be independent of each other. For example, I could make the change to accept variables without prefixing them with [$@%], then I could change `.' to access ob
Re: PDD for debugger
At 03:11 PM 5/2/2001 -0700, Dave Storrs wrote: >On Tue, 1 May 2001, Dan Sugalski wrote: > > > Right. What I'm thinking would be a good place to get to is a list of the > > functionality that the debugger needs to provide or have available to it > > from the interpreter, rather than the actual interface to the user. (Which > > is important, but a separate issue) >[snip] > > though. I think we're still at the "What functionality should the > > interpreter/compiler/parser provide to the person writing a debugger" > phase. > > > Errrmmm...sorry, but let me just be clear on this. I had intended >to write this document in (more or less) the following sections: > > - things that the user can do (set breakpoints, step, etc) > > - implementation details of each feature in the previous section >(what data structures do we use to store breakpoints? what information is >associated with them? etc) > > - the internals of the debugger; its APIs, etc. > > > It sounds like you don't want the first two sections. s/\./ yet./; >Can you >give me a better idea of what exactly you are looking for in this >document? I see I wasn't in the least bit clear. Sorry. :( What I want is a document that essentially declares "We want these things available to the debugger to present to the user". The primary use for this document is to make sure that we design in access points to the parser, compiler, optimizer, and interpreter so that the debugger can get access to the information that it needs and have the control one would usually like from a debugger. It's OK for this document to evolve into documentation of the debugger itself (though that could also be reasonably considered a separate thing), that's not what I was looking to shoot for yet. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Apocalypse 2 is up
Larry's Second Apocalypse (that's part 2 of his travels through the Camel writing about what will change in perl 6) is on the web at: http://www.perl.com/ Enjoy! Nat
Re: sandboxing
David L. Nicol wrote: > In all the discussion of customizing the parser, let us not > forget that we also need to be able to limit the parser. O.k., but what you say below isn't about limiting the parser, it's about limiting the VM. > is sandboxing something a language > should support at all, or is it best left to the OS to provide > a solid chroot facility? IMHO this is one of those things that should be kept firmly in the front of our minds as we design the engine. It is yet another area in which we could do right what java got half-right. -- John Porter It's so mysterious, the land of tears.
RE: sandboxing
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > > At 05:22 PM 5/3/2001 -0400, John Porter wrote: > >David L. Nicol wrote: > > > is sandboxing something a language should support > > > at all, or is it best left to the OS to provide > > > a solid chroot facility? > > > >IMHO this is one of those things that should be kept firmly > >in the front of our minds as we design the engine. > >It is yet another area in which we could do right what java > >got half-right. > > The biggest problem I have with sandboxing is that to do it right is > apparently difficult, judging by the number of people that > get it wrong. We need to rope in a security expert, I think, for > the design. A Language-Based Approach to Security: http://www.cs.cmu.edu/~rwh/papers/langsec/dagstuhl.pdf ResearchIndex is a fun site to explore: http://citeseer.nj.nec.com/volpano98language.html Java influenced papers: http://www.cs.princeton.edu/sip/pub/
Re: So, we need a code name...
Edward Peschko writes: : > : (is a nice city in Italy with a great symbol, the tower of Pisa). : > : : > : a'P' at the beginning, which means 'Perl', : > : an 'I' which may mean 'Interpreter', : > : a'S' which may means'Six' : > : an 'A' which may means'Alpha' : > : > I suggest [1]Peterbilt. : : Why not parrot, again? Too many dead parrot jokes? Too many lousy acronyms? Platform-Agnostic Rabidly Rapid Object Thrasher Urque. Since it's something underlying Perl, I'd suggest a decrement of "Perl", which would of course be "Perk". The Java engine would have to be "Perj", I guess, which seems fitting somehow. The C# engine might be "Peri" because it's around whether you like it or not. Then Perl language variants could go the other way and be: PermMicro Perl PernNano Perl PeroJava Perl PerpPython Perl PerqQuick Perl PerrRuby Perl PersStrict Perl PertTypesafe Perl PeruUnforgivable Perl PervVectorized Perl PerwWonky Perl PerxExperimental Perl PeryYet Another Perl PerzZany Perl Pesayour ad here Pesbyour ad here ... 'Course, at that rate, we eventually get back to "Pisa"... Appearances notwithstanding, I am seriously suggesting "Perk". The name is, er, perky. Hopefully the implementation would be too. Larry
Re: Please make "last" work in "grep"
> > It also reminds me of mjd's mention of: my($first) = sort {...} @list;
> > being O(n) if Perl were really Lazy.
>
> But it would need a completely different algorithm. Which is not too
> bad. And even
>
> my ($first, $second, $third) = sort {...} @list;
>
> is kind-of plausible. So we'd definitely want ...
my @heapa is heap;
@heapa = @list;
my $first = shift @heapa;
my $second = shift @heapa;
my $third = shift @heapa;
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Parse, munge, repeat.
apo 2
I am going to miss doublequoting being the default quoting for here strings. I find that to be a very nice optimization and would like to know more about the reasoning behind taking it away. I worry that official standard p6 will be more difficult to use than official standard p5. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Parse, munge, repeat.
Re: .NET
Dave Storrs said: > On 3 May 2001, Ilya Martynov wrote: > > >> You can serialize/deserilize object with Storable > > >> > > >> $foo = new Bar > > >> store_fd $foo, \*SOCKET; > > >> > > >> and on the other end > > >> > > >> $foo = retrieve_fd \*SOCKET; > > >> $foo->bar; > > >> > > >> It will work if you have Bar module on both ends. > > > > DS> Right, but I want it to work if you don't... > > > > Then maybe SOAP::Lite? SOAP allows to serialize/deserialize objects > > and make remote call. SOAP::Lite makes it quite transparent. > > > Errm...wasn't (something like) this discussed just recently and > deemed a massive security hole? If I download a program, I don't want to > have to inspect every line of source to make that it won't download some > bizarre Trojaned module (or even an object instantiated from that module, > which is worse because it leaves fewer traces by not writing to disk) from > some far corner of Script Kiddie Land. Java's Classloaders and SecurityManagers illustrate one solution to this problem. Being able to set a security policy for various sources of code solves much of this problem. ~ j. // The Almighty in His infinite wisdom did not see fit to // create Frenchmen in the image of Englishmen. // -- Winston Churchill, 1942
sandboxing
In all the discussion of customizing the parser, let us not forget that we also need to be able to limit the parser. The "Penguin" module offers one interface for doing that. But the larger question remains, is sandboxing something a language should support at all, or is it best left to the OS to provide a solid chroot facility? -- David Nicol 816.235.1187 [EMAIL PROTECTED] Parse, munge, repeat.
Re: apo 2
On Thu, May 03, 2001 at 10:14:47PM -0500, David L. Nicol wrote:
>
> I am going to miss doublequoting being the default quoting for
> here strings. I find that to be a very nice optimization and
> would like to know more about the reasoning behind taking it
> away. I worry that official standard p6 will be more difficult
> to use than official standard p5.
>
yeah, I agree, the apoc-doc also didn't give any reason as to why this was
happening. I'd think that the automagic going along with FH, ie:
while ($line = FH)
{
}
would generalize quite easily into
print <
Re: So, we need a code name...
On Thu, May 03, 2001 at 12:32:40PM -0700, Larry Wall wrote: : Edward Peschko writes: : : > : (is a nice city in Italy with a great symbol, the tower of Pisa). : : > : : : > : a'P' at the beginning, which means 'Perl', : : > : an 'I' which may mean 'Interpreter', : : > : a'S' which may means'Six' : : > : an 'A' which may means'Alpha' : : > : : > I suggest [1]Peterbilt. : : : : Why not parrot, again? : : Too many dead parrot jokes? Too many lousy acronyms? Indeed. : Platform-Agnostic Rabidly Rapid Object Thrasher : : Urque. : : Since it's something underlying Perl, I'd suggest a decrement of : "Perl", which would of course be "Perk". The Java engine would have : to be "Perj", I guess, which seems fitting somehow. The C# engine might : be "Peri" because it's around whether you like it or not. : : Then Perl language variants could go the other way and be: : : [snipped variations] : : 'Course, at that rate, we eventually get back to "Pisa"... : : Appearances notwithstanding, I am seriously suggesting "Perk". The name : is, er, perky. Hopefully the implementation would be too. I agree. There are "perks" to building Perl 6, etc. "Think happy thoughts Peter" Casey West -- "In case of fire, do your utmost to alarm the hotel porter." --In a Vienna hotel
Re: .NET
On 3 May 2001, Ilya Martynov wrote: > >> You can serialize/deserilize object with Storable > >> > >> $foo = new Bar > >> store_fd $foo, \*SOCKET; > >> > >> and on the other end > >> > >> $foo = retrieve_fd \*SOCKET; > >> $foo->bar; > >> > >> It will work if you have Bar module on both ends. > > DS> Right, but I want it to work if you don't... > > Then maybe SOAP::Lite? SOAP allows to serialize/deserialize objects > and make remote call. SOAP::Lite makes it quite transparent. Errm...wasn't (something like) this discussed just recently and deemed a massive security hole? If I download a program, I don't want to have to inspect every line of source to make that it won't download some bizarre Trojaned module (or even an object instantiated from that module, which is worse because it leaves fewer traces by not writing to disk) from some far corner of Script Kiddie Land. Dave
Re: So, we need a code name...
Larry Wall wrote: [...] > Then Perl language variants could go the other way and be: > > PermMicro Perl > PernNano Perl > PeroJava Perl > PerpPython Perl > PerqQuick Perl > PerrRuby Perl > PersStrict Perl > PertTypesafe Perl > PeruUnforgivable Perl > PervVectorized Perl > PerwWonky Perl > PerxExperimental Perl > PeryYet Another Perl > PerzZany Perl > Pesayour ad here > Pesbyour ad here > ... Darn, I was hoping for PerltranFortran Perl
Re: .NET
On Wed, 2 May 2001, Dan Brian wrote: > Another snippet from the .NET whitepaper: > > > Everyone believes the Web will evolve, but for that evolution to be > truly empowering for developers, businesses, and consumers, a radical new > vision is needed. Microsoft's goal is to provide that vision and the > technology to make it a reality. > > > In other words, evolution in and of itself is not empowering. Without the > vision[tm], evolution is "deempowering". Well, strictly speaking, they only implied that, without their Vision[tm], evolution would be nonempowering...which is different than deempowering; things could just remain in a steady state. It's still a pretty arrogant claim, no matter which way you slice it. Dave
Re: sandboxing
At 05:22 PM 5/3/2001 -0400, John Porter wrote: >David L. Nicol wrote: > > is sandboxing something a language > > should support at all, or is it best left to the OS to provide > > a solid chroot facility? > >IMHO this is one of those things that should be kept firmly >in the front of our minds as we design the engine. >It is yet another area in which we could do right what java >got half-right. The biggest problem I have with sandboxing is that to do it right is apparently difficult, judging by the number of people that get it wrong. We need to rope in a security expert, I think, for the design. I don't suppose we have one in the house somewhere? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: So, we need a code name...
> : (is a nice city in Italy with a great symbol, the tower of Pisa). > : > : a'P' at the beginning, which means 'Perl', > : an 'I' which may mean 'Interpreter', > : a'S' which may means'Six' > : an 'A' which may means'Alpha' > > I suggest [1]Peterbilt. Why not parrot, again? Ed
Re: apo 2
David L. Nicol writes:
: I am going to miss doublequoting being the default quoting for
: here strings. I find that to be a very nice optimization and
: would like to know more about the reasoning behind taking it
: away. I worry that official standard p6 will be more difficult
: to use than official standard p5.
Mostly I didn't want to deal with the muddy case of where the
identifier might be a quote operator, possibly even a user-defined
one. But it's not something I feel implacable about. I'm mostly just
trying to pare Perl's list of oh-by-the-ways down to a dull roar.
You'll note that a great deal of what's going on comes under the
category of simplification (even if half the Slashdot crowd doesn't
understand that). I'm particularly partial to the simplifications that
allow us to increase the power of other parts of the language. This
particular simplification is only a little bit that way, though I can
imagine deciding to extend << syntax in other directions someday, in
which case we might want to put random function names after the <<.
But certainly we're not taking the autoquoting away from {} or =>,
so I suppose there's something to be said for keeping it here too.
Larry
Re: Please make "last" work in "grep"
From: "Alexander Farber (EED)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 02, 2001 5:13 AM Subject: Please make "last" work in "grep" > Here I am looking for a button with a special name - "Delete ..." - > and there can be only one such button, so I have to interrupt the > "grep" after I find it I'd rather see grep have split-like magic, where it sees the length of the list it is being assigned to, and stops when it has filled the list. So ($a, $b) = grep /!(.*)/, qw(1 4 0 5 !0!0 98 46 !9 !097!0!9080"; would stop looking after it had found and returned 0!0 and 9, and never even glance at the 98. Basicly, if you assign to a list of lvalues, @returnlist, it will stop looking after it has found scalar(@returnlist) matches or end-of-input. -=- James Mastros
Re: sandboxing
> The biggest problem I have with sandboxing is that to do it right is > apparently difficult, judging by the number of people that get it wrong. We > need to rope in a security expert, I think, for the design. > > I don't suppose we have one in the house somewhere? "Where have you gone, Malcolm Beattie? A nation turns its lonely eyes to you. Oooh-ooh-ooh." Er, a republic.
