﻿/*
	© 2017 FrankHB.

	This file is part of the YSLib project, and may only be used,
	modified, and distributed under the terms of the YSLib project
	license, LICENSE.TXT.  By continuing to use, modify, or distribute
	this file you indicate that you have read the license and
	understand and accept it fully.
*/

/*!	\file Workflow.Annual2017.txt
\ingroup Documentation
\brief 工作流汇总报告 - 2017 年度。
\version r490
\author FrankHB <frankhb1989@gmail.com>
\since build 763
\par 创建时间:
	2017-01-27 16:01:59 +0800
\par 修改时间:
	2017-08-07 09:52 +0800
\par 文本编码:
	UTF-8
\par 模块名称:
	Documentation::Workflow::Annual2017
*/

// See "Meta.cpp" for meta descriptions.

$import $WORKFLOW;
$LINE-WIDTH-RESTRICT 0;

$WORKFLOW:
// Following lines are only for logging informal project information.
// See Meta.txt for formal project information.
// See ChangeLog.*.txt for accepted contents.

$2017-01:

report.impl:
Call expression of 'invoke' and its derivations like 'ystdex::invoke_nonvoid' is concerned.
	The left operand (pm-expression) of '.*' operator requires lvalue for build-in forms.
		The original form would accept non-lvalue left operand well-formed constructs, being distinct to the built-in operator rule.
	It is now changed to be aligned with built-in rule in 'ystdex::invoke'.
		It may being more friendly to catch bugs of wrong use.
		Now it is also same to the original proposal WG21 N4169 and the working draft WG21 N4606, without additional specification modification.
			Except for addtional of 'reference_wrapper' support is not included now.
				This was in the resolution of LWG 2219.
				See also N4170, though it seemed not to be accepted.
				It is likely to be supported in future in 'ystdex::invoke'.
		Note the original proposal N4169 seemed to miss this point.
			It was fixed in the referential implementation as https://github.com/tomaszkam/proposals/commit/8e9150acd1635f6cd33cb7db3f52e0c217538cd2.

$2017-02:

report.impl:
The 'TokenValue' type was introduced to eliminate non-terminated loop for reduction of delayed terms in 'EvaluateLeafToken' in build 753.
	Since delayed term evaluation would request retrying, it would be trapped in 'EvaluateLeafToken' again and thus it would loop forever if the term being evaluated was not changed.
	It was proved that allowing only 'TokenValue' rather than 'string' to be evaluated as tokens was an effective way for the purpose.
		'TokenValue' was a form of explicit unevaluated operands.
	However, the root cause was lack of proper normalization (i.e. 'Value' cleanup) after a successful reduction.
		This was fixed in build 755.
	The 'TokenValue' is still necessarily for ontology purpose, since token is not a simple lexeme in the design.
		There can be opportunities to insert some more semantic actions in this intermediate layer.
Some points about unevaluated expressions are concerned with the current implementation.
	There are different mechanisms to implement unevaluated expressions.
		As unevaluated expressions, 'DelayedTerm' is for general purposes after lexical analysis.
		'TokenValue' is different.
			It is used in lexical analysis passes.
			It is only for symbols, i.e. tokens to be evaluated, rather than arbitrary expressions.
			It is better on performance since no new terms have to be constructed during the evaluation.
		Transformation like 'TokenizeTerm' would be still preserved within a preprocessing pass in REPL context for saparation of lexical phase from further evaluation.
	Unevaluated expressions can be explicitly evaluated in function 'A1::EvaluateIdentifier' in module 'NPL::NPLA1'.
		Terms of 'TokenValue' and 'DelayedTerm' would be processed differently.
		For 'TokenValue', it is done here directly rather than by wrapping in a new delayed term and than calling 'A1::EvaluateLeafToken' for 2 reasons:
			Const-correctness is needed on parameter with type of reference to 'ContextNode' and in other cases the 'A1::EvaluateIdentifier' function has no need to modify the context node.
			Performance of direct handling is better because wrapping a term in 'DelayedTerm' is more expensive and there is no good reason to do that.
		The evaluation of unevaluated 'TokenValue' does not check the possible infinite loop.
			It is the responsibility of users of the API to configure the evaluation passes properly to provide strong normalization property on name expression evaluation required by the specification of NPLA.

