Concatenation of static strings?

Concatenation of static strings?

[Erik de Castro Lopo]

Hi all,

I find myself doing things like the following:

    let print_usage () =
        print_endline
	(	"\n" ^
		"Usage : progname [options]\n" ^
		"        progname [options] <config file>\n"
		)

and wondering, when those strings are concatenated. Is that done
at compile time?

Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
The difference between a violin and a viola is that a viola
burns longer.

RE: [Caml-list] Concatenation of static strings?

[David Allsopp]

I don't know whether the compiler optimises the concatenation (it ought to,
just as constant integer arithmetic ought to be evaluated by the compiler),
but how about writing:

    let print_usage () =
        print_endline "\n\
                       Usage : progname [options]\n\
                      \        progname [options] <config file>"

Which is less typing. I use this for long SQL statements in code, as well.
Note that you must escape the first space on the line if you want any spaces
after it to count (the lexer semantics for \CR or \LF ignore whitespace at
the start of the next line).


David 

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of Erik de Castro Lopo
Sent: 19 January 2008 03:33
To: caml-list@yquem.inria.fr
Subject: [Caml-list] Concatenation of static strings?

Hi all,

I find myself doing things like the following:

    let print_usage () =
        print_endline
	(	"\n" ^
		"Usage : progname [options]\n" ^
		"        progname [options] <config file>\n"
		)

and wondering, when those strings are concatenated. Is that done
at compile time?

Cheers,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
The difference between a violin and a viola is that a viola
burns longer.

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Concatenation of static strings?

[Erik de Castro Lopo]

David Allsopp wrote:

> I don't know whether the compiler optimises the concatenation (it ought to,
> just as constant integer arithmetic ought to be evaluated by the compiler),
> but how about writing:
> 
>     let print_usage () =
>         print_endline "\n\
>                        Usage : progname [options]\n\
>                       \        progname [options] <config file>"
> 
> Which is less typing.

Ah, thats much nicer. Thanks.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"C++ : Where friends have access to your private members."
-- Gavin Russell Baker

Re: [Caml-list] Concatenation of static strings?

[David Baelde]

Nice, I didn't know about the stripping of the first whitespaces.

Speaking of static strings, the static string allocation done by OCaml
is not compatible with the mutability of strings. I've been told that
the issue was raised a long time ago, so I'm not filing this as a bug,
but since I could not find any information on the web I thought
someone here might be able to recall what motivated the decision in
former discussions. Maybe the issue is considered a little price to
pay for the optimization, since we rarely use string mutations..

The issue can be witnessed with the following code, on 3.10, either in
the interactive loop or with any compiler:

# let f () = let s = "bla" in let c = s.[0] in s.[0] <- 'c' ; c ;;
val f : unit -> char = <fun>
# f () ;;
- : char = 'b'
# f () ;;
- : char = 'c'

This is to be contrasted with arrays, which are mutable too but not
statically allocated as for strings (let f () = let s =
[|'b';'l';'a'|] in let c = s.(0) in s.(0) <- 'c' ; c).

And for Erik, a test that tells us that concatenations are not done statically:

# let f () = let s = "b"^"la" in let c = s.[0] in s.[0] <- 'c' ; c ;;
val f : unit -> char = <fun>
# f () ;;
- : char = 'b'
# f () ;;
- : char = 'b'

Cheers,

David

Re: [Caml-list] Concatenation of static strings?

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]

I was hoping there would be some follow up discussion on the code below, but
haven't seen anything yet. Can someone please clarify why this is not
considered a bug (or is it). Given that s is locally scoped within f, I do
not see why f returns different answers.

> # let f () = let s = "bla" in let c = s.[0] in s.[0] <- 'c' ; c ;;
> val f : unit -> char = <fun>
> # f () ;;
> - : char = 'b'
> # f () ;;
> - : char = 'c'



On Jan 19, 2008 5:55 AM, David Baelde <david.baelde@gmail.com> wrote:
> Nice, I didn't know about the stripping of the first whitespaces.
>
> Speaking of static strings, the static string allocation done by OCaml
> is not compatible with the mutability of strings. I've been told that
> the issue was raised a long time ago, so I'm not filing this as a bug,
> but since I could not find any information on the web I thought
> someone here might be able to recall what motivated the decision in
> former discussions. Maybe the issue is considered a little price to
> pay for the optimization, since we rarely use string mutations..
>
> The issue can be witnessed with the following code, on 3.10, either in
> the interactive loop or with any compiler:
>
> # let f () = let s = "bla" in let c = s.[0] in s.[0] <- 'c' ; c ;;
> val f : unit -> char = <fun>
> # f () ;;
> - : char = 'b'
> # f () ;;
> - : char = 'c'
>
> This is to be contrasted with arrays, which are mutable too but not
> statically allocated as for strings (let f () = let s =
> [|'b';'l';'a'|] in let c = s.(0) in s.(0) <- 'c' ; c).
>
> And for Erik, a test that tells us that concatenations are not done
statically:
>
> # let f () = let s = "b"^"la" in let c = s.[0] in s.[0] <- 'c' ; c ;;
> val f : unit -> char = <fun>
> # f () ;;
> - : char = 'b'
> # f () ;;
> - : char = 'b'
>
> Cheers,
>
> David
>
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2945 bytes --]

Re: [Caml-list] Concatenation of static strings?

[Oliver Bandel]

Zitat von Ashish Agarwal <agarwal1975@gmail.com>:

