Fw: An import statement for Web IDL

[Forwarded with permission.]

----- Forwarded message from Dimitry Golubovsky <golubovsky@gmail.com> -----

From: Dimitry Golubovsky <golubovsky@gmail.com>
Date: Mon, 29 Jun 2009 07:27:28 -0400
To: Cameron McCormack <cam@mcc.id.au>
Subject: An import statement for Web IDL

Cameron,

On Mon, Jun 29, 2009 at 1:16 AM, Cameron McCormack<cam@mcc.id.au> wrote:
> Dimitry Golubovsky:
>> Is the compiler supposed to read the contents of dom.idl while
>> compiling svg.idl (which would happen automatically if #include's are
>> used)? Or are you tagreting separate compilation, delegating remaining
>> resolution to the native compiler/linker?
>
> Hmm, I suppose if you want to be able to copmile an individual IDL file
> then it’s not going to work without a #include of some sort.  Maybe it
> should allow an import statement (one that doesn’t rely on ensuring you
> fence the #include with #ifndef/#endif)?
>
> I might discuss this on public-webapps, see what other people think.

I just think that this is a problem separate (although related) from
the forward declarations that we started with, so let's discuss
#include's as well.

In fact, (maybe I didn't make myself clear) I am for keeping
#include's and therefore having all dependent idl files in a single
stream that compiler consumes just by using a standard preprocessor. I
was annoyed at #include's too at the very first sight (I worked on an
IDL to Haskell compiler back in 2007 and used it in my Haskell to
Javascript compilation project to produce proper type signatures for
DOM methods), but later I realized that they bring more benefits than
inconveniences. IDL files are basically alternative/abstracted syntax
of .h files, and the same principles (#include's and #if/#endif
guards) of handling them IMHO apply.

For the "import" statement proposed: how is it better than #include*?
Besides, one either has to hardcode paths to imported files**, and/or
to implement the same functionality that CPP already has (-I option
for path to include files). Plus, probably every IDL file existing
will have to be rewritten/patched.

So, to my belief, advantages of using #include's are (sorry if this is
too well known):

* File dependency tree is created automagically. gcc -M will create a
Makefile if needed
* Design of a compiler is simplified because it can just read
everything from stdin: CPP would take care of integration of the
dependent IDL files in a single stream.
* Existing files rely upon using #include's, and also do not have
strict rules of sectioning (one file per module, or one per interface,
many modules in a single file are possible).
* All other advantages CPP gives (that is, macros/conditional compilation)

May I ask you what are the advantages of not using #include's?

You wrote on the list:

-------------------------------------------------------------------------------------------------
I don’t think it would be good to require a C preprocessor to get the
same kind of inclusion behavior for Web IDL.  But I do think we need to
make sure that names resolve, so we need some kind of mechanism.
-------------------------------------------------------------------------------------------------

But why not?

----------------------------------
* E. g. a compiler might ignore #ifdef guards and treat #include's as
import statements, that is taking functionality of CPP on itself.
** You have URLs in your example; was this the goal to reference
directly to the W3C-stored files, and so would the compiler fetch them
from the Internet (thus requiring a working connection) every time an
IDL file is compiled?

PS I am not sending this message to the list, as it contains pieces of
our previous off-list conversation, but feel free to forward my
comments to the list.

Thank you.

-- 
Dimitry Golubovsky

Anywhere on the Web


----- End forwarded message -----

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Tuesday, 30 June 2009 00:53:41 UTC