Re: [lambda] Segmentation fault in simple lambda program

[John Freeman <jfreeman08 at gmail dot com>]

On Thu, Aug 6, 2009 at 6:27 AM, Adam Butcher <adam@jessamine.co.uk 
<mailto:adam@jessamine.co.uk>> wrote:

   I take you're point on [finish_struct_1] potentially being overkill
   but at least it means that user programs
   that copy can work.


Right.  I only added that comment so that other developers who come 
along and want to optimize it won't fall into the same trap I did.


   I've attached my two diffs made against the latest lambda head.
    First is explicit polymorphic lambda support via the
   additional template parameter syntax, second is the very hacky
   'for-discovery-purposes-only' prototype for typename
   inference.


I was hesitant to add the first patch alone, but now that you've got the 
second, I'm eager to take another look. 


   Currently for auto typename inference, cv-qualifiers (and other bits
   like attributes) are lost

   One thing I'm worried about is that I'm using make_tree_vec() with a
   length one greater than that of the previous
   vector in order to grow the template parameter list whilst parsing
   function arguments.


I'll be sure to look at these issues.


   There's a number of things I'm not sure about regarding location of
   the implementation (parser.c, semantics.c, decl.c
   etc).


The general guideline I followed was to put as much non-parsing logic 
into semantics.c as possible, and call into it from parser.c when 
needed.  I'm not sure what needs to go into decl.c either.


I will try to take this opportunity of renewed interest in the lambdas 
branch to look at dependent type support and name mangling.  When I say 
dependent type support, I mean using lambdas that capture or declare 
variables of dependent type from a surrounding template context.  Many 
people won't be able to effectively use lambdas until these features are 
added.

- John