{ANY}.io

7 Messages

Helmut Brandl

{ANY}.io

Reply Threaded

By reading the class ANY in detail, it looks like ANY is somewhat
minimal to support the naked language. The only exception is the feature
"io".

What about not having "io" in the kernel? I know this sounds very
intrusive, because io has been in ANY since the beginning of Eiffel. But
io is already more than the minimum. It pulls in STD_FILES, FILES, etc.
Something which might be disturbing for embedded applications.

In C e.g. if you don't #include anything you can just add some integers
(and a little bit more, but not that much). Nothing related to io is in
the kernel. This is very advantagous for embedded applications where
notions of stdin, stdout, stderr often do not make any sense, because
you have platform specific libraries to handle io.

The same applies e.g. for modules in the Linux kernel. No stdio available.

Any comments? I doubt that anybody likes a discussion like that one. I
do not yet have an opinion about that. But having io in ANY irritates me
a little bit.

Regards
Helmut
http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

Colin LeMahieu

Re: {ANY}.io

Reply Threaded

From my understanding the reason io was put in to ANY was to allow people to print hello world easily, essentially no divine reason.

We could debate all day long the coupling between the language and its KERNEL libraries. Why does the language understand STRING manifest constants? Why does it understand INTEGER manifest constants? Will the language convert the "7" INTEGER manifest constant to "7.0" if the type its being assigned to is a DOUBLE. Can the programmer define further manifest objects for further non-kernel types?

If you don't reference ANY.io it will be removed in the finalized version.

On Mon, Jul 28, 2008 at 4:12 PM, Helmut Brandl <helmut.brandl@...> wrote:

By reading the class ANY in detail, it looks like ANY is somewhat
minimal to support the naked language. The only exception is the feature
"io".

What about not having "io" in the kernel? I know this sounds very
intrusive, because io has been in ANY since the beginning of Eiffel. But
io is already more than the minimum. It pulls in STD_FILES, FILES, etc.
Something which might be disturbing for embedded applications.

In C e.g. if you don't #include anything you can just add some integers
(and a little bit more, but not that much). Nothing related to io is in
the kernel. This is very advantagous for embedded applications where
notions of stdin, stdout, stderr often do not make any sense, because
you have platform specific libraries to handle io.

The same applies e.g. for modules in the Linux kernel. No stdio available.

Any comments? I doubt that anybody likes a discussion like that one. I
do not yet have an opinion about that. But having io in ANY irritates me
a little bit.

Regards
Helmut
http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

Helmut Brandl

Re: {ANY}.io

Reply Threaded

Colin LeMahieu wrote:
>
> We could debate all day long the coupling between the language and its
> KERNEL libraries.
I do not understand why you react that harshly to my question which
didn't even try to push into one direction. I didn't start a debate. I
have just verbalized my irritation and wanted to get some feedback how
the others think about that point. Sorry, if it had already been
discussed over and over again. If thats the case, as a newcomer on this
list I apologize for not knowing it.
> Why does the language understand STRING manifest constants? Why does
> it understand INTEGER manifest constants? Will the language convert
> the "7" INTEGER manifest constant to "7.0" if the type its being
> assigned to is a DOUBLE.
That is something completely different. I cannot imagine another way in
Eiffel to define a string constant than to write it. The same applies to
integers and reals. Assignments from constants to variables is also part
of the language proper. That is defined clearly in the standard
(including conversion). Can you imagine a library giving access to
string constants?
> Can the programmer define further manifest objects for further
> non-kernel types?
As far as I know the answer is no. But he can define conversions from
defined manifest constants (or manifest tuples) to non-kernel types.
>
> If you don't reference ANY.io it will be removed in the finalized version.
I know. But I don't know, what this argument is good for.

Don't get me wrong. It is ok for me having io in ANY. It does not
disturb a lot. In my first post I have given already a strong reason to
leave it in (it has been in ANY since its beginning). If the majority
does not want any thinking about that issue (for whatever reason), it is
not a problem for me. tecomp works fine with and without {ANY}.io.

Regards
Helmut

http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

Peter Gummer-2

Re: {ANY}.io

Reply Threaded

In reply to this post by Colin LeMahieu

Colin LeMahieu wrote:

> From my understanding the reason io was put in to ANY was to
> allow people to print hello world easily, essentially no divine reason.

That has always been my assumption too.

