Indented multiline literals - Revision history

Kevin Reid: add info on second report

2009-01-16T00:55:10Z

add info on second report

New page

The E parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and [[quasi-literal]]s which is indifferent to the level of indentation in human-written programs.

==Proposals==

Several made in [http://www.eros-os.org/pipermail/e-lang/2009-January/012968.html]. [If opinions are expressed, expand this section to mention them specifically.]

==Discussion==

* [http://www.eros-os.org/pipermail/e-lang/2008-March/012520.html Initial report] by [[User:Kevin Reid]].
* [http://www.eros-os.org/pipermail/e-lang/2009-January/012968.html Second report] by Kevin Reid (who forgot he had written the first)

[[Category:Unresolved design issues]]

Kevin Reid: link to topic page for quasi-literals rather than into the Walnut

2008-03-05T01:45:53Z

link to topic page for quasi-literals rather than into the Walnut

←Older revision		Revision as of 01:45, 5 March 2008
Line 1:		Line 1:
-	The E parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and [[~~Walnut/Ordinary_Programming/Quasi-Literals_and_Quasi-Parsers\|~~quasi-~~literals~~]] which is indifferent to the level of indentation in human-written programs.	+	The E parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and [[quasi-literal]]s which is indifferent to the level of indentation in human-written programs.

	==Proposals==		==Proposals==

Kevin Reid: remove pretentious and distracting highlighting of 'E'

2008-03-05T01:39:25Z

remove pretentious and distracting highlighting of 'E'

←Older revision		Revision as of 01:39, 5 March 2008
Line 1:		Line 1:
-	The ~~'''''~~E~~'''''~~ parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and [[Walnut/Ordinary_Programming/Quasi-Literals_and_Quasi-Parsers\|quasi-literals]] which is indifferent to the level of indentation in human-written programs.	+	The E parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and [[Walnut/Ordinary_Programming/Quasi-Literals_and_Quasi-Parsers\|quasi-literals]] which is indifferent to the level of indentation in human-written programs.

	==Proposals==		==Proposals==

Ansible: link for quasi-literals

2008-03-04T21:01:44Z

link for quasi-literals

←Older revision		Revision as of 21:01, 4 March 2008
Line 1:		Line 1:
-	The '''''E''''' parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and quasi-literals which is indifferent to the level of indentation in human-written programs.	+	The '''''E''''' parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and [[Walnut/Ordinary_Programming/Quasi-Literals_and_Quasi-Parsers\|quasi-literals]] which is indifferent to the level of indentation in human-written programs.

	==Proposals==		==Proposals==

Ansible: Fixing the '''''E'''''.

2008-03-04T21:00:03Z

Fixing the '''''E'''''.

←Older revision		Revision as of 21:00, 4 March 2008
Line 1:		Line 1:
-	The E parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and quasi-literals which is indifferent to the level of indentation in human-written programs.	+	The '''''E''''' parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and quasi-literals which is indifferent to the level of indentation in human-written programs.

	==Proposals==		==Proposals==

Kevin Reid: useful for other than consistency

2008-03-03T14:05:58Z

useful for other than consistency

←Older revision		Revision as of 14:05, 3 March 2008
Line 1:		Line 1:
-	The E parser and printer fail to be consistent when given a string literal containing a line break.	+	The E parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and quasi-literals which is indifferent to the level of indentation in human-written programs.

	==Proposals==		==Proposals==

Kevin Reid at 14:02, 3 March 2008

2008-03-03T14:02:19Z

←Older revision		Revision as of 14:02, 3 March 2008
Line 1:		Line 1:
-	The E parser and printer fail to be consistent when given a string literal containing a line break~~. It would also be useful to have syntax for multi-line string and [[quasi-literal]]s which is indifferent to the level of indentation in human-written programs~~.	+	The E parser and printer fail to be consistent when given a string literal containing a line break.

	==Proposals==		==Proposals==

-	~~Several made in [http://www~~.~~eros-os.org/pipermail/e-lang/2009-January/012968.html]. [If opinions are expressed, expand this section to mention them specifically.]~~	+	None yet.

	==Discussion==		==Discussion==

-	* [http://www.eros-os.org/pipermail/e-lang/2008-March/012520.html Initial report~~] by [[User:Kevin Reid]~~].	+	* [http://www.eros-os.org/pipermail/e-lang/2008-March/012520.html Initial report].
-	* [http://www.eros-os.org/pipermail/e-lang/2009-January/012968.html Second report] by Kevin Reid (who forgot he had written the first)	+

	[[Category:Unresolved design issues]]		[[Category:Unresolved design issues]]