$2017-03:

report.impl:
Style of the Kernel language can be compared with current NPL, esp. NPLA1.
	The current specification is Revised^-1 Report on the Kernel Programming Language, with some rationales in the text.
	There are many similarity on design consideration. Despite developed without reference to Kenerl, many features are occasionally the same.
		The Principle G1 and G5 of Kernel is informally or implicitly implied by NPL design.
		Both can have homoiconic representations and many shared conceptual models of modern Lisp dialects.
		The same key feature is first-class support of modern forms of fexpr with lexical scopes.
		The naming of identifier like '$lambda' are often the same, with slightly differences on meaning.
			The original of '$' in NPLA1 is to express reserved identifier as well as traditional C-like '__'.
			It later changes to be function with unevaluated operands, i.e. fexprs, which is same to Kernel.
	Not all design are same, in the root of the design philosophies.
		Fundamental principles not only for ordinary users but also are significant for users who derive the language in NPL, are lack in Kernel.
			They may have higher priority in general.
			A dedicated example is the zero overhead principle.
				For example, operand tree matching does not requires duplication check, see description below on parameter tree.
		The Principle G2 of Kernel is not used by NPL design, because NPL is not designed to be a direct replacement of a Lisp dialect.
			However, Kernel is largely derived from R5RS Scheme.
			See below for differences about supported features.
		The Principle G3 of Kernel is informally used NPL design, but there can be difference on judgement of exceptional cases.
			That is, what is the precise extension of "dangerous computation behaviors", and what is "by accident".
		The Principle G4 is not used directly since it is better to be specified by derived implementations.
		Since NPL is designed as a family of languages rather than single general-purposed language in the very beginning, it requires no principle of single set of disciplines on interface design.
			Particularily, there is no guarantee on ease of use or avoiding misuses in general, which is inconsist to Kernel.
			Such properties are designed to be specified in derived implementations, which is an issue of QoI (quality of implementation) rather than designing.
		NPL has more focus on composition of abstraction.
			In general, NPL would prefer lower-level implementation-dependent features to abstract.
				This is often to avoid to violate the philosophy of zero overhead principle.
					If such lower-level features are not provided, users may have to fight against low usability with portability of the code. 
				The feasibility to introduce required functionalities should be kept. The usability should not be effected significantly.
			Some notable (global to the language design) examples as listed here.
				NPL prefers 'eqv?' than 'equal?', which is opposite to Kernel.
					The applicative 'equal?' is meant to be composited based on 'eqv?' or other API by design.
					The reason is that the difference of list and non-list terms are intrinsically and generally non-avoidable in the languages.
						To mandate 'equal?' while not 'eqv?' would be the nontrivial case of non-composable interface.
				NPL prefers acyclic representations and data structures by default.
					This choice implies acyclic ownership relationships in design.
						So garbage collection is essentially not needed specifically to break the cycles.
						Note NPLA renders undefined behavior for unexpected cyclic references.
					This choice simplifies overall design and its implementation a lot.
						NPLA does not support circular substructure in syntax.
							This simplifies the syntax. It is now more like reduced S-expression used in SXML, rather than in traditional Scheme dialects and Kernel.
						It eases some specification of acyclic constructs.
							So it is unnecessary to specify acyclic constructs like parameter tree for '$vau' in Kernel.
						It simplifies the implementation of many derived functions which have to guarantee the termination in traditional Scheme dialects even for circular-referenced data structures.
							For example, 'equal?'.
						It merges different representations of the operand.
							So it need no different treatment on operand as 'list' and 'list*' in Kernel.
						It also wipes out the vulnerability in some simple Kernel derivations.
							For example, 'list*' would be definitely terminated since the elements of a list is finite.
					This choice gives users the leeway to determine where to break the cycles and the chance to adjust the trade-offs in higher levels of abstraction.
						It plays better with zero overhead principle.
						If cyclic representations or data structures are necessary, use specific library derivation to solve the specific problems.
						Though facilities to operate on cyclic data structures are not provided directly now, they can be written by users.
							Mostly the base data structure would be a list with custom value type.
							The cost of operating and interacting on different value types depends on users.
					This have impacts on implementation of a few features, notably, first-class recursion by resolving defined names.
						This is different to traditional Scheme dialects and Kernel which hide recursive capability in the primitive "define". Note this may be underspecified in these languages.
							Their specifications do not state the recusion visibility of freshly defined symbol in "define" clause explicitly.
							Alghough it can be partially inferred by requirments on properly tail-recursive calls.
							Nonetheless, the capability for "letrec" family is explicitly specified.
						NPLA does not required it directly. All of the usability of it is up to the operatives for environment mutation being used.
							Since first-class environment is supported, it would be built on environment mutation, at least internally.
							The basic one may not support recusion at all.
							The advanced one can support recursion by nesting one more static environment internally.
							For "letrec" families, it can be composed by basic primitives, similar to Kernel.
						This also has impacts on resouce management in closures, notably, when mutual closures are incurred.
							The lexical mutual references are still allowed.
							However, acyclic ownership relationship are effectively required, otherwise the behavior may be undefined indetermintely.
							To reduce undefined behavior by accident, some mechanism for resource management is needed, optionally.
								For example, garbage collection or region inference.
								Not all of these are good to use.
									See discussion of basic feature adoption below.
								NPL/NPLA/NPLA1 all mandate yet nothing in this area.
	There are many differences on adopted basic features, which has obvious effect on functionality of primitives.
		NPL mandates resource semantics which implies ownership and object models in derived implementations, while Kernel as well as traditional Lisp relies on unlimited extents of objects.
			NPL allows undefined behavior on reference with different object models, while Kernel requires garbage collection.
			For general use on resource management, garbage collection is not acceptable as the center ownership holder.
				It also violates design of first-class object endorsed by Kernel.
		NPL mandates no external representation as traditonal Lisps and Kernel do.
			If necessary, they can be specified by derived implementations.
			If needed, they can be implemented by users.
		Lisp-like pairs (cons pairs) are not used as basic data structure of the internal program representation. So interface for pairs is deliberately omitted. Note pair mutation is also optional in Kernel.
			There is also no null cell of this sense in NPL.
				However, empty lists still exist. They can still be tested by 'null?' predicate.
			Dot notation is not supported in the syntax.
				This simplifies the syntax, having simliar effect as given by avoiding circular substructure.
				Althoug there needs additional treatment to variadic parameters.
			The syntatic element is either a list or an atom (a non-list), though the latter can have a list value.
				Others (non-list linked data structure including cyclic) are considered irregular.
			Combiners do not support irregular data structure. 
			The 'apply' applicative accepts only list as in Lisp, not as it in Kenerl.
				This loses no exresiveness since underlying operative also does not support irregular data structure for simplicity.
		NPL mandates no encapsulation.
			This can be good extension for the language generally in future.
			If needed, they can be specified by derived implementations.
		NPL mandates no partitioning of types.
			First of all, mandatory type system is avoid by design. See discussions below.
				The minimized requirement on typing leads agains to partitioning as a whole base system of typing.
			To allow variaties on interoperability, the type system in NPL is essentially not encapsulated.
				If needed, they can be specified by derived implementations.
					This is at least not the case in NPLA for C++ interoperations.
			This transparency also provides more flexibility to extend the language.
			Type predicates are essentially unspecified to be primitives or not.
				A type predicate only exist when the type exists.
					So no predicate is for a nonexisted type.
					This can occur when a value is only designed to be a unevaluated tag, like '#ignore' in Kernel.
						Since NPL mandates no external representation as traditonal Lisps and Kernel do, the data type is not required in most cases.
						This leads to simpler design in specification both on semantics and API.
				Predicates like 'bool?' would be specified in the type operation library as derived forms.
				Primitive type predicates always take one argument for simplicity.
		NPL deliberately keeps cyclic representation out of the program directly.
			This is opposite to Kernel as well as traditional Lisp.
			It is necessary to avoid bloating the minimal specification of a general language.
				This largely simplified many lengthy implementation of derived forms.
				If needed, features for cyclic data structures can be provided by library.
		Proper tail recursion is not required in NPL as in tradition Scheme dialects and Kernel.
			Most requirements on tail recursion is an issue of QoI rather than design, so it is not mandated.
			Ideally the operation on raw activation record frames should be deterministically handled. This requires the failure of allocation of activation records frame is always predicatable.
				Undefined behavior of recusion call failure in hosted language should be avoided.
					In typical naive native language implementation (e.g. C or C++) without TCO (tail call optimization), call stack overflow are unavoidable and it could be essentially unpredicatable even in aspect of implementation.
					So the implementation of object language should provide some guarantees to avoid such cases.
						Proper tail recursion is one effective way to specify the needed property.
			NPL does not specify the requirement of the general deterministic requirement on activation record frames yet.
				NPLA might require it someday.
				The form about requirments on tail calls would only be applied after there is a foundation of implementable rumtime continuation implementation.
		Kernel provides predicates for some special placeholder values, while NPL is not, for several reasons.
			The placeholder value needs to have a type only when it is evaluated.
		The value '#inert' is not supported in NPL because it is more correct to leave unspecified values as precise as the specification about the language semantics.
			To avoid misuses as additonal features is an issue of QoI but not requirements on language expresiveness.
			Even NPLA1 always uses %ValueToken::Unspecified for the unspecified values in API level, it is not required by the core semantics of the object language.
			This also recovers traditional 3-term form 'if' which is wiped out in Kernel due to inconsistency caused by explicitly overspecified '#inert' requirement on the result.
			There is no type or predicate for '#inter'.
		Formal parameter tree and operand tree of Kernel are not adopted in the same way in NPL, since there is no cons pairs in the internal representation.
			The NPL formal parameter is always a tree of either of a non-list or a list.
			Because there are no cons pairs to splicing the parameter in NPL, other mechanism is used to express variadic elements of parameter.
				The notation '...' is used to capture a list in the end.
					Since it can only occur once, there is no need to name it with specific symbol specified by users.
					For simplicity, named parameter like context parameter in the '$vau' operative is not provided.
			Operand tree matching does not requires duplication check, even it is indeed bad when misused.
				Kernel specifies the check mandated.
					This has trouble since other unique symbols can be rebound, so there must be extra mechanism taking extra resources (i.e. memory) to handle it correctly.
						This is a direct violation of the principle, so it is not adopted in the design.
				If the check is needed, it can be implemented ahead of matching.
		Many of combiners can be derived as Kernel does. However, not all are recommended implementation in NPLA.
			NPLA and NPLA1 may provide builtins as hosted primitive combiners to implement them.
			Derivations in Kernel can be time-ineffieient. Only in extreme conditions that the binary image size is important, the derivation can be used instead of builtins.
			The derivations could also easily have more unnecessary dependencies of implmentation, lead to bad design of dependency constructs and QoI.
				For example, the applicative 'list' as one of the fundamental core features:
					It is derived from '$vau' and '$wrap' in Kernel.
						In NPLA1 it works similarly, with slightly different syntax since '$vau' NPLA1 support multiple expressions at the end.
					In NPL it can be implemented around 'NPL::ReduceToList'.
					Even no extra specific NPLA1 implementation is needed.
						This is different to '$vau' and most other combiners.
						The combiner '$vau' is OK as a primitive for language specification, as some kinds of "inversion of dependency" on interface design.
						But it cannot be primitive enough in most cases based on reduction systems in reality.
							Nevertheless, it is still to be implemented as a builtin.
		Syntax of composite (by juxtaposition) terms is different to traditional Lisp dialects, esp. application for functions when there is no operand.
			Since NPL uses different syntax of parenthese to indicate composite expressions, the parenthese never stand for "application" solely.
				Note '(foo)' would reduced to 'foo' in the main reduction function which used as the default evaluator in NPLA1.
			Evaluation of combined terms are indicated implictly by boundary of expressions.
				This is different with traditional Lisp or Kernel where '(' and ')' are used to indicates application or combining.
				This is mostly to refine the tokens '(' and ')' play uniform roles of the expression boundary.
				It decouples the combining rules with the problem of empty list evaluation.
					Whether empty list evaluation should be well-formed or not has nothing to do with combining.
					It is actually ill-formed in most contexts just because the empty list is not expected to occur.
				It makes expressions easier to type in.
					As an example of motivation, in an REPL or interactive command line shell, there is no need to type in '()' around to evaluate the application.
				Some operatives are designed with this in mind.
					For example, the '$vau' operative supports variadic expression directly.
						There is no derivation of '$vau' like Kernel to support multiple expressions.
						Note the evaulations are not sequenced.
							If needed, '$sequence' should be used explicitly.
			To support evaluation on combined terms without operand, there has to be extra syntax to handle.
				The old hack is to remove '()' when the term has to chilren and '()' is in the 2nd position.
					This works only on applicatives, otherwise '()' which cannot handled by the default evaluator would be wrongly removed if the term has 2 children occasionally.
					Even on applicatives it does not work reliably.
						The handler has to implement special case (of no argument) if empty list is needed to be recognized as an argument, e.g. in 'list?'.
							This makes the implementation complicated a lot.
							It is also wrong in the exception message when the arity is mismatched.
				The new syntax contains support of prefix '()' mark to indicate the application.
					Now '() foo' (with explicit enclosing '()' or implicit boundary) is same to '(foo)' in Lisp-style syntax when 'foo' is the name of the function.
					This is a breaking change.
					Now empty list only can be part of the operand.
