<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Chris</div><div><br></div><div>Just realized the using the second rule in this definition</div><div>
<div class="page" title="Page 2">
<div class="layoutArea">
<div class="column">
<p><span style="font-size: 10.000000pt; font-family: 'ArialMT'"> string = """ {character} """ | digit {hexdigit} "X" . </span></p>
</div>
</div>
</div>makes your code non-portable.</div><div><br></div><div>The expression ("a" = 61X) is TRUE in one implementation and FALSE in another.</div><div><br><div>Jörg</div></div><div><div><br></div>Am 09.07.2016 um 08:34 schrieb Jörg Straube <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>>:<br><br></div><blockquote type="cite"><div><span>Chris</span><br><span></span><br><span>Indeed, you're right the Oberon-07 report allows for any charcter coding as the formulation "ordinal value" (of type INTEGER) is quite open. Even EBCDIC would do.</span><br><span>One small remark though, the Oberon EBNF is not complete as the rule "character" (used in the definition of "string") is not defined.</span><br><span></span><br><span>The ProjectOberon implementation supports CHAR in the range 0X to 7FX.</span><br><span></span><br><span>If the implementation decides for Unicode you should probably take UTF-32 as internal representation of CHAR, and INTEGER has to have at least 32 bit. If you would take UTF-16 or UTF-8 the rather simple ch := s[5] get's quite complicated to implement.</span><br><span>If you restrict yourself to Unicode BMP (no emoji), UTF-16 will do and INTEGERs can have 16 bit.</span><br><span></span><br><span>Jörg</span><br><span></span><br><span>Am 09.07.2016 um 04:03 schrieb Chris Burrows <<a href="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>>:</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>-----Original Message-----</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">mailto:oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Jörg Straube</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Sent: Saturday, 9 July 2016 5:06 AM</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>To: ETH Oberon and related systems</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Cc: <a href="mailto:paulreed@paddedcell.com">paulreed@paddedcell.com</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Subject: Re: [Oberon] CHAR to/from BYTE conversion</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Don't open that can of worms :-)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>- Should LEN(s) return the number of characters in s (logical length)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>or the number of bytes of s (physical length)?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Neither.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>LEN is the number of elements of an array. An array declared as </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> VAR s: ARRAY 12 OF CHAR </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>will always have 12 elements no matter how long the string is that is currently stored in the array. </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>LEN("abc") = 4 (* including the terminating NULL character *)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>s := "abc";</span><br></blockquote><blockquote type="cite"><span>LEN(s) = 12</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Similarly for an array declared as</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> VAR a: ARRAY 12 OF INTEGER</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>LEN(a) = 12.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>SYSTEM.SIZE will give you the number of bytes allocated to a variable. SYSTEM indicates that the value that SIZE returns is implementation-dependent.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The length of a string is the number of characters up to but not including the null terminating character. The longest string that can be stored in the array s where LEN(s) = 12 is 11 characters.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>- shoudn't the type CHAR better be called "ASCII"?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>No. Since 2013 the Oberon Report has not required it be Latin-1 / ASCII. CHAR is now defined as 'the characters of a standard character set'. </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>- As Unicode characters need up to 32 bit, should CHAR be 32 bit?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>There is nothing stopping an implementer of Oberon from defining characters as 32-bit (or 16-bit for that matter) items if they wanted it to be used to develop applications that required a character set other than ASCII.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Strings are quite tricky, especially a compact internal</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>representation of them.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>True.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Regards,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Chris Burrows</span><br></blockquote><blockquote type="cite"><span>CFB Software</span><br></blockquote><blockquote type="cite"><span><a href="http://www.astrobe.com">http://www.astrobe.com</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Am 08.07.2016 um 20:50 schrieb Skulski, Wojciech</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:skulski@pas.rochester.edu">skulski@pas.rochester.edu</a>>:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>That means both CHAR and BYTE holds values 0 to 255.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>No, CHAR holds characters, 0X to 0FFX, including "A", "B" etc.;</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>BYTE holds 0 to 255, a sub-range of the INTEGER range.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Your statement is indicative of how much damage C has done to the</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>world :)</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Characters should not be just English characters.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Your statement is indicative of how much damage ASCII has done to</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>world :)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>W.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>--</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>systems <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>--</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>systems <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>--</span><br></blockquote><blockquote type="cite"><span><a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems</span><br></blockquote><blockquote type="cite"><span><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a></span><br></blockquote></div></blockquote></body></html>