gmane.comp.lang.eiffel.smalleiffel

non-expanded external type

Paolo Redaelli — 2008-11-30T22:52:13

I was playing with external type example wondering what's the indetended usage of non-expanded external type. Current snapshot tells me that: "Classes with an external type must be expanded or deferred." I naively put together a little example to test non-expanded external classes that I have attached here. Is there any documentation about those types? The wiki page on external types is not helpful to me. Thanks in advance Paolo

Re: exit code of "se test"

Raphael Mack — 2008-11-25T20:27:28

Hi, Am Montag, den 24.11.2008, 22:33 +0100 schrieb Philippe Ribet: Thanks. This is encouraging. Here is a patch against r9294, but actually this does not completely satisfy me: We have simple test cases that essentially look like: class TEST_FEATURE1 inherit EIFFELTEST_TOOLS creation make feature make is do assert(1 = 2) end end -- class TEST_FEATURE1 This is very simple to create and I like it. But compiling and running this also does has an exit code of 0. Now I see three solutions: 1. adapt the test: make is local exit_code: INTEGER do assert(1 = 2) if 1 /= 2 then exit_code := 1 end die_with_code(exit_code) end 2. adapt EIFFELTEST_TOOLS: call die_with_code(1) at the end of label_assert 3. adapt EIFFELTEST_TOOLS and the test - add a failed_counter (similar to assert_counter) to EIFFELTEST_TOOLS which is incremented for each failing assertion and a feature exit_code: INTEGER which returns 1 if failed_counter > 0 - adapt the test to make is do assert(1 = 2) die_with_code(exit_code) end All versions have pros and cons. I'd prefer 2 or 3. Cheers, Rapha

Re: exit code of "se test"

Philippe Ribet — 2008-11-24T21:33:12

You're right, return code should reflect the test status. I can commit the patch. Best regards,

Re: exit code of "se test"

Raphael Mack — 2008-11-24T16:34:08

Hello, PLEASE comment on this. Would it be possible to get a patch commited, if I'd prepare one? What do other users (are there any) think? Thanks, Rapha Am Sonntag, den 19.10.2008, 11:01 +0200 schrieb Raphael Mack:

Re: A proposal for NATURAL syntax

2008-11-19T07:45:14

Speaking as a reader, I find the above much more readable and no more verbose or cumbersome than

A proposal for NATURAL syntax

Paolo Redaelli — 2008-11-18T08:15:52

I have a little proposal for NATURALs. People coming from other languages will find code like n8 := 1.to_natural_8 n16 := 1.to_natural_16 n32 := 1.to_natural_32 n64 := 1.to_natural_64 a little "verbose" or cumbersome to use. Someone could also wonder if such a syntax will be "optimized away" by the compiler either Eiffel or C. Chances are high that an unoptimized implementation will allocate an unnecessary temporary integer on the stack. I would like to propose a tentative syntax for Gnu-Eiffel that could look like: n8 := {NATURAL_8 1} n16 := {NATURAL_16 1} n32 := 1U n64 := {NATURAL_64 1} People reading code find "perfectly natural" to infer the type of an integer constant "from the context"; we have already lengtly discussed why inferring the type of an object from its context is not good for program clarity or even The proposal for 8,16 and 64 bit naturals is modelled after the usual in-place creation of objects. Syntax for 32bit is inspired from both C and SmartEiffel unicode string syntax. In fact declares things like: # define UINT32_MAX (4294967295U) As such a number does not fit an int. This C header also uses a low-level syntax like ours, in a form like this: # define INT64_MAX (__INT64_C(9223372036854775807)) C is also declaring the type of a constant together with its value, taking the same path of SmartEiffel but hiding it from the casual C programmer. As 64-bit processor is becoming really widespread I suggest to conceive a shorter notation also for 64 bit values. A generic solution could be valueUlength hence having n8 := 1U8 n16 := 1U16 n32 := 1U -- or 1U32 n64 := 1U64 Knowing that in a not-too-far future we could change the default when the length is not specified from 32 to 64 bit values. I find this particularly tricky. Perhaps it would be wiser to avoid a default length at all. At least it will make programmer conscious of the precision and resolution of the values they are using. Paolo who started programming on a Commodore 64 where "int" is 8bit....

Unicode characters

Paolo Redaelli — 2008-11-18T07:52:38