Mandatory type system is avoid by design of NPL, for both philosiphical and engineering reasons.
	Typing is not the silver bullet.
		There are multiple different uses that are not equally intuitively recoginzed by users, which causes confusion.
			Typing is first invented to rescue the mathematics foundation from Russell's paradox.
			Type system to be modeling (like in traditional OOAD and OOP approach) tools are plausible, but not strictly required in general.
		Naive design easily cause problems in design and applications.
	Mandatory type system is simply out of scope of the design of an expressive language aiming to be general-purposed, since there is no one-size-fit-all option in type system design.
		To be most general-purposed, the disciplines of typing have to be weaken engough.
			The main reason is to avoid insonsistency and to keep feasibility serving as many as domains.
			It utterly leads to no typing at all, except those necessitied for composing other non-typing first-class features.
			For example, to describe some domains of required values, normatively discrete types are required.
				One motivating concrete instance of this example is boolean value used if first-class conditional controlling constructs.
					It requires the dinstinction of 'bool' vs. others.
				This still minimizes the requirement on typing.
			The weaken disciplines effectively reject static typing as a mandated builtin feature of the language.
				Static typing is essentially built through refinements by phases (discrete "static" and "dynamic" phases like "compile-time" vs. "runtime") of underlying reduction disciplines.
					These underlying disciplines are expressed in either formal languages (metalanguages) or natural languages directly in the specification of the language.
					When mandated, it indicates there are some domain-specific rules are encoded in the specification of the language.
						Since it is mandated, conforming implementations cannot skip them, which may easily harm generality if the domain requirements are not suited to the typing.
				So the engineering weakness of high cost of wrong choice on typing can be (hopefully) minimalized.
	Mandatory of type systems requires a lot of unavoiadable work in specification even it is known not fit for several domains, which is agianst to simplicity of design.
	Similarly, it requires a lot of work on conformance in implementations.
	Type systems, if any, should be pluggable.
		The idea and similar consideration are available at http://www.bracha.org/pluggable-types.pdf.
	A related notion with similar side effects is nominal typing, which is used by contempory languages widely.
		It can be useful, but wrong design with static typing can have more power to make things in a mess, and little effort can be done to recover the errors.
			For instance, see http://stackoverflow.com/questions/4488727/what-is-the-point-of-dbnull.
		The necessity of mandatory on nominal typing is particalarly a widely adopted misconception.
			It makes users being confused of the purpose of typing (logical limitation vs. modeling, see above).
			It makes users being ignorant to other typing schemes.

