JavaScript:SpiderMonkey:Parser API - Revision history

Mgaudet1: Update deletion

2021-04-27T21:07:36Z

Update deletion

← Older revision		Revision as of 21:07, 27 April 2021
Line 1:		Line 1:
	{{OutdatedSpiderMonkey}}		{{OutdatedSpiderMonkey}}

	{{delete}}		{{delete\|Totally out of date}}

	== JavaScript API ==		== JavaScript API ==

Mgaudet1: Mark as Outdated

2021-04-27T21:06:34Z

Mark as Outdated

← Older revision		Revision as of 21:06, 27 April 2021
Line 1:		Line 1:
			{{OutdatedSpiderMonkey}}

			{{delete}}

	== JavaScript API ==		== JavaScript API ==

Dherman at 05:52, 27 February 2010

2010-02-27T05:52:48Z

← Older revision		Revision as of 05:52, 27 February 2010
Line 57:		Line 57:
	*[https://bugzilla.mozilla.org/show_bug.cgi?id=548461 Bug 548461] -- refactor JSCompiler to JSSourceCompiler and JSAstCompiler (draft done, patch under review)		*[https://bugzilla.mozilla.org/show_bug.cgi?id=548461 Bug 548461] -- refactor JSCompiler to JSSourceCompiler and JSAstCompiler (draft done, patch under review)
	*[https://bugzilla.mozilla.org/show_bug.cgi?id=533874 Bug 533874] -- implement marshalling to JsonMLAST (draft done, not quite ready for review)		*[https://bugzilla.mozilla.org/show_bug.cgi?id=533874 Bug 533874] -- implement marshalling to JsonMLAST (draft done, not quite ready for review)
			*implement source location information
	*generalize to take visitor (not started)		*generalize to take visitor (not started)
	*refactor to build on top of C++ API? (not started)		*refactor to build on top of C++ API? (not started)

Dherman: more cleanup of JS API

2010-02-27T05:48:03Z

more cleanup of JS API

← Older revision		Revision as of 05:48, 27 February 2010
Line 3:		Line 3:
	=== Design ===		=== Design ===

	A general parsing API could treat the visitor interface from [http://code.google.com/p/es-lab/wiki/JsonMLASTFormat JsonMLAST] as a ~~factory~~ with a parametric type. In Java-like pseudo-types:		A general parsing API could treat the visitor interface from [http://code.google.com/p/es-lab/wiki/JsonMLASTFormat JsonMLAST] as a [http://en.wikipedia.org/wiki/Builder_pattern builder] with a parametric type. In Java-like pseudo-types:

	<pre>		<pre>
Line 18:		Line 18:
	<pre>		<pre>
	class Parser<A> {		class Parser<A> {
	Parser(~~factory~~ : Visitor<A>?);		Parser(builder : Visitor<A>?);

	parse(src : string,		parse(src : string,
Line 30:		Line 30:
	This would allow the <code>parse</code> method to use the visitor as a way of injecting the parsed nodes into whatever type ''A'' the client wants. Making the argument optional makes it easy to default to the JsonMLAST format.		This would allow the <code>parse</code> method to use the visitor as a way of injecting the parsed nodes into whatever type ''A'' the client wants. Making the argument optional makes it easy to default to the JsonMLAST format.

	It's a little messy (wrt types) to reuse the visitor interface for this, since the JsonMLAST visitor expects JsonMLAST values as arguments, whereas this use expects the type ''A'' as arguments. So it's maybe better to have a parallel "~~Factory~~" interface that's the same as the visitor interface but with ~~createXXXX~~ methods instead.		It's a little messy (wrt types) to reuse the visitor interface for this, since the JsonMLAST visitor expects JsonMLAST values as arguments, whereas this use expects the type ''A'' as arguments. So it's maybe better to have a parallel "Builder" interface that's the same as the visitor interface but with buildXXXX methods instead:

			<pre>
			interface Builder<A> {
			buildThisExpr(attr : {}) : A;
			buildReturnStmt(attr : {},
			expr : A) : A;
			/* etc. */
			}
			</pre>


	Should also implement a JsonMLAST processor that takes a visitor:		Should also implement a JsonMLAST processor that takes a visitor:

	<pre>		<pre>
	~~processJsonMLAST~~(ast : JsonMLAST,		processAST(ast : JsonMLAST,
	visitor : Visitor<A>) : A;		visitor : Visitor<A>) : A;
	</pre>		</pre>

	This could be implemented in pure JS, at least initially. (It'll be ugly without pattern matching, though.)		This could be implemented in pure JS, at least initially. (It'll be ugly without pattern matching, though.)

	~~I dislike the verbosity of the JsonMLAST name. Maybe just AST is good enough.~~

	=== Plan ===		=== Plan ===

Dherman: fixed up types a little bit

2010-02-27T05:39:39Z

fixed up types a little bit

← Older revision		Revision as of 05:39, 27 February 2010
Line 8:		Line 8:
	interface Visitor<A> {		interface Visitor<A> {
	visitThisExpr(attr : {}) : A;		visitThisExpr(attr : {}) : A;
			visitReturnStmt(attr : {},
			expr : A) : A;
	/* etc. */		/* etc. */
	}		}
Line 15:		Line 17:

	<pre>		<pre>
	class Parser<A~~, Visitor~~> {		class Parser<A> {
	Parser(factory : Visitor<A>?);		Parser(factory : Visitor<A>?);

	parse(src : string,		parse(src : string,
	[filename : string ~~\| null~~,		[filename : string?,
	startLine : (number >= 1)?,		startLine : (number >= 1)?,
	startColumn : (number >= 0)?])		startColumn : (number >= 0)?])

Dherman: a couple more notes

2010-02-26T21:43:39Z

a couple more notes

← Older revision		Revision as of 21:43, 26 February 2010
Line 16:		Line 16:
	<pre>		<pre>
	class Parser<A, Visitor> {		class Parser<A, Visitor> {
	Parser(Visitor<A>? ~~factory~~);		Parser(factory : Visitor<A>?);

	parse(src : string,		parse(src : string,
	[filename : string \| null,		[filename : string \| null,
	startLine : number >= 1 ~~\| null~~,		startLine : (number >= 1)?,
	startColumn : number >= 0 ~~\| null~~])		startColumn : (number >= 0)?])
	: A;		: A;
	}		}
Line 27:		Line 27:

	This would allow the <code>parse</code> method to use the visitor as a way of injecting the parsed nodes into whatever type ''A'' the client wants. Making the argument optional makes it easy to default to the JsonMLAST format.		This would allow the <code>parse</code> method to use the visitor as a way of injecting the parsed nodes into whatever type ''A'' the client wants. Making the argument optional makes it easy to default to the JsonMLAST format.

			It's a little messy (wrt types) to reuse the visitor interface for this, since the JsonMLAST visitor expects JsonMLAST values as arguments, whereas this use expects the type ''A'' as arguments. So it's maybe better to have a parallel "Factory" interface that's the same as the visitor interface but with createXXXX methods instead.

	Should also implement a JsonMLAST processor that takes a visitor:		Should also implement a JsonMLAST processor that takes a visitor:
Line 36:		Line 38:

	This could be implemented in pure JS, at least initially. (It'll be ugly without pattern matching, though.)		This could be implemented in pure JS, at least initially. (It'll be ugly without pattern matching, though.)

			I dislike the verbosity of the JsonMLAST name. Maybe just AST is good enough.

	=== Plan ===		=== Plan ===

Dherman: JS API design notes

2010-02-26T21:39:27Z

JS API design notes

@@ Line 1: / Line 1: @@
-== Brendan's notes ==
+== JavaScript API ==
 Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.
@@ Line 23: / Line 74: @@
 [mailto:brendan@mozilla.org /be]
-== Kimman's Notes ==
+=== Kimman's Notes ===
 Work on this API originated from an email in the news group post by Jeremy. I volunteered to assist him and since then we have worked together on this. After getting a feel of the task at hand, we started work on a note outlining ideas for this API. Jeremy has been unable to devote time owing to other committments, and so I am posting this even though I have not had his comments on this note.
-=== Work Done So Far ===
+==== Work Done So Far ====
 Based on the hints provided in Brendan's post, the following progress
@@ Line 56: / Line 107: @@
 . Implementation of a non-recursive walker making the same callbacks.
-=== About the ParserAPI ===
+==== About the ParserAPI ====
 Before implementing an API, it is essential to have the end-use in
@@ Line 105: / Line 156: @@
-=== Design Ideas ===
+==== Design Ideas ====
 . A user of the API should be able to control the extent of
@@ Line 145: / Line 196: @@
 . Reviewing the SpiderMonkey code, there are several places where this walker (as a 'js_friend') could be used eg js_FoldConstants, js_EmitTree, CheckSideEffects and some others. These functions currently use recursion and in some cases this recursion appears expensive. I am not sure whether the 'auhtors/maintainers' of these functions would find the code easily maintained if they were to switch to using this API.
-=== Other Issues ===
+==== Other Issues ====
 . The API should provide human readable descriptions for elements

Patrice: /* Brendan's notes */

2007-03-03T13:48:51Z

Brendan's notes

← Older revision		Revision as of 13:48, 3 March 2007
Line 1:		Line 1:
	== ~~street scholoar is a sexist and racist asshole!~~ ==		== Brendan's notes ==

	Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.		Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.

Wikipedia is a misogynyic organization at 02:51, 3 March 2007

2007-03-03T02:51:09Z

← Older revision		Revision as of 02:51, 3 March 2007
Line 1:		Line 1:
	== ~~Brendan's notes~~ ==		== street scholoar is a sexist and racist asshole! ==

	Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.		Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.

Bkimman: /* Design Ideas */

2006-02-03T13:28:34Z

Design Ideas

← Older revision		Revision as of 13:28, 3 February 2006
Line 143:		Line 143:
	on TOK_ types. This would seem to be like introducing a 'guide' interface ie the guide interface prepares the visitable which a vistor can visit.		on TOK_ types. This would seem to be like introducing a 'guide' interface ie the guide interface prepares the visitable which a vistor can visit.

	5. Reviewing the SpiderMonkey code, there are several places where this ~~API~~ could be used eg js_FoldConstants, js_EmitTree, CheckSideEffects and some others. These functions currently use recursion and in some cases this recursion appears expensive. I am not sure whether the 'auhtors/maintainers' of these functions would find the code easily maintained if they were to switch to using this API.		5. Reviewing the SpiderMonkey code, there are several places where this walker (as a 'js_friend') could be used eg js_FoldConstants, js_EmitTree, CheckSideEffects and some others. These functions currently use recursion and in some cases this recursion appears expensive. I am not sure whether the 'auhtors/maintainers' of these functions would find the code easily maintained if they were to switch to using this API.

	=== Other Issues ===		=== Other Issues ===