define method and module vars... 
Author Message
 define method and module vars...

In the course the discussion of "nested generics" I was going to pose the
following as an example.  I decided to pass the code snippet through a
couple Dylan implementations just to make sure what I wasn't going to say
something incorrect.   I still think the DRM allows this, but most
of the implementations ( Harlequin and d2c ) disallowed the following
with varying degrees of objection.

define generic mumble ( obj1 , obj2 ) => result :: <object>  ;

define constant bumble ::  <generic-function> = mumble ;

define method bumble  ( o1 :: <integer> , o2 :: <integer> )
//define method mumble  ( o1 :: <integer> , o2 :: <integer> )
    => result :: <integer> ;
  o1 + o2 ;
end method;

The DRM says (p. 81):
 "define method" creates a method and adds it to a generic function in a
  module variable.

  [ I'd be happier if that said module constant variable, but that's another
     story. ]

That's the specification.  Now for the implementations.

Harlequin Dylan:

  Complains that "bumble" wasn't defined by a "define generic" statement.
  [ Gee, I really didn't think I needed to. :-) ].   Trying to invoke
  mumble or bumble on two integer causes an error.

D2C:

  No complaints. However, it seemingly silently ignores the method definition.
  Similar error upon invocation.

Mindy:

  It doesn't cmoplain and it does the "right thing".

        mumble ( 2 ,2 ) returns  4
  and   bumble ( 10 , 3) returns 13

The first two implementations actually implement macros so perhaps that has
something to do with it. :-)

It should be the type of object bound to the module variable that causes this
to be accpeted or not.  Not the type of the defining statement that brings
the module variable into existance.   I think latter is a parser
simplification.  [ Parsing Dylan is nontrival so I can sympathize,
but this deviation should be documented. ]

On a related front,  the required keywords for:  

              make (<generic-function>,...)