dep.merge:
libfat 1.1.0: reviewed, partially merged, partially shelved.
	Changes in libfat 1.1.0 (distributed by devkitPro r46) are reviewed.
		In summary, no changes except one minor are to be ported, and there is one extra change to be evaluated.
		All changes are not ported now.
	Change https://github.com/devkitPro/libfat/commit/abde1cb73b585ac5fc76b8d4d5d598ad6841597d is not applicable.
		There is no separated install script.
	Change https://github.com/devkitPro/libfat/commit/73ccaec8154e2a12fd8995514e10 is not applicable.
		Since 'NAME_MAX' was used instead of 'MAX_FILENAME_LENGTH' at beginning in the module YCLib::DSIO.
	No changes in https://github.com/devkitPro/libfat/pull/9 has to be ported.
		These changes were merged in https://github.com/devkitPro/libfat/commit/d4926573ac184656146f39749192372b3b7388b0.
		No change has to be ported as https://github.com/devkitPro/libfat/commit/d59c7c8b35fedc2b247afee56d91c2a44101253d.
			Since 'platform::LFN::ValidateName' had done it right since build 657, originated from 'DEntry::AddTo' since build 611.
		No change has to be ported as https://github.com/devkitPro/libfat/commit/3fde6ce161db5293a302ef5b839483065526c3b5.
			The change is questionable on POSIX conformance.
				See https://github.com/devkitPro/libfat/issues/10.
				The original is conforming.
			Member function 'platform_ex::FAT::Partition::Unlink' followed the original implementation.
		No change has to be ported as https://github.com/devkitPro/libfat/commit/b7c4d38b320b8da0c9e318dbbdc2cc0ad966a93b.
			The change is still conforming to POSIX, but unnecessary for conformance.
			The change reduced QoI since it made client code less probable to detect the error.
	Change https://github.com/devkitPro/libfat/commit/9e2f91dee6c27e797bb510320bb359cce11c1015 is deferred to be evaluated.
		The change on type of internal file descriptor may be required by new toolchain in devkitPro r46.
			However, it is not planned to be updated immediately.
	Change https://github.com/devkitPro/libfat/commit/78ca2bd297f59b617fb1d0241e9f32393aa9f1ca is not applicable.
		The '-ffunction-sections -fdata-sections' has been used on whole YFramework compliation for years.
	Change https://github.com/devkitPro/libfat/commit/b7450524b18118df693870f64242cabf5d62234b is to be ported.
		It may be better delayed, waiting for '::isDSiMode' brought by libnds 1.6.2.
		However, it is trivial, so the port is done directly using internal '::__dsimode' currently.

