Re: Haskell and W3C specs

Ian,

On 7/15/09, Ian Hickson <ian@hixie.ch> wrote:

> > There are a number of projects in Haskell targeting Web application
> > development. One piece missing is an IDL conversion tool. I am taking
> > care of this.
>
> Could you explain why an IDL conversion tool is useful here?

It helps generate correct Javascript for the client side. Haskell
program uses a library of templates which are regular functions
expanding to pieces of Javascript, including calls to DOM methods and
getting/setting attributes. These template functions should be given
proper type signatures based on interface name, method return type,
parameters type, etc. This information can be automatically derived
from IDL specifications. In this case the Haskell compiler takes care
of many things like not allowing to create a Javascript code calling
non-existing method for some interface, or setting a read-only
attribute, or to pass an object reference where a number is needed.
So, there is a higher chance to produce correct (per specification)
client-side code.

> > One is missing interfaces for some HTML tags that I have brought up
> > here. Another is inconsistent naming of tags and interfaces, see
> > http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0008.html.
>
> How would this handle arbitrary XML, where every element uses the
> interface "Element"? Why is HTML different?

This depends on how the spec is written. I am pointing at a simple
naming issue in the html2/html5 spec, not wider. To create a tag node
I need to encode "document.createElement(tag)", but with proper type
signature based on the interface name. For the most of the HTML tags
defined in html2/html5, I could strip "HTML" and "Element" from
interface name, and get the tag name. But not for <p>, <img>, <tr>,
<td>, some others where interface name and tag name are not related
such way.

So, basically, to define a template for a tag node creation code I
need two things: tag name and interface name; they are not always
named consistently. Supplementing a simple table, like this one:

http://code.haskell.org/yc2js/idlconv/spec/idltags.txt *

could help as the IDL conversion tool might derive the necessary
information from it.

> > Haskell used to generate client-side Javascript, IDL interface type
> > information matters only at compile time, and mostly disappears at
> > runtime.
>
> Could you elaborate on this? I don't understand what you mean.

Since Javascript code is untyped, the type information that Haskell
compiler used to generate Javascript templates, does not exist at the
runtime. Javascript code will still be "document.createElement(tag)"
for any tag node, but the compiler, using the type information in the
source code, provides that e. g. a node produced with the <img> tag
will not be treated as <td>. This also explains why it is good to have
an interface (even empty) specification for every distinctly tagged
node.

> I don't understand the use case, so I've no idea whether what you're doing
> even makes sense or not, let alone if we should be worrying about it. :-)

The use case is automatic derivation of IDL bindings for any language
where types are meaningful. I found these two issues (missing IDL for
some interfaces, and inconsistent naming of tags and interfaces) while
developing my tool for such derivation, so I am just suggesting to fix
this not by changing the spec, but by providing a supplemental pieces
of information.

It is for this work group to judge upon importance of this.

I am hoping I have expressed my views clearly.

Thank you.

---------------------------------
* produced as suggested in
http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0009.html may
be not 100% accurate, but at least gives something.

-- 
Dimitry Golubovsky

Anywhere on the Web

Received on Thursday, 16 July 2009 13:18:10 UTC