Re: best way to handle long strings!?

Re: best way to handle long strings!?

[Jacob Sparre Andersen]

Jonas wrote:

> for example: for a texteditor or sourceditor is it usefull to use the
> unbounded strings? and to put all lines in one string? or is there a
> better method to handle this?

I would certainly consider to use a data structure, which 
reflects the data better than just one long string. If you 
are going to edit Ada source code, which is line based, some 
kind of table/list/array of lines will probably make more sense.

Greetings,

Jacob
-- 
      My brain needs a "back" button so I can
          remember where I left my coffee mug.

Re: best way to handle long strings!?

[Robert Dewar]

jonas.gasser@dataflow.ch (drmed) wrote in message news:<c923f575.0208150903.5ac6b098@posting.google.com>...
> hi,
> 
> for example: for a texteditor or sourceditor is it usefull to use the
> unbounded strings? and to put all lines in one string? or is there a
> better method to handle this?


Putting all the data in one long unbounded string is a
perfectly frightful choice. Almost anything else would
be better.

Re: best way to handle long strings!?

[AG]

"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

Pardon me? Ada "line based" ?

Re: best way to handle long strings!?

[Robert Dewar]

"AG" <ang@xtra.co.nz> wrote in message news:<1oF79.6034$hk3.1116470@news.xtra.co.nz>...
> "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
> 
> Pardon me? Ada "line based" ?


I think it is fair to call Ada line based

Pragmatically, of course Ada sources are files of lines.

The standard talks of line breaks, and suggests laying
out the source in a definite line oriented manner.

Furthermore, RM 2.2(2) says

  The text of a compilation is divided into lines.

So I think the Pardon me? here is quite uncalled for :-)

Re: best way to handle long strings!?

[AG]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0208181653.5e16fc05@posting.google.com...
> "AG" <ang@xtra.co.nz> wrote in message
news:<1oF79.6034$hk3.1116470@news.xtra.co.nz>...
> > "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
> >
> > Pardon me? Ada "line based" ?
>
>
> I think it is fair to call Ada line based
>
> Pragmatically, of course Ada sources are files of lines.

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?

>
> The standard talks of line breaks, and suggests laying
> out the source in a definite line oriented manner.
>
> Furthermore, RM 2.2(2) says
>
>   The text of a compilation is divided into lines.
>

However, the 2.2(1) says:
"The text of each compilation is a sequence of separate
lexical elements. Each lexical element is formed from a
sequence of characters, and is either a delimiter, an identifier,
a reserved word, a numeric_literal, a character_literal,
a string_literal, or a comment. The meaning of a program
depends only on the particular sequences of lexical
elements ..."

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?

> So I think the Pardon me? here is quite uncalled for :-)

Sorry, I didn't mean it in any sort of offensive meaning.
Just an expression of my personal surprise (for which
I beg your pardon :-)

Re: best way to handle long strings!?

[Jacob Sparre Andersen]

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.

> 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.

Jacob
-- 
"Hungh. You see! More bear. Yellow snow is always dead
  give-away."

Re: best way to handle long strings!?

[AG]

"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 ...

Re: best way to handle long strings!?

[Bruce or Tracy Jacobs]

Just a side note - if you use Booch Unbounded String, you will have to 
dimension an initial string.  If you need a string that is larger, and 
end up having to dimension another sting and copy the original string
to the new string, be sure to deallocate the memory of the original 
string.  

We ran into problems at work where the original coder forgot to free
the original string when he had to get a longer string allocation, 
and we ran out of physical memory.  

At lease, the version of unbounded string we use has to be "free'ed".  

Bruce

Robert Dewar wrote:
> 
> jonas.gasser@dataflow.ch (drmed) wrote in message news:<c923f575.0208150903.5ac6b098@posting.google.com>...
> > hi,
> >
> > for example: for a texteditor or sourceditor is it usefull to use the
> > unbounded strings? and to put all lines in one string? or is there a
> > better method to handle this?
> 
> Putting all the data in one long unbounded string is a
> perfectly frightful choice. Almost anything else would
> be better.

Re: best way to handle long strings!?

[Robert Dewar]

Bruce or Tracy Jacobs <bljacobs2@mchsi.com> wrote in message news:<3D67A8C0.FB045D7E@mchsi.com>...
> Just a side note - if you use Booch Unbounded String

Don't! It is obsolete
Use Ada.Strings.Unbounded
and you do not have to worry about reallocating and copying

Re: best way to handle long strings!?

[Vincent Marciante]

Robert Dewar wrote:
> 
> Bruce or Tracy Jacobs <bljacobs2@mchsi.com> wrote in message news:<3D67A8C0.FB045D7E@mchsi.com>...
> > Just a side note - if you use Booch Unbounded String
> 
> Don't! It is obsolete
> Use Ada.Strings.Unbounded
> and you do not have to worry about reallocating and copying

I agree that for unbounded sequences of characters,
Ada.Strings.Unbounded would probably be better:  It
was designed specificly for that type of sequence.

However, the original Booch string components are
not obsolete.  They are generic and can be instantiated
to provide unbounded sequences of nonlimmited elements,
not just sequences of characters!

(The Ada95 Booch Components do not provide any "string"
components, thats how I know that original poster must
be refering to The Original Booch Components.)

Re: best way to handle long strings!?

[Simon Wright]

Vincent Marciante <marciant_remove@earthlink.net> writes:

> (The Ada95 Booch Components do not provide any "string"
> components, thats how I know that original poster must
> be refering to The Original Booch Components.)

Yes, no pressing need for string support given it's in the language
now.