Re: OK what does ` mean - seriously seems to be not documented.
- Posted by jimcbrown (admin) Apr 23, 2014
- 3404 views
I am sorry that this started a war.
How is one supposed to talk to you if a simple question starts a war?
The deleted posts thread ( http://openeuphoria.org/forum/m/124091.wc ) had nothing to do with you and was not your fault, nor did it start a "war".
Please do not be afraid to ask questions. We'll do our best to answer them here.
My problem with raw strings aka '`' aka `"""` has not been properly addressed. It is extremely unclear what the purpose of raw strings is in Eu given that they cannot be text (they need to be read in as source and interpreted).
That's just plain wrong. They're text. There's no interpretation of escape codes or anything like that.
Because they cannot contain '`' and `"""`
Raw strings using the backquote can contain the triple double quote within them.
Raw strings using the triple double quote can contain the backquote within them.
The triple double quote form is more common, as one is more likely to need to a single character (the backquote) than the same three characters in a row (the triple double quote). The point though is that if your text needs to include one of those two things, you can use the other raw string form to handle it.
raw strings cannot contain `"""`
Granted. This is the price for handling things as raw text, with no interpretation.
I suppose, if you really needed it, we could add a triple single quote raw string form.
This is really my question. Given that `"$,"` is not just some hacky back-end stuff allowing you to say "these characters" what is the point?
Actually, that's all it is.
It seems they can be read as source, they could be written as data, but they are really only strings and have no separate existence.
The raw string format is not really meant to represent raw Euphoria code or anything like that. The primary use in Euphoria's implementation and stdlib has been for help screens and the like, where a screenful of text that doesn't really ever change is displayed.
It just happens to be easier to do:
constant helptext = """ This is your multi-line help text. Some commands here. And even more detail here. """
instead of
constant helptext = "This is your multi-line help text.\n" & "Some commands here.\n"& "\n"& "And even more detail here.\n"
Eu raw strings remove carriage returns and therefore are of limited use as regex source on Windows.
The documentation say nothing about purpose except as being multi-line - but if they do not do carriage returns then how useful are they?
I sense this is really the main issue you are having. What's going on is that the operating system libraries for Windows below Eu strip off the carriage returns before handing the source code to Eu. So the raw string is only as raw as the OS will allow. I can see the C library imposing other limitations (e.g. no null characters). We could probably work around this by opening everything in binary instead of text mode.
Even so, we might want to add a with-statement option to control this behavior, as most of the time, if your Euphoria source code is stored in DOS CR-LF format, and you are only using raw strings for help text and such, you actually do want to strip the carriage returns out before displaying that text on the screen.
I'd like to blame M$ for this non-sense. On the PDP systems where C was born, binary mode meant reading a file one byte (9bits) at a time, whereas text mode meant reading a file one word (18bits) at a time. IIRC this was because files were actually writen to disk and stored in word-sized units instead of byte-sized units. So if you opened a file in text mode, it would sometimes pad the data with nulls. Binary mode was a way to see the raw file without padding if you needed to for some reason.
On the computers where MS-DOS ran on, files were stored in byte-sized units, so there's no need to do this. Same is true on modern unix systems, so today POSIX says that binary and text mode have no difference. However, M$ had this terrible idea of presenting text to programs using the unix text file format (newlines only), but storing it on disk in CRLF format. So text mode got you the file in unix text format (stripping out and inserting carriage returns behind the scenes) and binary format got you what the file actually looked like on disk.
I don't know why this decision was made, but the only suggestion I've heard is that some early serial printers allowed you to send a text file down the serial port, but you had to add in the carriage return in addition to the linefeed/newline or else the line would move down but the column wouldn't reset (so the next line could start in the middle or even at the end of the line, for example). Anyways, modern printers generally don't let you do that anymore and now that bad decision is still causing problems today.
