基盤 — Infra

2.1. 適合性

規範的でないものと明示的に記された節に加え，すべての表明, 図式, 例, 注記は、 規範的ではない。 他のすべては規範的である。 ◎ All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.

これらの~keywordは，小文字で記されても等価な意味になり、 規範的でない内容に現れることはない†。 ◎ These keywords have equivalent meaning when written in lowercase and cannot appear in non-normative content.

【† また、 現れたとしても，その内容が規範的とされるわけではない。 】

注記： これは RFC 8174 に対する`故意的な違反$であり、 判読能, および［ RFC 8174 以前の， IETF 以外から公表された多くの文書における、 長年の実施 ］を保全するよう欲されていることが，動機にある。 `RFC8174$r ◎ This is a willful violation of RFC 8174, motivated by legibility and a desire to preserve long-standing practice in many non-IETF-published pre-RFC 8174 documents. [RFC8174]

上のすべては、 この標準, および この標準を利用する文書に適用-可能になる。 この標準を利用する文書は、 ~keywordの利用を［ "`must^en", "`must not^en", "`should^en", "`may^en" ］のみに制限すること, および それらを小文字で記す†ことが奨励される — その方が一般に読易くなると考えられるので。 ◎ All of the above is applicable to both this standard and any document that uses this standard. Documents using this standard are encouraged to limit themselves to "must", "must not", "should", and "may", and to use these in their lowercase form as that is generally considered to be more readable.

【† 和訳においても，~mark-upされずに表記される。 】

2.2. 他の仕様への準拠性

一般に，仕様は、 他の多様な仕様とヤリトリしたり, それらに依拠する。 あいにく，ある種の状況下では、 互いに競合する必要性により，仕様が他の仕様による要件に違反することが要求される。 これが生じたときは、 この仕様を利用している文書は，そのような破戒を `故意的な違反@ （ `willful violation^en ）として表記して，その違反の理由を注記するベキである。 ◎ In general, specifications interact with and rely on a wide variety of other specifications. In certain circumstances, unfortunately, conflicting needs require a specification to violate the requirements of other specifications. When this occurs, a document using the Infra Standard should denote such transgressions as a willful violation, and note the reason for that violation.

前述の `§ 適合性＠#conformance$では、［ この標準【！Infra】により~commitされた RFC 8174 への`故意的な違反$ ］を文書化している。 ◎ The previous section, § 2.1 Conformance, documents a willful violation of RFC 8174 committed by Infra.

2.3. 各種用語

“または”, “いずれか” などの句（ “`or^en” ）は、 特に断らない限り，あるいは排他的としか解釈し得ない場合を除き、 排他的でないとする。 排他的になるときは、 “片方”, “いずれかのみ” 等々の句でそう記される。 ◎ The word "or", in cases where both inclusive "or" and exclusive "or" are possible (e.g., "if either width or height is zero"), means an inclusive "or" (implying "or both"), unless it is called out as being exclusive (with "but not both").

`~UA@ （ `user agent^en †）とは、 利用者に利するように動作する任意の~software実体である — 例えば、 ~web内容を検索取得して具現化して，［ 末端~利用者が，そのような内容とヤリトリする ］ことを手助けするような。 この標準を利用している仕様における~UAは、 一般に，その仕様を実装する~client~softwareの~instanceを指す。 ~client~software自体【平たく言えば~program~code】は、 `実装@ （ `implementation^en ）と称される。 人々は、 日常生活において多くの異なる`~UA$を利用し得る — 例えば，［ 複数の【利用者】~profile／ 実装の私的~閲覧~mode ］を利用することにより、［ いくつかの【同じ`実装$を伴う】`~UA$が同時に動作するよう，`実装$を環境設定する ］ことも含めて。 ◎ A user agent is any software entity that acts on behalf of a user, for example by retrieving and rendering web content and facilitating end user interaction with it. In specifications using the Infra Standard, the user agent is generally an instance of the client software that implements the specification. The client software itself is known as an implementation. A person can use many different user agents in their day-to-day life, including by configuring an implementation to act as several user agents at once, for example by using multiple profiles or the implementation’s private browsing mode.

【† 和訳では、 一貫して略称 “UA” を用いる。 】

何かが `実装定義@ （ `implementation-defined^en ）であると記されている場合、 何が［ 実装により定義されるものの~~詳細 ］を成すかは，当の`実装$に委ねられる。 逆に，そのような文言が無い下では、 `実装$は，この標準を利用している文書~内に~~指示された規則に従う必要がある。 ◎ If something is said to be implementation-defined, the particulars of what is said to be implementation-defined are up to the implementation. In the absence of such language, the reverse holds: implementations have to follow the rules laid out in documents using this standard.

【 または、 “〜は実装により定義される” ／ 形容詞として “実装定義な〜” とも記される。 】【 実装定義であるとしても、 ほとんどの事例では，挙動は一貫する （アリな選択肢のうち一つを選んだ実装は、 一貫してその挙動に従う） ことになろう。 そうなるとは限らない事例もあるが （~memoryなどの資源が逼迫してきたときは、 それらを節約する挙動に~fall-backするなど）。 】

“`実装定義$な方式で、 結果の各~行lには %n 個を超える符号位置は無いように， %入力 の中に `000A^U `LF^cn を挿入する” と記されているなら、 この要件の目的においては，各~行lは［ %入力 の始端 ／ %入力 の終端 ／ `000A^U `LF^cn ］で区切られる 【どの行lも`長さ$ ~LTE %n にすること以外、どこに `LF^cn を挿入するかは，実装に委ねられる】 ことになる。 ◎ Insert U+000A (LF) code points into input in an implementation-defined manner such that each resulting line has no more than width code points. For the purposes of this requirement, lines are delimited by the start of input, the end of input, and U+000A (LF).

2.4. ~privacyの懸念

この標準を利用している文書にて定義される特能には、 利用者の便利を利用者の~privacy保護策と引換えにしているものもあるかもしれない。 ◎ Some features that are defined in documents using the Infra Standard might trade user convenience for a measure of user privacy.

一般に，~internetの~architectureに因り、 互いの利用者は，~IP~addressにより判別され得る。 ~IP~addressは、 利用者が［ 機器から機器へ, あるいは~networkから~networkへ ］移動するに伴い変化するので，利用者と~~完全には合致しない。 同様に，［ ~NAT~routing, ~proxy~server, 共用~computer ］は、 実際には複数の利用者に対応付けられ，すべての~packetが同じ~IP~addressから来ているかのように現れることを可能化する。 ~onion~routingなどの技術を利用すれば、 ~HTTP要請を更に匿名~化できる — 同じ利用者による~internet上のある~nodeからの要請が，~network上の多数の全然異なる箇所から来ているかのように現れるように。 `RFC791$r ◎ In general, due to the internet’s architecture, a user can be distinguished from another by the user’s IP address. IP addresses do not perfectly match to a user; as a user moves from device to device, or from network to network, their IP address will change; similarly, NAT routing, proxy servers, and shared computers enable packets that appear to all come from a single IP address to actually map to multiple users. Technologies such as onion routing can be used to further anonymize requests so that requests from a single user at one node on the internet appear to come from many disparate parts of the network. [RFC791]

しかしながら，同じ利用者からの各~要請を互いに関係付けることもできる仕組みには、 ~IP~addressの他にもある。 例えば~cookieは、 これを可能化するよう特定的に設計されている — ほとんどの~webは、 それを基礎に置く~session特能により，~siteに~accountを有する利用者の~log-inを可能化している。 より一般には、 どの種類の［ ~cacheの仕組み／ ~HSTSその他により共有される状態／ ~HTTP~cache／ 接続の~group化／ ~storage~API ］も，当然のように濫用され得るものと予期される。 `COOKIES$r `RFC6797$r `STORAGE$r ◎ However, the IP address used for a user’s requests is not the only mechanism by which a user’s requests could be related to each other. Cookies, for example, are designed specifically to enable this, and are the basis of most of the web’s session features that enable you to log into a site with which you have an account. More generally, any kind of cache mechanism or shared state, including but not limited to HSTS, the HTTP cache, grouping of connections, storage APIs, can and ought to be expected to be abused. [COOKIES] [RFC6797] [STORAGE]

他にも，もっと微妙な仕組みがある。 利用者の~systemを成す ある種の特性は、 互いの利用者~groupを判別するために利用し得る。 そのような情報を十分に収集すれば、 個々の利用者の~browserの “~digital指紋” を算出できる。 それは、 どの要請が同じ利用者から来ているか突止める点において，~IP~addressより勝ることもある。 ◎ There are other mechanisms that are more subtle. Certain characteristics of a user’s system can be used to distinguish groups of users from each other. By collecting enough such information, an individual user’s browser’s "digital fingerprint" can be computed, which can be better than an IP address in ascertaining which requests are from the same user.

この方式で — とりわけ 複数の~siteにまたがって — 要請を~group化することは、 悪意ある目的にも利用できる。 例えば、 ある政府が 2 つの情報 — 個人の現住所 （ある~siteから運転方向を取得するとき利用した現在地から決定される） と，その者の外見上の支持政党 （その者が参加している~forum~siteを精査することから決定される） — を組合せて，その個人の選挙投票を妨げるべきかどうかを決定することが挙げられる。 ◎ Grouping requests in this manner, especially across multiple sites, can be used for malevolent purposes, e.g., governments combining information such as the person’s home address (determined from the addresses they use when getting driving directions on one site) with their apparent political affiliations (determined by examining the forum sites that they participate in) to determine whether the person should be prevented from voting in an election.

悪意ある目的は，著しく邪悪にもなり得るので、［ ~UAの実装者／仕様の策定者 ］には，［ 利用者を指紋収集したり追跡するためにも利用され得るような情報 ］の漏洩ngを最小限にすることが強く奨励される。 ◎ Since the malevolent purposes can be remarkably evil, user agent implementors and specification authors are strongly encouraged to minimize leaking information that could be used to fingerprint or track a user.

