Cobra Forums

Chuck wrote in Multiline strings

We haven't dealt with newlines varying between platforms. Windows is \r\n while Mac, Linux and friends are just \n.
Do we use the newline of the compiler's platform?
Or do we fetch the newline at run-time so that moving a .NET/CLR program from one platform to the other will respect the local convention?
This question also comes up for the \N proposal.

Depends if you think a major use/desire will be for multiplatform platform independant compiled apps - need a few other things before thats a reality

Using a default runtime fetch is also problematic since if you write a program that needs a specific newline string regardless of platform ( text network protocol say ) switching platform may
cause some unhappiness

I'd suggest duck and run
Allow explicit characters for the compile time (c'\N') and runtime ( c'\R' ??) platform newLine string and the individual parts (c'\n', c'\r'),
Let the developer choose what works for their app and anticipated platform deployment

Hmm - OR explicit chars for platform newline string, compiler setting or compiler directive for whether that's a compile time (compilers platform string) or a
runtime calculated option.....

OTOH worst case is its a recompile on/for the target platform(source portability) - for a commercial app paranoia dictates that you'd do that anyway...

Quick question, is there any language that is supporting implicit runtime evaluation of carriage returns?

Supporting an easy way to embed Environment.newLine could be great, but I don't think it shouldn't be the default behaviour.

If I'm embeding raw (magic) strings in the program, I'm expecting the string is encoded the same way as my source code.

edit: "should" was meant as "should'nt"

hopscc wrote:Depends if you think a major use/desire will be for multiplatform platform independant compiled apps - need a few other things before thats a reality

It's a reality today:

1 - Write a console program in Cobra on Windows XP using .NET
2 - Copy the .exe--not the source--to a Mac
3 - After installing Mono, run with "mono foo.exe"

CLR byte code is not platform specific. Neither is the format for assemblies.

You can do any kind of algorithms, data structures, networking, web, etc. you want. Ideally, you could do WinForms as well, but I haven't had good experiences running WinForms on Mac OS X 10.4 Tiger.

If I'm missing something, let me know.

hopscc wrote:Using a default runtime fetch is also problematic since if you write a program that needs a specific newline string regardless of platform ( text network protocol say ) switching platform may cause some unhappiness

Not if we use a new code like \N, and the existing codes (\n and \r) are left as is.

hopscc wrote:I'd suggest duck and run
Allow explicit characters for the compile time (c'\N') and runtime ( c'\R' ??) platform newLine string and the individual parts (c'\n', c'\r'),
Let the developer choose what works for their app and anticipated platform deployment

Hmm - OR explicit chars for platform newline string, compiler setting or compiler directive for whether that's a compile time (compilers platform string) or a
runtime calculated option.....

OTOH worst case is its a recompile on/for the target platform(source portability) - for a commercial app paranoia dictates that you'd do that anyway...

I currently favor:

-- \n and \r are treated the same way as in C# and Python. No special interpretation.
-- \N is for platform newline
-- \N adapts at run-time

For implementation, I guess that means that a string literal containing \N would be broken into "foo" + CobraCore.newLine + "bar". Interpolated strings would have to pay attention as well.

-Chuck

Chuck wrote:-- \n and \r are treated the same way as in C# and Python. No special interpretation.

Well that statement might be a little confusing when I say "No special interpretation" as the very point of \n and \r are to be interpreted as single characters. I should have just left it as:

Chuck wrote:-- \n and \r are treated the same way as in C# and Python.