I've read Glib section for Unicode. As far as I can understand Unicode characters are unsigned 32 bit values. Currently UNICODE_STRING actually uses signed values. AFAIK the occurrences of INTEGER_32 referring to character codes shall be changed to NATURAL_32. Is it right? Thanks in advance for your attention Paolo

Source code encoding

Paolo Redaelli — 2008-11-17T15:41:17

Is the following correct? Gnu-Eiffel source-code is expected to be encoded either ASCII UTF8. In case of UTF8 encoding all non-ASCII characters shall be enclosed into comments or in string manifest bodies. I fear there are some glitches in the previous sentence, in fact: ======= class US -- i.e. Unicode String creation make feature make is do stampa(U"Tànti èuri: 1000€".as_utf8) stampa("Tànti èuri: 1001") end stampa (s: STRING) is local i: INTEGER do print("Printing '"+s+"' character-by-character:%N") from i:=s.lower until i>=s.upper loop std_output.put_character(s< at >i) std_output.put_character('-') i:=i+1 end std_output.put_new_line end end ======= When compiled produce: paolo< at >laboratorio:~/tmp$ compile us && ./a.out Printing 'Tànti èuri: 1000€' character-by-character: T-�-�-n-t-i- -�-�-u-r-i-:- -1-0-0-0-�-�- Printing 'Tànti èuri: 1000' character-by-character: T-�-�-n-t-i- -�-�-u-r-i-:- -1-0-0- paolo< at >laboratorio:~/tmp$ file us.e us.e: UTF-8 Unicode C++ program text Is this behaviour the intended one? Thanks in advance for your attention Paolo

Re: conversion STRING to REAL_32

Raphael Mack — 2008-11-16T19:17:08

Hi, are there any comments from the se team on this? Thanks in advance, Am Sonntag, den 19.10.2008, 13:17 +0200 schrieb Raphael Mack:

Re: Unicode source code?

Cyril ADRIAN — 2008-11-04T20:44:53