doesn't include something for restricting the return value(s) type(s).
In Harlequin Dylan's browser, it says that there is a keyword "values:".
However, a few experiments in the Playground only would return a
(#rest <object>) return signature.  Evidently the "define generic" macro
knows how to use make with the correct incantation.  

--

Lyman S. Taylor           "Computers are too reliable to replace

                                Commander Nathan Spring, "Starcops"



Tue, 15 May 2001 03:00:00 GMT  
 define method and module vars...

Quote:

>something incorrect.   I still think the DRM allows this, but most
>of the implementations ( Harlequin and d2c ) disallowed the following
>with varying degrees of objection.

Hm. I filed this as a bug for d2c, I tend to agree with your reading of
the DRM.

Andreas

--
"Java requires the programmer to declare types and exceptions, simply to
make the compiler's job easy.  Which just seems like the wrong approach
to me:  CPU-cycles we have plenty of, good programmer cycles we don't."



Wed, 16 May 2001 03:00:00 GMT  
 define method and module vars...


Quote:

>In the course the discussion of "nested generics" I was going to pose the
>following as an example.  I decided to pass the code snippet through a
>couple Dylan implementations just to make sure what I wasn't going to say
>something incorrect.   I still think the DRM allows this, but most
>of the implementations ( Harlequin and d2c ) disallowed the following
>with varying degrees of objection.

>define generic mumble ( obj1 , obj2 ) => result :: <object>  ;

>define constant bumble ::  <generic-function> = mumble ;

>define method bumble  ( o1 :: <integer> , o2 :: <integer> )
>//define method mumble  ( o1 :: <integer> , o2 :: <integer> )
>    => result :: <integer> ;
>  o1 + o2 ;
>end method;

I agree with Lyman that the current spec allows this.  I'm also not suprised
that various compiled implementations don't support it, given the evolution
of the language towards a much more declarative style.  People working on
compilers focused their energies on supporting that style.

At this point in time, I wouldn't object, actually, to disallowing the
program fragment shown above.  Can anyone think of a justification for
it?



Fri, 18 May 2001 03:00:00 GMT  
 define method and module vars...


Quote:


>I agree with Lyman that the current spec allows this.  I'm also not suprised
...
>At this point in time, I wouldn't object, actually, to disallowing the
>program fragment shown above.  Can anyone think of a justification for
>it?

The only context I can think of is the following (which I've never had to
do )

define  variable  
    some-generic :: <generic-function> = if  ( predicate( global1 ) )
                                              imported-generic1
                                         else
                                              imported-generic2
                                         end if;

.....

define method  some-generic ( ... )

[ In essence, a sort of conditional definitions of methods on
   a generic based upon some global settings. ]

For open generics you can do this by running some sort of initialization
routine that invokes add-method (i.e., defer to runtime).

If the spec moved to disallow it I wouldn't disagree too much.  Having to
deal with that alias would probably give the optimizer digestion problems.

--

Lyman S. Taylor           "Computers are too reliable to replace

                                Commander Nathan Spring, "Starcops"



Fri, 18 May 2001 03:00:00 GMT  
 define method and module vars...


Quote:



>>I agree with Lyman that the current spec allows this.  I'm also not suprised
>...
>>At this point in time, I wouldn't object, actually, to disallowing the
>>program fragment shown above.  Can anyone think of a justification for
>>it?

>The only context I can think of is the following (which I've never had to
>do )

>define  variable  
>    some-generic :: <generic-function> = if  ( predicate( global1 ) )
>                                              imported-generic1
>                                         else
>                                              imported-generic2
>                                         end if;

>.....

>define method  some-generic ( ... )

>[ In essence, a sort of conditional definitions of methods on
>   a generic based upon some global settings. ]

>For open generics you can do this by running some sort of initialization
>routine that invokes add-method (i.e., defer to runtime).

I think we're agreeing that if you want to do something such as what
you've described above, it's better to use add-method than define method.
Yes?


Fri, 18 May 2001 03:00:00 GMT  
 define method and module vars...
In article

Quote:

> At this point in time, I wouldn't object, actually, to disallowing the
> program fragment shown above.  Can anyone think of a justification for
> it?

Allowing it makes for a cleaner standard?

--
Ashley Yakeley, Seattle WA



Fri, 18 May 2001 03:00:00 GMT  
 define method and module vars...


Quote:
>In article


>> At this point in time, I wouldn't object, actually, to disallowing the
>> program fragment shown above.  Can anyone think of a justification for
>> it?

>Allowing it makes for a cleaner standard?

I'm not sure it does.  I think it's reasonable to say that define
method is a declarative construct and should be used in declarative
situations, where the module binding in question is created by a call
to define generic, or imported from another module where that's done.

The current standard allows a mixture of declarative and procudural
programs in a way that (apparently) all three existing compiled
implementations of Dylan had trouble supporting.



Fri, 18 May 2001 03:00:00 GMT  
 define method and module vars...

Quote:

> Actually I think of define method as a macro calling add-method for me.

Right.

Quote:
> Adding a rule forbidding that in the standard would complicate the
> standard to make the compiler implementation easier, which I think is
> against the spirit.

I agree. Think about what 'define generic foo ...' does. What is 'foo'? A
binding. What is it bound to? An instance of <generic-function>. Can that
binding be changed? No. This seems functionally equivalent to a constant
to me.

Quote:
> On the other hand, if all implementations violate
> the standard, it's of little use.

I agree with this too. Ho hum.

--
Ashley Yakeley, Seattle WA



Fri, 18 May 2001 03:00:00 GMT  
 define method and module vars...
In article

Quote:

> An interesting question that may not be answered by the DRM is the effect
> of sealing on non-transparent aliasing *in the same library*.  e.g.,

>     define generic G ...;

>     define constant H = if ... G else ...;

> What's the effect of define method on H and the interactions/restrictions
> on the use of G (which may be sealed or have sealed domains), etc.  Worms
> everywhere...

'Define method' would have to throw errors at run-time, just like add-method.

--
Ashley Yakeley, Seattle WA



Fri, 18 May 2001 03:00:00 GMT  
 define method and module vars...

Quote:

>I think we're agreeing that if you want to do something such as what
>you've described above, it's better to use add-method than define method.
>Yes?

Actually I think of define method as a macro calling add-method for me.
Adding a rule forbidding that in the standard would complicate the
standard to make the compiler implementation easier, which I think is
against the spirit. On the other hand, if all implementations violate
the standard, it's of little use.

What do the Harlequin implementors say? Is there a chance to get that
working?

Andreas

--
"Java requires the programmer to declare types and exceptions, simply to
make the compiler's job easy.  Which just seems like the wrong approach
to me:  CPU-cycles we have plenty of, good programmer cycles we don't."



Sat, 19 May 2001 03:00:00 GMT  
 define method and module vars...


Quote:

>>I think we're agreeing that if you want to do something such as what
>>you've described above, it's better to use add-method than define method.
>>Yes?

>Actually I think of define method as a macro calling add-method for me.
>Adding a rule forbidding that in the standard would complicate the
>standard to make the compiler implementation easier, which I think is
>against the spirit. On the other hand, if all implementations violate
>the standard, it's of little use.
>What do the Harlequin implementors say? Is there a chance to get that
>working?

I believe it would be fairly easy to make the Harlequin implementation
support this, at least as far as runtime/load-time goes.  (Definition
modeling may need more help.)  The gyrations are similar to those that need
to be supported to handle specializers that are computed at load time.  In
this case, it's the generic function that isn't statically known.

An interesting question that may not be answered by the DRM is the effect
of sealing on non-transparent aliasing *in the same library*.  e.g.,

    define generic G ...;

    define constant H = if ... G else ...;

What's the effect of define method on H and the interactions/restrictions
on the use of G (which may be sealed or have sealed domains), etc.  Worms
everywhere...

---------------------------------------------------------------------------



Hunt:  500/346-7860      |



Sat, 19 May 2001 03:00:00 GMT  
 define method and module vars...


Quote:
>An interesting question that may not be answered by the DRM is the effect
>of sealing on non-transparent aliasing *in the same library*.  e.g.,

>    define generic G ...;

>    define constant H = if ... G else ...;

>What's the effect of define method on H and the interactions/restrictions
>on the use of G (which may be sealed or have sealed domains), etc.  Worms
>everywhere...

The definition of "explicitly known" was an attempt to address that.
However, I'm not sure the definition of that term is quite right.  It
might be that it should be talking about bindings rather than objects.
It was the intent that the compiler need not perform a data-flow
optimization pass in order to determine which definitions where assocated
with which.  It might also be that implicitly defined generic functions
needed more careful treatment.


Sat, 19 May 2001 03:00:00 GMT  
 define method and module vars...

Quote:


>>I think we're agreeing that if you want to do something such as what
>>you've described above, it's better to use add-method than define method.
>>Yes?

  I think you loose the abliity to conditionally set the methods of
  a sealed generic.  However, I think flipping between two different
  macro definitions at compile time could probably do the same thing
  (e.g.,  a debug library and a "normal" library. ).

Quote:

>Actually I think of define method as a macro calling add-method for me.

  I think that perhaps "define method" could use something else than
  add-method.

  Let's say that  you have the following code:

  ....
  add-method ( foo  ,  ... method ... )        \\ the result of define method
  end method                                    \\ exapansion.
  ....
  ....
  $some-constant :=  conditionally-init ();    \\  expansion of some constant
  ....                                          \\  declaration.
  ....
  define function conditionally-init ()
      ....
     add-method ( foo , ... method .... );
     ....
  end function ;
  ....
  define function backdoor ()
     ....
     add-method ( foo , ... method ....)
     ....
  end function ;
  .....

  At load time all the top level expression can be evaluated and the names
  initialized.    Can the conditionally-init function make an
  addition to a sealed generic?

  If it can't. What signifies the difference because they take the same
  arguments and run in the same context ( load time).  

  If it can. What keeps someone from invoking add-method
  inside of a sealed library through some sort of "backdoor" function later.
  If the answer is the context is different that seems a little "strange".
  Two functions both calling the same method but get different results.

Quote:
>Adding a rule forbidding that in the standard would complicate the
>standard to make the compiler implementation easier, which I think is
>against the spirit

  I think if you apply the "explicitly known" rule to the name passed
  to define method it wouldn't complicate the standard too much.

       "define method" adds a method to an explicity known generic function.

--

Lyman S. Taylor           "Computers are too reliable to replace

                                Commander Nathan Spring, "Starcops"



Sun, 20 May 2001 03:00:00 GMT  
 define method and module vars...


Quote:



>>>I think we're agreeing that if you want to do something such as what
>>>you've described above, it's better to use add-method than define method.
>>>Yes?

>  I think you loose the abliity to conditionally set the methods of
>  a sealed generic.  

If you're conditionally setting the methods, then the sealing loses
a lot of its value (i.e. for compile-time optimization).

Quote:
>  However, I think flipping between two different
>  macro definitions at compile time could probably do the same thing
>  (e.g.,  a debug library and a "normal" library. ).

>>Actually I think of define method as a macro calling add-method for me.

>  I think that perhaps "define method" could use something else than
>  add-method.

>  Let's say that  you have the following code:

>  ....
>  add-method ( foo  ,  ... method ... )        \\ the result of define method
>  end method                                    \\ exapansion.
>  ....
>  ....
>  $some-constant :=  conditionally-init ();    \\  expansion of some constant
>  ....                                          \\  declaration.
>  ....
>  define function conditionally-init ()
>      ....
>     add-method ( foo , ... method .... );
>     ....
>  end function ;
>  ....
>  define function backdoor ()
>     ....
>     add-method ( foo , ... method ....)
>     ....
>  end function ;
>  .....

>  At load time all the top level expression can be evaluated and the names
>  initialized.    Can the conditionally-init function make an
>  addition to a sealed generic?

No.  Only explicitly known methods can be in sealed generics.

Quote:
>  If it can't. What signifies the difference because they take the same
>  arguments and run in the same context ( load time).  

I didn't follow this.  The difference between what and what?

Quote:
>  If it can. What keeps someone from invoking add-method
>  inside of a sealed library through some sort of "backdoor" function later.
>  If the answer is the context is different that seems a little "strange".
>  Two functions both calling the same method but get different results.

It doesn't matter who calls the function.  In either case, you'd be
attempting to add a method to sealed function, which is an error.

Quote:
>>Adding a rule forbidding that in the standard would complicate the
>>standard to make the compiler implementation easier, which I think is
>>against the spirit

>  I think if you apply the "explicitly known" rule to the name passed
>  to define method it wouldn't complicate the standard too much.

>       "define method" adds a method to an explicity known generic function.

Right.  Then you just have to deal with the point that Kim made: the
definition of 'explicitly known' should refer to bindings rather than
to objects.


Mon, 21 May 2001 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. Defining class methods in a module

2. &whole, defsetf, define-setf-method, define-setf-expansions, &environment and other Lispy Questions

3. defining a method inside of another method

4. Can TPB be defined outside defining modules?

5. defines or C vars visible to python?

6. method vars environment support missing

7. methods, instance vars and what not...

8. Need suggestion: testing for methods & vars (Clipper5)

9. Info about vars, methods, etc.

10. methods and vars in zope objects

11. Module#include and module/class methods

12. accessors for module instance vars

 

 
Powered by phpBB® Forum Software