It has always struck me as an oddity. In the 1980s console applications were
the norm, so I can see why it would have been done, but in these days of GUI
and web applications I actually find it irritating. Personally I think ANY
would be a simpler and cleaner class without the io routines, but because of
backward-compatibility I doubt they will ever be removed.

- Peter

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

Helmut Brandl

Re: {ANY}.io

Reply Threaded

Peter Gummer wrote:

> Colin LeMahieu wrote:
>
>
>> From my understanding the reason io was put in to ANY was to
>> allow people to print hello world easily, essentially no divine reason.
>>
>
> That has always been my assumption too.
>
> It has always struck me as an oddity. In the 1980s console applications were
> the norm, so I can see why it would have been done, but in these days of GUI
> and web applications I actually find it irritating. Personally I think ANY
> would be a simpler and cleaner class without the io routines, but because of
> backward-compatibility I doubt they will ever be removed.
>
> - Peter
>
>

That's what I suspected as well. Clearly removing io from ANY would
break backward compatibility. But the break would be rather mild, if
acompanied by the provision of a class STANDARD_IO (I have just picked a
name), which provides io. The classes which use io simply would have to
insert "inherit STANDARD_IO" into its text and everything would work
smoothely (just editorial work, no risk to have any semantic problem).

But anyhow, thank you for your feedback.

Helmut

http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

Emmanuel Stapf

Re: {ANY}.io

Reply Threaded

> That's what I suspected as well. Clearly removing io from ANY would
> break backward compatibility. But the break would be rather mild, if
> acompanied by the provision of a class STANDARD_IO (I have just picked a
> name), which provides io. The classes which use io simply would have to
> insert "inherit STANDARD_IO" into its text and everything would work
> smoothely (just editorial work, no risk to have any semantic problem).
>
> But anyhow, thank you for your feedback.

It is going to be hard to remove it from ANY. One of Bertrand's reason for keeping
it in ANY is for teaching. You can write the hello world example without learning
about inheritance. You only need to know that there is this special thing called
`io'.

People may or may not agree on this, but that the state of the affair.

Regards,
Manu

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
freeelks-devel mailing list
freeelks-devel@...
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

------------------------------------------------------------------------
Eiffel Software
805-685-1006
http://www.eiffel.com
Customer support: http://support.eiffel.com
User group: http://groups.eiffel.com/join
------------------------------------------------------------------------

Colin LeMahieu

{ANY}.io

Reply Threaded

In reply to this post by Helmut Brandl

I didn't intend any malice with my reply. I'm was just stating that there is no end to the debate of how much can we mix kernel library and language. Since in Eiffel there are no "base types", everything is truly a class, writing "x := 8" is mixing kernel with language. The language needs to know what an "8" is, which is part of the kernel library.

On Mon, Jul 28, 2008 at 7:07 PM, Helmut Brandl <helmut.brandl@...> wrote:

Colin LeMahieu wrote:

We could debate all day long the coupling between the language and its KERNEL libraries.

I do not understand why you react that harshly to my question which didn't even try to push into one direction. I didn't start a debate. I have just verbalized my irritation and wanted to get some feedback how the others think about that point. Sorry, if it had already been discussed over and over again. If thats the case, as a newcomer on this list I apologize for not knowing it.

Why does the language understand STRING manifest constants? Why does it understand INTEGER manifest constants? Will the language convert the "7" INTEGER manifest constant to "7.0" if the type its being assigned to is a DOUBLE.

That is something completely different. I cannot imagine another way in Eiffel to define a string constant than to write it. The same applies to integers and reals. Assignments from constants to variables is also part of the language proper. That is defined clearly in the standard (including conversion). Can you imagine a library giving access to string constants?

Can the programmer define further manifest objects for further non-kernel types?

As far as I know the answer is no. But he can define conversions from defined manifest constants (or manifest tuples) to non-kernel types.

If you don't reference ANY.io it will be removed in the finalized version.

I know. But I don't know, what this argument is good for.

Don't get me wrong. It is ok for me having io in ANY. It does not disturb a lot. In my first post I have given already a strong reason to leave it in (it has been in ANY since its beginning). If the majority does not want any thinking about that issue (for whatever reason), it is not a problem for me. tecomp works fine with and without {ANY}.io.

Regards
Helmut

http://www.sourceforge.net/projects/tecomp
http://tecomp.sourceforge.net