Re: top 5 list needed

2005-10-18 Thread Stevan Little

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

2005-10-18 Thread Rob Kinyon
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

2005-10-18 Thread Luke Palmer
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

2005-10-18 Thread Luke Palmer
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

2005-10-18 Thread Stevan Little


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

2005-10-18 Thread Uri Guttman
 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

2005-10-18 Thread Rob Kinyon
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