Re: top 5 list needed
Uri, Well, aside from what is actually *in* Perl 6 currently, there are a number of interesting side projects, which may or may not get included in the final language design. Such as: On Oct 18, 2005, at 3:40 AM, Uri Guttman wrote: the new OO design (stole the best from the rest and perlized it) The current object model prototype (not yet totally approved) is a self-bootstrapping meta-circular object model which is heavily influenced by the CLOS Meta Object Protocol and Smalltalk. It includes several features which are not found in any of your traditional OO languages, such as Roles (which are a descendent of Traits, I could site some papers here is this would help). You might also want to include Luke Palmer's current work on Attribute Grammars and the Theory model. Both of these are very Haskell-ish. I will let Luke speak about those. Yuval Kogman's recent Exceptuation proposal (the marriage of exceptions and continuations, this exceptions you can *actuallY* recover from) is very similar to the condition system of Common LISP. There has also been much work on a type inferencing system for Perl 6 (type *checking* if just old-skool, all the cool kids infer). The fact Pugs is written in Haskell (a language only a professor could love) might be a help. There is also the new Perl 6 packaging system. It will be far more complex than the Perl 5 one, since it will not only include the 3 part name (Foo-0.0.1-cpan:JRANDOM), but it will probably need to support seperate compilation units as well. This is borrowed from everywhere, but specifically we have looked at Fortress (the new scientific progamming language from Sun) and the new .NET assembly model. Thats about all I can think of now. Stevan
Re: top 5 list needed
Some other features: 1) You can write your program in any combination of programming styles and languages, as you see fit. Thus, you can use your OO library written in Ruby, that really fast C routine, and your Perl code, all in one place. 2) There are a large number of operators that support list manipulation, such as the zipper, the == and == operators, reduce, and others I can't remember in addition to P5's map, grep, and sort. 3) Macros. Nuff said. 4) More declarative syntax. This is more of a handwavy, but the syntax feels (to me) as if it's more declarative than before. For example, for @x - $x { ... } for @x - $x, $y { ... } That reads like a math proof. For all X, do such-and-such. Rob
Re: top 5 list needed
On 10/18/05, Rob Kinyon [EMAIL PROTECTED] wrote: 3) Macros. Nuff said. Not quite. Lispish macros, that is, macros that let you look at what you're expanding. 4) More declarative syntax. This is more of a handwavy, but the syntax feels (to me) as if it's more declarative than before. For example, for @x - $x { ... } for @x - $x, $y { ... } That reads like a math proof. For all X, do such-and-such. Uh huh. Sure it does. (Were you referring to the fact that @x and $x are different things, but really refer to the same thing (a collection and a particular object in the collection)). Luke
Re: top 5 list needed
On 10/18/05, Uri Guttman [EMAIL PROTECTED] wrote: i have an opportunity to get an email sent to the faculty of a top CS dept. my goal is to get internal support for a potential YAPC to be hosted there. so i want to present perl 6 to them in a way which will sell them on its academic and cutting edge aspects. your mission is to write some short (2-3 sentence) bullet items that highlight some major area of interest to ivory tower types. Which one? CS departments vary in what they consider cool. When I talked to the attribute grammar guy here at CU, he snickered when he found out we were writing Perl 6 in Haskell, dismissing Haskell as a mathematical exercise. It would be wise to do some research and figure out what this CS department considers cool before trying to techword them. Luke
Re: top 5 list needed
On Oct 18, 2005, at 1:45 PM, Luke Palmer wrote: On 10/18/05, Rob Kinyon [EMAIL PROTECTED] wrote: 3) Macros. Nuff said. Not quite. Lispish macros, that is, macros that let you look at what you're expanding. To further expand on this, they will be AST-manipulating macros (LISP style) rather than text-replacing macros (C style). Stevan
Re: top 5 list needed
SL == Stevan Little [EMAIL PROTECTED] writes: SL On Oct 18, 2005, at 1:45 PM, Luke Palmer wrote: On 10/18/05, Rob Kinyon [EMAIL PROTECTED] wrote: 3) Macros. Nuff said. Not quite. Lispish macros, that is, macros that let you look at what you're expanding. SL To further expand on this, they will be AST-manipulating macros (LISP SL style) rather than text-replacing macros (C style). my impression is that both styles are supported as you can return either text or an AST (compiled code) from a macro. 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: top 5 list needed
On 10/18/05, Uri Guttman [EMAIL PROTECTED] wrote: SL == Stevan Little [EMAIL PROTECTED] writes: SL On Oct 18, 2005, at 1:45 PM, Luke Palmer wrote: On 10/18/05, Rob Kinyon [EMAIL PROTECTED] wrote: 3) Macros. Nuff said. Not quite. Lispish macros, that is, macros that let you look at what you're expanding. SL To further expand on this, they will be AST-manipulating macros (LISP SL style) rather than text-replacing macros (C style). my impression is that both styles are supported as you can return either text or an AST (compiled code) from a macro. That sounds really ... inefficient. For that to work, you'd have to have seen the macro definition earlier in the parse cycle, then encounter the call to the macro (thus consuming the token), unshift the tokens of the macro into the parse queue (thus necessitating a parse queue), then reparse the whole block because of potential bracing issues. Text-substitution macros would have to be handled in an earlier pass, but the macro might be referencing items from BEGIN blocks already seen ... It's called a preprocessor in C for a reason. Rob