> I was hoping there would be some follow up discussion on the code
> below, but
> haven't seen anything yet.
[...]

I just read your mail...
..and it's late .... chrrzzz...


...but if I'm not completely sleepy this looks like a bug. :-(

It behaves like if s would be defined on top of the
module, but it is  local constructed in the function f.
Look sstrange... I have the same behaviour here (Debians
OCaml here is 3.09.2, and I have tried with toplevel, bytecode
and naticecode).

=> Bug reports: http://caml.inria.fr/bin/caml-bugs



Ciao,
   Oliver

Re: [Caml-list] Concatenation of static strings?

[Loup Vaillant]

2008/1/25, Oliver Bandel <oliver@first.in-berlin.de>:
> Zitat von Ashish Agarwal <agarwal1975@gmail.com>:
>
> > I was hoping there would be some follow up discussion on the code
> > below, but
> > haven't seen anything yet.
> [...]
>
> [...]
> It behaves like if s would be defined on top of the
> module, but it is  local constructed in the function f.
> Look sstrange... I have the same behaviour here (Debians
> OCaml here is 3.09.2, and I have tried with toplevel, bytecode
> and naticecode).

Ouch: this is the same as in C: the attempt to modify a statically
defined string makes bad things happen. One should try this on Open
BSD: it may even crash, if the the data segment is protected from
write. Replacing "abc" by String.copy "abc" works around this, though:

# let f () = let s = String.copy "bla" in let c = s.[0] in s.[0] <- 'c' ; c ;;
val f : unit -> char = <fun>
# f();;
- : char = 'b'
# f();;
- : char = 'b'

Pure again :-)

Cheers,
Loup

Re: [Caml-list] Concatenation of static strings?

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

I submitted a bug report.


On Jan 25, 2008 5:47 AM, Loup Vaillant <loup.vaillant@gmail.com> wrote:

> 2008/1/25, Oliver Bandel <oliver@first.in-berlin.de>:
> > Zitat von Ashish Agarwal <agarwal1975@gmail.com>:
> >
> > > I was hoping there would be some follow up discussion on the code
> > > below, but
> > > haven't seen anything yet.
> > [...]
> >
> > [...]
> > It behaves like if s would be defined on top of the
> > module, but it is  local constructed in the function f.
> > Look sstrange... I have the same behaviour here (Debians
> > OCaml here is 3.09.2, and I have tried with toplevel, bytecode
> > and naticecode).
>
> Ouch: this is the same as in C: the attempt to modify a statically
> defined string makes bad things happen. One should try this on Open
> BSD: it may even crash, if the the data segment is protected from
> write. Replacing "abc" by String.copy "abc" works around this, though:
>
> # let f () = let s = String.copy "bla" in let c = s.[0] in s.[0] <- 'c' ;
> c ;;
> val f : unit -> char = <fun>
> # f();;
> - : char = 'b'
> # f();;
> - : char = 'b'
>
> Pure again :-)
>
> Cheers,
> Loup
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 2379 bytes --]

Re: [Caml-list] Concatenation of static strings?

[Jon Harrop]

On Thursday 24 January 2008 23:02:48 Ashish Agarwal wrote:
> I was hoping there would be some follow up discussion on the code below,
> but haven't seen anything yet. Can someone please clarify why this is not
> considered a bug (or is it).

This is not considered a bug. String literals are static but array literals 
are not.

> Given that s is locally scoped within f, I do not see why f returns
> different answers. 

A static local remains the same between calls (so it is not thread-safe).

This has been discussed before several times. The reason given more making 
strings static is performance.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Concatenation of static strings?

[Oliver Bandel]

Zitat von Jon Harrop <jon@ffconsultancy.com>:

> On Thursday 24 January 2008 23:02:48 Ashish Agarwal wrote:
> > I was hoping there would be some follow up discussion on the code
> below,
> > but haven't seen anything yet. Can someone please clarify why this
> is not
> > considered a bug (or is it).
>
> This is not considered a bug. String literals are static but array
> literals
> are not.

?!

>
> > Given that s is locally scoped within f, I do not see why f returns
> > different answers.
>
> A static local remains the same between calls (so it is not
> thread-safe).
[...]

To have mutable strings, which means it's imperative, not
functional programming, is one thing.

To -- in C-langauge terms -- copy the reference,
meaning a copy of a char*, which means a pointer,
is one thing. So one can use String.copy to have
a copy of the data, which is pointed to by the pointer
(isntead of only using a pointer-copy).

Another thing is, that the local used data is
not fresh every time it is used in a newly function call.

The copy of the references is fast.
To have no newly allocated local data,
if this data is a string, IMHO is not so fine.
And I see no advantages here.
And because it's new to me (nobody is pefect ;-))
I thought this is buggy behaviour.

I looked into the reference manual and found nothing on that
topic. Such decisions IMHO should be part of the reference manual.
The thing we discussed on the Array-comparisons btw should also
be mentioned in the manual (I did not looked for it in the manual,
possibly it's already there?).


>
> This has been discussed before several times. The reason given more
> making
> strings static is performance.
[...]

I remember several discussions on mutable strings
and the string-copy problem, but I do not remember
on the problem of the allocation inside functions,
which you call static. And this two kinds of discussions
are two pairs of shoes!

If you have a pointer to theese discussions (on that "static"
thing that makes frozen local data even on several function calls)
this would be fine. It seems I have missed these discussions.

Ciao,
   Oliver