Re: Non-Printable Characters in Strings

Luke-Jr <[email protected]> Mon, 9 Feb 2004 22:44:33 +0000
Newsgroups gmane.comp.lang.moo.general
Message-ID <[email protected]>
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 09 February 2004 08:01 pm, Gavin Lambert wrote:
> At 00:51 28/01/2004 +0000, Luke-Jr wrote:
>  >How should non-printable characters be represented in strings?
>  >Is C-style escaping of common characters (\n, \r, \t, \v, \x##,
>  >etc) a good idea? Including C-style's \### which uses octal or
>  >should \### use decimal (or hex?)?
>
> I've always regarded C-style escaping as a little messy... but
> then, that's mostly because I need to use the backslash a lot for
> paths and the like.
That's probably partially due to your operating system not using standard p=
ath=20
syntax. Most systems would use / as a directory seperator which doesn't hav=
e=20
this problem. Further, since MOO already uses the \ character for escaping,=
 I=20
wouldn't suggest breaking it. I was referring to the sequences following th=
e=20
\ character such as 'n', 'r', 't', 'x__', etc...
>
> One possible alternative (though I don't really know if it's any
> better) is to use Delphi-style escaping, a la:
>    "This is a string with"#10"a newline in the middle."
>    "This is a string with "" a double-quote in the middle."
>    "This is a string that " +
>      "spans two source lines."
With regard to the \<newline> part, I probably wasn't clear... I was thinki=
ng=20
using \<newline> as a way to insert a *literal* newline into the string, no=
t=20
as a way to continue the string on another line. Such a possiblity is an id=
ea=20
worth considering, though.
>
> Of course, the latter example is already valid in MOO code, but of
> course the internal compiler/decompiler will merge it back onto
> one source line.
I don't bother going to extreme trouble to keep compile/decompile formattin=
g=20
the same... Using my patch which renders 0xFF as an integer, for example, t=
he=20
decompiler will still output 255. To render it as 0xFF would probably requi=
re=20
adding a flag on Vars of TYPE_INT or a new TYPE_INTBASE (which has the flag=
=20
instead, but is treated as INT within the MOO), but both cases would either=
=20
use a lot of RAM and/or a lot of extentions to existing code when it's=20
probably not worth it. More important would be to preserve /* this style */=
=20
of comments which the MOO currently forgets completely, I think.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAKA1VZl/BHdU+lYMRAm91AJ9Mh1GOF44SMAHBj5RKQglYHualDwCeKeqB
swhLjeVp7XAHPM/pYcPmOPc=3D
=3DT+Qt
=2D----END PGP SIGNATURE-----


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn