String implementation questions.

[llothar]

I tried it and found out that explicit typing of manifest strings
seems not to work.

hello is
local
a: STRING_8
b: STRING_32
do
a := {STRING_8} "bar"
b := {STRING_32} "foo"
end

Is not implemented in Eiffel Studio 6.4 - is it just not implemented
or is the chapter in ETL3 out of date?

Also i wonder how the once notation is written correctly, couldn't
find this in ETL3 too:

b := once {STRING_32} "foo"
b := {STRING_32} once "foo"

And by the way, i would suggest to add an additional rule that

b := {POINTER} "foo"

is allowed to generate a c string pointer without creating an eiffel
object first. For example if you integrate a script language
interpreter in your program this can kill performance significantly. I
even implemented a

b := raw "foobar"

in my eiffel for this purpose.

[Martin Piskernig]

llothar wrote:
> a := {STRING_8} "bar"
> b := {STRING_32} "foo"

> Is not implemented in Eiffel Studio 6.4 - is it just not implemented
> or is the chapter in ETL3 out of date?

According to 8.29.3 in the standard this is ought to work, I think.

btw: EiffelStudio 6.5 was already released on december 8th and it has many
improvements over 6.4 in the compiler, too.

> Also i wonder how the once notation is written correctly, couldn't
> find this in ETL3 too:
>
> b := once {STRING_32} "foo"
> b := {STRING_32} once "foo"

A once string is definitely of the form (8.28.1) "once Manifest_string" and
Manifest_string does not have a manifest type. So according to the standard
both your lines are standard-invalid syntax.

Martin

[llothar]

On 20 Dez., 22:41, llothar <scholz.lot...@gmail.com> wrote:

Oh i forgot one more question:
Is it allowed to put manifest strings into read only memory.

[Emmanuel Stapf [ES]]

On 12/20/2009 1:41 PM, llothar wrote:
> Is not implemented in Eiffel Studio 6.4 - is it just not implemented
> or is the chapter in ETL3 out of date?

The issue is that no specification of what encoding should Eiffel source
code be in. As a consequence we do not yet support the syntax, and
instead one has to rely on conversion.

b: STRING_32

b := "foo"

> Also i wonder how the once notation is written correctly, couldn't
> find this in ETL3 too:
>
> b := once {STRING_32} "foo"
> b := {STRING_32} once "foo"

Actually the standard does not allow it, since the syntax is `once
Manifest_string' and `Manifest_string' is not typed. It is clearly an
oversight. I would expect

b := once {STRING_32} "foo"

to be the proper syntax.

> And by the way, i would suggest to add an additional rule that
>
> b := {POINTER} "foo"
>
> is allowed to generate a c string pointer without creating an eiffel
> object first. For example if you integrate a script language
> interpreter in your program this can kill performance significantly. I
> even implemented a
>
> b := raw "foobar"

In the meantime, without having to resort to this addition, you can
simply define your own POINTER constants. Isn't it what you are supposed
to do in practice, always use symbolic names and not hard coded constants?

> Is it allowed to put manifest strings into read only memory.

Eiffel has no notion like that. Nevertheless in EiffelStudio, you can
define IMMUTABLE_STRING_X that are equivalent of read only memory. There
is even discussion at the ECMA committee to make the `Manifest_string'
type immutable by default.

Regards,
Manu

[llothar]

> The issue is that no specification of what encoding should Eiffel source
> code be in. As a consequence we do not yet support the syntax, and
> instead one has to rely on conversion.

Why not add a simple option in the ACE file?

I also wonder why you haven't defined a STRING_16. It is native
in .NET, Java, MacOSX and Windows. Everyone who is talking about the
problem with surrogate characters seem to not have understood Unicode
and text processing at all. Linguistic text processing just doesn't
work on a character level - so it doesn't matter if you have
CHARACTER_32 or two CHARACTER_16 if the context for an operation spans
multiple glypth anyway.

> >           b := raw "foobar"
>
> In the meantime, without having to resort to this addition, you can
> simply define your own POINTER constants. Isn't it what you are supposed
> to do in practice, always use symbolic names and not hard coded constants?

Well they make sense for numeric constants but not really for strings
when the string literal is already using a valid "readable" meaning
and especially is only used in one context. For example you gain
nothing when using

script.call(script_my_function) over script.call
({POINTER}"my_function")

And since when can i declare a

script_my_function: POINTER is "my_function"

Yeah i can use variables and add the pointers in a creator function
but this is even more terrible duplication of code. Once you read a
few hundert constants even the most uncomplaining user starts hating
you.

Something is missing here.

[Ulrich Windl]

llothar <scholz...@gmail.com> writes:

>> The issue is that no specification of what encoding should Eiffel source
>> code be in. As a consequence we do not yet support the syntax, and
>> instead one has to rely on conversion.
>
> Why not add a simple option in the ACE file?

I think it should be in some of the structuring comments as well. Just
in case someone wants to print a file outside of the development studio.

>
> I also wonder why you haven't defined a STRING_16. It is native

I wonder: How well would "UTF-8" work in a STRING_8? Do we actually need
a "locale-aware STRING" instead? I mean putting UTF-16 in a STRING_16
will prbably not make comparisons correct, would it?

The Eiffel heritage seems to be: "Assume there is only US-ASCII, and put
our head in the sand if something else comes around."

[...]

Regards,
Ulrich