From: Daniel Nugent <nugend@...>
Date: 2006-02-09T04:11:11+09:00
Subject: Re: Meta-Meta-Programming

My beef with the specific implementation in this thread as it applies
to Design By Contract is that you're issuing these wrapper methods
individually.

A more preferential solution would involve setting up a list of
functions that need a contract applied and then being able to, in one
fell swoop, ensure that they all are bound to the contract at once,
whether that be preconditions, postconditions, or ensurances about the
parameters passed.  Maybe that'll require a couple of method calls,
but you'd still generally be doing it all at once.

I think, for me, the way we're talking about it here quacks too much
like static typing.

On 2/8/06, Mauricio Fernandez <mfp@acm.org> wrote:
> On Thu, Feb 09, 2006 at 01:44:46AM +0900, James Edward Gray II wrote:
> > On Feb 8, 2006, at 7:48 AM, Erik Veenstra wrote:
> >
> > >Did I mention that it is possible to double-wrap a method with
> > >two or more monitor-functions?
> >
> > How is the term "monitor-functions" you have used in this thread
> > different from the standard "higher-order functions," if you don't
> > mind my asking?
> >
> > http://en.wikipedia.org/wiki/Higher-order_functions
>
> Erik's "monitor-functions" would be a subset of (the more general)
> higher-order functions (for a relaxed definition, accounting for the
> fact that neither the input nor the output are actually functions, but
> the symbols given as input map to methods, and the "output" is the
> side-effect of changing a method definition).
>
> The "type-checking monitors" would be noted as
>
>  env(#f=f1)  x  meth-name  x  arg-type-list   ->  env(#f=f2)
>  =========                    =============       =========
> 'world state'                 type-checking info  new environment where
>  where #f is                                      #f checks the args before
>  defined as f1                                    doing f1
>  (f1 would be the AST)
>
> --
> Mauricio Fernandez
>
>


--
-Dan Nugent