この節の最初の段落に黙示したように、 あいにく，指紋収集や追跡~目的にも濫用できる~APIを公開することで，多大な便益が派生することも ときどき あり、 あらゆる漏洩を阻止するだけで済むほど容易ではない。 一例として、 何かを投函するために，特定の識別情報の下で ~siteに~log-inする能には、 定義により，当の利用者による要請すべてが同じ利用者から来ていることが，多少なりとも識別-可能になることが要求される。 もっと微妙な例として、 ~text幅などの情報もある — それは、 ~canvas上に~textを描くことを孕むような，多くの効果に必要yである （例：~textの周りに境界線を描くことを孕むような任意の効果）。 それもまた，利用者の要請を~group化するために利用できる情報を漏洩する （この事例では、 利用者は どの~fontを~installしたかが，総当たり探索を介して公開され得る — それは、 利用者ごとに~~有意に変わり得る情報になる）。 ◎ Unfortunately, as the first paragraph in this section implies, sometimes there is great benefit to be derived from exposing APIs that can also be abused for fingerprinting and tracking purposes, so it’s not as easy as blocking all possible leaks. For instance, the ability to log into a site to post under a specific identity requires that the user’s requests be identifiable as all being from the same user, more or less by definition. More subtly, though, information such as how wide text is, which is necessary for many effects that involve drawing text onto a canvas (e.g., any effect that involves drawing a border around the text) also leaks information that can be used to group a user’s requests. (In this case, by potentially exposing, via a brute force search, which fonts a user has installed, information which can vary considerably from user to user.)

◎追跡路 この標準を利用している文書~内で定義される特能のうち， `追跡~行路@ （ `tracking vector^en ）として利用され得るものには、 この段落に示される印が付与される。 ◎ (This is a tracking vector.) Features that are defined in documents using the Infra Standard that can be used as a tracking vector are marked as this paragraph is.

~platformにおける他の特能も — 次に挙げるものに限らず — 同じ目的に利用され得る： ◎ Other features in the platform can be used for the same purpose, including, but not limited to:

• ~UAがどの特能を~supportしているかの，正確な~list。 ◎ The exact list of which features a user agents supports.
• ~scriptの再帰に許容される，~stackの最大~深さ。 ◎ The maximum allowed stack depth for recursion in script.
• 利用者の環境を述べるような特能。 ◎ Features that describe the user’s environment.
• 利用者の地域時間帯。 ◎ The user’s time zone.
• ~HTTP要請~header。 ◎ HTTP request headers.

3.1. 適合性

~algo, あるいは ~algoの一部として命令的†に句される要件 （ “頭部の空白~並びを取り除く”, “~F を返す” など） は、 当の~algoや手続きを導入するときに利用された~keyword （ “〜するモノトスル”, 等） を意味するものと解釈することになる。 そのような~keywordが利用されていない所では “モノトスル” が含意される。 ◎ Algorithms, and requirements phrased in the imperative as part of algorithms (such as "strip any leading spaces" or "return false") are to be interpreted with the meaning of the keyword (e.g., "must") used in introducing the algorithm or step. If no such keyword is used, must is implied.

【† 原文の英語では命令形であるが、 和訳では終止形（ “現在形” ）。 】

【 ~algoに限らず，和訳では、 同様の規約を，要件の箇条書き等にも利用している — 例： “次に従うモノトスル： （…箇条書き…）” 】

~algoや特定の手続きとして句されている適合性~要件は、 ~~最終的な結果が等価になる限り，どのような方式で実装されてもヨイ （特に、 各種~algoは，追い易いように意図されており、 処理能を高めることは意図されていない。） ◎ Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms are intended to be easy to follow, and not intended to be performant.)

注記： 処理能を正しく高めることは扱い難い代物である — ［ 利用者の知覚, ~computer~architecture, 様々な型の入力 ］がそれに波及し、 これらの普及度も 時を経れば変化し得るので。 一例として，［ 単独の~algoとして標準~化されたもの ］用の［ ~JS~engineにおける~code ］は、 速度や~memory消費を最適化するため，多数に分枝する見込みが高い。 それらの~code分枝すべてを標準~化するのは 無理な注文であり，生産的でない — 単独の~algoほどに年月に耐え得るものではないので。 したがって、 処理能については互いに競う分野に残しておくのが最善である。 ◎ Performance is tricky to get correct as it is influenced by user perception, computer architectures, and different types of input that can change over time in how common they are. For instance, a JavaScript engine likely has many different code paths for what is standardized as a single algorithm, in order to optimize for speed or memory consumption. Standardizing all those code paths would be an insurmountable task and not productive as they would not stand the test of time as well as the single algorithm would. Therefore performance is best left as a field to compete over.

3.2. ~algoの入力に対する上限を避けること

この標準を利用している文書は、 一般に，~algoの入力に対し，その［ ~size, 資源の利用度，あるいは等価な何か ］に関して自身に特有な上限を施行するベキでない — ［ ~UAたちが互いに競うことを許容する ］ため，および［ 将来あり得る~computingの必要性を拘束しない ］ため。 ◎ A document using the Infra Standard generally should not enforce specific limits on algorithm inputs with regards to their size, resource usage, or equivalent. This allows for competition among user agents and avoids constraining the potential computing needs of the future.

◎追跡路 それでも、 ~UAは，［ 他では拘束されない入力 ］に対し［ `実装定義$な上限 ］を課してもヨイ。 例 ⇒＃ ~DoS攻撃を防止するため／ ~memoryの使い切りに抗して防護するため／ ~platformに特有な制限に対処するため ◎ (This is a tracking vector.) Nevertheless, user agents may impose implementation-defined limits on otherwise unconstrained inputs. E.g., to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

注記： 資源に対する大域的な上限は、 ~side~channelとして — 資源~枯渇~攻撃の変種を通して — 利用され得る。 攻撃者は、 それにより［ 被害者の~appが大域的な上限に達したかどうか ］を観測できる。 上限は，~UAを指紋収集するためにも利用され得るが、 当の上限が何らかの方式で ~UAを より一意~化する場合に限られる — 例：下層の~hardwareに特有な上限など。 ◎ Global resource limits can be used as side channels through a variant on a resource exhaustion attack, whereby the attacker can observe whether a victim application reaches the global limit. Limits could also be used to fingerprint the user agent, but only if they make the user agent more unique in some manner, e.g., if they are specific to the underlying hardware.

~memory内に~bitmapを作成することを許容する~APIは、 どの寸法も — あるいは、［ ~JSの `Number.MAX_SAFE_INTEGER^c の様な何らかの巨大な上限 ］を超えない どの寸法も — 許容するよう指定されるかもしれない。 しかしながら，実装は、 大量な~memoryを割振るよう試みる代わりに， 当の寸法に対し何らかの`実装定義$な（したがって指定されない）上限を課すことを選べる。 ◎ An API that allows creating an in-memory bitmap might be specified to allow any dimensions, or any dimensions up to some large limit like JavaScript’s Number.MAX_SAFE_INTEGER. However, implementations can choose to impose some implementation-defined (and thus not specified) limit on the dimensions, instead of attempting to allocate huge amounts of memory.

~programming言語には、 ~call~stack~sizeの最大を指定しないものもあるかもしれない。 しかしながら，実装は、 実施~上の理由により，それを課すことも選べる。 ◎ A programming language might not have a maximum call stack size specified. However, implementations could choose to impose one for practical reasons.

【作者】~codeは，特定0の上限に依存するようになり得るので、 相互運用能を得るために上限を定義することが有用になることもある。 ときには、 それを受け入れても［ 将来に問題になり得ることはなく， 当の~codeが より多くの~UAで走れるようになる ］こともある。 ◎ As code can end up depending on a particular limit, it can be useful to define a limit for interoperability. Sometimes, embracing that is not problematic for the future, and can make the code run in more user agents.

`実装定義$な上限を より低い上限で拘束することが有用になることもある。 すなわち、 すべての実装が，所与の最小~sizeの入力を取扱えることを確保するよう。 ◎ It can also be useful to constrain an implementation-defined limit with a lower limit. I.e., ensuring all implementations can handle inputs of a given minimum size.

3.3. 宣言

~algo名は，通例的には動詞~句で記されるが、 標準や読者が当の~algoを より成句的に参照rできるよう，その自立的~存在をはっきりさせる名前が与えられることもある。 ◎ Algorithm names are usually verb phrases, but sometimes are given names that emphasize their standalone existence, so that standards and readers can refer to the algorithm more idiomatically.

【 言い換えれば、 “~algoであること” を表す語が付加された名前 — 次の例に示すような。 】【 動詞~句による~algo名 “[〜する]” を参照rする所では、 “[〜する] ~algoは…” の様に記されることが多い。 】

後者の部類に入る~algo名の例 ⇒＃ “属性~変更-時の手続き”, “~module~script~graphを~fetchする内部~手続-”, “多重定義~解決~algo”。 ◎ Some algorithm names in the latter category include "attribute change steps", "internal module script graph fetching procedure", and "overload resolution algorithm".

~algoは、 その［ 名前, 各~parameter, 返り値の型 ］を次の形で言明することにより宣言する： ◎ Declare algorithms by stating their name, parameters, and return type, in the following form:

（~algo名が動詞~句でない場合【名詞~句である場合】、 “`[~algo名]^dfn は…を遂行する” を利用する。） （~parameter宣言には、 より複雑な形もある — `§ ~parameter＠#algorithm-params$を見よ。） ◎ (For non-verb phrase algorithm names, use "To perform the [algorithm name]…". See also § 3.4 Parameters for more complicated parameter-declaration forms.)

値を返さない~algoは、 より短い形を利用する。 値を返す~algoであっても、 返り値の型を容易に推定できるならば，同じ形を利用できる： ◎ Algorithms which do not return a value use a shorter form. This same shorter form can be used even for algorithms that do return a value if the return type is relatively easy to infer from the algorithm steps:

ごく短い~algoは、 単文で【和訳においては、 1 個の段落で】［ 宣言する／指定する ］こともできる： ◎ Very short algorithms can be declared and specified using a single sentence:

~algoの宣言には型を含めるベキであるが、 ~parameter名から, あるいは文脈から十分~明瞭ならば，省略してもヨイ （例えば、 別の~algoを包装するだけの~algoなど）。 ◎ Types should be included in algorithm declarations, but may be omitted if the parameter name is clear enough, or if they are otherwise clear from context. (For example, because the algorithm is a simple wrapper around another one.)

