Re: best way to handle long strings!?

["AG" <ang@xtra.co.nz>]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:3D60BA20.7010007@nbi.dk...
> AG wrote:
>
> > Currently, yes. But if someone was to write
> > an Ada compiler for a paper-tape based machine
> > with no concept of a line break even? Would that
> > compiler stop being Ada?
>
> Yes, since comments are defined to be terminated by line breaks.

The comments themselves are specifically
excluded from determining the program's
meaning. So, the compiler can support
them (and EOL for them) but it will never
see either in inputs from that particular system.
This won't change the meaning of the input.

Consider a trivial source file conversion:

Remove all comments. Replace all EOLs
with a single space. Feed it to the same
compiler.

Assuming no capacity breaches (max
line length etc) the two should compile
exactly the same, correct?)

That's because by doing that you haven't
removed any program-related information.
Only the formatting/representation layer one.

You can, easily, store these two kind of
data in a separate files: One which contains
a single line of code with no comments or
tabs and just single spaces where required.
The other with all the comments and
indentation and, yes, line breaks.

In this way, compiler only cares about
the first file. The second is only needed by
your IDE or text editor or whatever
presentation layer software you use.

In fact, in a multi-user environment, each
user could have a unique presentation file
and see the code formatted (and coloured
and capitalised btw) in a way totally different
from the other users. None of this is of any
concern to the compiler or the language it
compiles.

Now contrast it with a language that says
that an "if" statement must always start on
a new line. Here, the concept of a new line
is part of a syntax that compiler must know
about - you can't hide it from it since it
wouldn't be able to compile (or get incorrect
interpretations). In this case, you can't do the
representation swap for the users since, at
least part of the representation, determines
the meaning of what you see. (This is
probably equivalent to trying to remove
spaces from Ada - as opposed to EOLs).

>
> > Also, the 2.2(2) goes on to add (after your quote) that
> > "representation for an end of line is implementation
> > defined". I'm not too sure about that one, but does it mean
> > that an implementation is allowed to *not* represent
> > the EOL at all, provided it has no problem compiling
> > the result?
>
> It is free to choose the _representation_ of the source
> code, but it has to support all the characters in ISO 8859-1.

You are assuming here that the EOL on the
target system is represented by character(s).
Or that it is, in fact, part of the source code.




[Coming back to the original quote now]

I'm afraid it is actually a bit ambiguous:

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:3D5D0D64.9070601@nbi.dk...

> If you
> are going to edit Ada source code, which is line based

I took it to mean that "Ada" is line based.
And based my replies on that assumption.

If it was meant to say that the "source code"
is line based - then it just depends on your
code editors I guess - no point in invoking
RM clauses for all the languages that could
use that system ...