JavaScript:Narcissus:Types: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 1: Line 1:
== Types in Narcissus ==
== Types in Narcissus ==
= Problem Description =
= Problem Description =
The current implementation of [[JavaScript]] in [[Narcissus]] only takes the ECMAScript v3 "type" system into account. ECMAScript v4 will introduce static type checking and type annotations into the language. In order to prototype new language features fast, we should extend Narcissus to understand the type annotations.
The current implementation of [[JavaScript]] in [[Narcissus]] implements only the ECMAScript v3 type conversion rules, mostly metacircularly (by using the host SpiderMonkey interpreter to do the converting). ECMAScript v4 will introduce type annotations and optional static type checking into the language. In order to prototype new language features fast, we should extend Narcissus to understand Edition 4 type annotations.


= Proposal for Adding Types to Narcissus =
= Proposal for Adding Types to Narcissus =

Revision as of 00:35, 27 April 2006

Types in Narcissus

Problem Description

The current implementation of JavaScript in Narcissus implements only the ECMAScript v3 type conversion rules, mostly metacircularly (by using the host SpiderMonkey interpreter to do the converting). ECMAScript v4 will introduce type annotations and optional static type checking into the language. In order to prototype new language features fast, we should extend Narcissus to understand Edition 4 type annotations.

Proposal for Adding Types to Narcissus

Note: The current proposal for adding types to JavaScript is currently behind a passworded wiki. I'll link to the relevant sections when they become public.

There are a couple of things that need doing:

  • Keeping track of declared types.

This can be done through another array (or map) in the CompilerContext types = []. As a type becomes complete (has no references to incomplete types) it'll be put in the map. Incomplete types will be put on a seperate list, and if we reach the end of a compilation unit with any incomplete types, throw an error. I think that we'll need another structure to keep track of the structure of a type (e.g., for function types, it'll keep track of the parameters and the return values).

  • We need to map variable names and function names to the types given in their annotations.

This should be easily done by adding this information to the funDecls and varDecls arrays (and making those maps between names and types).

Once the parser knows how to pass the types through to the execution context, we can start implementing type checking and some of the other, more interesting proposals.