Piraha Parser Discussion - Revision history

173.253.152.138 at 12:47, 18 March 2013

2013-03-18T12:47:09Z

2013-03-18T12:18:19Z

2013-03-18T12:11:46Z

2013-03-18T12:07:03Z

2013-03-17T16:16:02Z

add comment re column numbers

2013-03-12T11:57:36Z

2013-03-12T11:41:39Z

2013-03-12T11:41:26Z

2013-03-12T11:40:33Z

2013-03-12T09:39:48Z

suggest form for

@@ Line 5: / Line 5: @@
 ** RH: possibly in the form similar to activethorns, ie like a global parameter but that is required to be first in the file
 ** Or could be a structured comment starting with an exclamation mark
 * Require triple quotes for multiline quotes
 * Require quotes for all strings and keywords

@@ Line 16: / Line 16: @@
 * Could have a different format for lists (i.e. ActiveThorns and list of variables that should be output) that doesn't require multi-line strings; this could instead be a list of strings (using e.g. square brackets and commas), which is then converted to a single string after parsing
 ** This would also get rid of comments-in-strings, and possible multi-line comments
 * Could allow "+=" with such lists, so that they don't have to be defined in a single place; this would be useful for I/O variable lists
 * The "=" sign should be mandatory when setting parameters
 * RH: when outputting error messages, include the column number as well as the line number (rather than just the caret indicator) this makes it easier to parse the error in an editor/ide and also in not prone to line breaking/variable character width/mail program indentation issues.
 * ES: Final newline should be required.

@@ Line 13: / Line 13: @@
 * compiled() option to provide compiled-in values for parameters
 ** ES: I prefer the name "fixed" over "compiled", and it doesn't need to look like a function call, it should be more like an attribute of a parameter
 * Could have a different format for lists (i.e. ActiveThorns and list of variables that should be output) that doesn't require multi-line strings; this could instead be a list of strings (using e.g. square brackets and commas), which is then converted to a single string after parsing
 ** This would also get rid of comments-in-strings, and possible multi-line comments

←Older revision		Revision as of 12:07, 18 March 2013
Line 18:		Line 18:
	* The "=" sign should be mandatory when setting parameters		* The "=" sign should be mandatory when setting parameters
	* RH: when outputting error messages, include the column number as well as the line number (rather than just the caret indicator) this makes it easier to parse the error in an editor/ide and also in not prone to line breaking/variable character width/mail program indentation issues.		* RH: when outputting error messages, include the column number as well as the line number (rather than just the caret indicator) this makes it easier to parse the error in an editor/ide and also in not prone to line breaking/variable character width/mail program indentation issues.
		+	* ES: Final newline should be required.

←Older revision		Revision as of 16:16, 17 March 2013
Line 17:		Line 17:
	* Could allow "+=" with such lists, so that they don't have to be defined in a single place; this would be useful for I/O variable lists		* Could allow "+=" with such lists, so that they don't have to be defined in a single place; this would be useful for I/O variable lists
	* The "=" sign should be mandatory when setting parameters		* The "=" sign should be mandatory when setting parameters
		+	* RH: when outputting error messages, include the column number as well as the line number (rather than just the caret indicator) this makes it easier to parse the error in an editor/ide and also in not prone to line breaking/variable character width/mail program indentation issues.

@@ Line 4: / Line 4: @@
 * New format tag at the top to allow backwards compatibility
 ** RH: possibly in the form similar to activethorns, ie like a global parameter but that is required to be first in the file
 * Require triple quotes for multiline quotes
 * Require yes/no for booleans
 ** RH: allowing 1/0 can be useful for parameter file scripts since then the same variable can be used in the scripting languages "if" statement and in the Cactus parameter file (since both "yes" and "no" tend to evaluate as logical true in these languages).
 ** SRB: We could standardize on True/False instead, if we want to be Python-like.
 * compiled() option to provide compiled-in values for parameters