3.4. ~parameter

~algo~parameterは、 通例的には， `§ 宣言＠#algorithm-declaration$にて述べられる流儀で連列的に~listされる。 しかしながら，より複雑な事例もある。 ◎ Algorithm parameters are usually listed sequentially, in the fashion described in § 3.3 Declaration. However, there are some more complicated cases.

~algo~parameterは、 省略可能（ `optional^en ）にし得る。 その事例では、 ~algo宣言は，それらを — 省略可能でない どの~parameterよりも後に — そのように~listしなければナラナイ†。 それらは、 既定の値も与えるか，~algo本体にて当の引数が与えられたかどうか検査できる。 具象的には、 次に挙げるいずれかの形を利用すること： ◎ Algorithm parameters can be optional, in which case the algorithm declaration must list them as such, and list them after any non-optional parameters. They can either be given a default value, or the algorithm body can check whether or not the argument was given. Concretely, use the following forms:

• … [型] `[~parameter]^V（省略時は ε ）…† 【原文では `… an optional [type] [parameter] …^en】 ◎ … an optional [type] [parameter] …

• … [型] `[~parameter]^V（省略時は [既定~値] ） … 【原文では `… an optional [type] [parameter] (default [default value]) …^en 】 ◎ … an optional [type] [parameter] (default [default value]) …

【† 前者の形による “省略時は ε” は、 和訳に特有である。 和訳では、 既定~値が指定されていない ほぼすべての事例で， 既定~値として特殊~値 ε を与えるように改めている。 】

省略可能な`真偽値$をとる~parameterには、 既定~値が指定されなければナラナイ — その既定は ~F でなければナラナイ。 ◎ Optional boolean parameters must have a default value specified, and that default must be false.

省略可能な位置的~parameter†を伴う~algoを~callするときは、 尾部を成す省略可能な引数~値に限り省略できる。 【† すなわち、後述する有名~parameterではない。】 ◎ To call algorithms with such optional positional parameters, the optional argument values can be omitted, but only the trailing ones.

特に，省略可能な~parameterに対しては、 位置的~parameter†に代えて，有名~parameter††を利用すれば、 ~callする箇所に もっと明確さと柔軟さを与えられる。 そのような~parameterは、［ 変数, 定義 ］の両者として~mark-upされ，~callする箇所から~linkされる。 ◎ Optional named parameters, instead of positional ones, can be used to increase clarity and flexibility at the call site. Such parameters are marked up as both variables and definitions, and linked to from their call sites.

【† `positional parameters^en — ~callする箇所に与えた位置により，~algoの宣言を成す どの引数に対応するか決定される~parameter （記された順序と同じ順序で，各~引数に対応付けられる）。 】【†† `named parameters^en — `構造体$のように名前を伴う~parameter （~callする箇所では、 各~parameterに 対応する引数の名前を逐一伴わせる）。 】【 ［ 位置的~parameter, 有名~parameter ］両者の組合nを利用している~algoもある。 】

注記： この~algoを成す手続きの中では、 引数~値は~parameter宣言へ~linkされず，ただの変数~参照であり続けることに注意。 当の~parameter宣言へ~linkするのは、 ~callする箇所に限られる。 ◎ Note how within the algorithm steps, the argument value is not linked to the parameter declaration; it remains just a variable reference. Linking to the parameter declaration is done only at the call sites.

省略可能でない~parameterにも、 有名~parameterを利用してヨイ — 同じ規約を利用して。 そうすれば、 ~callする箇所における明確さを改善し得る。 ◎ Non-optional named parameters may also be used, using the same convention of marking them up as both variables and definitions, and linking to them from call sites. This can improve clarity at the call sites.

明確さを改善するための別の相補的な技法は、 関係する値たちを`構造体$の中に梱包しておいて，その構造体を~parameterとして渡すことである。 これは，とりわけ、 複数の~algoの入力に同じ［ 関係する値たちが成す集合 ］が利用されるときに適用-可能になる。 【例：~HTMLの`~navi~params＠~HTMLnav#navigation-params$】 ◎ Another complementary technique for improving clarity is to package up related values into a struct, and pass that struct as a parameter. This is especially applicable when the same set of related values is used as the input to multiple algorithms.

3.5. 変数

変数は、 "~LET" 【原文では “`let … be …^en”】 で宣言され， "~SET" 【原文では “`set … to …^en”】 で変更される。 ◎ A variable is declared with "let" and changed with "set".

変数は、 宣言される前に利用してはナラナイ。 変数の`視野は~block＠https://en.wikipedia.org/wiki/Scope_(computer_science)#Block_scope$である。 同じ変数を複数~回 宣言してはナラナイ。 ◎ Variables must not be used before they are declared. Variables are block scoped. Variables must not be declared more than once per algorithm.

【 入子な~block（あるいは手続き）の中で同じ名前の変数が宣言されることは、 あるかもしれない （通例的には避けられるが） — その場合、 それは別な変数として扱われることになる。 】

`~tuple$を成す`~item$sctたちを複数個の変数に一括してアテガう構文も利用できる — そのためには、 各~変数を~commaで分離した上で，全体を丸括弧で括る。 ただし、 変数の個数は，`~tuple$を成す`~item$sctの個数と相違し得ない。 ◎ A multiple assignment syntax can be used to assign multiple variables to the tuple’s items, by surrounding the variable names with parenthesis and separating each variable name by a comma. The number of variables assigned cannot differ from the number of items in the tuple.

3.6. 制御~flow

~algoの制御~flowにて “~RET” ／ “~THROW （例外の投出）” 【原文では “`return^en” ／ “`throw^en”】 として記される要件は、 それが記されている~algoを終了させる。 “~RET” に値が与えられている場合、 その値が~call元に渡される。 “~THROW” は，~call元でも自動的に所与の値を再投出させ，~call元~の~algoも終了させる。 ~call元においては、 注釈文により，例外を “~catchして” 別の動作を遂行することもある。 ◎ The control flow of algorithms is such that a requirement to "return" or "throw" terminates the algorithm the statement was in. "Return" will hand the given value, if any, to its caller. "Throw" will make the caller automatically rethrow the given value, if any, and thereby terminate the caller’s algorithm. Using prose the caller has the ability to "catch" the exception and perform another action.

【 和訳においては、 ある~algoの中に入子にされた手続きの中の ~RET は，当の手続きのみを終了させる — 他が指定されない限り、 入子にしている~algoは終了されない。 （原文では “`abort these steps^en” と記されることが多いが、 表記を一貫させるため，和訳では ~RET に統一している。） 】

3.7. 条件付きな中止-

ときには、［ 一連の段を遂行-中に，ある条件が満たされたときには停止する ］ことが有用になることもある。 ◎ Sometimes it is useful to stop performing a series of steps once a condition becomes true.

これを行うためには、 所与の［ 手続き／一連の段 ］ %段たち に対し，［ 特定の %条件 に達した `ときは中止する@ （ `abort^en ） ］と言明する。 これは、 %段たち は — 記されたとおりではなく，それに加えて — %段たち を成す各~段の前に［ %条件 を評価して、 %条件 が満たされたならば，残りの段は飛ばす ］段を挿入した下で，評価するモノトスルことを指示する。 ◎ To do this, state that a given series of steps will abort when a specific condition is reached. This indicates that the specified steps must be evaluated, not as-written, but by additionally inserting a step before each of them that evaluates condition, and if condition evaluates to true, skips the remaining steps.

そのような~algoにおいては、 後続な段にて，［ `中止されたときは@ 別の一連の段を走らす ］ように注釈できる — そのような一連の段は、［ 前述の %条件 が満たされたことに因り， %段たち の残りの段が飛ばされた ］場合, その場合に限り，走らすモノトスル。 ◎ In such algorithms, the subsequent step can be annotated to run if aborted, in which case it must run if any of the preceding steps were skipped due to the condition of the preceding abort when step evaluated to true.

注記： この構成子が利用される所では、 実装には %段たち を成す各~段の［［ 前／後 ］ではなく，その間 【例えば、段が呼出した手続きを遂行している間】 ］で %条件 を評価することも — 最終結果が判別-可能にならないならば — 許容される。 一例として，上の例における %結果 が算出-演算の間に変異されないならば、 ~UAはその演算を停止することもできる。 ◎ Whenever this construct is used, implementations are allowed to evaluate condition during the specified steps rather than before and after each step, as long as the end result is indistinguishable. For instance, as long as result in the above example is not mutated during a compute operation, the user agent could stop the computation.

3.8. 条件付き言明

~algo内の条件付き言明には、 ~keyword［ ~IF ／ ~ELSE ／ ~ELIF ］および "：" を利用するベキである。 ◎ Algorithms with conditional statements should use the keywords "if", "then", and "otherwise".

【 原文では，順に［ `if … then …^en ／ `otherwise …^en ／ `otherwise if …^en ］ — 和訳では、 `then^en に代えて "：" が利用され， `otherwise^en が利用される所でも "：" は省略されない。 】

3.9. 反復

一連の段を，ある条件に達するまで繰返す種々の仕方がある。 ◎ There’s a variety of ways to repeat a set of steps until a condition is reached.

注記： この標準は，これについて（まだ）網羅的でない。 何か必要であれば，課題を申請されたし。 ◎ The Infra Standard is not (yet) exhaustive on this; please file an issue if you need something.

…を成す ~EACH ( … ) に対し… 【原文では “`For each … of …^en”】 ◎ For each

［ ~list（およびその派生型）の`反復する$ ／ ~mapの`反復する$map ］に定義されるものと同様。 ◎ As defined for lists (and derivatives) and maps.

【 `of …^en （…を成す）の部分を `in …^en （…内の）と記している仕様もある（現時点では、 後者の方が多い）。 前者は、 ~JSの `for … of^c 構文に倣ったものとも思われる （その方が `for … in^c 構文より意味論的に近いなどの理由で）。 】

【 和訳では、 `~list$や`有順序~map$に限らず，順序が定義される何であれ ~EACH( … ) の表記を利用している （他が指定されない限り，先頭から順に反復する）。 例： “文字列 %S を成す ~EACH( %文字 ) に対し…” 】

`~WHILE@ 【原文では “`While …^en”】 ◎ While

条件が満たされる限り，一連の段を繰返す指示書き。 ◎ An instruction to repeat a set of steps as long as a condition is met.

1. ~WHILE %条件 ~EQ `満たされる^l ： ◎ While condition is "met":

   1. …

