Redesigning "define interface" 
Author Message
 Redesigning "define interface"

Hello!I have some questions about how Melange (CMU's excellent high-level
interface generator) should work in future releases of Gwydion Dylan. Right
now, it runs as a preprocessor:

  Module: some-module

  /* Dylan code... */

  define interface
    #include "ctype.h",
      /* import options */;
    /* clause options */
  end;

Is this conceptually the right approach? Or should it work more like
"define module"?

  Module: dylan-user

  /* Library definition */

  define interface ctype
    #include "ctype.h";
  end;

The first form expands inline, dumping a whole pile of C-FFI definitions
into the local module. The second form would effectively create a new
module containing those definitions. Which of these is more appropriate
behavior for a Dylan extension?

Also, for consistency with the rest of the FFI, "define interface" should
become "define c-interface". Any comments?

Cheers,
Eric



Sat, 14 Jul 2001 03:00:00 GMT  
 Redesigning "define interface"


    Date: Tue, 26 Jan 1999 12:06:26 -0500

    Hello!I have some questions about how Melange (CMU's excellent high-level
    interface generator) should work in future releases of Gwydion Dylan. Right
    now, it runs as a preprocessor:

      Module: some-module

      /* Dylan code... */

      define interface
        #include "ctype.h",
          /* import options */;
        /* clause options */
      end;

    Is this conceptually the right approach? Or should it work more like
    "define module"?

If we're changing 'define interface' incompatibly in any way, can we
also lose the "#" from 'include'?  AFAIK, '#include' is a throwback to
when Apple Dylan's macro system or parser couldn't deal with just plan
'include'.

      Module: dylan-user

      /* Library definition */

      define interface ctype
        #include "ctype.h";
      end;

    The first form expands inline, dumping a whole pile of C-FFI definitions
    into the local module. The second form would effectively create a new
    module containing those definitions. Which of these is more appropriate
    behavior for a Dylan extension?

    Also, for consistency with the rest of the FFI, "define interface" should
    become "define c-interface". Any comments?

I think your second form has the right idea, but doesn't provide quite
enough control:

  define c-interface ctype
    include "ctype.h",
      export: { Foo    => foo-value,         // i.e., rename on export
                SetFoo => foo-value-setter,
                ... };
    export other-stuff...;
  end;

You would be able to use 'export: all' to export the whole pile.



Sat, 14 Jul 2001 03:00:00 GMT  
 Redesigning "define interface"

Quote:
>  Module: some-module

>  /* Dylan code... */

>  define interface
>    #include "ctype.h",
>      /* import options */;
>    /* clause options */
>  end;

>Is this conceptually the right approach? Or should it work more like
>"define module"?

I like this approach, because it makes it easy for user-written manual
import/export methods to live in the same module as the imported interface.
(This doesn't necessarily have anything to do with being a preprocessor;
define c-interface would become a hook into the parser just like define
class is.)

Quote:
>Also, for consistency with the rest of the FFI, "define interface" should
>become "define c-interface". Any comments?

Sounds good.




Sat, 14 Jul 2001 03:00:00 GMT  
 Redesigning "define interface"

Quote:

> If we're changing 'define interface' incompatibly in any way, can we also
> lose the "#" from 'include'?  AFAIK, '#include' is a throwback to when
> Apple Dylan's macro system or parser couldn't deal with just plan
> 'include'.

We need to break compatibility a bit, because "define interface" currently
handles a number of things which your low-level FFI does better. Plus,
there's a whole bunch of "unresolved issues" in the Melange manual which
need to get resolved.

We'll try to do this with minimal disruption to existing users of Melange,
but it's better to break things now and get them right.

Quote:
> I think your second form has the right idea, but doesn't provide quite
> enough control:

[example snipped]

Yes, all the current options for controlling imports will still be
available.

Cheers,
Eric



Sat, 14 Jul 2001 03:00:00 GMT  
 Redesigning "define interface"

Quote:

>Hello!I have some questions about how Melange (CMU's excellent high-level
>interface generator) should work in future releases of Gwydion Dylan.

We have some internal design notes on this question.
I'll see what I can dig out for you.

Dave.



Sun, 15 Jul 2001 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

2. define "variable" word

3. defining "|" as or in Poplog Prolog

4. Lets define "pointer"

5. Lets define "pointer"

6. Naming of "defined?"

7. defining "preferences" in cosmo with code

8. use defined PROTO in "Browser.createVrmlFromString"?

9. +define+unknown="'bx" chokes verilog

10. Defining "public" functions

11. "#define" and C2Ada

12. best way of defining a "timer"

 

 
Powered by phpBB® Forum Software