$2017-04:

report.impl:
Recursive captured vau abstraction names in variable binding constructs (e.g. definitios) in general need some special treatment including shared ownership.
	The evaluation order of vau abstraction expression implies the side effect of binding sequenced after the evaluation of the binding target.
		So without additional mechanism, resolution for recursive name used as definiends cannot be implemented in evaluation of binding target.
	For binding constructs like '$define!' in Kernel, multiple symbols can be bound at same time.
		The recursive binding constructs need to store data structure holding the mapping from bound symbol to reference during evaluation of the binding construct.
	For encapsulation reason, the vau handlers need to store captured symbols in its static environment.
		So they cannot be modified after the binding expression is evaluated.
			Thus shared values are mandated to modify them after the side effect of binding.
			This cannot be implemented using determinstic initialization only once.
			This can be implemented in a 2-phase manner for simplicitly.
				First, for each symbols to be bound, it need a thunk to hold the state (value of functions) temporarily, which is never intended to be called.
				Second, after evauation of binding constructs, the bound references are ready to be referenced.
					Thunks are assigned to the real bindings.
					There may be some housekeeping on the names being bound for ownership reason (see below).
	The lifetime of owning references should be longer than any external non-owning reference, otherwise it would not be first class or there would be traditional funarg problems.
	It is obvious that if none of the references to created functions are owning, resource introduced by bindings will leak.
		To prevent the leak, at least one reference should be owning.
		For each bound name, only one reference is special, if any. That is, the reference on name being bound.
	For the reasons above, and since GC is not allowed by the design, it needs shared ownership.
	However, if all references are based on (reference-counted) shared pointers, there would be cyclic references.
		Resources would leak eventually.
		The cycles are explicitly disallowed by the design for the very reason.
		So weak references are needed.
		To be deterministic and simple, the reference to entity denoted directly by the defined name is to be owner.
	There is one more problem to implement 'unwrap' like Kernel.
		The type of object bound on the name is actually not the same to a directly bound object if no trick is performed.
		Thus, the bound object has to be a proxy with same type referenced by a non owning reference and builtin shared ownership.
	The solution used in NPL implementation is hidden behind the native form implemantation of vau abstractions.
		It uses a thunk data type holdings the shared 2-phase initialization thunks to be initialized.
		In the 1st phase, the thunks are initialized to default value of context handler which will always throw when called.
		In the 2nd phase, after the evaluation of the binding target and side effects of bindings, the thunks are assigned to the newly initialized real bindings, and the bound references are replaced with the proxy.