反復の~flowは、 `~CONTINUE@ ／ `~BREAK@ 【原文では “`continue^en” ／ “`break^en”】 と記される要件を介して制御できる。 `~CONTINUE$は、 反復における残りの段たちを飛ばして，次の~itemの~~処理に~~移行する — 次の~itemがなければ，そこで反復は停止する。 `~BREAK$は、 反復における残りの段たちを飛ばすことに加えて，反復も停止する。 ◎ An iteration’s flow can be controlled via requirements to continue or break. Continue will skip over any remaining steps in an iteration, proceeding to the next item. If no further items remain, the iteration will stop. Break will skip over any remaining steps in an iteration, and skip over any remaining items as well, stopping the iteration.

3.10. 表明

~algoに不変則を言明している表明（ `assertion^en ）を追加すると、 より読易くなることもある。 そのためには、 "`~Assert@：" 【原文では “`Assert:^en”】 に続けて，真になる筈の言明（ `statement^en ）を記す。 言明が偽になる場合、 この標準を利用している当の文書における課題であることを指示するので，報告され, 取組まれるベキである。 ◎ To improve readability, it can sometimes help to add assertions to algorithms, stating invariants. To do this, write "Assert:", followed by a statement that must be true. If the statement ends up being false that indicates an issue with the document using the Infra Standard that should be reported and addressed.

注記： 言明は必ず真になるので、 実装にとっての含意はない。 【が、当の~algoを利用している仕様~策定者に課される要件を成し得る。】 ◎ Since the statement can only ever be true, it has no implications for implementations.

4.1. ~NULL

値 ~NULL は、 値を欠いていることを指示するために利用される。 ~NULL は、 ~JS `null^jv 値 `ECMA-262$r と交換可能に利用され得る。 ◎ The value null is used to indicate the lack of a value. It can be used interchangeably with the JavaScript null value. [ECMA-262]

【 したがって、 表記上も区別されない。 和訳では、［ ~JS `null^jv ／ ~IDL ~NULL ］値と区別する — 仕様~levelの値であることを明確化する — ため， ~NULL に代えて特殊~値 ε を利用することもある。 】

4.2. 真偽値

`真偽値@ （ `boolean^en ）は、［ ~T または ~F ］をとるとする。 ◎ A boolean is either true or false.

4.3. ~number

~numberは、 【特に，その［精度, 範囲］の取扱いに関して】 複雑である — `課題 #87＠https://github.com/whatwg/infra/issues/87$ を見られたし。 ここには、 追って，［ 型, 数学的な演算 ］を巡る指導を もっと提供するものと希望されている。 皆の助力を請う。 ◎ Numbers are complicated; please see issue #87. In due course we hope to offer more guidance here around types and mathematical operations. Help appreciated!

`8 ~bitな無符号~整数@ は、 範囲 { 0 〜 255 } （ 0 〜 2`8^sup ~MINUS 1 ） に入る整数である。 ◎ An 8-bit unsigned integer is an integer in the range 0 to 255 (0 to 28 − 1), inclusive.

`16 ~bitな無符号~整数@ は、 範囲 { 0 〜 65535 } （ 0 〜 2`16^sup ~MINUS 1 ） に入る整数である。 ◎ A 16-bit unsigned integer is an integer in the range 0 to 65535 (0 to 216 − 1), inclusive.

`32 ~bitな無符号~整数@ は、 範囲 { 0 〜 4294967295 } （ 0 〜 2`32^sup ~MINUS 1 ） に入る整数である。 ◎ A 32-bit unsigned integer is an integer in the range 0 to 4294967295 (0 to 232 − 1), inclusive.

`64 ~bitな無符号~整数@ は、 範囲 { 0 〜 18446744073709551615 } （ 0 〜 2`64^sup ~MINUS 1 ） に入る整数である。 ◎ A 64-bit unsigned integer is an integer in the range 0 to 18446744073709551615 (0 to 264 − 1), inclusive.

`128 ~bitな無符号~整数@ は、 範囲 { 0 〜 340282366920938463463374607431768211455 } （ 0 〜 2`128^sup ~MINUS 1 ） に入る整数である。 ◎ A 128-bit unsigned integer is an integer in the range 0 to 340282366920938463463374607431768211455 (0 to 2128 − 1), inclusive.

~IPv6~addressは、 `128 ~bitな無符号~整数$である。 ◎ An IPv6 address is an 128-bit unsigned integer.

`8 ~bitな有符号~整数@ は、 範囲 { −128 〜 127 } （ −2`7^sup 〜 2`7^sup ~MINUS 1 ） に入る整数である。 ◎ An 8-bit signed integer is an integer in the range −128 to 127 (−27 to 27 − 1), inclusive.

`16 ~bitな有符号~整数@ は、 範囲 { −32768 〜 32767 } （ −2`15^sup 〜 2`15^sup ~MINUS 1 ） に入る整数である。 ◎ A 16-bit signed integer is an integer in the range −32768 to 32767 (−215 to 215 − 1), inclusive.

`32 ~bitな有符号~整数@ は、 範囲 { −2147483648 〜 2147483647 } （ −2`31^sup 〜 2`31^sup ~MINUS 1 ） に入る整数である。 ◎ A 32-bit signed integer is an integer in the range −2147483648 to 2147483647 (−231 to 231 − 1), inclusive.

`64 ~bitな有符号~整数@ は、 範囲 { −9223372036854775808 〜 9223372036854775807 } （ −2`63^sup 〜 2`63^sup ~MINUS 1 ） に入る整数である。 ◎ A 64-bit signed integer is an integer in the range −9223372036854775808 to 9223372036854775807 (−263 to 263 − 1), inclusive.

4.4. ~byte

`~byte@ （ `byte^en ）は［ 8 個の~bitが成す並び ］であり、 その `値@byte と称される下層の~numberを表す，範囲 { `00^X 〜 `FF^X }† に入る［ `0x^l と後続する 2 個の`~ASCII~hex数字（大文字）$ ］として表現される。 ◎ A byte is a sequence of eight bits and is represented as "0x" followed by two ASCII upper hex digits, in the range 0x00 to 0xFF, inclusive. A byte’s value is its underlying number.

【† この “範囲” は、 表記上の範囲のみならず，数量的な範囲も包摂する （`値$byteは、 無符号な~numberとして扱われるので）。 】

`40^X は、 `~byte$であり，その`値$byteは 64 である。 ◎ 0x40 is a byte whose value is 64.

`~ASCII~byte@ は、 範囲 { `00^X (NUL) 〜 `7F^X (DEL) } に入る`~byte$である。 ここに記したように、 `~ASCII~byte$には，［ `ASCII format for Network Interchange^cite `RFC20$r の `§ 標準~code＠~RFCx/rfc20#section-2$ に挙げられている表現 ］が丸括弧で括られて後続してもヨイ — ただし， `28^X, `29^X は除く。 それらに対しては、 順に， "`(left parenthesis)^en", "`(right parenthesis)^en" が後続してもヨイ†。 ◎ An ASCII byte is a byte in the range 0x00 (NUL) to 0x7F (DEL), inclusive. As illustrated, an ASCII byte, excluding 0x28 and 0x29, may be followed by the representation outlined in the Standard Code section of ASCII format for Network Interchange, between parentheses. [RFC20] ◎ 0x28 may be followed by "(left parenthesis)" and 0x29 by "(right parenthesis)".

