Re: Fw: An import statement for Web IDL

Dimitry Golubovsky:
> 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.

I don’t want to have to require IDL processors to implement a whole C
preprocessor.

> For the "import" statement proposed: how is it better than #include*?

Well, only slightly.  It would allow referencing a URL, to avoid hard
coding relative local filenames.  It would also not need the #ifdef
guards.

> 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.

There are not yet many existing Web IDL files.

> 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

The author of the IDL fragment needs to be careful about including files
correctly at the appropriate place, and preventing files from being
included twice.  That’s a disadvantage to me.  An import statement would
just as easily allow dependency analysis.  (You couldn’t use gcc -M
exactly, though, which I guess is your point.)

> * 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.

I don’t want to rely on the CPP.

> * 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).

Most existing IDL files aren’t Web IDL files, though.  My suggested
import statement wouldn’t have strict rules of sectioning either.

> * All other advantages CPP gives (that is, macros/conditional
> compilation)

To me, this seems like complexity that is out of scope for the IDL
language.  I’d say that you’d be free to use the CPP to process IDL
files before handing them off to the IDL processor if you want, but that
CPP syntax shouldn’t be part of the IDL language itself.

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

* Not having to make spec writers publish IDL fragments with hard coded
  local filenames for dependencies.

* Not having to make spec writers be careful about multiple inclusions
  by using #ifdef guards.

* Not requiring the use of an external program (the CPP), or making IDL
  processor implementors interpret CPP directives.

> 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?

If I am writing an IDL processor it may not be convenient to invoke an
external program to perform the CPP processing.

> ----------------------------------
> * E. g. a compiler might ignore #ifdef guards and treat #include's as
> import statements, that is taking functionality of CPP on itself.

I would find it a bit strange, though, if Web IDL defined syntax that
looked like C preprocessor directives but which are to be handled like
import statements instead.

> ** 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?

I imagined that fetching them would be required only once (or no times
at all, if the IDL processor knew about certain common IDL URLs, and had
a cache of them).


I made a counter-proposal at the end of
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1376.html,
which removes import statements (and #includes) and instead relies on
some specification outside of the IDL fragments themselves to state what
the dependencies are.

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

Received on Tuesday, 30 June 2009 01:24:32 UTC