Total perl6 test failure; are recent changes to IMCC involved?
After a complete cygwin reinstall, I've finally gotten parrot to install and pass 100% tests. Ok, great. However, perl6 seems to be breaking. Seems meaning that 100% of the tests are failing. This is bad. I've mananged to trace the error to the imcc phase. The outputted imcc code seems correct (or at least consistant with previous, working versions), but generates an error (test.warn) of: last token = [] (error) line 27: parse error Didn't create output asm. It gets the same error for any set of perl6 generated imcc. In this case, line 27 is: .emit Did anything get changed with this syntax? Joseph F. Ryan [EMAIL PROTECTED]
Re: [perl #20315] [PATCH] eval
Leopold Toetsch wrote: So it seems, that for multiple code segments, we'll have to take the PackFile_ConstTable out of the structure and include file/line/debug/whatever information. This would look like: packfile aka interpreter-code: - constants - code_segment[] - byte_code - byte_code_size - [ more of current packfile ] - filename - lines[] - [ more aditional stuff ] - prederefed_code - jit_info (jitted code) - fixups The debug stuff should have its own segment, linked to the corresponding code segment. The return value of Bcompile would then be a pointer to such a code_segment. BTW a PackFile_Constant should be a union IMHO, currently each type has its own storage. As a first step towards multiple code segments I did apply locally Juergen Boemmels Patch #18056. With little rediffing and twigging, this runs all tests, imcc's packout() for writing pbc files is working too. Only packdump is broken, but this didn't do very much anyway. So people please have a look at this patch and the description. With this patch in place, it shouldn't be too hard, to have multiple code segments, currently only in memory and with extending the PBC file also external. leo
Re: pretty pictures
On Thu, Jan 16, 2003 at 11:25:34AM -0800, Tupshin Harper said: The ability to download autodia off of the primary site and the mirror is unfortunately broken. Fwd-d to the author and apparently it's fixed now. Simon
APIS and metadata
Dear list, Please excuse my ignorance, and if the answer is just RTFM, then please shoot me. What is the plan for declaring Object Oriented APIs in parrot. In dotnet il, you have a OO concept built into the assembly, but parrot seems to be missing this. Is there a plan for supporting the high level definition of an abstract oo api that all parrot languages can use? Is there a way to wrap a c api in parrot and provide hints to the languages how to marschall the data. Have you considered porting the IL meta-data system on top of parrot? mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Total perl6 test failure; are recent changes to IMCC involved?
Joseph F. Ryan wrote: After a complete cygwin reinstall, I've finally gotten parrot to install and pass 100% tests. Ok, great. However, perl6 seems to be breaking. Seems meaning that 100% of the tests are failing. This is bad.error (test.warn) of: last token = [] (error) line 27: parse error Didn't create output asm. I did make a little change in imcc.l, but I have no difference in test results. $ make test $ perl6 --test -r both give: Failed TestStat Wstat Total Fail Failed List of Failed --- t/compiler/1.t1 256141 7.14% 14 t/compiler/b.t1 256 61 16.67% 4 2 subtests skipped. Does make test in languages/imcc succeed? Joseph F. Ryan [EMAIL PROTECTED] leo
Re: pretty pictures
On Thu, Jan 16, 2003 at 10:46:21AM -0800, Marc M. Adkins wrote: I have a Perl program that processes Perl source and generates fake C++ headers that doxygen will process. Doxygen doesn't have a hook for adding a I've done the same thing, you can get it or see the output here: http://smop.org/ -- Bart.
Re: pretty pictures
cool! i will try that out. mike --- Bart Schuller [EMAIL PROTECTED] wrote: On Thu, Jan 16, 2003 at 10:46:21AM -0800, Marc M. Adkins wrote: I have a Perl program that processes Perl source and generates fake C++ headers that doxygen will process. Doxygen doesn't have a hook for adding a I've done the same thing, you can get it or see the output here: http://smop.org/ -- Bart. = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thu, Jan 16, 2003 at 04:14:20PM -0600, Jonathan Scott Duff wrote: On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote: The headers I received make no mention of character set - does your mailer mark the message in any way? If not, then STMP will assume it's good old 7 bit ASCII Thus we are back to using uuencode :-) Which, actually, might not be a bad thing. It will give Unicode a boost by forcing people to become more aware of this issue. To a large extent, the software industry as a whole is driven by what makes the lives of programmers easier--as a simple example, programming editors are written by and for programmers, who use them to write other programs. If editors become Unicode by default (both input and output) then the other programs will start to become Unicode by default. Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. Could you explain why not? I'd like to be able to easily exchange mail and scripts with people in other countries. --Dks
Re: L2R/R2L syntax (was Re: Everything is an object.)
--- David Storrs [EMAIL PROTECTED] wrote: On Thu, Jan 16, 2003 at 04:14:20PM -0600, Jonathan Scott Duff wrote: On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote: The headers I received make no mention of character set - does your mailer mark the message in any way? If not, then STMP will assume it's good old 7 bit ASCII Thus we are back to using uuencode :-) Which, actually, might not be a bad thing. It will give Unicode a boost by forcing people to become more aware of this issue. To a large extent, the software industry as a whole is driven by what makes the lives of programmers easier--as a simple example, programming editors are written by and for programmers, who use them to write other programs. If editors become Unicode by default (both input and output) then the other programs will start to become Unicode by default. Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? Not just no, but Hell, no! The people who love Unicode best are those who've never had to work with it. That being said, I'm the guy who wants it, so what gives? Unicode is way more than most people will ever need. I can't think of very many people who really want sizeof(char) = sizeof(int). What we need is the ability to support selective Unicodification -- using a simple character set by default, but automatically transitioning/expanding/recoding as appropriate. For example, take your basic simple editor, and have it parse \u21F6 as (whatever glyph that is) and display it correctly. But it is allowed to store \u21F6 in the output stream. Or, have it convert to and from trigraphs. Instead of \u21F6, it could store ~ (or ??) or whatever) in the stream. This will encourage terminal software to support fonts that contain the code pages we need, and encourage text editor writers to code in a character-width-independent manner, but won't require the whole operating system to suddenly switch to Unicode. The point is that we know there's lots of utilities out there that we want to continue to be able to use, and they're not Unicode. So while we support unicode, and we lead the way in adopting, integrating, and utilizing Unicode, we have to do it in a way that's compatible with the rest of the world so they'll be encouraged to follow us. =Austin
Re: L2R/R2L syntax (was Re: Everything is an object.)
* David Storrs [EMAIL PROTECTED] [2003-01-17 19:29:25]: On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. Could you explain why not? I'd like to be able to easily exchange mail and scripts with people in other countries. Hi, I am a native Lithuanian, and the issue of different charsets and unicode is very important to me. We used to use iso-8859-4 charset and our current standard is iso-8859-13. Now, when I say standard, it means an official standadrd de jure , not the standard de facto. Desktop systems are dominated by Windows, and Microsoft has a terrible attitude towards this charset issue. Windows still uses iso-8859-4 and a bastardised version of iso-8859-13, which is called windows-1257. Things would be great if everyone used Unicode, but again, this presents a lot of problems. I usually use utf-8 but this means that most windows users will not be able to read my writings in emails (Outlook just scrables the whole thing). So my point would be that the world is not ready for unicode. At least until major companies start to take it seriously. Sure, it would be a nice thing to have everything in unicode, but I am afraid that is not possible yet. Especially when we have a lot of old systems, where the only editor is vi via ssh. And I am telling you this, because I know how hard it is to live in a world where your charset characters are not in ASCII (and I'm talking not 7-bit ascii, but ascii as a whole). So, yes, it would be nice to live in a perfect world, but we are not quite there yet. Petras Kudaras -- Just Another Lithuanian Perl Hacker
Re: L2R/R2L syntax (was Re: Everything is an object.)
At 8:08 AM -0800 1/17/03, David Storrs wrote: On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. Could you explain why not? Because it makes life significantly harder for everyone on the planet who already has a perfectly fine local system. What you're asking for is a massive software, hardware, and data conversion project, with all the work being done by all the world that doesn't use straight ASCII. Given that covers a good 80% of the world, well... seems just the tiniest bit arrogant to me. Very few people need to deal with inter-language data exchange. The vast majority of data is kept in the native language of the operator of the system, with most of the remainder in 7-bit ASCII, which fits in everyone's local character set anyway. Unicode is like XML. It's the least-bad solution we have for general data interchange. We just don't often *need* general data interchange. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Fri, Jan 17, 2003 at 12:19:01PM -0500, Dan Sugalski wrote: At 8:08 AM -0800 1/17/03, David Storrs wrote: On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote: At 7:13 AM -0800 1/17/03, David Storrs wrote: Do we at least all agree that it would be a good thing if Unicode were the default character set for everything, everywhere? That is, editors, xterms, keyboards, etc? No. No, we don't. Could you explain why not? Because it makes life significantly harder for everyone on the planet who already has a perfectly fine local system. What you're asking for is a massive software, hardware, and data conversion project, with all the work being done by all the world that doesn't use straight ASCII. Given that covers a good 80% of the world, well... seems just the tiniest bit arrogant to me. Actually, that's *not* what I'm asking for. It would appear that either my question was not clearly written, or that people didn't read it very careful before jumping to conclusions. I didn't say Let's start doing the conversion. I didn't say Let's force everyone else to do the conversion. What I said was Do we agree that this would be a good thing? To me it seems like a good thing. All I wanted to know was if there were issues I wasn't thinking of. Very few people need to deal with inter-language data exchange. The vast majority of data is kept in the native language of the operator of the system, with most of the remainder in 7-bit ASCII, which fits in everyone's local character set anyway. Unicode is like XML. It's the least-bad solution we have for general data interchange. We just don't often *need* general data interchange. Even if, for the sake of argument, we grant that this is the case right now (and, given the number of messed-up characters I get in my email every day, I do *not* grant it), it is becoming less and less the case every day. In 10 or 20 years, I believe it will be not just common but expected to have projects (programming and otherwise) that consist of people scattered all over the world, constantly passing their data around. To paraphrase your comment above, Unicode may be a pain, but it is the least bad solution we have. --Dks
Re: L2R/R2L syntax
So, to bring this thread back on track *again*, I hopefully offer this
summary.
1) Damian's idea of using ~ and ~ as L2R and R2L is well-liked. Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = grep { ... } ~ map { ... } ~ @in; # (2) (perl6)
@out ~ grep { ... } ~ map { ... } ~ @in; # (3)
@in ~ map { ... } ~ grep { ... } ~ @out; # (4)
My impression was that this was _instead_ of (1), eliminating the
specialized syntax of the map, grep, etc. functions in favor of this
more generic piping syntax, but that wasn't explicitly stated. Is that
correct?
2) You might be able to combine L2R and R2L piping in one statement.
Maybe.
3) How pretty you think the above is depends almost entirely on how the
tilde is rendered in your font.
4) Some people like the idea of having Unicode operators in perl6.
Some don't. There are issues with it. Larry hasn't come up with a
ruling yet. We should wait for his decision.
5) Sarcasm is, apparently, dead.
MikeL
Re: L2R/R2L syntax
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
So, to bring this thread back on track *again*, I hopefully offer this
summary.
1) Damian's idea of using ~ and ~ as L2R and R2L is well-liked. Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = grep { ... } ~ map { ... } ~ @in; # (2) (perl6)
@out ~ grep { ... } ~ map { ... } ~ @in; # (3)
@in ~ map { ... } ~ grep { ... } ~ @out; # (4)
My impression was that this was _instead_ of (1), eliminating the
specialized syntax of the map, grep, etc. functions in favor of this
more generic piping syntax, but that wasn't explicitly stated. Is that
correct?
I have to wonder how many people actually like this syntax, and how many only
say they do because it's Damian Conway who proposed it. And map/grep aren't
specialized syntax, you could do the same thing with a sub with a prototype
of (block, *@list).
2) You might be able to combine L2R and R2L piping in one statement.
Maybe.
Oh goody. I was worrying they might not be confusing enough.
3) How pretty you think the above is depends almost entirely on how the
tilde is rendered in your font.
I have a font where ~ is in the center, and I still hate it.
4) Some people like the idea of having Unicode operators in perl6.
Some don't. There are issues with it. Larry hasn't come up with a
ruling yet. We should wait for his decision.
5) Sarcasm is, apparently, dead.
MikeL
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
RE: L2R/R2L syntax
Mr. Nobody:
# I have to wonder how many people actually like this syntax,
# and how many only say they do because it's Damian Conway who
# proposed it. And map/grep aren't specialized syntax, you
IIRC Damian also supports Unicode operators (and may have originated the
idea), and obviously many people don't like them.
# could do the same thing with a sub with a prototype of
# (block, *@list).
Great. That could mean it won't work right for MyCustomArrayLikeThing.
# 2) You might be able to combine L2R and R2L piping in one statement.
# Maybe.
#
# Oh goody. I was worrying they might not be confusing enough.
There are a lot of confusing syntaxes in Perl--if you don't believe me,
go look at the Obfuscation section on PerlMonks. :^) That doesn't mean
we try to get rid of them--we just tell people not to use them, and they
don't unless they're trying to be perverse.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Mr. Nobody) writes: I have to wonder how many people actually like this syntax, and how many only say they do because it's Damian Conway who proposed it. And map/grep aren't specialized syntax, you could do the same thing with a sub with a prototype of (block, *@list). Well, I'll go record and say I think it's Bloody Silly. It's over-cutesy, adding syntax for the sake of syntax, doesn't do anything for the readability of code, and doesn't really actually gain very much anyway. But even so I dare say it'll go in because Damian likes it. -- King's Law of Clues : Common sense is inversely proportional to the academic intelligence of the person concerned.
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Brent Dax) writes: # could do the same thing with a sub with a prototype of # (block, *@list). Great. That could mean it won't work right for MyCustomArrayLikeThing. Can you explain what you mean by this, because it's not apparent to me that your statement is in any way correct. There are a lot of confusing syntaxes in Perl--if you don't believe me, go look at the Obfuscation section on PerlMonks. :^) That doesn't mean we try to get rid of them Of course not; it means we need to add more! -- MISTAKES: It Could Be That The Purpose Of Your Life Is Only To Serve As A Warning To Others http://www.despair.com
Re: L2R/R2L syntax
Mr. Nobody said:
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
So, to bring this thread back on track *again*, I hopefully offer this
summary.
1) Damian's idea of using ~ and ~ as L2R and R2L is well-liked. Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = grep { ... } ~ map { ... } ~ @in; # (2) (perl6)
@out ~ grep { ... } ~ map { ... } ~ @in; # (3)
@in ~ map { ... } ~ grep { ... } ~ @out; # (4)
My impression was that this was _instead_ of (1), eliminating the
specialized syntax of the map, grep, etc. functions in favor of this
more generic piping syntax, but that wasn't explicitly stated. Is that
correct?
I hope not. Don't forget that despite the caveats, the Perl should stay
Perl RFC was actually accepted.
OK, I could be convinced that there should be a change if it would
simplify and generalise, but I see no point in change for its own sake.
I have to wonder how many people actually like this syntax, and how many
only say they do because it's Damian Conway who proposed it.
I trust that we are all sufficiently grown up and devoid of marketing hype
that we can judge suggestions on their own merit.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
RE: Objects, finally (try 1)
At 10:28 AM -0600 1/15/03, Garrett Goebel wrote: Peter Haworth wrote: Dan Sugalski wrote: Adriano wrote: I think what Jonathan asked for was an operator for returning a method (as an object) which can be invoked later with some arguments (or even applied with a partial list of arguments for currying). This would be a lot more useful than a yes-or-no answer about the existence of a method. Exactly. 'Yes' might be valid one moment, and invalid the next. Not a very useful operation... Returning a coderef on the other hand is useful. Returning a valid coderef isn't often useful, very limiting, and potentially inappropriate for our main targets. The only way they're of any general use is if they just wrap the method invocation again, in which case they're also slower than a plain method call. I have this nasty feeling I'm going to be going over this explanation several times, so I'm going to do it once here and hope for the best. We are building an OO system for dynamic languages. This means the list of methods that exist for an object may vary over time, it means the list of methods that can be satisfied for an object vary over time, and it means the two sets don't completely overlap. Plus we also have multimethods to contend with, for the unwary When you invoke a method, like: foo-bar One of several things could happen: 1) The bar method somewhere in foo's hierarchy is invoked 2) The bar method for no args is invoked in foo's hierarchy 3) AUTOLOAD, or its moral equivalent, is invoked somewhere in the hierarchy because there is no bar method, so the fallback is used 4) Like #3, only it then creates a bar method 5) We invoke the bar method, which then changes before we can invoke it again Getting a handle on the real method, then, is potentially wrong in cases 2 and 5, and not possible or really wrong in 3 and 4 (depending on how we do autoloadish things). It's only really correct for case 1. For user-level code, that's perfectly fine--if you want to write code that is potentially really wrong, there's no problem. (You won't be the first nor, alas, the last) For that reason we should provide a way to get the real handle for a particular invocation, so if you only want it for user code, that's cool, read no further. For the interpreter's purposes, though, we can't really use it. User code can incorrectly function in the face of mutating back-ends, but the interpreter must behave correctly in all cases. That's where things get more interesting for us. Yes, I fully want a caching method-invocation layer, so we can do our best to go as fast as possible in the common case. There's a lot of literature on this, and I'm well aware that we need it if we want to have any hope of blazing speed. Doing that right, though, means caching method lookups and trapping symbol table mutations, doing... interesting potential dispatch courtesy of multimethods, and generally getting funky. Static method handles, though, are just of no use for the *interpreter*. User program, sure, interpreter, no way. The languages are just too dynamic for it to be correct. For that we need dynamic handles, and those are much more work. That's one of the reasons I didn't really address method invocation with objects, as I wasn't quite ready to get into methods yet. (And I'm still not sure how to handle closed classes, or if we even should--perl/ruby/python classes aren't ever closed, though .NET/JVM classes, IIRC, are all entirely closed) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Total perl6 test failure; are recent changes to IMCC involved?
Leopold Toetsch wrote: Joseph F. Ryan wrote: However, perl6 seems to be breaking. Seems meaning that 100% of the tests are failing. This is bad.error (test.warn) of: I did make a little change in imcc.l, but I have no difference in test results. $ make test $ perl6 --test -r both give: Failed TestStat Wstat Total Fail Failed List of Failed --- t/compiler/1.t1 256141 7.14% 14 t/compiler/b.t1 256 61 16.67% 4 2 subtests skipped. Does make test in languages/imcc succeed? Seems to. perl t/harness t/imcpasm/opt1.ok t/imcpasm/opt2.ok t/imcpasm/sub..ok t/syn/clashok t/syn/constok t/syn/labels...ok t/syn/namespaceok t/syn/scopeok All tests successful. Files=8, Tests=21, 2 wallclock secs ( 1.63 cusr + 0.81 csys = 2.44 CPU)
RE: Objects, finally (try 1)
At 11:44 AM -0500 1/15/03, attriel wrote: I think what Jonathan asked for was an operator for returning a method (as an object) which can be invoked later with some arguments (or even applied with a partial list of arguments for currying). This would be a lot more useful than a yes-or-no answer about the existence of a method. Exactly. 'Yes' might be valid one moment, and invalid the next. Not a very useful operation... Returning a coderef on the other hand is useful. Er. How could Is it possible to call this method become invalid, but the fptr remains valid? I'm not sure that I follow that ... I get the function pointer. Points to a method. Someone comes and redefines that method in the object's class, or deletes it outright. I still have a handle, so the code doesn't go away, but it's no longer the right code for that method name. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
occasioanl CVS hickups?
Here is a snippet from my last check in: .. /cvs/public/parrot/include/parrot/interpreter.h,v -- interpreter.h new revision: 1.62; previous revision: 1.61 done Cannot open file /tmp/#cvs.lastdir.27414: No such file or directory Access allowed: Personal Karma exceeds Environmental Karma. Checking in languages/ook/ook.pasm; /cvs/public/parrot/languages/ook/ook.pasm,v -- ook.pasm new revision: 1.2; previous revision: 1.1 done Mailing the commit message to [EMAIL PROTECTED] ^^ For the commit of interpreter.h the mail was not generated and I see no entry in perl.cvs.parrot. The following ci was ok then again. These commits were done in one bunch. leo
RE: Objects, finally (try 1) [x-adr][x-bayes]
At 11:44 AM -0600 1/15/03, Garrett Goebel wrote: From: attriel [mailto:[EMAIL PROTECTED]] I think what Jonathan asked for was an operator for returning a method (as an object) which can be invoked later with some arguments (or even applied with a partial list of arguments for currying). This would be a lot more useful than a yes-or-no answer about the existence of a method. Exactly. 'Yes' might be valid one moment, and invalid the next. Not a very useful operation... Returning a coderef on the other hand is useful. Er. How could Is it possible to call this method become invalid, but the fptr remains valid? I'm not sure that I follow that ... Perhaps I'm misunderstanding Dan's meaning when he talks of invalidating method handles. Yep. (Horse, meet stick. Stick, meet horse. Prepare to be thumped again) I'm not talking about user-level code. I had originally figured that would just walk through the symbol tables and inheritance trees and find the method there and grab it, with no vtable involvement at all--code of the form: $foo = Bar-can(baz); doesn't really involve parrot's method code at all. (Or so I thought, though I'm coming to think differently, as even that will need to be delegated to the objects at some point) I've been concerned with cases like: foo-bar foo-bar foo-bar where the compiler would be getting foo's bar method once, sticking it into a PMC reg, and invoking it three times. Which would be very wrong, as that handle would be potentially really wrong after the first use. (Heck, finding it could potentially invalidate it, making the first use wrong) The common case for method handles, if they work, is as a shortcut/optimziation for the compiler, not for user code use, so that's what I'm most concerned with. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Objects, finally (try 1)
At 9:38 AM -0800 1/15/03, Jonathan Sillito wrote: I realize this will vary from language to language, but generally we will need a PMC that encapsulates a method (and responds to the invoke vtable method like Sub, or maybe the Sub PMC could do?). This python code is interesting: a = A() a.f()# output: A.f() x = a.f # get the method, a limited form of currying x() # output: A.f() setattr(A, f, g) # replace A's f with g a.f()# output: g() x() # output (still): A.f() !!! Which shows that the dispatch (i.e. selecting which method to call) can happen before the invocation. Right, which argues for a method fetch. Which is cool, we need it, I'll make sure it gets in the list. I've been arguing for things that will be generally of use to the compiler and interpreter though--things that will be useful for emitted code inferred from what the user's written, hence the confusion. The interpreter itself can't do that sort of explicit caching without a lot of infrastructure to support it. Though, as I dig through the mail, I'm realizing more and more that we *must* do the explicit caching layer, and if we want to take full advantage of it we need to expose it to the compilers rather than keeping it secret, though it may be fairly inefficient to start with. Damn. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Objects, finally (try 1)
At 3:06 PM -0500 1/15/03, Christopher Armstrong wrote: On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote: At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote: But who knows, maybe it could be made modular enough (i.e., more interface-oriented?) to allow the best of both worlds -- I'm far too novice wrt Parrot to figure out what it'd look like, unfortunately. It'll actually look like what we have now. If you can come up with something more abstract than: callmethod P1, foo that delegates the calling of the foo method to the method dispatch vtable entry for the object in P1, well... gimme, I want it. :) I'll add define method dispatch more to the list o' stuff for the next edit of the proposal. I'll help you along by offering this explanation of how instance methods work in Python. (sorry if you're already familiar with this stuff, but it's in my best interest to make sure you are ;-)) When you say something like `o.foo()', it translates into these steps: 1) LOAD_NAME 'o' 2) LOAD_ATTR 'bar' 3) CALL_FUNCTION #2 has extra magic. What I mean is, when you LOAD_ATTR a function from a *class*, you just get back a plain old `unbound method'. When you LOAD_ATTR from an *instance*, and (after failing to find an instance attribute) the attribute is found on its class, you get a `bound method', which basically means that Python has curried that method so the first argument is automatically passed -- that first argument is the instance which you LOAD_ATTRd from. This is why you see all those python methods with the first argument being `self', and rarely see code which explicitly passes that first argument. Now, like I said, this magic is done in LOAD_ATTR, not CALL_FUNCTION, so you can take that bound method object and do whatever you want with it before calling it. Here's an interesting code snippet which also demonstrates the fact that methods are just attributes. Hrm, interesting. Single symbol table for methods and attributes, though that's not too surprising all things considered. That may make interoperability interesting, but I was already expecting that to some extent. The bound method call thing we can do as a curried function, so I'm not that concerned about it in general, but it does definitely imply that we need to build in currying support to the core rather than leaving it to the compilers to do, though there's no reason that the functionality can't be left to the python opcode backwards-compatibility set and more explicit logic built into the python front end, but... Hrm. I appreciate the heads up here. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Objects, finally (try 1)
At 8:54 PM + 1/15/03, Nicholas Clark wrote: On Wed, Jan 15, 2003 at 01:00:59AM -0500, Dan Sugalski wrote: At 8:53 PM -0800 1/14/03, Adriano wrote: I think what Jonathan asked for was an operator for returning a method (as an object) which can be invoked later with some arguments (or even applied with a partial list of arguments for currying). This would be a lot more useful than a yes-or-no answer about the existence of a method. I thought about this--it's what the find_method vtable method was for in the first place. Unfortunately, as was pointed out to me, there's no good way to cache the result, since it could potentially be wrong by the time the method is actually called. We could potentially get around this if we put in place a notification framework to invalidate these method handles, but that means we have to have a fair amount of infrastructure in place to do that. (Though, honestly, I do really like the idea, as it means we can be faster by default and just pay the price when things change, but there's that pesky code that needs writing and systems that need designing to support it...) How much infrastructure do you need? I thought perl5 cached method lookup, but had a global (per interpreter) generation count, which went up by one every time you (re)defined a method. So for parrot you return a thingy that is initially implemented as the direct pointer, a generation count, plus enough other stuff to redo the search. If at the time of calling the generation count is the same, wehay, go for it. Otherwise redo the search there and then, and update. What I don't want is to check every time. I want method invalidation to be done only on demand, so the common case (multiple use without intervening redefinition) is as fast as possible. If we do implicit handles we'll need a good infrastructure with defined semantics to make sure those handles get either invalidated or rejigged when changes are made, plus we need them to support the cases where there is no real method and we're faking it all. I think I know what needs to be designed, and what semantics we need, and I'm pretty sure I know how to fake it until the structure's done, too, so after I dig through the rest of the aftermath here it'll be time to start writing. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Objects, finally (try 1)
At 3:03 PM -0800 1/15/03, Jonathan Sillito wrote: Sounds like we want objects *and* classes to support: static_attribs - which are defined at compile time and accessed by offset probably stored in an array. dynamic_attribs - which come and go at run time and are generally accessed by name and likely stored in a hash. Yep. I've pretty much decided that classes are objects, so the one falls out of the other there. We can deal with the dynamism fairly simply, though there are issues of efficiency, as I have the feeling that supporting the dynamic case well (which is reasonably rare, relatively speaking) will make all cases, or at least all method calls, slower. I think. Need to ponder this more. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #20298] Operators neg and abs in core.ops
At 4:53 PM + 1/14/03, Bernhard Schmalhofer (via RT) wrote: I have been looking at the ops 'neg' and 'abs' in core.ops. I have been adding testcase in t/op/arithmetics.t and found a couple of problematic cases. Sorry this one sat. I want to apply it, but the test patch looks to be reversed, and you included all of core.ops rather than a diff, and it's changed some. Could you send diffs? I'll apply it then. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #20298] Operators neg and abs in core.ops
On Fri, Jan 17, 2003 at 12:21:33PM -0500, Dan Sugalski wrote:
Sorry this one sat. I want to apply it, but the test patch looks to
On Tue, Jan 14, 2003 at 04:53:25PM +, Bernhard Schmalhofer wrote:
For the operator 'abs' I use the functions 'abs()' and 'fabs()' from the
C math library. 'abs()' might be problematic, as it isn't in the C99
standard, http://std.dkuug.dk/JTC1/SC22/WG14/www/standards.
fabs() is in C89 and C99.
???
Dan, problem, surely? Unless/until we work around things we want being
absent. In this case it's more getting the Configure infrastructure in place
to probe for the missing functions
Secondly, these routines assume that INTVAL is an int (not a long, nor
heresy), and that FLOATVAL is a double. I believe we can't make that
assumption:
inline op abs( inout INT) {
$1 = abs( $1 );
goto NEXT();
}
inline op abs(inout NUM) {
$1 = fabs( $1 );
goto NEXT();
}
inline op abs(out INT, in INT) {
$1 = abs( $2 );
goto NEXT();
}
inline op abs(out INT, in NUM) {
$1 = (INTVAL)fabs($2);
goto NEXT();
}
inline op abs(out NUM, in INT) {
$1 = (FLOATVAL)abs($2);
goto NEXT();
}
inline op abs(out NUM, in NUM) {
$1 = fabs( $2 );
goto NEXT();
}
We'd need more complex code to conditionally use fabs, fabsf, fabsl
(or work around absence of fabsf and fabsl), and abs, labs, llabs
(and work around the last one being missing)
We could make the call that we're not going to work around missing long
double functions - if you ain't got 'em, we refuse to Configure for that size.
Given that if you don't have fabsl, you probably don't have more tricky
functions such as sqrtl, modfl or atan2l
Nicholas Clark
Re: [perl #20298] Operators neg and abs in core.ops
--- Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Jan 17, 2003 at 12:21:33PM -0500, Dan Sugalski wrote:
Sorry this one sat. I want to apply it, but the test patch looks to
On Tue, Jan 14, 2003 at 04:53:25PM +, Bernhard Schmalhofer wrote:
For the operator 'abs' I use the functions 'abs()' and 'fabs()' from the
C math library. 'abs()' might be problematic, as it isn't in the C99
standard, http://std.dkuug.dk/JTC1/SC22/WG14/www/standards.
fabs() is in C89 and C99.
???
Dan, problem, surely? Unless/until we work around things we want being
absent. In this case it's more getting the Configure infrastructure in
place
to probe for the missing functions
Secondly, these routines assume that INTVAL is an int (not a long, nor
heresy), and that FLOATVAL is a double. I believe we can't make that
assumption:
inline op abs( inout INT) {
$1 = abs( $1 );
goto NEXT();
}
inline op abs(inout NUM) {
$1 = fabs( $1 );
goto NEXT();
}
inline op abs(out INT, in INT) {
$1 = abs( $2 );
goto NEXT();
}
inline op abs(out INT, in NUM) {
$1 = (INTVAL)fabs($2);
goto NEXT();
}
inline op abs(out NUM, in INT) {
$1 = (FLOATVAL)abs($2);
goto NEXT();
}
inline op abs(out NUM, in NUM) {
$1 = fabs( $2 );
goto NEXT();
}
We'd need more complex code to conditionally use fabs, fabsf, fabsl
(or work around absence of fabsf and fabsl), and abs, labs, llabs
(and work around the last one being missing)
We could make the call that we're not going to work around missing long
double functions - if you ain't got 'em, we refuse to Configure for that
size.
Given that if you don't have fabsl, you probably don't have more tricky
functions such as sqrtl, modfl or atan2l
Nicholas Clark
We could always use the old standby:
inline op abs(inout INT)
if($1 0) $1 = -$1;
goto NEXT();
}
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
[perl #20374] Solaris tinderbox failures: PANIC: Unknown signature type
# New Ticket Created by Andy Dougherty # Please include the string: [perl #20374] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20374 The Solaris tinderboxes are failing with the unhelpful message PANIC: Unknown signature type. Would it be possible to include the signature type that was failing to match in the error message? In this case, I suspect it's failing to match pIt, which was recently added to interpeter.c:setup_default_compreg(). -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #20374] Solaris tinderbox failures: PANIC: Unknown signature type
At 6:42 PM + 1/17/03, Andy Dougherty (via RT) wrote: # New Ticket Created by Andy Dougherty # Please include the string: [perl #20374] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=20374 The Solaris tinderboxes are failing with the unhelpful message PANIC: Unknown signature type. Would it be possible to include the signature type that was failing to match in the error message? In this case, I suspect it's failing to match pIt, which was recently added to interpeter.c:setup_default_compreg(). This seems to be killing everything. I'll go see about fixing it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: L2R/R2L syntax
Simon Cozens:
# [EMAIL PROTECTED] (Brent Dax) writes:
# # could do the same thing with a sub with a prototype of
# # (block, *@list).
#
# Great. That could mean it won't work right for
# MyCustomArrayLikeThing.
#
# Can you explain what you mean by this, because it's not
# apparent to me that your statement is in any way correct.
OK. Let's say I'm implementing HugeOnDiskArray, and instead of slurping
the array in and grepping over it, I want to grab the elements one at a
time, run them through the grep function's coderef, and stick them in
another HugeOnDiskArray. Or, if I have RemoteArray (which works with an
array on another computer via a server and a TCP/IP connection), I might
want to try to serialize the code reference given to grep and run the
grep on the remote computer. (If I can't serialize the coderef due to,
say, nonsense with closures, I'd run the grep locally.)
No, it won't work efficiently isn't the same as it won't work, but I
suspect there are cases I haven't thought of.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: L2R/R2L syntax
On Fri, Jan 17, 2003 at 09:57:47AM -0800, Mr. Nobody wrote:
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
@out = grep { ... } ~ map { ... } ~ @in; # (2) (perl6)
@out ~ grep { ... } ~ map { ... } ~ @in; # (3)
@in ~ map { ... } ~ grep { ... } ~ @out; # (4)
I have to wonder how many people actually like this syntax, and how many only
say they do because it's Damian Conway who proposed it.
I like this syntax because it's the best one proposed so far. As soon
as someone comes up with something better, this syntax would fall into
my mental gutter of good, but not good enough ideas.
I'd like - and - even more, if they were both available.
But we still need to hear from our Language Designer as to what he
thinks. He may decide that the whole concept isn't worth the hassle or
can be accomplished another way and then we don't have to worry about
syntax any more.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: L2R/R2L syntax
--- Thom Boyer [EMAIL PROTECTED] wrote: Mr. Nobody [mailto:[EMAIL PROTECTED]] groused: I have to wonder how many people actually like this syntax, and how many only say they do because it's Damian Conway who proposed it. Some of us like it because we've wanted something like it for years. On the other hand, at least one of us seems to dislike it just because it's Damian Conway who proposed it. =thom I have nothing against Damian himself, he's had some good ideas in the past. I just don't like proposals that make things more complicated for no gain. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: L2R/R2L syntax
You've overlooked ~| or ~ or whatever that operates on context by
default.
given @foo {
~ classify ~ @categories;
~ sort - @sorted_foo;
~ improve ~ @bar;
};
Personally, I'd like to see that syntax improved a little.
Anyway, I'd suggest that the order of execution of lines beginning with
a dangling grin or dragon operator by undefined. (So that p6.1 can run
them in separate threads.)
Which makes for a good motorized personal transporter(*) into another
TFH(+): Threads.
(!)
=Austin
(*) Segway -- aka segue.
(+) Topic From Hell
(!) All your base are belong to us! Fnord!
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
So, to bring this thread back on track *again*, I hopefully offer
this
summary.
1) Damian's idea of using ~ and ~ as L2R and R2L is well-liked.
Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = grep { ... } ~ map { ... } ~ @in; # (2) (perl6)
@out ~ grep { ... } ~ map { ... } ~ @in; # (3)
@in ~ map { ... } ~ grep { ... } ~ @out; # (4)
My impression was that this was _instead_ of (1), eliminating the
specialized syntax of the map, grep, etc. functions in favor of this
more generic piping syntax, but that wasn't explicitly stated. Is
that
correct?
2) You might be able to combine L2R and R2L piping in one statement.
Maybe.
3) How pretty you think the above is depends almost entirely on how
the
tilde is rendered in your font.
4) Some people like the idea of having Unicode operators in perl6.
Some don't. There are issues with it. Larry hasn't come up with a
ruling yet. We should wait for his decision.
5) Sarcasm is, apparently, dead.
MikeL
Re: L2R/R2L syntax
On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote: [EMAIL PROTECTED] (Mr. Nobody) writes: I have to wonder how many people actually like this syntax, and how many only say they do because it's Damian Conway who proposed it. And map/grep aren't specialized syntax, you could do the same thing with a sub with a prototype of (block, *@list). Well, I'll go record and say I think it's Bloody Silly. It's over-cutesy, adding syntax for the sake of syntax, doesn't do anything for the readability of code, and doesn't really actually gain very much anyway. That I will agree with to some extent. But mainly because I think that IF a pipe-like syntax is added then it should do just that, pipe. What has been proposed is not a pipe, unless each part gets converted to a co-routine and its arguments are really an interator that calls the previous stage to get the next argument. But even so I dare say it'll go in because Damian likes it. That statement I dont agree with. Yes Larry has put a lot of trust in Damian, but that has not resulted in Damian always getting what he wants, just most of the time :-) Graham.
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Brent Dax) writes: # # could do the same thing with a sub with a prototype of # # (block, *@list). OK. Let's say I'm implementing HugeOnDiskArray, and instead of slurping the array in and grepping over it, I want to grab the elements one at a time, run them through the grep function's coderef, and stick them in another HugeOnDiskArray. So if you want a lazy grep, you use (block, $list) rather than (block, *@list). Still no additional syntax required. -- Nuclear war can ruin your whole compile. -- Karl Lehenbauer
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Paul Johnson) writes: I trust that we are all sufficiently grown up and devoid of marketing hype that we can judge suggestions on their own merit. Do you need pointing to the archives at this point? -- DYSFUNCTION: The Only Consistent Feature of All of Your Dissatisfying Relationships is You. http://www.despair.com
Re: L2R/R2L syntax
I have to wonder how many people actually like this syntax, and how
many only say they do because it's Damian Conway who proposed it.
And map/grep aren't specialized syntax, you could do the same
thing with a sub with a prototype of (block, *@list).
I have to say that I am not specially entusiasthic about the ~
syntax.
I'd feel more confortable with a plain OO syntax:
@out = @in.grep({...}).map({.}).grep({...});
But my prefered option would be to ban map and grep alltogether,
replacing them with a non-void context for, enhanced with a where
clause:
@out = for @in where {...} {
...
}
The simplest cases don't get so horrible:
@out = map { $_* 2 } @in; # P5
@out = for @in { $^a * 2 }; # P6
@out = grep { $_ 0 } @in; # P5
@out = for @in where { $_ 0 };# P6
(Notice the implied {$_} in the for body)
And if you are really planning to chain nine different greps/maps/.. I
am afraid no amount of beautiful or ugly syntax will help you much.
Overall, I am worried that we are putting too much effort in creating
optimal syntaxes for some very specific cases.
This happens to be also my complain about hyperoperators (sorry for
bringing this again). Too much syntax, for a so small value.
I have always favoured RFC 207[1] syntax instead of hyperoperators
because it, at least, gives you some extra power:
@mat3 = @mat1[|i,|j] * @mat2[|j,|i]
But that's a different story,
-angel
[1] http://dev.perl.org/rfc/207.html
RE: L2R/R2L syntax
--- Brent Dax [EMAIL PROTECTED] wrote:
Simon Cozens:
# [EMAIL PROTECTED] (Brent Dax) writes:
# # could do the same thing with a sub with a prototype of
# # (block, *@list).
#
# Great. That could mean it won't work right for
# MyCustomArrayLikeThing.
#
# Can you explain what you mean by this, because it's not
# apparent to me that your statement is in any way correct.
OK. Let's say I'm implementing HugeOnDiskArray, and instead of
slurping
the array in and grepping over it, I want to grab the elements one at
a
time, run them through the grep function's coderef, and stick them in
another HugeOnDiskArray. Or, if I have RemoteArray (which works with
an
array on another computer via a server and a TCP/IP connection), I
might
want to try to serialize the code reference given to grep and run the
grep on the remote computer. (If I can't serialize the coderef due
to,
say, nonsense with closures, I'd run the grep locally.)
No, it won't work efficiently isn't the same as it won't work,
but I
suspect there are cases I haven't thought of.
I don't follow your example. If you can make
@safe_text = grep { ! /fnord/; } @HugeArrayOnDisk;
work, then why couldn't you make
@HugeArrayOnDisk - grep { ! /fnord/; } - @safe_text;
work just as well? I haven't read anything which says that the
different expressions call different incarnations of grep at the
bottom. (That would be the Array are/aren't Objects thread, and its
result STILL shouldn't impact the behavior of grin.)
=Austin
Re: L2R/R2L syntax
On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote: [EMAIL PROTECTED] (Mr. Nobody) writes: I have to wonder how many people actually like this syntax, and how many only say they do because it's Damian Conway who proposed it. And map/grep aren't specialized syntax, you could do the same thing with a sub with a prototype of (block, *@list). Well, I'll go record and say I think it's Bloody Silly. It's over-cutesy, adding syntax for the sake of syntax, doesn't do anything for the readability of code, and doesn't really actually gain very much anyway. It does something for me (at least the ~ version does). I find it annoying that to generate a map + sort + grep pipeline, I have to interrupt my L2R flow and construct it backwards. It mayn't be much, but I'd be happier if I had the option to construct the pipeline in a L2R manner. But even so I dare say it'll go in because Damian likes it. Was this some of that stealth sarcasm, or do you really believe this? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: L2R/R2L syntax
I'd like to point out one thing that I'm not sure of. It seems like the
original proposal only allowed for the operators to change terms around.
So given the same (1)-(4) from the message, (4) is exactly the same as (1), and
(2) and (3) are exactly the same as each other and as
@out = @in.map({ ... }).grep({ ...}); # (5)
I guess what I'm trying to point out is that the user still has to know which
syntax is really natively supported, and can only use ~ and ~ as crutches for
reversing that. IOW, we can't just eliminate the global map {block} @list
function, or @list ~ map {block} simply won't work (but could be written as
@list.map({block}). Somehow this feels even more confusing than ever.
So, to bring this thread back on track *again*, I hopefully offer this
summary.
1) Damian's idea of using ~ and ~ as L2R and R2L is well-liked. Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = grep { ... } ~ map { ... } ~ @in; # (2) (perl6)
@out ~ grep { ... } ~ map { ... } ~ @in; # (3)
@in ~ map { ... } ~ grep { ... } ~ @out; # (4)
My impression was that this was _instead_ of (1), eliminating the
specialized syntax of the map, grep, etc. functions in favor of this
more generic piping syntax, but that wasn't explicitly stated. Is that
correct?
2) You might be able to combine L2R and R2L piping in one statement.
Maybe.
3) How pretty you think the above is depends almost entirely on how the
tilde is rendered in your font.
Yes, it wasn't until I got on a different computer with ~ centered that I
understood why anyone even conceived of this. But Unicode is worse, since I
have NEVER gotten ANY of those to work. Apparently my gnome-terminal/ssh/less
combination just doesn't like unicode. But this is perl, so who cares if
anyone can read it, right?
4) Some people like the idea of having Unicode operators in perl6.
Some don't. There are issues with it. Larry hasn't come up with a
ruling yet. We should wait for his decision.
5) Sarcasm is, apparently, dead.
I'm not dead yet! I'm feeling much better, really.
MikeL
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
What exactly do we mean when we use the word semantics?
Re: L2R/R2L syntax
* Mr. Nobody [EMAIL PROTECTED] [2003-01-17 19:55:41]:
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
@out ~ grep { ... } ~ map { ... } ~ @in; # (3)
@in ~ map { ... } ~ grep { ... } ~ @out; # (4)
I have to wonder how many people actually like this syntax, and how many only
say they do because it's Damian Conway who proposed it.
Just for statistical purposes I would like to say that I do like this syntax and
this has nothing to do with Damian. I would have liked it if it was proposed
by anyone else anyway.
2) You might be able to combine L2R and R2L piping in one statement.
Maybe.
I think this is great. At least it caries the true Perlish philosophy of doing
things in an obfuscated way. However, although I like it because I am a Perl
programmer, these kind of things scare new people away because they think that
Perl is an awful language which is write-only. I thought this was going to
change with Perl6.
3) How pretty you think the above is depends almost entirely on how the
tilde is rendered in your font.
I have a font where ~ is in the center, and I still hate it.
I have a font where ~ is rendered above, and I still like it.
4) Some people like the idea of having Unicode operators in perl6.
Some don't. There are issues with it. Larry hasn't come up with a
ruling yet. We should wait for his decision.
As long as there is a [alternative] way to input (and read) Perl scripts in
simple ascii, I'm happy. Should there be an approach that Java used to have --
where \u escape sequences are parsed first and then the code is parsed?
(I am not terribly familiar with unicode technologies in programming languages,
so you can think of me as an ordinary newbie at this point ;)
Petras Kudaras
--
Just Another Lithuanian Perl Hacker
Re: L2R/R2L syntax
Mr. Nobody [EMAIL PROTECTED] wrote :
I have to wonder how many people actually like this syntax, and how many
only
say they do because it's Damian Conway who proposed it. And map/grep
aren't
specialized syntax, you could do the same thing with a sub with a
prototype
of (block, *@list).
I 50% like it: I think Damian was on the right track. It will be good to
have a way
for L2R pipes to work (whatever the syntax): but the Perl5 syntax for R2L
works
for me already (I'm neutral about adding extra syntax for it).
But the squiggly arrow doesn't seem right. I contrast it with the anonymous
sub composer (-) which was chosen, I think, because it worked well in
the context of a Cfor loop. Consider the following:
$\ = |; $, = ,;
1,2,3 - { print } # 1,2,3
1,2,3 ~ print;# 1,2,3
1,2,3 ~ - { print } # 1,2,3, but ugly
for 1,2,3 - { print } # 1|2|3
for 1,2,3 ~ print;# 1|2|3, but syntax error (*)
for 1,2,3 print; # 1|2|3, but syntax error
all(1,2,3) ~ print # junction(1,2,3)
all(1,2,3) - { print } # 1|2|3, but random order
It seems to me that the difference between the straight and squiggly arrows
is that one works with named subs; and the other with anonymous. If this
distinction is necessary, and ubiquitous, then perhaps we can live with it.
But then we shift our perception to think that - is an L2R pipe into a
block: not an anonymous sub composer. Similarly, the Cfor function is
a strange thing sends its elements down the pipe, one-by-one -- its not
a loop at afterall! (A junction, in contrast, would send its elements down
the pipe in random order, or concurrently).
Dave.
p.s. has Larry finished with those LoTR DVDs yet?
Re: L2R/R2L syntax
On Friday, January 17, 2003, at 09:57 AM, Mr. Nobody wrote:
And map/grep aren't specialized syntax, you could do the same thing
with a sub with a prototype of (block, *@list).
The specialized part is that, in perl5, it's:
@out = grep { ... } map { ... } @in;
instead of:
@out = grep { ... }, map { ... }, @in;
...the absence of the commas is what's special. If they were normal
functions/subroutines/methods/whatever, you would need a comma after
the first argument, or we need a generic rule saying that a comma is
optional after any closure.
The other, bigger issue is whether map, grep, etc. are methods of
arrays/lists, or as special (universal) functions. Using a pipe-like
syntax allows the following things to happen:
- Cmap, Cgrep, etc., all become methods, not universal functions.
That means you can override them for subclasses of Arrays just like you
would any other method, and you can make new methods that act like them
and have the same syntax.
- If you want a customized Cmap or Cgrep method for a subclass of
Array, you don't need to worry about _also_ overriding the universal
Cmap and Cgrep functions to recognize each of your subclasses using
multimethod variants.
- We don't need special comma-dropping rules for the grep and map
syntax.
- You can use the same piping syntax for indirect-object-style calls on
any methods:
$b = ~ fooify ~ mooify ~ gooify ~ $a;
same as:
$b = $a.gooify.mooify.fooify;
So short answer is, putting an operator in there like ~ and ~ is a
more generic syntax, and especially works better if arrays and lists
are objects. That's why it's being discussed.
MikeL
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Michael Lazzaro) writes: ...the absence of the commas is what's special. If they were normal functions/subroutines/methods/whatever, you would need a comma after the first argument This is plainly untrue. See the perlsub documentation, which talks about creating your own syntax with the prototype. You can do all this in Perl 5, and it saddens me that some of the people redesigning Perl don't know what Perl can do. -- Look, there are only a few billion people in the world, right? And they can only possibly know a few thousand bits of information not known by someone else, right? So the human race will never have a real need for more than a few terabits of storage, except possibly as cache. - Geraint Jones
Re: L2R/R2L syntax
Michael Lazzaro wrote:
So, to bring this thread back on track *again*, I hopefully offer this
summary.
1) Damian's idea of using ~ and ~ as L2R and R2L is well-liked. Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = grep { ... } ~ map { ... } ~ @in; # (2) (perl6)
@out ~ grep { ... } ~ map { ... } ~ @in; # (3)
@in ~ map { ... } ~ grep { ... } ~ @out; # (4)
My impression was that this was _instead_ of (1), eliminating the
specialized syntax of the map, grep, etc. functions in favor of this
more generic piping syntax, but that wasn't explicitly stated. Is that
correct?
My impression was that ~ and ~ were more general than that, and mainly
did syntax-rewriting.
So (4) above was translated in the parsing stage to be exactly identical
to (1), by the following conversions:
# original (4)
@in ~ map { ... } ~ grep { ... } - @out;
# Fully Parenthesized
(((@in ~ map { ... } ) ~ grep { ... } ) - @out
# @a ~ function becomes function @a
((map { ... } @in) ~ grep { ... } ) ~ @out
# @a ~ function === function @a
(grep { ... } (map { ... } @in)) ~ @out
# @a ~ @b === @b = @a
@out = (grep { ... } (map { ... } @in))
# removal of duplicate parenthesis
@out = grep { ... } map { ... } @in
So the syntax in (1) is still valid.
With (2) and (3), the situation is different, because they get
syntax-converted into a different form:
# Original (3)
@out ~ grep { ... } ~ map { ... } ~ @in;
# fully parenthesized
@out - ( grep { ... } ~ ( map { ... } ~ @in));
# function ~ @a function :@a
@out - { grep { ... } - { map { ... } :@in ));
# function ~ @a = function :@a
@out ~ grep { ... } :(map { ... } :@in)
# @a ~ @b = @a = @b
@out = grep { ... } :(map { ... } :@in)
which is horrible, and no one would want to use that directly as opposed
to syntax (1). But I can see beauty in (2) or (3).
Of course, since indirect-object syntax is syntactic sugar itself, this
goes on to be:
# function :@a === @a.function, applied repeatedly
@out = @in.map({...}).grep({...});
which is yet another L2R syntax.
But it also implies that map(block) and grep(block) are methods on
arrays (or Arrays).
The issue, as I see it, is that some people like to follow data flow
from right to left through a chain of actions. Perl 5 supported this
fine when it came to chained function calls:
sub byChar { $a cp $b }
for @words {
my $anagram = sort byChar split //, $_; # R2L flow of data.
push @$anagrams{$anagram}, $_;
}
Other people like to follow data flow from left to right through a chain
of actions. Perl 5 supported this fine when it came to method invocations:
$emplyeeTable-select('unionized')-raiseSalary(0.05);
But if you needed to have a chain of function calls, you couldn't easily
do left to right, and if you needed to have a chain of method
invocations, you couldn't easily to right to left.
The one saving grace for method invocation was the use of indirect
object syntax, which says that if the first argument of a
multi-argument function is an object and is not followed by a comma,
then the function should be interpreted as a method on that object:
print $filehandle $text;
is equivalent (in Perl 5) to
$filehandle-print($text);
But that doesn't scale. You can do the block that evaluates to an
object trick to do some chaining, which gets you:
raiseSalary {select $employeeTable 'unionized'} 0.05;
But that is ugly as sin and not truely Right to Left; it's more Middle
to Out.
To summarize (and, Piers, you can quote me on this)
Perl 5 allows you to do:
$object-meth1-meth2-meth3; # Perl5 chained method, L2R
Perl 6 will also allow you to do:
$data ~ sub1 ~ sub2 ~ sub3;# Perl6 chained subs, L2R
Perl 5 allows you to to:
sub3 sub2 sub1 $data; # Perl5 chained subs, R2L
Perl 6 will also allow you to do:
meth3 ~ meth2 ~ meth1 ~ $Xbject # Perl 6 chained methods, R2L
All four syntaxes will be available in Perl 6, modulo the fact that '-'
is now spelled '.'
The additional functionality that when the last sub or method in the ~
and ~ is a variable an assigment is done is a convenience issue.
2) You might be able to combine L2R and R2L piping in one statement.
Maybe.
(As an aside
I almost wish that calling a method with an incomplete argument list
would return a curried function, because that means that
$data ~ print ~ $filehandle;
would work!)
Re: L2R/R2L syntax
On Friday, January 17, 2003, at 10:41 AM, Dave Whipp wrote: But then we shift our perception to think that - is an L2R pipe into a block: not an anonymous sub composer. Similarly, the Cfor function is a strange thing sends its elements down the pipe, one-by-one -- its not a loop at afterall! (A junction, in contrast, would send its elements down the pipe in random order, or concurrently). And note that as pretty as - is, we couldn't have - for piping because it would conflict rather strongly things like if ($a-5)# (negative five, or pipelike?) Otherwise, using - and - would be ideal. Especially since then $foo-bar and $foo.bar are exactly equiv, helping perl5 people. Ah, well. :-/ MikeL
RE: L2R/R2L syntax
Buddha Buck:
# My impression was that ~ and ~ were more general than that,
# and mainly
# did syntax-rewriting.
Correct.
# So (4) above was translated in the parsing stage to be
# exactly identical
# to (1), by the following conversions:
#
## original (4)
#@in ~ map { ... } ~ grep { ... } - @out;
#
## Fully Parenthesized
#(((@in ~ map { ... } ) ~ grep { ... } ) - @out
#
## @a ~ function becomes function @a
#((map { ... } @in) ~ grep { ... } ) ~ @out
#
## @a ~ function === function @a
#(grep { ... } (map { ... } @in)) ~ @out
#
## @a ~ @b === @b = @a
#@out = (grep { ... } (map { ... } @in))
#
## removal of duplicate parenthesis
#@out = grep { ... } map { ... } @in
#
# So the syntax in (1) is still valid.
Incorrect. The translation sequence is:
@in ~ map { ... } ~ grep { ... } ~ @out
((@in ~ map { ... }) ~ grep { ... }) ~ @out
((@in.map({ ... })).grep({ ... })) ~ @out
@out=((@in.map({ ... })).grep({ ... }))
@[EMAIL PROTECTED]({ ... }).grep({ ... })
The only difference between '~' and '.' is that '~' is taken as the
terminator of an unparenthesized argument list, while '.' is taken as
binding to the last term.
# With (2) and (3), the situation is different, because they get
# syntax-converted into a different form:
#
## Original (3)
#@out ~ grep { ... } ~ map { ... } ~ @in;
#
## fully parenthesized
#@out - ( grep { ... } ~ ( map { ... } ~ @in));
#
## function ~ @a function :@a
#@out - { grep { ... } - { map { ... } :@in ));
#
## function ~ @a = function :@a
#@out ~ grep { ... } :(map { ... } :@in)
#
## @a ~ @b = @a = @b
#@out = grep { ... } :(map { ... } :@in)
#
# which is horrible, and no one would want to use that directly
# as opposed
# to syntax (1). But I can see beauty in (2) or (3).
#
# Of course, since indirect-object syntax is syntactic sugar
# itself, this
# goes on to be:
#
## function :@a === @a.function, applied repeatedly
#@out = @in.map({...}).grep({...});
#
# which is yet another L2R syntax.
Correct.
# But it also implies that map(block) and grep(block) are methods on
# arrays (or Arrays).
Correct again.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: L2R/R2L syntax
On 2003-01-17 at 19:00:04, Simon Cozens wrote: This is plainly untrue. See the perlsub documentation, which talks about creating your own syntax with the prototype. You can do all this in Perl 5, and it saddens me that some of the people redesigning Perl don't know what Perl can do. Well, if even some of the people redesigning the language are ignorant of some of its capabilities, that is an argument for making those capabilities easier to discover, and maybe even more intuitive to use, in the new design. The fact that a in a prototype obviates the following comma is a pretty obscure detail; it's not the sort of consistent behavior I'd want to build around going forward. But as I see it, the real problem being solved by the new syntax is that grep and map can exist solely as methods on some class in the inheritance tree of @arrays, no global functions required. That is a Good Thing. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: L2R/R2L syntax
On Fri, Jan 17, 2003 at 11:03:43AM -0800, Michael Lazzaro wrote: And note that as pretty as - is, we couldn't have - for piping because it would conflict rather strongly things like if ($a-5)# (negative five, or pipelike?) Pipelike. Longest token rule. --Dks
Re: L2R/R2L syntax
On 2003-01-17 at 14:15:46, I wrote: But as I see it, the real problem being solved by the new syntax is that grep and map can exist solely as methods on some class in the inheritance tree of @arrays, no global functions required. That is a Good Thing. I realize that such also be true if we just disallowed that direction, requiring e.g. %hash.keys.grep().map(). I would personally be perfectly happy with that restriction, and in fact find the operation much clearer when written that way. But I don't see any harm in providing a mechanism to allow the reversal; TMTOWDI is going to be as true of Perl6 as it is of Perl5. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: L2R/R2L syntax
Brent Dax wrote:
Incorrect. The translation sequence is:
@in ~ map { ... } ~ grep { ... } ~ @out
((@in ~ map { ... }) ~ grep { ... }) ~ @out
((@in.map({ ... })).grep({ ... })) ~ @out
@out=((@in.map({ ... })).grep({ ... }))
@[EMAIL PROTECTED]({ ... }).grep({ ... })
The only difference between '~' and '.' is that '~' is taken as the
terminator of an unparenthesized argument list, while '.' is taken as
binding to the last term.
Hmmm, I must have misunderstood Damian's suggestion when he said
(quoting Damian Conway)
Suppose ~ takes its left argument and binds it to
the end of the argument list of its right argument,
then evaluates that right argument and returns the result.
So an L2R array-processing chain is:
@out = @a ~ grep {...} ~ map {...} ~ sort;
I didn't read that as stating a semi-equivalence between '~' and '.'.
I guess I live and learn.
Re: L2R/R2L syntax
On Friday, January 17, 2003, at 11:00 AM, Simon Cozens wrote: [EMAIL PROTECTED] (Michael Lazzaro) writes: ...the absence of the commas is what's special. If they were normal functions/subroutines/methods/whatever, you would need a comma after the first argument This is plainly untrue. See the perlsub documentation, which talks about creating your own syntax with the prototype. You can do all this in Perl 5, and it saddens me that some of the people redesigning Perl don't know what Perl can do. No. I said it was _special_, not _impossible_. You're creating your own syntax -- that's exactly my point. Cmap, etc. are using an invocation syntax _slightly_ different from the vast majority of other cases -- one that skips a comma. Yes, it's a special case that exists because of the prototype and the special case caused by '', which is a special case precisely so that there can be *any* way to emulate the special case Cmap syntax. But whether we like the perl5 Cmap syntax or not, we should at least recognize that it's not regular. I'm not saying the ~ version is going to be any easier to learn, I'm just saying that it offers considerably more language-wide bang for the buck, especially if we're going to adopt stronger OO practices. On Friday, January 17, 2003, at 11:15 AM, Mark J. Reed wrote: The fact that a in a prototype obviates the following comma is a pretty obscure detail; it's not the sort of consistent behavior I'd want to build around going forward. But as I see it, the real problem being solved by the new syntax is that grep and map can exist solely as methods on some class in the inheritance tree of @arrays, no global functions required. That is a Good Thing. An emphatic yes, on both counts. MikeL
Re: L2R/R2L syntax
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
On Friday, January 17, 2003, at 11:00 AM, Simon Cozens wrote:
[EMAIL PROTECTED] (Michael Lazzaro) writes:
...the absence of the commas is what's special. If they were normal
functions/subroutines/methods/whatever, you would need a comma after
the first argument
This is plainly untrue. See the perlsub documentation, which talks
about
creating your own syntax with the prototype. You can do all this in
Perl 5, and it saddens me that some of the people redesigning Perl
don't
know what Perl can do.
No. I said it was _special_, not _impossible_. You're creating your
own syntax -- that's exactly my point. Cmap, etc. are using an
invocation syntax _slightly_ different from the vast majority of other
cases -- one that skips a comma. Yes, it's a special case that exists
because of the prototype and the special case caused by '', which is a
special case precisely so that there can be *any* way to emulate the
special case Cmap syntax. But whether we like the perl5 Cmap
syntax or not, we should at least recognize that it's not regular.
The syntax is going to be special no matter what. It has the power to turn
a bare block into a subref:
sub foo ($x) { }
sub bar (x) { }
foo { }; # hash
bar { }; # sub
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: L2R/R2L syntax
Dave Whipp wrote:
But the squiggly arrow doesn't seem right. I contrast it with the anonymous
sub composer (-) which was chosen, I think, because it worked well in
the context of a Cfor loop. Consider the following:
$\ = |; $, = ,;
Except, of course, those won't exist in Perl 6.
You want something like:
$*STDOUT.ors(|);
$*STDOUT.ofs(,);
1,2,3 - { print } # 1,2,3
Err, no. That generates the list: (1, 2, 3, sub(){print})
1,2,3 ~ print;# 1,2,3
Yes. Except it's: 1,2,3|
1,2,3 ~ - { print } # 1,2,3, but ugly
No. That's an error since you're specifying that the pointy sub
takes no parameters, and then trying to pass it three.
for 1,2,3 - { print } # 1|2|3
Yes. Though the output is actually 1|2|3|
And the - is redundant.
for 1,2,3 ~ print;# 1|2|3, but syntax error (*)
Kinda. The Cfor is missing its block. So it won't actually compile.
So the Cprint won't be called. But, if it had been:
for 1,2,3 ~ print {...}
then you get 1|2|3|
for 1,2,3 print; # 1|2|3, but syntax error
Huh? Just a syntax error, I think.
On the other hand:
for (1,2,3), print;
works, and isn't an error.
all(1,2,3) ~ print # junction(1,2,3)
No. You can't print junctions directly. You have to say how
you want them serialized. For example:
all(1,2,3).values ~ print # prints: 1,2,3|
all(1,2,3).dump ~ print # prints: all(1,2,3)
all(1,2,3).pick ~ print # prints on the values at random
all(1,2,3) - { print } # 1|2|3, but random order
This is the two-element list: ( 1|2|3, sub(){print} )
p.s. has Larry finished with those LoTR DVDs yet?
Probably.
We should bear in mind that Larry has had some health issues.
And that he's currently unemployed with four children to support.
Other matters are taking precedence at the moment.
Damian
Re: [perl #20374] Solaris tinderbox failures: PANIC: Unknown signature type
Andy Dougherty (via RT) wrote: In this case, I suspect it's failing to match pIt, which was recently added to interpeter.c:setup_default_compreg(). Nothing to suspect here ;-) In [CVS ci] eval #1 I wrote: Missing and left for an exercise for Joe Other Parrothacker: build_nativecall.pl lacks to handle an 'I' signature type, the interpreter should be pushed on the stack. Also the signature pIt is missing. So eval runs only on jit/i386 now. I think we can stand 3 failing tests for one or two days, when the reason is well known. leo
Re: [perl #20374] Solaris tinderbox failures: PANIC: Unknown signature type
At 9:38 PM +0100 1/17/03, Leopold Toetsch wrote: Andy Dougherty (via RT) wrote: In this case, I suspect it's failing to match pIt, which was recently added to interpeter.c:setup_default_compreg(). Nothing to suspect here ;-) In [CVS ci] eval #1 I wrote: Missing and left for an exercise for Joe Other Parrothacker: build_nativecall.pl lacks to handle an 'I' signature type, the interpreter should be pushed on the stack. Also the signature pIt is missing. So eval runs only on jit/i386 now. I think we can stand 3 failing tests for one or two days, when the reason is well known. Three? Every test fails under OS X because of this... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #20374] Solaris tinderbox failures: PANIC: Unknown signature type
On Fri, 17 Jan 2003, Leopold Toetsch wrote: Andy Dougherty (via RT) wrote: In this case, I suspect it's failing to match pIt, which was recently added to interpeter.c:setup_default_compreg(). Nothing to suspect here ;-) In [CVS ci] eval #1 I wrote: Missing and left for an exercise for Joe Other Parrothacker: build_nativecall.pl lacks to handle an 'I' signature type, the interpreter should be pushed on the stack. Also the signature pIt is missing. So eval runs only on jit/i386 now. Ah, I see. That's reasonable. Certainly you've done lots and lots; we can't expect you to do everything. I think we can stand 3 failing tests for one or two days, when the reason is well known. Well, it's more like there are perhaps 3 passing tests; everything else fails :-). That's one reason I didn't find your earlier message describing this problem. It wasn't obvious to me that this massive failure of nearly everything was due to eval, so I didn't think to look for messages in that thread. What I was actually hoping was that after suggesting a fix to cpu_dep.c yesterday to get it to at least compile, I could check the tinderbox today and see if my suggested fix worked. I can see my fix got cpu_dep.c to compile, but I don't know if it would also have passed any tests. Oh, well. I'm sorry I don't have much time to dig in myself and fix things. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #20374] Solaris tinderbox failures: PANIC: Unknown signature type
Dan Sugalski wrote: I think we can stand 3 failing tests for one or two days, when the reason is well known. Three? Every test fails under OS X because of this... Oops, dynamic vs static NCI..., sorry. If not done yet, I'll fix this tomorrow. leo
Re: L2R/R2L syntax
--- Damian Conway [EMAIL PROTECTED] wrote: We should bear in mind that Larry has had some health issues. And that he's currently unemployed with four children to support. Maybe he could find work hacking perl. I've heard he's pretty good... ;-) =Austin
Re: L2R/R2L syntax
Mark J. Reed wrote:
On 2003-01-17 at 19:00:04, Simon Cozens wrote:
This is plainly untrue. See the perlsub documentation, which talks about
creating your own syntax with the prototype. You can do all this in
Perl 5, and it saddens me that some of the people redesigning Perl don't
know what Perl can do.
Well, if even some of the people redesigning the language are
ignorant of some of its capabilities, that is an argument for making
those capabilities easier to discover, and maybe even more intuitive
to use, in the new design.
I see it more as the people who are ignorant of the features of Perl5
should go RTFM (Research The Features that they are Making?)
The fact that a in a prototype obviates
the following comma is a pretty obscure detail; it's not the sort
of consistent behavior I'd want to build around going forward.
Why not? Its a syntax that everyone (or at least, most people)
seem to like.
But as I see it, the real problem being solved by the new syntax
is that grep and map can exist solely as methods on some class
in the inheritance tree of @arrays, no global functions required.
That is a Good Thing.
In your opinion. I'll still want to be able to write 1-liners and
short scripts. I'm sure perl6 will still be used for things other
than large applications. Is it such a sin to want the old syntax?
Even if the definition for grep lives in a method, why couldn't
there also exist a global function that looks like:
sub grep(code,@array) {
@array.grep(code);
}
Or even if this function does not exist, there's nothing stopping
the compiler from simply aliasing:
grep {} @array;
to:
@array.grep({});
Joseph F. Ryan
[EMAIL PROTECTED]
Re: L2R/R2L syntax
Buddha Buck wrote:
My impression was that ~ and ~ were more general than that, and mainly
did syntax-rewriting.
You can certainly think of it as syntax rewriting
(though, personally, I don't).
What ~ and ~ do is to (respectively) allow arguments and invocants to
appear in a different position to normal: arguments to the left of the
subroutine/method name, and invocants to the right of the method's
argument list.
So, for subroutine arguments, these are exactly equivalent:
($arg2, $arg3, $arg4) ~ subname $arg1;
subname ($arg1, $arg2, $arg3, $arg4);
and for method invocants, these are exactly equivalent:
method($arg1, $arg2) ~ $invocant;
$invocant.method($arg1, $arg2);
method $invocant: $arg1, $arg2;
Notice that, in addition to pipelines, these proposed operators give us
MTOWTDI with respect to ordering of the components of a sub or method call.
That is, Perl 6 subroutines may have prefix and/or postfix argument lists,
and Perl 6 methods may have invocants that are any(prefix, infix, postfix).
Any similarity to Lingua::Romana::Perligata is strictly coincidental.
So (4) above was translated in the parsing stage to be exactly identical
to (1), by the following conversions:
# original (4)
@in ~ map { ... } ~ grep { ... } - @out;
# Fully Parenthesized
(((@in ~ map { ... } ) ~ grep { ... } ) - @out
# @a ~ function becomes function @a
((map { ... } @in) ~ grep { ... } ) ~ @out
# @a ~ function === function @a
(grep { ... } (map { ... } @in)) ~ @out
# @a ~ @b === @b = @a
@out = (grep { ... } (map { ... } @in))
# removal of duplicate parenthesis
@out = grep { ... } map { ... } @in
Yes. And the inference that most people seem to have drawn
is that this implies that Perl 6 would still have stand-alone
Cmap and Cgrep functions.
However, I suspect the correct inference is that Perl 6 will have
Cmap and Cgrep *multimethods*.
With (2) and (3), the situation is different, because they get
syntax-converted into a different form:
# Original (3)
@out ~ grep { ... } ~ map { ... } ~ @in;
# fully parenthesized
@out - ( grep { ... } ~ ( map { ... } ~ @in));
Correct.
# function ~ @a function :@a
No. method ~ @a method @a:
@out - { grep { ... } - { map { ... } :@in ));
No. That should be either:
@out ~ ( grep { ... } ~ ( map @in: { ... } ));
or:
@out ~ ( grep { ... } ~ ( @in.map({ ... }) ));
# function ~ @a = function :@a
@out ~ grep { ... } :(map { ... } :@in)
That's:
@out ~ grep (map @in: { ... }): { ... };
or:
@out ~ @in.map({ ... }).grep({ ... });
# @a ~ @b = @a = @b
@out = grep { ... } :(map { ... } :@in)
That's:
@out = grep (map @in: { ... }): { ... };
or:
@out = @in.map({ ... }).grep({ ... });
To summarize (and, Piers, you can quote me on this)
Perl 5 allows you to do:
$object-meth1-meth2-meth3; # Perl5 chained method, L2R
Perl 6 will also allow you to do:
$data ~ sub1 ~ sub2 ~ sub3;# Perl6 chained subs, L2R
Perl 5 allows you to to:
sub3 sub2 sub1 $data; # Perl5 chained subs, R2L
Perl 6 will also allow you to do:
meth3 ~ meth2 ~ meth1 ~ $Xbject # Perl 6 chained methods, R2L
All four syntaxes will be available in Perl 6, modulo the fact that '-'
is now spelled '.'
The additional functionality that when the last sub or method in the ~
and ~ is a variable an assigment is done is a convenience issue.
Exactly. Thank-you for summarizing it so well.
(As an aside
I almost wish that calling a method with an incomplete argument list
would return a curried function, because that means that
$data ~ print ~ $filehandle;
would work!)
You'll recall that we did consider those implicit semantics for
currying and decided against them, since they greatly degrade the
compiler's ability to detect accidentally incomplete argument lists.
Besides, since the precedences of ~ and ~ would differ
(~ binding tighter than ~), that *would* work:
$data ~ print ~ $filehandle;
=== ($data ~ (print ~ $filehandle));
=== ($data ~ $filehandle.print);
=== ($filehandle.print($data));
Damian
Re: L2R/R2L syntax
Buddha Buck wrote:
Brent Dax wrote:
Incorrect.
Hmmm, I must have misunderstood Damian's suggestion when he said
(quoting Damian Conway)
Suppose ~ takes its left argument and binds it to
the end of the argument list of its right argument,
then evaluates that right argument and returns the result.
So an L2R array-processing chain is:
@out = @a ~ grep {...} ~ map {...} ~ sort;
I didn't read that as stating a semi-equivalence between '~' and '.'.
I guess I live and learn.
No. Your reading was correct. This is a rare case of Brent being mistaken.
Damian
Re: L2R/R2L syntax
On 2003-01-17 at 17:17:03, Joseph F. Ryan wrote:
But as I see it, the real problem being solved by the new syntax
is that grep and map can exist solely as methods on some class
in the inheritance tree of @arrays, no global functions required.
That is a Good Thing.
In your opinion. I'll still want to be able to write 1-liners and
short scripts. I'm sure perl6 will still be used for things other
than large applications. Is it such a sin to want the old syntax?
Of course not. Nor is anybody arguing against the utility of
1-liners and short scripts, or the desirability of maintaining
Perl's usefulness for such.
Even if the definition for grep lives in a method, why couldn't
there also exist a global function that looks like:
sub grep(code,@array) {
@array.grep(code);
}
In that scenario, if you wanted to alter the behavior of grep, you
could probably get away with just modifying the array method, but
some modifications might require changing the function, too. Having
to change something in two places is generally a bad thing.
Or even if this function does not exist, there's nothing stopping
the compiler from simply aliasing:
grep {} @array;
Yes, but the goal is to avoid special cases. If these:
grep {expr} @array
map {expr} @array
become these:
@array.grep({expr})
@array.map({expr})
that violates the standard interpretation of such sequences. The
indirect object syntax (assuming that were inferred despite the
lack of a colon) would instead interpret them as this:
{expr}.grep(@array)
{expr}.map(@array)
While if we inverted the IO interpretation of the syntax, then this:
print $STDERR foo
would become this:
foo-print($STDERR)
What we're looking for is a way to keep something close to
the old syntax, but in a more generally applicable way.
Why? Because general rules are, in general (:)), better than special
cases, simply because they result in less stuff to remember. It's true
that you often have to violate that principle to get good usability, and
Perl is the archetypical example of willingness to do so, but that doesn't
mean that the principle itself is bad. It just can be overdone
(and TCL would be my candidate for the archetypical example of overdoing
it).
All that said, one other thing for both sides of this argument to remember
is this: if the final syntax is not to our liking, then there's
nothing to stop us from writing our own - as a global function or whatever.
And there's likely to be a module that supplies the alternative syntax
anyway, possibly even bundled with the distribution.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
RE: L2R/R2L syntax [x-adr][x-bayes]
From: Damian Conway [mailto:[EMAIL PROTECTED]] We should bear in mind that Larry has had some health issues. And that he's currently unemployed with four children to support. Other matters are taking precedence at the moment. Hmm... If the Larry and the Perl Foundation would be agreeable. I'd just as soon see a grant set up for Larry again this year. And if so, I'd like to see the Perl Foundation grant(s) publicized before tax-deductable donations to non-profit organizations can no longer be applied to 2002. If so, I'm pretty sure I'll be able to match last years' contribution. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: L2R/R2L syntax
Damian Conway:
# Brent Dax wrote:
# Incorrect.
# No. Your reading was correct. This is a rare case of Brent
# being mistaken.
Ack, sorry to both you and Buddha, and anyone else I inadvertently
confused. Well, at least I'm good enough for this to be considered a
rare case. :^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
RE: L2R/R2L syntax
Damian Conway:
# What ~ and ~ do is to (respectively) allow arguments and
# invocants to appear in a different position to normal:
# arguments to the left of the subroutine/method name, and
# invocants to the right of the method's argument list.
#
# So, for subroutine arguments, these are exactly equivalent:
#
# ($arg2, $arg3, $arg4) ~ subname $arg1;
# subname ($arg1, $arg2, $arg3, $arg4);
So
@a ~ grep { ... } ~ @b
Is the same as
@b = grep { ... } @a
?
# Notice that, in addition to pipelines, these proposed
# operators give us MTOWTDI with respect to ordering of the
# components of a sub or method call. That is, Perl 6
# subroutines may have prefix and/or postfix argument lists,
# and Perl 6 methods may have invocants that are any(prefix,
# infix, postfix).
...
# Yes. And the inference that most people seem to have drawn
# is that this implies that Perl 6 would still have
# stand-alone Cmap and Cgrep functions.
#
# However, I suspect the correct inference is that Perl 6 will
# have Cmap and Cgrep *multimethods*.
As in...
class Array {
...
method grep (Array $ary: Code $code) returns Array {
...
}
method grep (Code $code: Array $ary) returns Array {
...
}
}
? And this would automagically get mapped into Array::grep? (Reminds
me of C++ operator overloading for e.g. operator +(int,
MyStringType)...)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: L2R/R2L syntax [x-adr][x-bayes]
We should bear in mind that Larry has had some health issues. And that he's currently unemployed with four children to support. Other matters are taking precedence at the moment. Hmm... If the Larry and the Perl Foundation would be agreeable. I'd just as soon see a grant set up for Larry again this year. And if so, I'd like to see the Perl Foundation grant(s) publicized before tax-deductable donations to non-profit organizations can no longer be applied to 2002. It's my understanding that TPF is not intending to offer Larry (or Dan) another grant for 2003. They feel that too many people have come to see TPF's role and contribution to have been limited to Perl 6 (though funding Dan was in fact supporting the much broader benefits of Parrot development and funding me probably benefitted Perl 5 even more than Perl 6). However, I am sure they would welcome feedback on what the community would actually like to donate towards: http://www.perlfoundation.org/index.cgi?page=contacts If so, I'm pretty sure I'll be able to match last years' contribution. [People may not realize what a very generous offer that is. Garrett has been a *major* contributer in the past. And, unless he's living in a parallel economic dimension, funds must be tighter this year.] Damian
Re: L2R/R2L syntax
Brent Dax asked:
So
@a ~ grep { ... } ~ @b
Is the same as
@b = grep { ... } @a
Yes.
As in...
class Array {
...
method grep (Array $ary: Code $code) returns Array {
...
}
method grep (Code $code: Array $ary) returns Array {
...
}
}
No. As in:
sub grep (Code|Hash $selector, *@candidates) is multi {...}
class Array {
...
method grep(Array $self: *@candidates) {...}
}
Multimethods don't belong to classes; they mediate interactions *between* classes.
? And this would automagically get mapped into Array::grep?
No. Both would be explicitly and separately defined.
(Reminds me of C++ operator overloading for e.g. operator +(int,
MyStringType)...)
Which is *exactly* why we're doing it slightly differently. ;-)
Damian
Civility, please. (was Re: L2R/R2L syntax)
On Friday, January 17, 2003, at 02:17 PM, Joseph F. Ryan wrote: Mark J. Reed wrote: On 2003-01-17 at 19:00:04, Simon Cozens wrote: This is plainly untrue. See the perlsub documentation, which talks about creating your own syntax with the prototype. You can do all this in Perl 5, and it saddens me that some of the people redesigning Perl don't know what Perl can do. Well, if even some of the people redesigning the language are ignorant of some of its capabilities, that is an argument for making those capabilities easier to discover, and maybe even more intuitive to use, in the new design. I see it more as the people who are ignorant of the features of Perl5 should go RTFM (Research The Features that they are Making?) 'kay, let it be noted that I had let that first little zing slide, but I do think we need to be more careful here. I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, unless 'ignorant' is a new synonym for 'disagree with'. Argument by emotion has drawbacks. I could, for example, point out that everyone bitches about how the language needs to be more regular, until you point out an irregularity that they like. Or that people want the language to be cleanly object oriented, unless it means making things act more like objects. And Lord help us if we get into an argument about whether or not putting code on CPAN makes you more of an 'expert' programmer than someone who writes proprietary code for money. Or what 'expert' means, when it comes to Perl, and whether or not such technical prowess is solely proportional to your visibility at Perl-related conferences. Or if Perl5 syntax is truly the pinnacle of language design against no other ideas can hold a candle. So. If people wanted to point out the merits of the old Cmap syntax, _aside_ from the fact that Perl5-did-it-that-way, that would be wonderful. But name-calling needs to go. Let's not light that fuse, OK? :-| MikeL
Re: L2R/R2L syntax [x-adr][x-bayes]
On Fri, Jan 17, 2003 at 03:10:48PM -0800, Damian Conway wrote: It's my understanding that TPF is not intending to offer Larry (or Dan) another grant for 2003. They feel that too many people have come to see TPF's role and contribution to have been limited to Perl 6 (though funding Dan was in fact supporting the much broader benefits of Parrot development and funding me probably benefitted Perl 5 even more than Perl 6). Well, I'll be pretty interested to discover what cause is deemed more deserving than Larry, Perl 6 or Parrot. The P still stands for Perl, right? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: L2R/R2L syntax [x-adr][x-bayes]
Paul Johnson wrote: Well, I'll be pretty interested to discover what cause is deemed more deserving than Larry, Perl 6 or Parrot. The P still stands for Perl, right? True. But I suspect that TPF's position is that, to many people, Perl 6 is far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, or Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or any of a hundred other projects on which their job depends on a daily basis. Supporting those efforts is important too, and TPF has only limited resources. Of course, it's my belief that supporting Larry (and Dan) to create Perl 6 is the single most important thing that TPF could do. Because, ultimately, it will benefit all those other projects enormously too. But I'm clearly biased. :-) Damian
Re: L2R/R2L syntax [x-adr][x-bayes]
On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote: True. But I suspect that TPF's position is that, to many people, Perl 6 is far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, or Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or any of a hundred other projects on which their job depends on a daily basis. That may well be true, but it seems to me that if people's jobs depend on those projects then there is (or could be or should be) a source of funding available, should such be required, namely the companies who are (hopefully) making a profit on the backs of those projects. Yes, I know it's not that easy. No one's job depends on Perl 6 or Parrot (yet). Well, hardly anyone's :) Still, I suppose I am preaching to the choir in the wrong chapel. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: L2R/R2L syntax
[EMAIL PROTECTED] (Michael Lazzaro) writes: No. I said it was _special_, not _impossible_. You said in Perl 5 it was X instead of Y. But it turned out to be Y after all. -- He was a modest, good-humored boy. It was Oxford that made him insufferable.
Re: Civility, please. (was Re: L2R/R2L syntax)
[EMAIL PROTECTED] (Michael Lazzaro) writes: I don't think any aspect of this discussion is hinged on people being 'ignorant' of perl5 behaviors, Oh, I do, and you've dismissed that argument out of hand. This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. The Lord knows that languages designed by committees of professional standards-writers are pretty bad, and we're still a long way from that. -- A Law of Computer Programming: Make it possible for programmers to write in English and you will find that programmers cannot write in English.
Re: L2R/R2L syntax [x-adr][x-bayes]
[EMAIL PROTECTED] (Damian Conway) writes: True. But I suspect that TPF's position is that, to many people, Perl 6 is far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, or Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or any of a hundred other projects on which their job depends on a daily basis. Amen to that. -- DISCLAIMER: Use of this advanced computing technology does not imply an endorsement of Western industrial civilization.
Re: L2R/R2L syntax [x-adr][x-bayes]
[EMAIL PROTECTED] (Paul Johnson) writes: That may well be true, but it seems to me that if people's jobs depend on those projects then there is (or could be or should be) a source of funding available, should such be required, namely the companies who are (hopefully) making a profit on the backs of those projects. And to what organisation do you suggest such companies make a donation in order to make best use of that funding? -- Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. -- Howard Aiken
Re: Civility, please. (was Re: L2R/R2L syntax)
Simon Cozens wrote: This isn't name-calling; this is a plea for Perl 6 not to become a language designed by a committee of ignorant amateurs. Fortunately there is absolutely no chance of that. Perl 6 is a language being designed by exactly one person. And he's neither ignorant, nor an amateur. The rest of us are merely offering suggestions, feedback, and advice. It's important to remember that Larry loves Perl more than any of us, and that he's not about to be seduced into butchering it by the wild suggestions of so-called ignorant amateurs. Though, of course, he would never *dream* of using that term himself (except perhaps as a profound compliment). On the other hand, I know that Larry cherishes all the ignorant amateur suggestions he receives. Because they help him explore the design space. Because they spark counter-ideas. And because they so often encode -- albeit sometimes very cyptically -- truly guileless expressions of real problems that real Perl users experience. Larry is well-known for extracting the nutritional value from these encodings (i.e. the underlying needs and desires they highlight) without swallowing the unpalatable packaging they sometimes come in. It's instructive to review the PSA ratings of the RFCs covered by the first six Apocalypses and consider the fact that Larry almost always rates the problem space addressed by an individual RFC much higher than the solution it proposes. And *then* typically goes on to describe an alternate approach that solves the problem better and far more generally. Personally, I think we're in safe hands. Damian
Re: L2R/R2L syntax [x-adr][x-bayes]
On Sat, Jan 18, 2003 at 02:11:37AM +, Simon Cozens wrote: [EMAIL PROTECTED] (Paul Johnson) writes: That may well be true, but it seems to me that if people's jobs depend on those projects then there is (or could be or should be) a source of funding available, should such be required, namely the companies who are (hopefully) making a profit on the backs of those projects. Hey! You carefully elided my disclaimer. And to what organisation do you suggest such companies make a donation in order to make best use of that funding? It seems to me that TPC would be the perfect vehicle for any company wishing to fund a specific Perl project. Previous disclaimer still applies. But now we are off topic. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: L2R/R2L syntax
If the usual syntax for a 2-arg subroutine call is:
foo A, B; # (1)
and the preferred perl5 Cmap syntax is:
map {...} @a; # (2)
Then (2) is not grammatically following the same rule as (1). It works
because there is a rule that says the {...} doesn't need the comma to
separate it from the next arg.
If the rule was, you can leave the comma out after any argument, no
matter what type, it would be more consistent. (But a nightmare.)
If the rule was, you can never leave the comma out, it would be more
consistent. (But cost one more character.)
I'm not saying it's awful, and I'm not saying it's impossible. I'm
*just* saying that p6 does not have that syntax, _UNLESS_ it is given a
similar comma-sucking rule. So, should there be such a rule?
I am contesting the net benefit of the rule for p6. My objections:
1) It's a special case, which is by definition something to be generally avoided.
2) The commaless syntax looks enough like indirect object syntax to
confuse many people. Indirect object syntax (the colon form) is already
creating a lot of confusion, and I'm worried this rule would make
matters worse.
3) Curly brackets already will have other p6 magic. I'd rather not add
more if there is any possible way around it.
4) We have several ways around it: direct object syntax, indirect object
syntax, and pipelike syntax.
This is the sum total of my argument against the perl5 map syntax. May
Larry have mercy on my soul.
:-/
MikeL
Parrot compilers
Hey folks - In my wanders through the parrot/languages subdirectories, it appears that most example languages implement a complete compiler (ie lexxer - parser - optimizer - code emitter), which seems to be somewhat of a duplication of labour. Has or is anyone worked on a framework a la gcc which would only require that new languages have a lexxer/parser written that coerced data into a standardized AST which could be passed off to other compilation stages? (Similarly, other end targets (such as Java bytecode or native code would only require the implementation of a new code emission module.) -c
Re: L2R/R2L syntax
Michael Lazzaro wrote:
If the usual syntax for a 2-arg subroutine call is:
foo A, B; # (1)
and the preferred perl5 Cmap syntax is:
map {...} @a; # (2)
Then (2) is not grammatically following the same rule as (1). It works
because there is a rule that says the {...} doesn't need the comma to
separate it from the next arg.
If the rule was, you can leave the comma out after any argument, no
matter what type, it would be more consistent. (But a nightmare.)
If the rule was, you can never leave the comma out, it would be more
consistent. (But cost one more character.)
If the rule was, you can leave a comma out either side of a block/closure,
no matter where it appears in the argument list, it would also be more
consistent.
And that's what's being contemplated. Because otherwise, you also have
to have:
for @list, {...}
if $condition, {...}
given $value, {...}
:-(
3) Curly brackets already will have other p6 magic. I'd rather not add
more if there is any possible way around it.
Without comma-optionality, their other p6 magic will be much less wonderous.
Damian
Re: Array Questions
Michael Lazzaro wrote: Great -- then I have only one more question, I think. In the words of a certain cartoon character, what's *this* button do? my $b is $a; Syntax error, I'd expect. Though the desired effect could probably be achieved with the Cprop meta-property: my $b is prop($a); Damian
Re: Array Questions
Jonathan Scott Duff wrote: will this: my $a $b; be illegal? I certainly hope so! Damian
Re: Array Questions
Piers Cawley observed: BTW, Cmy Foo $a is Foo is just sick! (i.e. I'll *definitely* be using it ;-) Surely anyone who does C my Array @foo , or C my Scalar $foo will be using it, albeit indirectly. Of course, but without the brain-twisting effect of the repeated classname. ;-) Damian
Re: Parrot compilers
Yes, languages should now use IMCC as their target. Basically, they generate IMCC instructions without regards for optimization and such so that only a lexer/parser is needed. Take a look at the bf and ook languages for an example. I think perl6 is also heading there. Tanton - Original Message - From: Cory Spencer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 17, 2003 9:10 PM Subject: Parrot compilers Hey folks - In my wanders through the parrot/languages subdirectories, it appears that most example languages implement a complete compiler (ie lexxer - parser - optimizer - code emitter), which seems to be somewhat of a duplication of labour. Has or is anyone worked on a framework a la gcc which would only require that new languages have a lexxer/parser written that coerced data into a standardized AST which could be passed off to other compilation stages? (Similarly, other end targets (such as Java bytecode or native code would only require the implementation of a new code emission module.) -c