$2017-05:

report.impl:
Symbol evaluation is reviewed.
	See $2017-02 report.impl for previous status.
	To make symbol term to be evaluated only once, the reduction now produces 'ReductionStatus::Clean' rather than 'Reduction::Retrying'.
		This make '$set!' implementable as in Kernel.
		This also makes it unnecessary to care about normalization besides infinite execution in leaf token passes.
Names as replacement of 'car' and 'cdr' are considered.
	For short, the anwser are 'first' and 'rest', currently.
		The name 'first' is consistent with SFRI-1, Racket, Clojure, etc.
		The name 'rest' is consistent with Racket, Clojure, etc.
		They may be not best names, though.
			Notably, 'first' should not imply the numeric value 1.
				Nothing is relying on the Peano axioms here.
				Exact numbers are also not required in gerenal.
					Though Kernel relies on it for some cases like derivation of 'map', they should be better avoid in the spirit of the principle rules of Kernel itself.
				It is still acceptable when noted.
	The old names are bad for several reasons.
		They are leak of implementation details historically.
			See https://en.wikipedia.org/wiki/CAR_and_CDR.
			This is not the case of 'cons', which is still accaptable here.
		They have no clear lexical meaning.
			This may be compromised because it seems that English has no specific words for the components of a pair.
		The name 'car' is misleading to English-centric speakers because of its meaning other than in Lisp world.
			It is even more misleading in sense of Chinese (with primary school education, probably), for obvious reasons in mind of native speakers of Chinese.
		It is sill not fully resolved that nested name like 'caddr' are not natually support in alternative naming schemes.
			Although things like 'ffirst' can be supported, they are not natural enough.
			For 'caddr' ones, it can be complemented by adding support of SRFI-1 ordinal names like 'second', 'third', etc.
			For others, it can be argued that those name should not be used to get the code more difficult to read, besides the probable ease of writing.
			And even mandated (by RnRS, etc), the nesting level is limited, which can be fatal to treat them as necessity.
				So things like 'list-ref' are still superior in general, besides it is relying on the exact integers so it may be limited by other way (e.g. by dependency management policies in base library).
			Currently NPL does not support them at all.
				They may be also better avoided in derivation of library functions.
		See also http://arclanguage.org/item?id=10546.
		Someone may think lack of such names would violate the principle of least astonishment "for people coming from Lisp".
			For instance, http://software-ninja-ninja.blogspot.com/2011/08/clojure-patterns-cons-car-and-cdr.html.
			But more importantly, those old names has already violated the principle for other people, which is still not a good reason to be kept.
			Moreover, the 'cons' form is still supported in such case.
				In fact, it requires 2nd argument as a list in all major derivation of Lisp.
				It is actually the right design choice to signal an error for 'cons 1 2' because '2' is not a list.
			And anyway, cons pairs are still virtually supported in NPLA1 as well as in Clojure.

