<div dir="ltr">Paul, I fully agree with your reasoning. Historically speaking.<div><br></div><div>But perhaps we should now enter the realm of the language wars :). I am used in Ada to call a spade a spade. and I have found that is for good reasons: It stops me from being stupid.</div><div><br></div><div>Here is an existing example in the RISC distribution:</div><div>At the moment in ORG.Mod a filename is defined as:</div><div><br></div><div>name: ORS.Ident;<br></div><div><br></div><div>in ORS.Mod ident is defined as </div><div><br></div><div> TYPE Ident* = ARRAY IdLen OF CHAR;<br></div><div><br></div><div>and IdLen is then ultimately defined as 32 . And in an obvious place too, where it is easily changed by the unaware. And it does not say there, that it effects the length of a file name.</div><div><br></div><div>So excuse my french, but to me this is an unholy mess only for the sake of not exposing FileDir.</div><div><br></div><div>And the good news is that we only need to add 1 line to Files.Mod to alleviate this type confusion:</div><div><br></div><div>TYPE FileName* = FileDir.FileName;</div><div><br></div><div>Now all of a sudden we can work in some reasonable typesafe way. I understand that the system can still be abused, </div><div>but at least now the obvious thing to do is right there in Files.mod.</div><div><br></div><div>End of suggestion.</div><div><br></div><div>2. Question:</div><div>I see that the 'numerical' CASE implementation is missing in ORP.Mod, although it is in the language spec and although we might reasonably expect people to port programs from O2 to O7.</div><div><br></div><div>Would it be in the interest of the community for me to try and implement that part, at least for constant labels?</div><div><br></div><div>I am aware that 1. a table driven CASE might take up some codespace and 2. that coding it as an IF THEN ELSIF THEN</div><div>will bring no speed advantage. But at the same time there are many instances where a CASE statement is easy to write and convenient to read.</div><div><br></div><div>3. Question:</div><div>Why does the numerical CASE have no ELSE part anymore in O7. It is a very convenient error catcher. (i.e. when not all cases are catered for, the program does not silently fall through without warning.)</div><div><br></div><div>Cheers,</div><div><br></div><div>j.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 5, 2015 at 11:15 PM, Paul Reed <span dir="ltr"><<a href="mailto:paulreed@paddedcell.com" target="_blank">paulreed@paddedcell.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jan,<br>
<span class=""><br>
> But it seems that the FileDir symbolfile is missing in the Risc image.<br>
> I dumped the strings in the image, but it is not to be found.<br>
<br>
</span>The downloadable image is intended to be as small as reasonably possible,<br>
obviously other things may be added to the system e.g. by compiling, but<br>
they will differ depending on who you are and what you want to do.<br>
<span class=""><br>
<br>
> At the same time I like to have it available so a FileDir.FileName can be<br>
> specified as just that.<br>
<br>
</span>If you haven't already (or if you're like me, even if you have!), you<br>
should definitely read Chapter 7 of the book carefully and then decide if<br>
you still want to do this.<br>
<br>
As the chapter points out, Files is the user filesystem API, accepting,<br>
for example, strings as filenames (and checking them).  Conversely,<br>
FileDir exposes the innards to system programmers only, and uses<br>
fixed-length filename structures which often also appear on-disk.<br>
<br>
Hence you probably don't want to propagate FileDir internals (or data<br>
structures based on them) down (up) the module hierarchy.<br>
<br>
Without knowing what you want to do, I hope that at least helps a bit.<br>
<br>
Cheers,<br>
Paul<br>
<br>
<br>
</blockquote></div><br></div>