Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Wed, 9 Feb 2005, Larry Wall wrote: roadblocks thrown in their way. That's true not only for LP, but also for FP, MP, XP, AOP, DBC, and hopefully several other varieties ^^ ^^^ ^^ ^^^ 1. 2. Ehmmm... sorry for the ignorance, but... 1. Functional Programming (right?) 2. Aspect Oriented Programming (right?) What about the others? Well, I know about Google (and I'll try ASAP in any case), but I fear those acronyms could be just a little bit too generic, although probably including also 'programming paradigm' as search keys would help. Michele -- Whoa! That is too weird! I asked around among the math faculty here and it turns out that _every one's_ wife is married to a mathematician! - Dave Rusin in sci.math, Re: Genetics and Math-Ability
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
MD == Michele Dondi [EMAIL PROTECTED] writes: MD On Wed, 9 Feb 2005, Larry Wall wrote: roadblocks thrown in their way. That's true not only for LP, but also for FP, MP, XP, AOP, DBC, and hopefully several other varieties MD ^^ ^^^ MD ^^ ^^^ MD 1. 2. MD Ehmmm... sorry for the ignorance, but... MD 1. Functional Programming (right?) MD 2. Aspect Oriented Programming (right?) i think so but i can't read larry's mind (nor would i want to! :) XP = extreme programming DBC = design by contract (or even designed by conway :) MP = ?? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
John Macdonald wrote: The basic problem is that a junction does not work well with boolean operations, because the answer is usually sometimes yes and sometimes no and until you resolve which of those is the one you want, you have to proceed with both conditions. Well, just patch the boolean operators to return one of (yes, no, sometimes) instead of plain (true, false) :) Anyway, what are the usual semantics with junctions boolean operators in some other languages? (This is so new concept to me, that I don't know of any language to compare against.) -- Markus Laire Jam. 1:5-6
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
Uri Guttman wrote: [...] i think so but i can't read larry's mind (nor would i want to! :) XP = extreme programming DBC = design by contract (or even designed by conway :) MP = ?? Modular Programming David
Re: = vs == [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
Aaron Sherman wrote: So hold on to your socks... what about: @x @y; This reminds me of AWK's string concatenation behaviour: print this $1 that $2 This was nice feature at the time, but caused problems down the track when they wanted to add functions to the language in a subsequent revision. See section 8.1 of The AWK Programming Language for more details. For that reason alone (future-proofing the grammar), I would be leery of going down this route. David
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
[EMAIL PROTECTED] wrote: i think so but i can't read larry's mind (nor would i want to! :) XP = extreme programming DBC = design by contract (or even designed by conway :) MP = ?? Modular Programming David I think it's Metaprogramming. :) Miro
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Thu, 10 Feb 2005, Miroslav Silovic wrote: Modular Programming David I think it's Metaprogramming. :) The only thing that sprung to my mind was MetaPost... Michele -- No one can ever predict all of the possible error conditions, of course; as soon as we write idiot-proof code, along comes a better idiot. But it's still worth making the attempt. - Sherm Pendley in clpmisc (edited)
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Thu, Feb 10, 2005 at 12:32:21PM +0100, Miroslav Silovic wrote: : [EMAIL PROTECTED] wrote: : : i think so but i can't read larry's mind (nor would i want to! :) : : XP = extreme programming : DBC = design by contract (or even designed by conway :) : MP = ?? : : : Modular Programming : : David : : I think it's Metaprogramming. :) You win. Though it did occur to me at the time I wrote it that it could also stand for multiprocessing. Larry
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Tue, 8 Feb 2005, Matt Fowles wrote: pipe dreams Juerd wondered if he could mix = and == in a sane way. The answer appears to be no. Once you bring in == you should stick with it. Huh?!? It doesn't seem to me that the answer is 'no'. In fact C == is supposed to be yet another operator, albeit somewhat a special one. If I got it right the answer is actually 'yes': what Larry suggested is that it would be _stylistically_ better to stick with it once it is used in the first place. Michele -- Ah, but the REAL myster is -- did Pythagoras really discourage eating beans because they resembled human testicles? Or is that another myth? I always thought it was because of their musical qualities. - Robert Israel in sci.math (slightly edited)
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
Michele Dondi wrote: On Tue, 8 Feb 2005, Matt Fowles wrote: pipe dreams Juerd wondered if he could mix = and == in a sane way. The answer appears to be no. Once you bring in == you should stick with it. Huh?!? It doesn't seem to me that the answer is 'no'. In fact C == is supposed to be yet another operator, albeit somewhat a special one. If I got it right the answer is actually 'yes': what Larry suggested is that it would be _stylistically_ better to stick with it once it is used in the first place. It was also a matter of precedence, as = binds more tightly than == so extra brackets would be required, leading to == being neater if you only use it in conjunction with other ==. Which I rather liked.
= vs == [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
On Wed, Feb 09, 2005 at 10:04:48AM +0100, Michele Dondi wrote: : On Tue, 8 Feb 2005, Matt Fowles wrote: : : pipe dreams :Juerd wondered if he could mix = and == in a sane way. The answer :appears to be no. Once you bring in == you should stick with it. : : Huh?!? It doesn't seem to me that the answer is 'no'. In fact C == : is supposed to be yet another operator, albeit somewhat a special one. If : I got it right the answer is actually 'yes': what Larry suggested is that : it would be _stylistically_ better to stick with it once it is used in the : first place. Yes, you can certainly intermix them as long as you keep your precedence straight with parentheses. Though I suppose we could go as far as to say that = is only scalar assignment, and you have to use == or == for list assignment. That would be...interesting...to say the least. For instance, it would eliminate the guessing games about whether the syntactic form of the left side indicates a list. Doubtless there would be some downsides too... Larry
Re: = vs == [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
On Wed, 9 Feb 2005, Larry Wall wrote: Yes, you can certainly intermix them as long as you keep your precedence straight with parentheses. Though I suppose we could go as far as to say that = is only scalar assignment, and you have to use == or == for list assignment. That would be...interesting...to Yes, it would indeed be interesing, but... it would also be really kinda too much! Michele -- I agree with Tore; it's sort of a Zen question. If you have to ask, it means you won't understand the answer. If you know enough to understand the answer, you won't need the question. - Joe Smith in clpmisc, Re: Perl neq Python
Re: = vs == [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
Larry Wall wrote: On Wed, Feb 09, 2005 at 10:04:48AM +0100, Michele Dondi wrote: : On Tue, 8 Feb 2005, Matt Fowles wrote: : : pipe dreams :Juerd wondered if he could mix = and == in a sane way. The answer :appears to be no. Once you bring in == you should stick with it. : : Huh?!? It doesn't seem to me that the answer is 'no'. In fact C == : is supposed to be yet another operator, albeit somewhat a special one. If : I got it right the answer is actually 'yes': what Larry suggested is that : it would be _stylistically_ better to stick with it once it is used in the : first place. Yes, you can certainly intermix them as long as you keep your precedence straight with parentheses. Though I suppose we could go as far as to say that = is only scalar assignment, and you have to use == or == for list assignment. That would be...interesting...to say the least. For instance, it would eliminate the guessing games about whether the syntactic form of the left side indicates a list. Doubtless there would be some downsides too... Larry I have to say that my initial reaction to this was one of disgust, but the more I think about it, the more I am warming to the idea of having a more robust method of declaring list context vs scalar context. Issues that arise (my mind has yet to settle enough to label them downsides): - List assignment is way too common to inflict a three char operator on, especially one that really likes having \S around it. (But don't ask me what else to use, not much is left available.) At least, it's way too common for me. - orthogonality says that we would then need a left scalar assignment operator to mimic ==. Linguistically, this is Calculate all this, then stuff the result into $x. This would be very nifty when building long self-referring assignments, because the assignment appears after the expression which used the previous value, which just flows better. Insert arguments about why conditional predicates are a good idea. - Would C @x = @y; then mean C @x := @y; ? - Somehow, C %x == %y; feels very, very wrong. Pluses: - I've often considered list assignment to be one of the most useful and subtle things that makes Perl Perl, especially when combined with hash/array slices. However, attempting to bring less monkish fellows up to enlightenment often encounters mental blocks. This might help, having a different syntax makes it significantly less 'magical'. (even though Magic is Good, imho) I should probably stop rambling now and get some sleep. -- Rod Adams
Re: = vs == [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
On Wed, 2005-02-09 at 06:04, Rod Adams wrote: Larry Wall wrote: Yes, you can certainly intermix them as long as you keep your precedence straight with parentheses. Though I suppose we could go as far as to say that = is only scalar assignment, and you have to use == or == for list assignment. That would be...interesting...to say the least. For instance, it would eliminate the guessing games about whether the syntactic form of the left side indicates a list. Doubtless there would be some downsides too... Issues that arise (my mind has yet to settle enough to label them downsides): - List assignment is way too common to inflict a three char operator on, especially one that really likes having \S around it. (But don't ask me what else to use, not much is left available.) At least, it's way too common for me. Yeah, well I always thought []= made more sense anyway :) DISCLAIMER: I've been off perl6-* for a bit, and might not have my syntax right here. Sorry. There are a few ways to short-cut that. First off, you could (either in-core, or in a module) set this up: @x.(@y); This is legit syntax today AFAIK, but has no plausible meaning that I can figure out. It's still 3 characters, but eliminates any whitespace ambiguity. Ok, so the next method would be: [EMAIL PROTECTED] = [EMAIL PROTECTED]; What does that do today? Is it legit? Again, 3 chars, but no ambiguity So hold on to your socks... what about: @x @y; Hey, if you're going to Huffman the syntax... But stay with me. This is simply a matter of verbing the @x, which would have the same effect as: @x.(@y); and we discussed what that would mean, above. This has some nice ramifications: my @x 1, 2, 3; # Initialize @x with list of numbers my @x foo(); # enforce scalar context on foo() and store @x @y @z; # Chaining -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
--- Matt Fowles [EMAIL PROTECTED] wrote: Logic Programming in Perl 6 Ovid asked what logic programming in perl 6 would look like. No answer yet, but I suppose I can pick the low hanging fruit: as a limiting case you could always back out the entire perl 6 grammar and insert that of prolog. I dunno about that. The predicate calculus doesn't exactly translate well to the sort of programming that Perl 6 is geared for. I don't think it's a matter of redefining a grammar. Maybe unification can be handled with junctions, but backtracking? I am thinking that some serious work down at the Parrot level would be necessary, but I would be quite happy to be corrected :) Cheers, Ovid = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Wed, Feb 09, 2005 at 11:57:17AM -0800, Ovid wrote: : --- Matt Fowles [EMAIL PROTECTED] wrote: : : Logic Programming in Perl 6 : Ovid asked what logic programming in perl 6 would look like. No : answer : yet, but I suppose I can pick the low hanging fruit: as a : limiting case : you could always back out the entire perl 6 grammar and insert : that of : prolog. : : I dunno about that. The predicate calculus doesn't exactly translate : well to the sort of programming that Perl 6 is geared for. I don't : think it's a matter of redefining a grammar. Maybe unification can be : handled with junctions, but backtracking? I am thinking that some : serious work down at the Parrot level would be necessary, but I would : be quite happy to be corrected :) Depending on what level you write your engine, the backtracking can be handled either with exceptions or, more generally, with continuations. I personally think that unification is the hard part, but then it's possible I'm just not in the right brainstate yet with regard to junctions. I tend to see junctions as sets of scalar values rather than sets of list values, but maybe that's just the Pooh coming out in me. I was, in fact, thinking about Prolog unification just a bit when I cargo-culted in the [$head, [EMAIL PROTECTED] form of parameter parsing, but I don't profess to understand all of the implications. Basically, logic programming is one of those things I'm not trying to solve directly in Perl 6--I'm just trying to get Perl 6 close enough that the real experts can have a go at it without having too many roadblocks thrown in their way. That's true not only for LP, but also for FP, MP, XP, AOP, DBC, and hopefully several other varieties of alphabet soup yet to be invented. Larry
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Wed, Feb 09, 2005 at 11:57:17AM -0800, Ovid wrote: --- Matt Fowles [EMAIL PROTECTED] wrote: Logic Programming in Perl 6 Ovid asked what logic programming in perl 6 would look like. No answer yet, but I suppose I can pick the low hanging fruit: as a limiting case you could always back out the entire perl 6 grammar and insert that of prolog. I dunno about that. The predicate calculus doesn't exactly translate well to the sort of programming that Perl 6 is geared for. I don't think it's a matter of redefining a grammar. Maybe unification can be handled with junctions, but backtracking? I am thinking that some serious work down at the Parrot level would be necessary, but I would be quite happy to be corrected :) Cheers, Ovid This kind of ties in to the 4 $x 2 issue with junctions. As long as junctions retain state to determine such relations correctly, they should be able to be used for logic programming too. I'd kind of like there to be a version of junctions that acted as a Quantum Superposition. So: $x = ( 1|3|5 ); 4 $x 2; would keep track of both the truth values and the the corresponding subsets of the junction. So, as the interpretor evaluated 4 $x it would give a result of (true=(5),false=(1|3)); then the evaluation of $x 2 would modify that to (true=(),false=(1|3|5)). That type of junction would have the same result of false even if the statement was written as: 4 $x and $x 2; That would be a good thing, because I don't think that the chain comparisons are the only place where juctions will give ridiculous answers because multually exclusive subsets of the junction value are found to fulfil different conditions in a sequence of steps. Unfortunately, doing this properly would lead to having the program form into multiple processes and would lead to problems with irreversible actions that occur while the superposition is still multi-determinate. The basic problem is that a junction does not work well with boolean operations, because the answer is usually sometimes yes and sometimes no and until you resolve which of those is the one you want, you have to proceed with both conditions. The all/any/none/one (but we're missing not-all and all-but-one from a full list of operators) give a local scale resolution to this discrepancy, but sometimes you want a larger scale selection. If code is being evaluated tentatively (we don't know whether the current member of the junction will be considered a true element of the result) you really need to limt your actions to side-effect-free operations. I'm afraid that I have too much fluff in my very little brain to have a good solution to this. --
Perl 6 Summary for 2005-01-31 through 2004-02-8
Perl 6 Summary for 2005-01-31 through 2004-02-8 All~ Welcome to yet another summary in which I will undoubtedly confuse to homophones. Probably more than a few this week as I am a little tired. But perhaps the alien on my window or the vampire on my monitor will help straighten it all out. Perl 6 Language autothreading generalization Luke Palmer's thread about auto-threading seems to have wound down without much resolution, or at the very least without a syntax that I like. http://xrl.us/e26z Featherweight Perl6 Autrijus Tang introduced Featherweight Perl6, a side-effect-free subset of Perl6. FP6 is the first step on a journey for Pugs to conquer the world. http://xrl.us/e262 Value Types vs Implementation Types Autrijus Tang in his work on FP6 became confused by types. He asked some questions about Types on perl 6 language and was apparently told to go to perl 6 compilers. From perl 6 compilers, he was told he should really be on perl 6 language. Sorry for the run around, the proper place for questions about language semantics is perl 6 language as he originally posted. Eventually all of that was settled and he even got his question answered. http://xrl.us/e263 -- original post http://xrl.us/e264 -- retry with less compiler speak Logic Programming in Perl 6 Ovid asked what logic programming in perl 6 would look like. No answer yet, but I suppose I can pick the low hanging fruit: as a limiting case you could always back out the entire perl 6 grammar and insert that of prolog. http://xrl.us/e265 the leaning tower of numbers Autrijus Tang asked what sort of number tower Perl6 had. He was planning (and implemented) that of Scheme until he gets an answer. http://xrl.us/e266 some quick questions Autrijus Tang asked a few questions about operators in specific contexts. He got a few answers, although I don't think he got them all. http://xrl.us/e267 getopt::signature Juerd wants to be able to give his script a general signature which magically parses command line arguments. Many people thought it was a cool idea that should be provided as a module rather than in the core. This led to talk about creating a signature object which could be passed to this module so that it doesn't need macros. Sounds good to me. http://xrl.us/e268 S03 inconsistency Juerd found a knit to pick. No comment about whether to pick the first or second option though... http://xrl.us/e269 regex precedence Nicholas Clark wondered about adding a little operator precedence to regexes so that people could avoid a few common problems. Sounds like a good idea to me... http://xrl.us/e27a pipe dreams Juerd wondered if he could mix = and == in a sane way. The answer appears to be no. Once you bring in == you should stick with it. http://xrl.us/e27b 4 $x 2 == true?!? Autrijus Tang wondered how junctions and chained comparators worked. He found that under certain semantics, one can receive very troubling answers. Larry agreed with Autrijus that the unintuitive semantics should be avoided. http://xrl.us/e27c Perl 6 Compilers Pugs 6.0.0 Autrijus Tang released Pugs 6.0.0. It has many cool features and was created in only 6 days. A testament to the power of Haskel or the caffeine intake of Autrijus. (Although to be fair he skipped more version numbers then Java did in its jump to 5.0...) http://xrl.us/e27d -- anouncement http://autrijus.org/pugs/ -- pugs website http://use.perl.org/~autrijus/journal/ -- implementation journal Parrot gdbmhash warning Bernhard Schmalhofer fix a problem where gdbmhash could make configure produce a warning. Leo applied it. http://xrl.us/e27e PyNCI Sam and Leo worked out the correct way to create NCI methods for Python. Leo ended by proposing a table to assist Parrot based on the current language, no answer to that idea... http://xrl.us/e27f makefile cleanup Bernhard Schmalhofer cleaned up some of the makefiles and configure system. Leo applied the patch. http://xrl.us/e27g ParrotIOLayer* const or not François Perrad provided a patch making the ParrotIOLayer* const in the API. Leo applied it, but Melvin warned that while this may be safe now, the API intended to allow mutability. I think for the moment it is still in though... http://xrl.us/e27h Win32 Parrot Ron Blaschke helped Parrot back onto its feet in the windows world. http://xrl.us/e27i http://xrl.us/e27j http://xrl.us/e27k http://xrl.us/e27m http://xrl.us/e27n http://xrl.us/e27o http://xrl.us/e27p -- latest results Parrot_load_bytecode failure? Ian Joyce wondered what would happen if Parrot_load_bytecode failed. The answer