$2017-07:

report.impl:
Code bloat of exception message is still not resolved in the devkitARM release 46 toolchain.
	See $2015-12 for previous status.
	See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936.
		This is not backported for GCC 6.
	This may be better in upcoming devkitARM release 47 since it would update to GCC 7.
Use of direct evaluation is general preferred, even '$quote' has been now introduced.
	This is as the same style as in Kernel.
	In general, there are no need to '$quote' since 'eval' handles lists well.
		Lists are constructed by 'cons', 'list', 'list*' or other constructors.
	However, when necessary, '$quote' can improve some readability by avoiding excessive nested 'list' applicative in the 1st operand of 'eval'.
		This may also likely (but not guaranteed) provide some performance improvement if used properly.
	Passing a symbol to be evaluated without knowledge of enclosing environment can be potentionally dangerous becuase access of dangling references denoted by symbol after rebinding will cause undefined behavior.
		Direct 'eval' style has already prevent it largely.
			Symbols to be bound can be specified as operand as '$vau', or derived modifying operatives based on it (e.g. '$set!' and '$setrec!'), with no need to construct symbols reflectively (e.g. passing a 'string->symbol' result as an operand).
		The use of '$quote' also reduce necessity of reflective use of symbol further.

$2017-08:

report.impl:
Transformation of lvalue expressions support in NPLA1 implemented carefully.
	There are multiple purposes to add such support by an intermediate layer (i.e. 'TermReference') with massive update in implementation of evaluation routines.
		One is to add support of modifiable reference in specific operations like '$set-first!', without mandatory reference for each first-class objects.
		The second is to add support of list reference as well as other reference to terms.
		Another is to make it extensible for more metadata, esp. type tags like 'const' qualifiers or rvalue references, and new value categories like xvalue.
	Basically, well-formed code should need no modification to function well.
		The only exception is that varibles (implictly) captured by vau abstractions would now get reference semantics and this feature is explicitly documented.
	In general, to support lvalue reference with such backward compatibility kept, a universal conversion on the operand tree is needed.
		This is 'NPL::LiftToOther'.
	Every term of const lvalue that would be evaluated should be considered.
		Since the operand tree does not support lvalue references as binding source yet, each instance also needs to be handled properly.
			This is simplified as 'NPL::LiftToSelf' before other operations.
		The parameter tree is not so special.
			It still needs to be handled similarily since it might be evaluated as well, though not common when directly used (in vau abstractions).
	For terms that are not to be evaluated, direct 'LiftTerm' call is still OK.
	There are also other simpler operations provided by NPLA.
		For example, if no recursion is needed, 'NPL::LiftTermOrRef' can be used to replace 'NPL::LiftToOther' or 'NPL::LiftToSelf'.
			There is no real instance to use it currently.
		Direct access like 'NPL::ReferenceTerm' is more efficient for operations like equality test.
		Call of 'NPL::AccessTermPtr' can also be used to replace 'YSLib::AccessPtr'.
			This is not necessary after call of 'NPL::LiftTermOrRef' or similar functions.
	For operations only require immutable reference, new underline expression categories are to be introduced.
		They are not in schedule.