Hi Paolo, On Tue, Nov 4, 2008 at 10:30 AM, Paolo Redaelli poste.it>wrote: Java has allowed it since the beginning. But I never saw anything written otherwise than with standard ASCII7 alphanum, except in comments. The reason, I guess, is twofold: (but then, maybe I'm biased) 1- our keyboards do not allow to easily input greek or in general non-ascii characters, so entering something that's not ascii is usually cumbersome. 2- anyway most people tend to write code in English; I do, because doing otherwise disrupts the thought process with complex inter-language translations. In countries with other alphabets than latin maybe inputting something in their own language may be more straightforward... But is Unicode widespread? Or other different "code pages"? At the office I currently work with Chinese people overseas, and even though I never saw their keyboards they seem to be able to enter ASCII characters quite easily. We share screens and work on code together, and the only latency is the network, not the typing speed. Well, I don't know if it is worth it... But I have no strong opinion either way. Just my 2 cents... Best regards,

Unicode source code?

Paolo Redaelli — 2008-11-04T09:30:59

I'm still working - in the few spare time that real life leaves me - on eiffel-gcc-xml. I'm updating it to work with latest SmartEiffel snapshots and to produce low-level wrappers that uses the plug-in mechanism. I noticed that XML_COMPOSITE_NODE "took the place" of XML_NODE and that attributes names and values are now Unicode strings. So my question is: can Eiffel source code be encoded in Unicode? If - as I suspect - it is not the case what's the preferred encoding? Since we are handling the XML representation of a C/C++ program/library I think that something as naive as print((U" arbitrary Unicode string from GCC-XML output").as_utf8) could be fine since it would end up producing ASCII with almost any conceivable output of gccxml. I already checked that UTF8 in comments is easily digested by compiler. Since I'm writing about encoding of SmartEiffel source file I would like to open a little discussion about a question that has been puzzling me for a while. I remember that in OOSC2 Meyer told that symbols like Döppleganger should not be allowed for several reasons that were agreeable and reasonable. Now I'm wondering if it is instead useful to allow Unicode source-code to allow usage of mathematical operators and Greek letters that looks "normal" to many people, for example to distinguish between scalar and dot products in matrices. It would allow to write math-dealing code is a more natural way, writing features like: infix "∋", has (an_element: like item): BOOLEAN is infix "∌", doesnt_have (an_element: like item): BOOLEAN is infix "≤", infix "<=" is infix "≥", infix ">=" infix "⨯", cross_product and so on. Also symbols like Greek letters (α,β,γ,δ,η,μ,φ) are widespread in many scientific expressions and if allowed would make code more readable than alpha,beta,gamma,delta, because expressions will be much shorter without sacrificing understandability and readability of the indended readers. I think that you will agree with me that SmartEiffel source code is meant to be read by people and only after that compiled by a computer.... Thanks in advance for your attention, Paolo PS: See Unicode from U+2200 U+22FF for math symbols. I found http://live.gnome.org/Gucharmap useful to browse Unicode symbols.

Re: Frozen STRING's infix "< at >"

Cyril ADRIAN — 2008-10-30T13:59:46

Ah, I forgot... On Thu, Oct 30, 2008 at 2:58 PM, Cyril ADRIAN gmail.com>wrote: There is *also* a technical reason. Using aliases one may redefine one and not the other, leading to unwanted discrepancies. Using one frozen feature we are sure that both features stay in sync. Best regards,

Re: Frozen STRING's infix "< at >"

Cyril ADRIAN — 2008-10-30T13:58:01

Sure, but the reason is not technical and must be sought elsewhere. In fact the origin of the separation is to produce a clearer documentation. Using Eiffeldoc it's very simple to add "See also" links, but such links are not automatically generated when there are aliases. Best regards,

Re: Frozen STRING's infix "< at >"

Paolo Redaelli — 2008-10-30T13:54:04

Il giorno Wed, 29 Oct 2008 21:15:33 +0100 "Cyril ADRIAN" gmail.com> ha scritto: Right.... then why having two separate features when frozen infix "< at >", item (i: INTEGER): CHARACTER is..... would have sufficed? See attached example... it works just as expected. < at > is frozen and item can be redefined. Paolo

Re: Frozen STRING's infix "< at >"

Cyril ADRIAN — 2008-10-29T20:15:33

Hi Paolo, On Wed, Oct 29, 2008 at 5:50 PM, Paolo Redaelli poste.it>wrote: I guess it's only because infix "< at >" must stay an alias of item. If you want to redefine infix "< at >", redefine item instead. Best regards,

Frozen STRING's infix "< at >"

Paolo Redaelli — 2008-10-29T16:50:26

Is there a particular reason to have STRING's infix "< at >" frozen? I was going to create an "easier-to-read" heir of STRING, named LINKED_STRING, useful to implement fast concatenation and fast message-formatter-like features, more or less like the attached source. The idea was to allow code like this: print(linked_string("My foo") | my_string | " is good "| another_string) or something like: print(linked_string ("inline < at >(1) < at >(2) (< at >(3) a_structure) { a_structure->< at >(4); }") # c_type # (a_structure_name+"_get_"+c_field) # structure_type # c_field)

Re: conversion STRING to REAL_32

Guillaume Lemaître — 2008-10-19T10:59:20

This should be checked, but I think REAL_64.force_to_real_32 is only a simple C cast in boost mode. 2008/10/19 Raphael Mack raphael-mack.de>:

conversion STRING to REAL_32

Raphael Mack — 2008-10-19T10:42:23

Hello, is there any feature to convert a STRING into a REAL_32? Else I suggest to add a to_real_32 in class STRING. Thanks for every comment, Rapha

Re: conversion STRING to REAL_32

Guillaume Lemaître — 2008-10-19T10:50:16

STRING.to_real.force_to_real_32 2008/10/19 Raphael Mack raphael-mack.de>:

Re: conversion STRING to REAL_32

Raphael Mack — 2008-10-19T10:57:28

Am Sonntag, 19. Oktober 2008 schrieb Guillaume Lemaître: Thanks for that workaround. But of cause this is not what I want... The only reason to use a REAL_32 and not a REAL_64 is performance, when I know, that 32 bits fit my needs for accuracy and range. So creating a temporary REAL_64 and converting this to a REAL_32 cannot be the choice. - I guess this is not optimized away by the compiler... Rapha

Re: conversion STRING to REAL_32

Raphael Mack — 2008-10-19T11:17:07

Am Sonntag, 19. Oktober 2008 schrieb Guillaume Lemaître: This is only a cast, yes. But STRING.to_real creates a REAL_64, which occupies 64 bits. Even though we have a "simple" c cast to REAL_32 then, this needs to change the binary representation from double to float. And already the to_real feature in class STRING does MANY REAL_64 operations, which are quite slow, if you do not have a FPU. And this is the case for me... so, I still suggest a feature STRING.to_real_32 (which could of cause mainly copy-pasted from STRING.to_real) I also think to_real should be renamed to to_real_64 (and have an alias to_real). Cheers, Rapha