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: 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, 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.
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. --