Update of devkitARM is carefully handled.
	The build system is modified a little to adapt to devkitARM r47.
		The command 'objcopy -O binary' would not work properly.
			It would produce a large binary with all sections and made it failed to link.
		This would actually not work since devkitARM r46 after update of linker script and crt0 objects.
	In FAT implementation in YFramework on platform DS, max lengths of name have been changed.
		This is caused by upstream change of value of 'NAME_MAX' macro in header <sys/syslimit.h>.
			The value previously in devkitARM r44 (as used by b611) is 768, and was changed to 255.
			See https://github.com/devkitPro/newlib/commit/770821c9e4745d69c2df69624f0e4b1f759ecfb6.
		The value of 'platform::FAT::LFN::MaxMBCSLength' is adapted in 'YCLib.FileSystem' for 2 reasons:
			To make the static assertion in 'YCLib_(DS).DSIO' happy, otherwise it does not compile.
			To make the actual limitation sane, otherwise the length error condition is wrong.
		The value of 'platform::FAT::LFN::MaxLength' (for UCS-2 sequence) is also changed to keep it not greater than length of converted MBCS.
		As a result, length of FAT long filename greater than 255 now does not work.
	The upstream newlib libsystem file descriptor change need 'YCLib_(DS).DSIO' to be updated now.
		See also the deferred change in $2017-03 dep.merge.

dep.merge:
libfat 1.1.0: reviewed, partially merged, partially shelved.
	Change https://github.com/devkitPro/libfat/commit/9e2f91dee6c27e797bb510320bb359cce11c1015 is ported.
		Actually it is adjusted manually independent to the commit.
	Change https://github.com/devkitPro/libfat/commit/b7450524b18118df693870f64242cabf5d62234b is ported.
		The function '::isDSiMode' is used instead of internal '::__dsimode'.

////