【† 和訳では、 例外なく `28^X `(^smb, 等々と記すことにする。 】

次の結果は、 `符号位置$ `0049^U `I^smb になる ⇒ `~UTF-8復号する$( `49^X `I^smb ) ◎ 0x49 (I) when UTF-8 decoded becomes the code point U+0049 (I).

4.5. ~byte列

`~byte列@ （ `byte sequence^en, 略して `bytes^en ） は、 0 個~以上の`~byte$たちが成す連列であり，各~byteを~spaceで分離して表現される。 ~byte列のうち［ どの~byteも範囲 { `20^X (SP) 〜 `7E^X `~^smb } 内に入るもの ］は，文字列としても記され得るが、 実際の`文字列$と混同されないよう， 引用符に代えて ~backtick（ `backtick^en, "`" ）で括られる。 ◎ A byte sequence is a sequence of bytes, represented as a space-separated sequence of bytes. Byte sequences with bytes in the range 0x20 (SP) to 0x7E (~), inclusive, can alternately be written as a string, but using backticks instead of quotation marks, to avoid confusion with an actual string.

【 （参考） ~byte列による値は、 ~IDLにおいては `ByteString$c 型で表現される。 】

【 和訳では、 `文字列$との区別が不要な所では，~backtickは省略することもある。 例えば、 もっぱら定義を参照するための名前として利用されていて，`~byte列$として演算されていない~keywordなど。 】

注記： `文字列$から`~byte列$を取得するときは、 `~UTF-8符号化する$ `ENCODING$r の利用が奨励される。 稀な状況下では、 `同型に符号化する$必要があるかもしれない。 ◎ To get a byte sequence out of a string, using UTF-8 encode from Encoding is encouraged. In rare circumstances isomorphic encode might be needed. [ENCODING]

`~byte列$の `長さ@byte （ `length^en ）は、 それが包含する`~byte$の個数である。 ◎ A byte sequence’s length is the number of bytes it contains.

所与の`~byte列$ %B, 負でない整数 %n に対し， “%B を成す %n 番の`~byte$” という句は、 %B を成す［ %n ~PLUS 1 ］個目のそれを指すとする （すなわち， 0 番から数える）。 【この規約は、この訳による追加（原文では、“%n`-th^en ／ `at index^en %n” などと記されることが多い）。】

【 他に解釈しようがない場合を除き， %入力 を改変することはない — 単に “%何か を~byte小文字~化する” と記された場合に限り、 “%何か ~SET `~byte小文字~化する$( %何か )” の略記を表す。 （次の “~byte大文字~化する” も同様。） 】

4.6. 符号位置

`符号位置@ （ `code point^en ）†は~Unicode符号位置であり、 その `値@cp と称される下層の~numberを表す，範囲 { `0000^U 〜 `10FFFF^U }† に入る［ `U+^l と後続する 4 〜 6 個の`~ASCII~hex数字（大文字）$ ］として表現される。 ◎ A code point is a Unicode code point and is represented as "U+" followed by four-to-six ASCII upper hex digits, in the range U+0000 to U+10FFFF, inclusive. A code point’s value is its underlying number.

【 訳語の “~~符号位置” は~Unicodeに特有であり，他の符号化法の “符号点” に相当する。 】【† `~byte$のときと同じく，この “範囲” も、 表記上の範囲のみならず，数量的な範囲も包摂する。 】

`符号位置$には，［ その名前／丸括弧で括られたその具現化形 ］, あるいはこの両者が後続してもヨイ。 判読能を得るため，この標準を利用している文書には、［［ 具現化できない`符号位置$, および `0028^U, `0029^U† ］には その名前 ／ 他の場合は丸括弧で括られた具現化形 ］を後続させることが奨励される。 ◎ A code point may be followed by its name, by its rendered form between parentheses when it is not U+0028 or U+0029, or by both. Documents using the Infra Standard are encouraged to follow code points by their name when they cannot be rendered or are U+0028 or U+0029; otherwise, follow them by their rendered form between parentheses, for legibility.

【† 和訳では、 `0028^U, `0029^U に対しても， `0028^U `(^smb, `0029^U `)^smb と記すことにする。 】

`符号位置$の名前は、 `UNICODE$r にて定義され，`~ASCII大文字~化$されて表現される。 ◎ A code point’s name is defined in Unicode and represented in ASCII uppercase. [UNICODE]

`000A^U などの一義的に具現化するのは困難な`符号位置$は、 “`000A^U `LF^cn” のように表記できる。 `0029^U は，具現化できるが丸括弧の括りが揃わなくなるので “`0029^U `RIGHT PARENTHESIS^cn” のように表記できる。 【が，和訳では、上述したとおり，他と同様に記すことにする。】 ◎ Code points that are difficult to render unambigiously, such as U+000A, can be referred to as "U+000A LF". U+0029 can be referred to as "U+0029 RIGHT PARENTHESIS", because even though it renders, this avoids unmatched parentheses.

`符号位置$は、 `文字$（ `character^en ）と称されることもあり，ある種の文脈では "U+" に代えて "0x" が接頭される。 【 "0x" は、主に，数量としての値が念頭に置かれている場合に利用される。】 ◎ Code points are sometimes referred to as characters and in certain contexts are prefixed with "0x" rather than "U+".

次に挙げる各種 `符号位置$たちが成す集合が定義される： ◎ ↓

`頭部~surrogate@ ◎ A leading surrogate＼

{ `D800^U 〜 `DBFF^U } ◎ is a code point that is in the range U+D800 to U+DBFF, inclusive.

`尾部~surrogate@

{ `DC00^U 〜 `DFFF^U } ◎ A trailing surrogate＼ ◎ is a code point that is in the range U+DC00 to U+DFFF, inclusive.

`~surrogate@ ◎ A surrogate＼

{ `頭部~surrogate$, `尾部~surrogate$ } ◎ is a leading surrogate or a trailing surrogate.

【 すなわち，代用対（ `surrogate pair^en ）を成し得る`符号位置$ 】

`~scalar値@ ◎ A scalar value＼

`~surrogate$でない`符号位置$ ◎ is a code point that is not a surrogate.

`非文字@ ◎ A noncharacter＼

{ `FDD0^U 〜 `FDEF^U, `FFFE^U, `FFFF^U, `1FFFE^U, `1FFFF^U, `2FFFE^U, `2FFFF^U, `3FFFE^U, `3FFFF^U, `4FFFE^U, `4FFFF^U, `5FFFE^U, `5FFFF^U, `6FFFE^U, `6FFFF^U, `7FFFE^U, `7FFFF^U, `8FFFE^U, `8FFFF^U, `9FFFE^U, `9FFFF^U, `AFFFE^U, `AFFFF^U, `BFFFE^U, `BFFFF^U, `CFFFE^U, `CFFFF^U, `DFFFE^U, `DFFFF^U, `EFFFE^U, `EFFFF^U, `FFFFE^U, `FFFFF^U, `10FFFE^U, `10FFFF^U } ◎ is a code point that is in the range U+FDD0 to U+FDEF, inclusive, or U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, or U+10FFFF.

【 ~Unicodeにて `恒久的に予約済み＠https://www.unicode.org/faq/private_use.html#noncharacters$（未定義）とされている符号位置。 ここに挙げられたものは、 `そこに挙げられているもの＠https://www.unicode.org/faq/private_use.html#nonchar4$と一致する。 】【 その名に反して，これらも`文字$である。 】

`~ASCII符号位置@ ◎ An ASCII code point＼

{ `0000^U `NULL^cn 〜 `007F^U `DELETE^cn } ◎ is a code point in the range U+0000 NULL to U+007F DELETE, inclusive.

`~ASCII~tabや~ASCII改行文字@ ◎ An ASCII tab or newline＼

{ `0009^U `TAB^cn, `000A^U `LF^cn, `000D^U `CR^cn } ◎ is U+0009 TAB, U+000A LF, or U+000D CR.

`~ASCII空白@ ◎ ASCII whitespace＼

{ `0009^U `TAB^cn, `000A^U `LF^cn, `000C^U `FF^cn, `000D^U `CR^cn, `0020^U `SPACE^cn } ◎ is U+0009 TAB, U+000A LF, U+000C FF, U+000D CR, or U+0020 SPACE.

注記： 空白（ `whitespace^en ）は数えられない名詞（ mass noun ）である。 【したがって、複数個あり得る場合でも英文では単数形で記される。】 ◎ "Whitespace" is a mass noun.

注記： ［ ~XML／~JSON／~HTTP仕様を成す各所 ］は、 空白の定義から `000C^U `FF^cn を除外する： ◎ The XML, JSON, and parts of the HTTP specifications exclude U+000C FF in their definition of whitespace:

• `~XMLの S 生成規則＠~TR/xml/#NT-S$ ◎ XML’s S production
• `~JSONの ws 生成規則＠~RFCx/rfc8259#section-2$ ◎ JSON’s ws production
• `~HTTP空白＠~FETCH#http-whitespace$ ◎ HTTP whitespace

新たな特能~用には、［ ~Infraによる`~ASCII空白$の定義を利用すること ］を選好すること — 当の仕様が排他的に［ ~XML／~JSON／~HTTP ］を処していない限り。 ◎ Prefer using Infra’s ASCII whitespace definition for new features, unless your specification deals exclusively with XML/JSON/HTTP.

`~C0制御文字@ ◎ A C0 control＼

{ `0000^U `NULL^cn 〜 `001F^U `INFORMATION SEPARATOR ONE^cn } ◎ is a code point in the range U+0000 NULL to U+001F INFORMATION SEPARATOR ONE, inclusive.

`~C0制御文字や~space@ ◎ A C0 control or space＼

{ `~C0制御文字$, `0020^U `SPACE^cn } ◎ is a C0 control or U+0020 SPACE.

`制御文字@ ◎ A control＼

{ `~C0制御文字$, `007F^U `DELETE^cn 〜 `009F^U `APPLICATION PROGRAM COMMAND^cn } ◎ is a C0 control or a code point in the range U+007F DELETE to U+009F APPLICATION PROGRAM COMMAND, inclusive.

`~ASCII数字@ ◎ An ASCII digit＼

{ `0030^U `0^smb 〜 `0039^U `9^smb } ◎ is a code point in the range U+0030 (0) to U+0039 (9), inclusive.

`~ASCII~hex数字（大文字）@ ◎ An ASCII upper hex digit＼

{ `~ASCII数字$, `0041^U `A^smb 〜 `0046^U `F^smb } ◎ is an ASCII digit or a code point in the range U+0041 (A) to U+0046 (F), inclusive.

`~ASCII~hex数字（小文字）@ ◎ An ASCII lower hex digit＼

{ `~ASCII数字$, `0061^U `a^smb 〜 `0066^U `f^smb } ◎ is an ASCII digit or a code point in the range U+0061 (a) to U+0066 (f), inclusive.

`~ASCII~hex数字@ ◎ An ASCII hex digit＼

{ `~ASCII数字$, `0041^U 〜 `0046^U , `0061^U 〜 `0066^U } ◎ is an ASCII upper hex digit or ASCII lower hex digit.

`~ASCII英大文字@ ◎ An ASCII upper alpha＼

{ `0041^U `A^smb 〜 `005A^U `Z^smb } ◎ is a code point in the range U+0041 (A) to U+005A (Z), inclusive.

`~ASCII英小文字@ ◎ An ASCII lower alpha＼

{ `0061^U `a^smb 〜 `007A^U `z^smb } ◎ is a code point in the range U+0061 (a) to U+007A (z), inclusive.

`~ASCII英字@ ◎ An ASCII alpha＼

{ `~ASCII英小文字$, `~ASCII英大文字$ } ◎ is an ASCII upper alpha or ASCII lower alpha.

`~ASCII英数字@ ◎ An ASCII alphanumeric＼

{ `~ASCII数字$, `~ASCII英字$ } ◎ is an ASCII digit or ASCII alpha.

4.7. 文字列

`文字列@ は、 0 個以上の［ `符号単位@ （ `code unit^en ）とも称される， `16 ~bitな無符号~整数$ ］たちが成す連列である。 `文字列$は、 ~JS文字列とも称される。 `文字列$は、 二重引用符で括られ，等幅~fontで表記される。 ◎ A string is a sequence of 16-bit unsigned integers, also known as code units. A string is also known as a JavaScript string. Strings are denoted by double quotes and monospace font. A string is a sequence of unsigned 16-bit integers,

`Hello, world!^l は文字列を表す。 ◎ "Hello, world!" is a string.

注記： これは、 `UNICODE$r による “符号単位” の定義-法†と異なる — 特に， `UNICODE$r が定義する~Unicodeの 16 ~bit文字列を排他的に指す。 【† `参照先＠https://www.unicode.org/versions/Unicode9.0.0/ch03.pdf#G7404$：~Unicodeが定義する符号単位は、 16 ~bitに限られない。】 ◎ This is different from how Unicode defines "code unit". In particular it refers exclusively to how Unicode defines it for Unicode 16-bit strings. [UNICODE]

`文字列$は、 ~JS仕様の `§ String 型＠~TC39#sec-ecmascript-language-types-string-type$ に定義される変換を施すことにより，`符号位置$を包含しているものとも解釈できる。 `ECMA-262$r ◎ A string can also be interpreted as containing code points, per the conversion defined in The String Type section of the JavaScript specification. [ECMA-262]

注記： この変換~処理nは、 各~surrogate~pairを対応する`~scalar値$に変換して， 残りの各~surrogateを対応する`符号位置$ — 実質的には，そのまま — に対応付ける。 ◎ This conversion process converts surrogate pairs into their corresponding scalar value and maps any remaining surrogates to their corresponding code point, leaving them effectively as-is.

`符号単位$列［ `D83D^X, `DCA9^X, `D800^X ］が成す`文字列$は、 `符号位置$を包含するものと解釈されるときは，`符号位置$列［ `1F4A9^U, `D800^U ］になる。 ◎ A string consisting of the code units 0xD83D, 0xDCA9, and 0xD800, when interpreted as containing code points, would consist of the code points U+1F4A9 and U+D800.

`文字列$の `長さ@ （ `length^en ）は、 それが包含する`符号単位$の個数とする。 ◎ A string’s length is the number of code units it contains.

`文字列$の `符号位置~長さ@ は、 それが包含する`符号位置$の個数とする。 ◎ A string’s code point length is the number of code points it contains.

所与の`文字列$ %S, 負でない整数 %n に対し， “%S を成す %n 番の［ `符号位置$／`符号単位$ ］” という句は、 %S を成す［ %n ~PLUS 1 ］個目のそれを指すとする （すなわち， 0 番から数える）。 【この規約は、この訳による追加（原文では、 “%n`-th^en ／ `at index^en %n” などと記されることが多い）。】

`文字列$が包含し得る`符号位置$に対する追加的な制約を表すため、 この仕様は［ `~ASCII文字列$, `同型~文字列$, `~scalar値~文字列$ ］を定義する。 これらを利用することで、 各~仕様における明確さは改善される。 ◎ To signify strings with additional restrictions on the code points they can contain this specification defines ASCII strings, isomorphic strings, and scalar value strings. Using these improves clarity in specifications.

`~ASCII文字列@ は、 次を満たす`文字列$である ⇒ それを成す`符号位置$は，すべて`~ASCII符号位置$である ◎ An ASCII string is a string whose code points are all ASCII code points.

`同型~文字列@ は、 次を満たす`文字列$である ⇒ それを成す`符号位置$は， すべて範囲 { `0000^U `NULL^cn 〜 `00FF^U `ÿ^smb } に入る ◎ An isomorphic string is a string whose code points are all in the range U+0000 NULL to U+00FF (ÿ), inclusive.

【 同型（ `isomorphic^en ）とは、 “~byte列と同型” を意味する。 】

`~scalar値~文字列@ は、 次を満たす`文字列$である ⇒ それを成す`符号位置$は，すべて`~scalar値$である ◎ A scalar value string is a string whose code points are all scalar values.

注記： `~scalar値~文字列$は、 後で`~UTF-8符号化する$ことになるような，入出力その他の演算に有用になる。 ◎ A scalar value string is useful for any kind of I/O or other kind of operation where UTF-8 encode comes into play.

【 （参考） ~IDLにおいては、 `文字列$は `DOMString$c 型, `~scalar値~文字列$は `USVString$c 型で表現される。 】

他が言明される所を除き、 文字列の比較には，`一致する$が利用される。 ◎ Except where otherwise stated, all string comparisons use is.

【 和訳では、 ほとんどの場合，単に %A ~EQ %B （その否定は ~NEQ ）と記される。 】

注記： `文字列$に対する この種の比較は、 `HTML$r においては，以前は “文字大小区別” による比較と称されていた。 2 個の文字列が`一致する$かどうかの比較には、 文字大小（大文字か小文字か）のみならず，符号位置に対し選ばれた他の符号化法の違い — 正規化~形や結合符の順序など — も含まれる。 2 個の文字列は、 `UNICODE$r に則って［ 視覚的に等価, さらには正準的に等価 ］であっても，`一致-$しないかもしれない。 ◎ This type of string comparison was formerly known as a "case-sensitive" comparison in HTML. Strings that compare as identical to one another are not only sensitive to case variation (such as UPPER and lower case), but also to other code point encoding choices, such as normalization form or the order of combining marks. Two strings that are visually or even canonically equivalent according to Unicode might still not be identical to each other. [HTML] [UNICODE]

~~対象が`符号単位$であることが文脈から明瞭であるときは — 例：一方の文字列は、 ~literalであり，範囲 { `0020^U `SPACE^cn 〜 `007E^U `~^smb } 内の文字のみからなるなど — “%B は %A の`符号単位~接頭辞$である” の同義語として， “%A は %B `から開始して@ いる” も利用できる。 ◎ When it is clear from context that code units are in play, e.g., because one of the strings is a literal containing only characters that are in the range U+0020 SPACE to U+007E (~), "input starts with potentialPrefix" can be used as a synonym for "potentialPrefix is a code unit prefix of input".

未知な値に対しては、 明示的にした方が良い — 例： “%~target文字列 は %利用者~入力 の`符号単位~接頭辞$である” 。 一方で~literalに対しては、 より平素な文言を利用できる — 例： “%利用者~入力 は `!^l `から開始して$いる” 。 ◎ With unknown values, it is good to be explicit: targetString is a code unit prefix of userInput. But with a literal, we can use plainer language: userInput starts with "!".

~~対象が`符号単位$であることが文脈から明瞭であるときは — 例：一方の文字列は、 ~literalであり，範囲 { `0020^U `SPACE^cn 〜 `007E^U `~^smb } 内の文字のみからなるなど — “%B は %A の`符号単位~接尾辞$である” の同義語として， “%A は %B `で終端して@ いる” も利用できる。 ◎ When it is clear from context that code units are in play, e.g., because one of the strings is a literal containing only characters that are in the range U+0020 SPACE to U+007E (~), "input ends with potentialSuffix" can be used as a synonym for "potentialSuffix is a code unit suffix of input".

未知な値に対しては、 明示的にした方が良い — 例： “%~target文字列 は %~domain の`符号単位~接尾辞$である” 。 一方で~literalに対しては、 より平素な文言を利用できる — 例： %~domain は `.^l `で終端して$いる” 。 ◎ With unknown values, it is good to be explicit: targetString is a code unit suffix of domain. But with a literal, we can use plainer language: domain ends with ".".

例えば、［ 符号位置 `FF5E^U `FULLWIDTH TILDE^cn `～^smb は， 符号位置 `1F600^U `😀^smb より明白に小さい ］が，［ 前者は 1 個の符号単位 `FF5E^X から構成される一方で， 後者は 2 個の符号単位 `D83D^X, `DE00^X から構成される ］ので、 後者は前者`未満の符号単位~列$になる。 ◎ For example, the code point U+FF5E FULLWIDTH TILDE (～) is obviously less than the code point U+1F600 (😀), but the tilde is composed of a single code unit 0xFF5E, while the smiley is composed of two code units 0xD83D and 0XDE00, so the smiley is code unit less than the tilde.

【 これらの~algoの名前は、 原文では，どれも同じ名前 “符号単位~部分文字列” として定義されているが、 和訳では — どの~algoを指すのか，一目で区別できるよう — このように違えることにする。 】

`符号単位~部分文字列$( `Hello world^l, 1, 3 ) は、 `ell^l になる。 これは， 1 から 4 までを`成す符号単位~部分文字列$としても表出できる。 ◎ The code unit substring from 1 with length 3 within "Hello world" is "ell". This can also be expressed as the code unit substring from 1 to 4.

注記： これらの~algoに与えられる~number（ %始端, %終端 ）は、 符号単位~自身の~indexではなく，`符号単位$たちの`合間^emを指す位置として捉えるのが最も良い — 返される部分文字列は、 これらの位置の合間にある符号単位~列により形成される。 例えば，［ 空~文字列の中の 0 から 0 までを`成す符号単位~部分文字列$ ］が — 空~文字列の中の 0 番の符号単位は無いにもかかわらず — なぜ空~文字列になるかは、 そう捉えることで説明される。 ◎ The numbers given to these algorithms are best thought of as positions between code units, not indices of the code units themselves. The substring returned is then formed by the code units between these positions. That explains why, for example, the code unit substring from 0 to 0 within the empty string is the empty string, even though there is no code unit at index 0 within the empty string.

【 これらの~algoの名前は、 原文では，どれも同じ名前 “符号位置~部分文字列” として定義されているが、 和訳では — どの~algoを指すのか，一目で区別できるよう — このように違えることにする。 】

4.8. 時間

時間【時刻／時間の長さ】は、 仕様~型［ `~moment$／`所要時間$ ］を利用して表現すること。 これらを［ 作成する／~JSと交換する ］ときは、 `HR-TIME$r `§ 仕様~策定者~用の~tool＠~HRTIME#sec-tools$ における助言に従うこと。 ◎ Represent time using the moment and duration specification types. Follow the advice in High Resolution Time § 3 Tools for Specification Authors when creating these and exchanging them with JavaScript. [HR-TIME]

5.1. ~list

`~list@ （ `list^en ）は、 仕様~levelの型である。 その各~instanceは、 有限~個の `~item@ （ `item^en ）からなる有順序~連列である。 ◎ A list is a specification type consisting of a finite ordered sequence of items.

【 ~IDL`連列~型$の値は、 `~list$として扱われ，~list用の各種［ 演算／定義／表記 ］が利用されることもある。 逆に，一定の条件を満たす`~list$は、 ~IDL連列~型の値として扱えるものとされている。 】

簡便な表記法として、 `~list$を~literalで表出するための構文も利用できる — そのためには、 各`~item$を~commaで分離した上で，全体を文字 «, » で括る。 ~list用の~indexing構文も利用できる — そのためには、 角括弧（ [, ] ）の内側に 0 番から数える~indexを供する。 ~indexは，`存在-$について~~述べる場合を除いて，~~範囲を超えられない。 ◎ For notational convenience, a literal syntax can be used to express lists, by surrounding the list by « » characters and separating its items with a comma. An indexing syntax can be used by providing a zero-based index into a list inside square brackets. The index cannot be out-of-bounds, except when used with exists.

%例 として`~list$ « `a^l, `b^l, `c^l, `a^l » が与えられた下では、 %例[1] は `文字列$ `b^l を表す。 ◎ Let example be the list « "a", "b", "c", "a" ». Then example[1] is the string "b".

単に “新たな`~list$” と記されたときは、 他が指定されない限り， 0 個の`~item$からなる新たな`~list$を作成することを表す （すなわち，`空$／ « » ）。 したがって、 `~list$でもある他の仕様~levelの型も同様になる （例： “新たな`有順序~集合$” ）。 【この規約は、この訳による追加。】

簡便な表記法として、 `~list$ %~list を成す`~item$たちを複数個の変数に一括してアテガう構文を利用してもヨイ — そのためには、 各~変数を~commaで分離した上で，全体を文字 «, » で括る。 %~list の`~size$は、 アテガわれる変数の個数と同じでなければナラナイ。 各 %n ~IN { 1 〜 %~list の`~size$ } に対し， %n 個目の変数は %~list[ %n −1 ] に設定される。 ◎ For notational convenience, a multiple assignment syntax may be used to assign multiple variables to the list’s items, by surrounding the variables to be assigned by « » characters and separating each variable name with a comma. The list’s size must be the same as the number of variables to be assigned. Each variable given is then set to the value of the list’s item at the corresponding index.

`~list$ %~list が~~外部から与えられる事例など， %~list の`~size$が~~不確かなときは、 期待される~sizeであることを確保するため， この構文を利用する前に %~list の`~size$を検査するベキである。 ◎ When a list’s contents are not fully controlled, as is the case for lists from user input, the list’s size should be checked to ensure it is the expected size before list multiple assignment syntax is used.

• `有順序~集合$でない`~list$ %L に所与の`~item$ %item を `付加する@ ときは ⇒ %item を %L の末尾に追加する ◎ To append to a list that is not an ordered set is to add the given item to the end of the list.

• `~list$ %A を`~list$ %B で `拡張する@ ときは、 %B を成す `~EACH$( %~item ) に対し ⇒ %A に %~item を`付加する$ ◎ To extend a list A with a list B, for each item of B, append item to A.

  1. %ルパン一味 ~LET « `ルパン三世^l, `次元大介^l » ◎ Let ghostbusters be « "Erin Gilbert", "Abby Yates" ».
  2. %ルパン一味 を « `石川五ェ門^l, `峰不二子^l » で`拡張する$ ◎ Extend ghostbusters with « "Jillian Holtzmann", "Patty Tolan" ».
  3. `~Assert$： %ルパン一味 の`~size$ ~EQ 4 ◎ Assert: ghostbusters’s size is 4.
  4. `~Assert$： %ルパン一味[ 2 ] ~EQ `石川五ェ門^l ◎ Assert: ghostbusters[2] is "Jillian Holtzmann".

• `有順序~集合$でない`~list$ %L に所与の`~item$ %item を `前付加する@ ときは ⇒ %item を %L の先頭に追加する ◎ To prepend to a list that is not an ordered set is to add the given item to the beginning of the list.

• `有順序~集合$でない`~list$ %L の中で `置換する@ ときは、 %L 内の［ 所与の %条件 に合致する`~item$ ］すべてを，所与の`~item$ %item に置換する （合致するものが無ければ何もしない）。 ◎ To replace within a list that is not an ordered set is to replace all items from the list that match a given condition with the given item, or do nothing if none do.

  注記： `~list$が`有順序~集合$でもあるときには、 上の定義は改変される — 下に与える［ `付加する$set ／ `前付加する$set ／ `置換する$set ］を見よ。 ◎ The above definitions are modified when the list is an ordered set; see below for ordered set append, prepend, and replace.

• `~list$ %L の中に所与の`~item$ %item を %index の前に `挿入する@ ときは：

  1. `~Assert$： 0 ~LTE %index ~LT ( %L の`~size$ )
  2. ~IF［ %index ~EQ 0 ］ ⇒ %L に %item を`前付加する$
  3. ~ELSE ⇒ %L 内の %L[%index − 1] と %L[%index ] の合間に %item を追加する
  ◎ To insert an item into a list before an index is to add the given item to the list between the given index − 1 and the given index. If the given index is 0, then prepend the given item to the list.

• `~list$ %L から所与の %条件 に合致する`~item$を `除去する@ ときは ⇒ ［ %条件 に合致する %L 内の`~item$ ］すべてを %L から除去する （合致するものが無ければ何もしない） ◎ To remove zero or more items from a list is to remove all items from the list that match a given condition, or do nothing if none do.

  %L ~EQ `~list$ « %x, %y, %z, %x » から %x を`除去する$ときは、 %L から %x に等しいすべての~itemを除去する。 結果の %L は、 « %y, %z » に等価になる。 ◎ Removing x from the list « x, y, z, x » is to remove all items from the list that are equal to x. The list now is equivalent to « y, z ».

  %L ~EQ `~list$ « `a^l, `b^l, `ab^l, `ba^l » から［ `文字列$ `a^l で開始する~item ］すべてを`除去する$ときは、 ~item［ `a^l, `ab^l ］を除去する。 結果の %L は、 « `b^l, `ba^l » に等価になる。 ◎ Removing all items that start with the string "a" from the list « "a", "b", "ab", "ba" » is to remove the items "a" and "ab". The list is now equivalent to « "b", "ba" ».

• `~list$ %L を `空にする@ ときは ⇒ %L 内のすべての`~item$ 【すなわち，条件 “無条件” に合致する~item】 を`除去する$ ◎ To empty a list is to remove all of its items.

• `~list$ %L が`~item$ %item を `包含して@ いるとは、 %L 内に %item が現れることをいう。 （ “`包含して$いない” は、 その否定を表す。）

  “ %item ~IN %L ” とも表記される。 （ “ %item ~NIN %L ” は、 その否定を表す。）

  `~list$ %L が~index %index 番の`~item$を`包含して$いることを “%L[ %index ] は`存在-$する” ともいう。 （ “`存在-$しない” は、 その否定を表す。）

  ◎ A list contains an item if it appears in the list. We can also denote this by saying that, for a list list and an index index, "list[index] exists".
• `~list$ %L の `~size@ （ `size^en ）とは、 %L が`包含して$いる`~item$の個数をいう。 【重複する~instanceも別々に数える。】 ◎ A list’s size is the number of items the list contains.
• `~list$ %L が `空@ （ `empty^en ）であるとは、［ %L の`~size$ ~EQ 0 ］であることをいう。 ◎ A list is empty if its size is zero.
• `~list$ %L から `~index群を取得する@ ときは、 `範囲$ { 0 〜 %L の`~size$ − 1 } を返す。 ◎ To get the indices of a list, return the range from 0 to the list’s size, exclusive.

• `~list$ %L 内の各`~item$に対し~list順に，一連の段を遂行するように `反復する@ （ `iterate over^en ）ときは、 “ %L を成す`~EACH$( %item ) に対し：” という句の下で，後続な注釈文にて %item に対し演算する。

  【 和訳では、 “反復する” は利用せず，もっぱら “~EACH(…)” を表記に利用している。 】【 仕様には、 逆順の~listに変換するなどにより，実質的に逆順に反復している箇所もたまにある。 そのような箇所は，和訳では、 “~EACH( %item ) に対し，`逆順に^em” のような句により，表記を簡約することもある。 】

  ◎ To iterate over a list, performing a set of steps on each item in order, use phrasing of the form "For each item of list", and then operate on item in the subsequent prose.

• `~list$ %L を `~cloneする@ ときは：

  1. %~clone ~LET %L と同じ型の 新たな`~list$ 【すなわち、%L が`~stack$なら 新たな`~stack$，等々】
  2. %L を成す `~EACH$( %~item ) に対し ⇒ %~clone に %~item を`付加する$
  3. ~RET %~clone

  結果の %~clone は、 %L と同じ`~item$たちを同じ順序で`包含して$いることになる。

  ◎ To clone a list list is to create a new list clone, of the same designation, and, for each item of list, append item to clone, so that clone contains the same items, in the same order as list.

  注記： `~item$自身は~cloneされないので、 これは “浅い~clone” である。 ◎ This is a "shallow clone", as the items themselves are not cloned in any way.

  %L が`有順序~集合$ « `a^l, `b^l, `c^l » であったなら， %L を`~clone$して作成される新たな`有順序~集合$ %~clone において、 %~clone 内の`文字列$ `a^l を `foo^l で`置換-$setした結果は « `foo^l, `b^l, `c^l » になるが， %L[ 0 ] は `a^l のまま変わらない。 ◎ Let original be the ordered set « "a", "b", "c" ». Cloning original creates a new ordered set clone, so that replacing "a" with "foo" in clone gives « "foo", "b", "c" », while original[0] is still the string "a".

［ %L は，`~tuple$ ( 整数, 文字列 ) たちが成す`~list$ « ( 200, `OK^l ), ( 404, `Not Found^l ), ( ~NULL, `OK^l ) » ］，［ `小なり~algo$ %小なり( %A, %B ) は，［ %A を成す文字列 ~LT`符号単位$sub %B を成す文字列ならば ~T ／ ~ELSE_ ~F ］を返す ］とするとき、 `~listを昇順に~sortする$( %L, %小なり ) の結果は ⇒ « ( 404, `Not Found^l ), ( 200, `OK^l ), ( ~NULL, `OK^l ) » ◎ Let original be the list « (200, "OK"), (404, "Not Found"), (null, "OK") ». Sorting original in ascending order, with a being less than b if a’s second item is code unit less than b’s second item, gives the result « (404, "Not Found"), (200, "OK"), (null, "OK") ».

`~list$型は、 ~JS仕様に由来する （その仕様では、 "`List$" と~~大文字化されている）。 ここでは、 参照し易くするため，その定義を再掲して、 `~list$を操作するための語彙を拡げる。 ~JSが `List$ を期待する所では、 ここに定義される`~list$を利用できる — それらは同じ型である。 `ECMA-262$r ◎ The list type originates from the JavaScript specification (where it is capitalized, as List); we repeat some elements of its definition here for ease of reference, and provide an expanded vocabulary for manipulating lists. Whenever JavaScript expects a List, a list as defined here can be used; they are the same type. [ECMA-262]

5.2. ~map

`有順序~map@ （ `ordered map^en ）は、 仕様~levelの型である。 その各~instanceは、 有限~個の［ `~entry@ （ `entry^en ）と呼ばれる，［ `~key@map （ `key^en ）, `値@map （ `value^en ） ］からなる`~tuple$ ］たちが成す有順序~連列であり，かつ 同じ`~key$mapが重ねて現れないものである。 ◎ An ordered map, or sometimes just "map", is a specification type consisting of a finite ordered sequence of tuples, each consisting of a key and a value, with no key appearing twice. Each such tuple is called an entry.

注記： `有順序~集合$と同様に，実装~間での相互運用能を得るため、 ~mapも既定で有順序と見做す必要がある。 ◎ As with ordered sets, by default we assume that maps need to be ordered for interoperability among implementations.

【 単に “~map” と称されることもある — 特に，順序が有意でない（順序の相違が観測され得ない）場合。 】【 `~entry$は`~tuple$なので、［ %~entry[ 0 ], %~entry[ 1 ] ］のような記法も許容されることになる — 順に， %~entry の［ `~key$map, `値$map ］を表すことになる。 】【 ~IDL［ `辞書~型$／`~record型$ ］の値は、 `有順序~map$として扱われ，~map用の各種［ 演算／定義／表記法 ］（順不同）が利用されることもある。 逆に，一定の条件を満たす`有順序~map$は、 ~IDL［ 辞書~型／~record型 ］の値として扱えるものとされている。 （辞書~型は、 ~keyたちが成す集合が固定的なので，意味論的には`構造体$の方が近いが。） 】

`有順序~map$を~literalで表出するための構文も利用できる — そのためには、 各 `~entry$を "%~key → %値" の~~形で記して, 各~entryを~commaで分離した上で, 全体を文字 «[, ]» で括る。 ◎ A literal syntax can be used to express ordered maps, by surrounding the ordered map with «[ ]» characters, denoting each of its entries as key → value, and separating its entries with a comma.

%M ~EQ `有順序~map$ «[ `a^l → `x^bl, `b^l → `y^bl ]» が与えられた下では、 %M[`a^l] は `~byte列$ `x^bl を表す。 ◎ Let example be the ordered map «[ "a" → `x`, "b" → `y` ]». Then example["a"] is the byte sequence `x`.

単に “新たな`有順序~map$” と記されたときは、 他が指定されない限り， 0 個の`~entry$からなる新たな`有順序~map$を作成することを表す （すなわち，`空$map ／ «[ ]» ）。 【この規約は、この訳による追加。】

• `有順序~map$ %M 内の`~key$map %K に対応する `値を取得する@ ときは、 次を返す ⇒ %M は［ `~key$map %K を伴う`~entryを包含して$いる ］ならば その`値$map ／ ~ELSE_ ε ◎ To get the value of an entry in an ordered map map given a key key: • Assert: map contains key. • Return the value of the entry in map whose key is key.

  【 原文では、 表明を通して，［ %M が該当する`~entryを包含して$いない場合には、 この~algoは利用し得ない ］ものと定義されているが （すなわち、 この演算を利用する前に，該当する`~entryを包含して$いることを確保する必要がある）、 和訳では，これに意図的に従わず、 ε を返すものと定義を改める — したがって、 `~entry$の`値$mapは ε をとり得ないことになる。 】

  `値を取得する$は、 ~indexing構文でも表記できる — 当の~mapの直後に角括弧で括られた`~key$mapを供することにより。 ◎ We can also denote getting the value of an entry using an indexing syntax, by providing a key inside square brackets directly following a map.

  ~IF［ %M[ `test^l ] ~NEQ ε ］ ⇒ ~RET %M[ `test^l ] ◎ If map["test"] exists, then return map["test"].

• `有順序~map$ %M 内の `~key$map %K に対応する `値を設定する@ ときは、 所与の値 %V に対し：

  1. `~Assert$： %V ~NEQ ε
  2. ~IF［ %M[ %K ] ~NEQ ε ］ ⇒ %M 内の［ %K を`~key$mapとする`~entry$ ］の`値$map ~SET %V
  3. ~ELSE ⇒ %M の末尾に新たな`~entry$ ( %K → %V ) を追加する

  この演算は、 “ %M[ %K ] ~SET %V ” とも表記される。 【和訳では、もっぱら，この表記を利用している。】

  ◎ To set the value of an entry in an ordered map to a given value is to update the value of any existing entry if the map contains an entry with the given key, or if none such exists, to add a new entry with the given key/value to the end of the map. We can also denote this by saying, for an ordered map map, key key, and value value, "set map[key] to value".

• `有順序~map$ %M から 所与の %条件 に合致する `~entryを除去する@ ときは ⇒ %M 内の［ %条件 に合致する`~entry$ ］すべてを %M から除去する （合致するものが無ければ何もしない）

  “ %M[ %K ] ~SET ε ” という表記は、 %M から条件［ %K を`~key$mapとする ］に合致する`~entryを除去する$ことを~~意味する。 【これは、和訳に特有な表記法である。】

  ◎ To remove an entry from an ordered map is to remove all entries from the map that match a given condition, or do nothing if none do. If the condition is having a certain key, then we can also denote this by saying, for an ordered map map and key key, "remove map[key]".
• `有順序~map$ %M を `~clearする@map ときは ⇒ %M からすべての`~entry$を除去する ◎ To clear an ordered map is to remove all entries from the map.

• `有順序~map$ %M が `~key$map %K を伴う `~entryを包含して@ いるとは、［ %K を`~key$mapとする`~entry$ ］が %M 内に存在することをいう。

  この条件は、 `値を取得する$ときの表記を利用して “ %M[ %K ] ~NEQ ε ” と記しても同じなので，そう表記されることもある （ “ %M[ %K ] ~EQ ε ” は、 その否定を表すことになる）。 【これは、和訳に特有な表記法である — 実際には、ほとんどの箇所で，この表記法が利用される。】

  ◎ An ordered map contains an entry with a given key if there exists an entry with that key. We can also denote this by saying that, for an ordered map map and key key, "map[key] exists".

• `有順序~map$ %M から `~key群を取得する@ ときは：

  1. %S ~LET 新たな`有順序~集合$
  2. %M を成す `~EACH$map( `~entry$ %K → %V ) に対し ⇒ %S に %K を`付加する$set
  3. ~RET %S
  ◎ To get the keys of an ordered map, return a new ordered set whose items are each of the keys in the map’s entries.

• `有順序~map$ %M から `値~群を取得する@ ときは：

  1. %L ~LET 新たな`~list$
  2. %M を成す `~EACH$map( `~entry$ %K → %V ) に対し ⇒ %L に %V を`付加する$
  3. ~RET %L
  ◎ To get the values of an ordered map, return a new list whose items are each of the values in the map’s entries.
• `有順序~map$ %M の `~size@map （ `size^en ）は、 次の結果の`~size$とする ⇒ %M から`~key群を取得する$ ◎ An ordered map’s size is the size of the result of running get the keys on the map.
• `有順序~map$ %M が `空@map （ `empty^en ）であるとは、［ %M の`~size$map ~EQ 0 ］を満たすことをいう。 ◎ An ordered map is empty if its size is zero.
• `有順序~map$ %M を順に `反復する@map ときは、 “ %M を成す`~EACH$map( `~entry$ %K → %V ) に対し：” という句の下で，後続な注釈文にて［ %K, %V ］に対し演算する。 【和訳に特有な規約は、~list用の`反復する$を見よ。】 ◎ To iterate over an ordered map, performing a set of steps on each entry in order, use phrasing of the form "For each key → value of map", and then operate on key and value in the subsequent prose.

• `有順序~map$ %M を `~cloneする@map ときは：

  1. %~clone ~LET 新たな`有順序~map$
  2. %M を成す `~EACH$map( %~key → %値 ) に対し ⇒ %~clone[ %~key ] ~SET %値
  3. ~RET %~clone

  ◎ To clone an ordered map map is to create a new ordered map clone, and, for each key → value of map, set clone[key] to value.

  注記： ［ `~key$map, `値$map ］自身は~cloneされないので、 これは “浅い~clone” である。 ◎ This is a "shallow clone", as the keys and values themselves are not cloned in any way.

  %M は`有順序~map$ «[ `a^l → « 1, 2, 3 », `b^l → «» ]» とする。 %M を`~cloneする$と，新たな`有順序~map$ %~clone が作成される。 %~clone[ `a^l ] ~SET « −1, −2, −3 » とした場合、 %~clone は «[ `a^l → « −1, −2, −3 », `b^l → «» ]» になるが， %M は変化しない。 しかしながら， %~clone[ `b^l ] に 4 を`付加する$と、 %~clone, %M 両者とも対応する`値$mapは — 同じ`~list$を指しているので — 改変されることになる。 ◎ Let original be the ordered map «[ "a" → «1, 2, 3», "b" → «» ]». Cloning original creates a new ordered map clone, so that setting clone["a"] to «-1, -2, -3» gives «[ "a" → «-1, -2, -3», "b" → «» ]» and leaves original unchanged. However, appending 4 to clone["b"] will modify the corresponding value in both clone and original, as they both point to the same list.

5.3. 構造体

`構造体@ （ `struct^en ）は、 仕様~levelの型である。 その各~instanceは、 有限~個の `~item@sct （ `item^en ）たちが成す集合であって，各`~item$sctには［ 一意, かつ変異-不能 ］な `名前@sct （ `name^en ）がある。 各`~item$sctは、 ある定義-済みな型を伴う値を保持する。 ◎ A struct is a specification type consisting of a finite set of items, each of which has a unique and immutable name. An item holds a value of a defined type.

【 各~名前には対応する値があることにおいて，`有順序~map$に似るが、 `~key$mapにあたる`名前$sctたちが成す集合は固定的になる。 】