OOP Language for OS Development

OOP Language for OS Development

[KingIshu]

Hi All,
I am developing an object oriented OS code-named "ikbocs".
1) What are the pros and cons of the following languages interms of  
Effectiveness on System Programming, Object Orientedness etc ?
(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
I suppose Java is not suitable for Sys. Programming.

2) Which OOP language would be better for OS development?

TIA
KingIshu

Re: OOP Language for OS Development

[Martin Krischik]

KingIshu wrote:

> Hi All,
> I am developing an object oriented OS code-named "ikbocs".

> 1) What are the pros and cons of the following languages interms of
> Effectiveness on System Programming, Object Orientedness etc ?
> (Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
> I suppose Java is not suitable for Sys. Programming.

Pros for Ada:

Ada has been created for embedded programming and as such is suitable for
system programing.

Ada's representation clauses alow you to specify the pyhsical layout of
*any* datatype. Important for maping hadware interfaces.

Ada's units are based on bit not byte so exotic data types (like 4 bit enums
and 12 bit integers) are handled by the language. No need for complex bit
shifting.

Ada is very strict so many programing mistakes are found at compile time.
Very heplfull since debugging an operating system is quite painfull.

Ada checks for null pointer and protects against buffer overruns as well as
range over- and underruns. No need to add asserts all over the code. 

All checks metioned above can be switched off when speed os more important
then robustness.

Ada 95 supports all major OO features as well a generic programing
(templates).

> 2) Which OOP language would be better for OS development?

Answering that question will only lead to a flame war - so I hope nobody
does.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: OOP Language for OS Development

[Ioannis Vranos]

"KingIshu" <ikbocs@yahoo.com> wrote in message
news:95db0572.0404142153.431fd058@posting.google.com...
> Hi All,
> I am developing an object oriented OS code-named "ikbocs".
> 1) What are the pros and cons of the following languages interms of
> Effectiveness on System Programming, Object Orientedness etc ?
> (Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
> I suppose Java is not suitable for Sys. Programming.
>
> 2) Which OOP language would be better for OS development?


I 'll talk about C++ which is the language i know about. Both runtime and
space efficiency was one of its design criteria. Abstraction facilities do
not impose additional run-time or space cost than equivalent C-style code.
"It leaves no room for a lower level programming language (except
assembly)".

It supports the OO paradigm, generic programming paradigm (templates),
modular programming paradigm (namespaces) and procedural paradigm. Each
paradigm is supported *well* and with space/run-time efficiency.

Actually those are the reasons that i decided to learn C++ after i learned
C. I think C++ is the best language out there and this not because of
language fanatism.



References:

http://www.research.att.com/~bs/esc99.html
http://www.research.att.com/~bs/bs_faq2.html
http://www.research.att.com/~bs/






Ioannis Vranos

Re: OOP Language for OS Development

[Thomas Gagné]

Smalltalk has already been used for building an operating system so you 
can either use that as a benchmark showing it can be done, or a reason 
to do it in another language to prove it can be done with it as well.

KingIshu wrote:

>Hi All,
>I am developing an object oriented OS code-named "ikbocs".
>1) What are the pros and cons of the following languages interms of  
>Effectiveness on System Programming, Object Orientedness etc ?
>(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
>I suppose Java is not suitable for Sys. Programming.
>
>2) Which OOP language would be better for OS development?
>
>TIA
>KingIshu
>  
>

-- 
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>

Re: OOP Language for OS Development

[Ioannis Vranos]

"Ioannis Vranos" <ivr@guesswh.at.emails.ru> wrote in message
news:c5lv0f$ogq$1@ulysses.noc.ntua.gr...
>
> I 'll talk about C++ which is the language i know about. Both runtime and
> space efficiency was one of its design criteria. Abstraction facilities do
> not impose additional run-time or space cost than equivalent C-style code.
> "It leaves no room for a lower level programming language (except
> assembly)".
>
> It supports the OO paradigm, generic programming paradigm (templates),
> modular programming paradigm (namespaces) and procedural paradigm. Each
> paradigm is supported *well* and with space/run-time efficiency.
>
> Actually those are the reasons that i decided to learn C++ after i learned
> C. I think C++ is the best language out there and this not because of
> language fanatism.
>
>
>
> References:
>
> http://www.research.att.com/~bs/esc99.html
> http://www.research.att.com/~bs/bs_faq2.html
> http://www.research.att.com/~bs/



And of course http://www.research.att.com/~bs/bs_faq.html






Ioannis Vranos

Re: OOP Language for OS Development

[jeffc]

"KingIshu" <ikbocs@yahoo.com> wrote in message
news:95db0572.0404142153.431fd058@posting.google.com...
> Hi All,
> I am developing an object oriented OS code-named "ikbocs".

You're not going to have to kill me now, are you?

Re: OOP Language for OS Development

[Luke Guest]

"KingIshu" <ikbocs@yahoo.com> wrote in message
news:95db0572.0404142153.431fd058@posting.google.com...
> Hi All,
> I am developing an object oriented OS code-named "ikbocs".
> 1) What are the pros and cons of the following languages interms of
> Effectiveness on System Programming, Object Orientedness etc ?
> (Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
> I suppose Java is not suitable for Sys. Programming.
>
> 2) Which OOP language would be better for OS development?

You don't have to use an OO language to develop an OO OS. When I get back
onto my OS project, it will be written in Ada, it will be an OO OS, but it
will not be using tagged types (classes).

You need to define what you want your OS to do first, then decide what
language will help you to achieve this goal. You will need some assembly
language in there, and maybe some other languages may creep in ;-) Who
knows?

Luke.

Re: OOP Language for OS Development

[Ender Everett]

KingIshu wrote:

> Hi All,
> I am developing an object oriented OS code-named "ikbocs".
> 1) What are the pros and cons of the following languages interms of
> Effectiveness on System Programming, Object Orientedness etc ?
> (Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
> I suppose Java is not suitable for Sys. Programming.
> 
> 2) Which OOP language would be better for OS development?
> 
> TIA
> KingIshu

Whichever one you understand the finer points of best.

-- 
http://barfdader.com
"Beat your children at least once a day; if you don't know why, they do."
-A surprisingly famous guy

Re: OOP Language for OS Development

[EventHelix.com]

> 2) Which OOP language would be better for OS development?

At this point C++ would seem to be the best choice. I don't think any other
language would match C++ in performance and power.

Besides, many operating systems have already been written in C++.

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - System Architecture Design CASE Tool

Re: OOP Language for OS Development

[Martin Krischik]

EventHelix.com wrote:

>> 2) Which OOP language would be better for OS development?
> 
> At this point C++ would seem to be the best choice. I don't think any
> other language would match C++ in performance and power.

This statement is of corse useless unless you state which progamming
languages you a firm with.

I for example a firm in C++, C, Java, Modula 2, Pascal and Ada and would use
Ada if I ever wanted to write an OS.

You can find the reason for my preference in my other posting.

> Besides, many operating systems have already been written in C++.

The question was for quality not quantity. It might well be that there is
the perfect language out there for OS development only nobody ever tried it
out yet.

Besides, where is the fun in doing what everybody else does?

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: OOP Language for OS Development

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

"EventHelix.com" <eventhelix@hotmail.com> a �crit dans le message de news:566e2bfb.0404181753.2844342f@posting.google.com...
> > 2) Which OOP language would be better for OS development?
>
> At this point C++ would seem to be the best choice. I don't think any other
> language would match C++ in performance and power.
>
You are certainly free to argue that C++ is a *good* choice, but when you say it is the *best* choice, could you tell over which
languages?

For example, do you know Ada well enough  to explain why C++ would be superior?

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: OOP Language for OS Development

[Ioannis Vranos]

"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
news:op306c.fjq.ln@skymaster...
 >
> You are certainly free to argue that C++ is a *good* choice, but when you
say it is the *best* choice, could you tell over which
> languages?
>
> For example, do you know Ada well enough  to explain why C++ would be
superior?


I think that it is happening what the OP intended: A war between
civilizations... There is no better way to start a flame than cross-posting
in different language newsgroups about which is the best language.






Regards,

Ioannis Vranos

Re: OOP Language for OS Development

[Philippe Ribet]

EventHelix.com wrote:
> At this point C++ would seem to be the best choice. I don't think any other
> language would match C++ in performance and power.
> 

Do you at least ever heard of Eiffel? I would say that C++ is far from 
matching Eiffel power.

What about performance? If only you have made a single benchmark...

Such assessment is just a flame war start.

	Nice day to everybody,

-- 
Philippe Ribet



                          The README file said
               "Requires Windows 95, NT 4.0, or better."
                     So... I installed it on Linux!

Re: OOP Language for OS Development

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]


"Ioannis Vranos" <ivr@guesswh.at.emails.ru> a �crit dans le message de news:c605da$2f9d$1@ulysses.noc.ntua.gr...
> I think that it is happening what the OP intended: A war between
> civilizations... There is no better way to start a flame than cross-posting
> in different language newsgroups about which is the best language.
>
Not necessarily wars. Technical discussions are interesting, provided people have a wide enough view.
Note that I didn't say "Ada is superior", I said "please explain why you think that C++ is superior".

And if we refrain from religious argument, a technical discussion about what makes a language appropriate for writing an OS (or
anything else) could be quite interesting.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: OOP Language for OS Development

[Martin Krischik]

Ioannis Vranos wrote:

> I think that it is happening what the OP intended: A war between
> civilizations...

> There is no better way to start a flame than
> cross-posting in different language newsgroups about which is the best
> language.

No, KingIshu first question was Ok. He asked for advantages and
disadvantages in respect to OS development. And we are the people to answer
that question. And to discuss the answers.

It would have been better not to ask the 2nd question.

The real problem are answers like the one from EventHelix. He did not state
any specific advantages of C++ just stating C++ is best. This shows great
inexperience in the use of the usenet.

Experienced usenet users will only state the advandages and disadvantages
of there favorite languages and refrain from comenting on other languages.
And saying that one language is best is - indirectly - comenting on other
languages.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: OOP Language for OS Development

[Christopher Benson-Manica]

In comp.lang.c++ Ioannis Vranos <ivr@guesswh.at.emails.ru> wrote:

(comp.lang.c++ removed from follup-to)

> I think that it is happening what the OP intended: A war between
> civilizations... There is no better way to start a flame than cross-posting
> in different language newsgroups about which is the best language.

Indeed, which is why a) the crossposting to comp.lang.c++ should stop
immediately, if nothing else, and b) I am plonking this thread as of
now.

-- 
Christopher Benson-Manica  | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org    | don't, I need to know.  Flames welcome.

Re: OOP Language for OS Development

[Calum]

Philippe Ribet wrote:

> EventHelix.com wrote:
> 
>> At this point C++ would seem to be the best choice. I don't think any 
>> other
>> language would match C++ in performance and power.
>>
> 
> Do you at least ever heard of Eiffel? I would say that C++ is far from 
> matching Eiffel power.

In terms of "raw power", both languages are Turing powerful (if we 
ignore the "can a finite computer be Turing complete" pedentry).  So 
power in what sense?  What's really nice and neat to do in Eiffel that 
is difficult in C++?  Give some source code, or at the very least a link 
to an article.

Can for example Eiffel implement its own allocators, or is its type 
system itself Turing complete (C++ templates)?

> What about performance? If only you have made a single benchmark...
> 
> Such assessment is just a flame war start.
> 
>     Nice day to everybody,
> 

Re: OOP Language for OS Development

[John English]

Calum wrote:
> In terms of "raw power", both languages are Turing powerful (if we 
> ignore the "can a finite computer be Turing complete" pedentry).  So 
> power in what sense?  What's really nice and neat to do in Eiffel that 
> is difficult in C++?  Give some source code, or at the very least a link 
> to an article.

http://burks.bton.ac.uk/burks/language/eiffel/index.htm

---------------------------------------------------------------------
  John English                   | mailto:je@brighton.ac.uk
  Senior Lecturer                | http://www.it.bton.ac.uk/staff/je
  School of Computing Maths & IS | ** NON-PROFIT CD FOR CS STUDENTS **
  University of Brighton         |    -- see http://burks.bton.ac.uk
---------------------------------------------------------------------

Re: OOP Language for OS Development

[Philippe Ribet]

Calum wrote:
> Philippe Ribet wrote:
> 
>> EventHelix.com wrote:
>>
>>> At this point C++ would seem to be the best choice. I don't think any 
>>> other
>>> language would match C++ in performance and power.
>>>
>>
>> Do you at least ever heard of Eiffel? I would say that C++ is far from 
>> matching Eiffel power.
> 
> 
> In terms of "raw power", both languages are Turing powerful (if we 
> ignore the "can a finite computer be Turing complete" pedentry).  So 
> power in what sense?  What's really nice and neat to do in Eiffel that 
> is difficult in C++?  Give some source code, or at the very least a link 
> to an article.

It's obvious here that language power means expressivity.

> Can for example Eiffel implement its own allocators, or is its type 
> system itself Turing complete (C++ templates)?

Could you please re-formulate questions about allocators and type 
system? I do not understand what you mean, sorry.


-- 
Philippe Ribet



                          The README file said
               "Requires Windows 95, NT 4.0, or better."
                     So... I installed it on Linux!

Re: OOP Language for OS Development

[Calum]

Philippe Ribet wrote:

> Calum wrote:
> 
>> Philippe Ribet wrote:
>>
>>> EventHelix.com wrote:
>>>
>>>> At this point C++ would seem to be the best choice. I don't think 
>>>> any other
>>>> language would match C++ in performance and power.
>>>>
>>>
>>> Do you at least ever heard of Eiffel? I would say that C++ is far 
>>> from matching Eiffel power.
>>
>>
>>
>> In terms of "raw power", both languages are Turing powerful (if we 
>> ignore the "can a finite computer be Turing complete" pedentry).  So 
>> power in what sense?  What's really nice and neat to do in Eiffel that 
>> is difficult in C++?  Give some source code, or at the very least a 
>> link to an article.
> 
> 
> It's obvious here that language power means expressivity.

I am in no doubt that Eiffel is cleaner safer language, however that's 
not quite the same as power.

So what can you express in Eiffel that cannot be expressed in C++? 
[Actually, resolving name-clashes in multiple inheritance is one, 
contracts is another.]  But are these fundamentally difficult in C++, or 
just a little uglier?

>> Can for example Eiffel implement its own allocators, or is its type 
>> system itself Turing complete (C++ templates)?
> 
> 
> Could you please re-formulate questions about allocators and type 
> system? I do not understand what you mean, sorry.

C++ allows you to specify where in memory an object resides.  This is a 
low-level feature that most people would not use, but gives C-like 
performance since you can cache-localize data, and implement more 
efficient memory managers where you know the allocation patterns.

Are parameterized types in Eiffel as flexible as those in C++?

Re: OOP Language for OS Development

[Steven Wurster]

Calum <calum.bulk@ntlworld.com> wrote in message news:<c6ap5j$1nh$1@newsg1.svr.pol.co.uk>...
> 
> I am in no doubt that Eiffel is cleaner safer language, however that's 
> not quite the same as power.
> 
> So what can you express in Eiffel that cannot be expressed in C++? 
> [Actually, resolving name-clashes in multiple inheritance is one, 
> contracts is another.]  But are these fundamentally difficult in C++, or 
> just a little uglier?

Contracting is fundamentally difficult in C++, because adhering to the
inheritance rules of contracting is not easily accomplished.  Doing so
requires a lot of preprocessor directives/macros, and makes the code
extremely ugly.

Resolving name clashes in C++ *can* be difficult if there are a lot of
them, and you need to make sweeping changes.  Automated search and
replace can help, of course, but may not do everything you need. 
Otherwise, it's just flat out ugly in C++.

Eiffel supports selective exporting, covariant argument redefinition,
constrained genericity, and has polymorphism by default without any
added performance penalty.  C++ supports none of these.  Eiffel also
fully supports the Open Closed Principle, while C++ does not (due to
requirement of virtual keyword and private access limitations).  None
of these issues really affect the choice about whether one can develop
an OS with them or not.


> Are parameterized types in Eiffel as flexible as those in C++?

Not really.  Eiffel supports constrained genericity, but it does not
support expression templates like C++ does.  Of course, expression
templates are really a side-effect in C++, as they were not part of
the original intention.  They are great for performance and expressive
power, but they are damn ugly.  :-)

Steve

Re: OOP Language for OS Development

[Hyman Rosen]

Steven Wurster wrote:
> Eiffel supports covariant argument redefinition

Which is a huge mistake, since it menas that one can
no longer supply a derived class to something which
expects a base class.

Re: OOP Language for OS Development

[Georg Bauhaus]

In comp.lang.ada Calum <calum.bulk@ntlworld.com> wrote:
 
: I am in no doubt that Eiffel is cleaner safer language, however that's 
: not quite the same as power.
: 
: So what can you express in Eiffel that cannot be expressed in C++? 
: [Actually, resolving name-clashes in multiple inheritance is one, 
: contracts is another.]  But are these fundamentally difficult in C++, or 
: just a little uglier?

How would you write "once" routines in C++?
How about the fine grained visibility control (where each feature
can be made visible to only a specified set of types)?

: 
:>> Can for example Eiffel implement its own allocators, or is its type 
:>> system itself Turing complete (C++ templates)?
:> 
:> 
:> Could you please re-formulate questions about allocators and type 
:> system? I do not understand what you mean, sorry.
: 
: C++ allows you to specify where in memory an object resides.  This is a 
: low-level feature that most people would not use, but gives C-like 
: performance since you can cache-localize data, and implement more 
: efficient memory managers where you know the allocation patterns.
: 
: Are parameterized types in Eiffel as flexible as those in C++?

They are different I think. Can you express

 deferred class C [P -> T]
 feature foo(x: P): P is deferred end
 end -- C

in C++?

Then there is currently a (justified) limitation in C++ with
float parameters. This is not the case in Ada generics.

georg

Re: OOP Language for OS Development

[Hyman Rosen]

Georg Bauhaus wrote:
> How would you write "once" routines in C++?

With a static method containing a static value, of course.

class UponATime
{
     static double Once(/* args */)
     {
         static double value = /* some calculation */;
         return value;
     }
};

It appears from my looking up what once functions do,
that arguments to the call are irrelevant for determining
whether it should be re-executed. If so, that's another
example of a hideous language design choice made by Eiffel.

> How about the fine grained visibility control (where each feature
> can be made visible to only a specified set of types)?

Speaking of hideous design decisions. This whole concept
of classes having fine-grained dictatorial control over
whom they allow access to their innards is more than a
little silly.

> They are different I think. Can you express
>  deferred class C [P -> T]
>  feature foo(x: P): P is deferred end
>  end -- C
> in C++?

Sure. You just don't define the method, and if it gets used,
the linker will complain. Or if it's virtual, then you can
make it abstract.

template <typename T>
struct C
{
     T foo(T x);
     virtual T bar(T x) = 0;
};

Re: OOP Language for OS Development

[Georg Bauhaus]

In comp.lang.ada Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> How would you write "once" routines in C++?
: 
: With a static method containing a static value, of course.

So in the general case where the method will have (side)
effects on object variables I use an if (once) {...} with a
static bool once, I guess?  Whatever suggests the necessity
of ONCE in a language, if it is necessary then being able
to write ONCE might have an advantage in my view.

:> They are different I think. Can you express
:>  deferred class C [P -> T]
:>  feature foo(x: P): P is deferred end
:>  end -- C
:> in C++?
: 
: Sure. You just don't define the method, and if it gets used,
: the linker will complain.

So the compiler, compiling seperately, will not know which types
can be passed to some_C.foo before the linker is run.

Re: OOP Language for OS Development

[Hyman Rosen]

Georg Bauhaus wrote:
> So in the general case where the method will have (side)
> effects on object variables I use an if (once) {...} with a
> static bool once, I guess?

What do you mean? A static variable in a function is initialized
the first time control passes through the declarartion, and never
again. So my code is equivalent to your ONCE method - the first
time the function is called, the variable will be initialized, so
you can plant all of the code you want to execute once as part of
that initialization. After that, no matter how many times you call
the function, the initialization code won't be executed.

> Whatever suggests the necessity of ONCE in a language, if it is
 > necessary then being able to write ONCE might have an advantage
 > in my view.

*Shrug* I'm not thrilled with a language feature which allows the
compiler to replace a call to f(2) with an earlier call to f(1),
but maybe that's just me. Ada allows you to decorate a function
with Pragma Pure, and then it can elide multiple calls to a function
if it is called with the same parameters (regardless of whether the
function has side effects).

> So the compiler, compiling seperately, will not know which types
> can be passed to some_C.foo before the linker is run.

In C++, there is no some_C.foo. There is a some_C<T>.foo for each
type T that some_C is instantiated with. Each one is a logically
separate function, and they have nothing to do with each other.

Re: OOP Language for OS Development

[Brian_Heilig]

Hyman Rosen:
> Steven Wurster:
> > Eiffel supports covariant argument redefinition
> 
> Which is a huge mistake, since it menas that one can
> no longer supply a derived class to something which
> expects a base class.

Either I don't understand your post or you are mistaken. If the
derived class conforms to (inherits from) the parameter's type then
there is no problem.

Brian

Re: OOP Language for OS Development

[Hyman Rosen]

Brian_Heilig wrote:
> Either I don't understand your post or you are mistaken. If the
> derived class conforms to (inherits from) the parameter's type then
> there is no problem.

In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
That means that if you have a Base object, and you call
some_base_reference.Foo(some_other_base_reference), the call
looks correct, but if some_base_reference is really a Derived
and some_other_base_reference is not a Derived, you have an
error.

It's a horrible misfeature, but its proponents cling to it
tenaciously, and they have spent years trying to figure out
workarounds so that the errors can be caught.

Re: OOP Language for OS Development

[Brian_Heilig]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1082738747.300309@master.nyc.kbcfp.com>...
> Georg Bauhaus wrote:
> > How would you write "once" routines in C++?
> 
> With a static method containing a static value, of course.
> 
> class UponATime
> {
>      static double Once(/* args */)
>      {
>          static double value = /* some calculation */;
>          return value;
>      }
> };

You are nowhere near the expressivity of once routines:
1. The body of `Once' will be executed with each call except for the
stuff after the static declaration. In other words, you must put all
of your calculation behind the equal sign!
2. You still need once per thread, once per object, and manual once
functions.

> It appears from my looking up what once functions do,
> that arguments to the call are irrelevant for determining
> whether it should be re-executed. If so, that's another
> example of a hideous language design choice made by Eiffel.

This is of course a consequence of your misunderstanding of once
functions.

> > How about the fine grained visibility control (where each feature
> > can be made visible to only a specified set of types)?
> 
> Speaking of hideous design decisions. This whole concept
> of classes having fine-grained dictatorial control over
> whom they allow access to their innards is more than a
> little silly.

You're funny.

> template <typename T>
> struct C
> {
>      T foo(T x);
>      virtual T bar(T x) = 0;
> };

You missed the constrained generic parameter. G -> T means that G is
the generic type and it must conform to T. I don't think C++ templates
can emulate constrained generics yet, but I could be wrong.

C++ will never reach the expressive power of Eiffel, but then again,
you can't make an Eiffel compiler solve factorials, so maybe you win?

Brian

Re: OOP Language for OS Development

[Steven Wurster]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1082732696.152155@master.nyc.kbcfp.com>...
> Steven Wurster wrote:
> > Eiffel supports covariant argument redefinition
> 
> Which is a huge mistake, since it menas that one can
> no longer supply a derived class to something which
> expects a base class.

That's not true.  I've done it plenty of times in Eiffel, even with
covariant redefinition.  Redefinition isn't necessary, but is
supported.  In fact, in many cases, it's the best solution.

Let's get off this language holy war argument.

Re: OOP Language for OS Development

[Steven Wurster]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1082738747.300309@master.nyc.kbcfp.com>...
> 
> It appears from my looking up what once functions do,
> that arguments to the call are irrelevant for determining
> whether it should be re-executed. If so, that's another
> example of a hideous language design choice made by Eiffel.

Explain why.  Don't just say it's 'hideous' without giving rationale.


> Speaking of hideous design decisions. This whole concept
> of classes having fine-grained dictatorial control over
> whom they allow access to their innards is more than a
> little silly.

Why?  You need to provide your reason for your opinion.  Selective
exporting is way ahead of the public/protected/private of C++ and
Java.  A good example is the visitor design pattern, in which the
visit routines should only be available to the accepting classes. 
This is easily done using selective exports in Eiffel.  But in C++ one
must either make the routines public, which violates encapsulation, or
make *every* accepting class a friend, which violates information
hiding and requires a lot of programmer bookkeeping.

Steve

Re: OOP Language for OS Development

[Brian_Heilig]

ikbocs@yahoo.com (KingIshu) wrote in message news:<95db0572.0404142153.431fd058@posting.google.com>...
> Hi All,
> I am developing an object oriented OS code-named "ikbocs".
> 1) What are the pros and cons of the following languages interms of  
> Effectiveness on System Programming, Object Orientedness etc ?
> (Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
> I suppose Java is not suitable for Sys. Programming.
> 
> 2) Which OOP language would be better for OS development?
> 
> TIA
> KingIshu

Eiffel Pros:
Design by Contract - a process and a language, Design by Contract
defines things like software correctness, software errors, and
exceptions like no other method. Integration into the language
dramatically helps with documentation and debugging. Many other
reasons why DbC alone puts Eiffel near the top of the list. No problem
with buffer overruns in Eiffel (the number one security risk in
operating systems), thanks to DbC.
Tight language design - all language features can be traced back to
about 10 basic principles. Eiffel has been systematically designed as
a language making it concise, easy to learn and easy to use.
Strict type system - operating systems require secure and correct
code. With Eiffel you'll catch more bugs at compile time. This strict
system makes it more difficult to design your code, but the benefit
greatly outweighs the increased effort.

Eiffel Cons (related to OSes):
There is no turnkey Eiffel compiler for you to use for operating
systems. All the current compilers are system-oriented, that is, they
generate systems, which for example have command-line arguments and
garbage collectors. Unless I'm mistaken this is probably the show
stopper.
I'm pretty sure it is impossible to write an entire OS completely in
Eiffel. Number one reason, Eiffel has no method for declaring
interrupt handlers. The good news is that Eiffel integrates with other
languages easily (C for example which has an interrupt keyword).
If efficiency is your number one priority Eiffel may not be for you.
SmartEiffel and ISE Eiffel generate very efficient code, but I don't
think it meets the demands of a CPU scheduler, for example.

Brian

Re: OOP Language for OS Development

[Georg Bauhaus]

In comp.lang.eiffel Hyman Rosen <hyrosen@mail.com> wrote:
 
: What do you mean? A static variable in a function is initialized
: the first time control passes through the declarartion, and never
: again. So my code is equivalent to your ONCE method -

O.K., though that will require another non-local private function?

Re: OOP Language for OS Development

[Robert C. Martin]

On Fri, 23 Apr 2004 18:33:05 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Brian_Heilig wrote:
>> Either I don't understand your post or you are mistaken. If the
>> derived class conforms to (inherits from) the parameter's type then
>> there is no problem.
>
>In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
>That means that if you have a Base object, and you call
>some_base_reference.Foo(some_other_base_reference), the call
>looks correct, but if some_base_reference is really a Derived
>and some_other_base_reference is not a Derived, you have an
>error.
>
>It's a horrible misfeature, but its proponents cling to it
>tenaciously, and they have spent years trying to figure out
>workarounds so that the errors can be caught.

It's an LSP violation.  Code written to deal with base classes can be
broken by new derivatives that can't accept the arguments that the
base can.  This makes it hard to follow the Open Closed Principle
which says that you should try to make modules extensible without
having to change them.  



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

Re: OOP Language for OS Development

[JKop]

Steven Wurster posted:

> Calum <calum.bulk@ntlworld.com> wrote in message
> news:<c6ap5j$1nh$1@newsg1.svr.pol.co.uk>... 
>> 
>> I am in no doubt that Eiffel is cleaner safer language, however 
that's
>> not quite the same as power.
>> 
>> So what can you express in Eiffel that cannot be expressed in C++? 
>> [Actually, resolving name-clashes in multiple inheritance is one, 
>> contracts is another.]  But are these fundamentally difficult in 
C++,
>> or  just a little uglier? 
> 
> Contracting is fundamentally difficult in C++, because adhering to 
the
> inheritance rules of contracting is not easily accomplished.  Doing 
so
> requires a lot of preprocessor directives/macros, and makes the 
code
> extremely ugly.
> 
> Resolving name clashes in C++ *can* be difficult if there are a lot 
of
> them, and you need to make sweeping changes.  Automated search and
> replace can help, of course, but may not do everything you need. 
> Otherwise, it's just flat out ugly in C++.
> 
> Eiffel supports selective exporting, covariant argument 
redefinition,
> constrained genericity, and has polymorphism by default without any
> added performance penalty.  C++ supports none of these.  Eiffel 
also
> fully supports the Open Closed Principle, while C++ does not (due 
to
> requirement of virtual keyword and private access limitations).  
None
> of these issues really affect the choice about whether one can 
develop
> an OS with them or not.
> 
> 
>> Are parameterized types in Eiffel as flexible as those in C++?
> 
> Not really.  Eiffel supports constrained genericity, but it does 
not
> support expression templates like C++ does.  Of course, expression
> templates are really a side-effect in C++, as they were not part of
> the original intention.  They are great for performance and 
expressive
> power, but they are damn ugly.  :-)
> 
> Steve


Why the hell would you want automatic polymorphism? There's times 
when I want functions NOT to be polymorphic!

-JKop

Re: OOP Language for OS Development

[Anthony Weissenberger]

Hyman Rosen wrote:
> In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
> That means that if you have a Base object, and you call
> some_base_reference.Foo(some_other_base_reference), the call
> looks correct, but if some_base_reference is really a Derived
> and some_other_base_reference is not a Derived, you have an
> error.
Your first statement is incorrect. You can decide whether it's 
Derived::Foo (Derived) or Derived::Foo (Base). If you do implement the 
former, you will indeed get an error. If you implement the latter, no 
errors are generated.

Could you provide a scenario where you would need to have both the base 
and derived class existing in the program, and you would need to 
implement Derived::Foo (Derived) overriding Base::Foo (Base)?

> 
> It's a horrible misfeature, but its proponents cling to it
> tenaciously, and they have spent years trying to figure out
> workarounds so that the errors can be caught.

Those are some interesting allegations. Do you have any references which 
support your claims?

Re: OOP Language for OS Development

[Greg C]

JKop <NULL@NULL.NULL> wrote in message news:<XHvic.5501$qP2.13349@news.indigo.ie>...
 
> Why the hell would you want automatic polymorphism? There's times 
> when I want functions NOT to be polymorphic!
> 
> -JKop

If the polymorphism is determined automatically, you don't need to
plug "virtual" keywords everywhere, and you don't need to spend any
time guessing as to which function should be allowed to be
polymorphic. Also, by determining this automatically, the Eiffel
compiler can optimize calls to eliminate polymorphism where it's not
needed. This is something that would be very difficult or impossible
for a C++ compiler to accomplish. If you know you don't want a
function to be polymorphic, then in Eiffel you declare it frozen.

Greg C

Re: OOP Language for OS Development

[Thomas Gagné]

Back to the original question...

I would expect there's conflicting demands on the operating system and 
consequently the language it's written in.  It is presumably responsible 
for interfacing directly with hardware, and must provide suitable 
abstractions for anything that might be attached to it.

At the same time, the operating system must play host to applications 
written for it, and it doesn't make sense to me that the OS should place 
restrictions on application languages--though it could turn the tables.

In today's popular operating systems the lower-level a language you are 
the greater advantage you have over higher-level languages.  If the 
operating system were written in an OOL that normally requires a virtual 
machine then that VM would be more native (or natural, perhaps) to other 
OOLs that could use the same VM.  Low level languages would have to run 
inside their own VM because the low-level operations might not be 
available to them.  Imagine writing a C program that didn't run as fast 
as a Java program because the C program had to run inside a VM on top 
the OS!

Of course, that may not be required.  But let's look at two languages on 
opposite sides of the spectrum--C and Smalltalk.

If the OS was written in Smalltalk then its imaginable the natural 
instructions might be Smalltalk's.  Would C programs be compiled into 
Smalltalk opcodes?  That would be interesting.  Imagine if such a thing 
were successful then chip manufacturers could begin developing chips to 
make the VM run faster as was suggested by Alan Kay years ago: 
<http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html#coda>

    "Hardware is really just software crystallized early. It is there to
    make program schemes run as efficiently as possible. But far too
    often the hardware has been presented as a given and it is up to
    software designers to make it appear reasonable. This has caused
    low-level techniques and excessive optimization to hold back
    progress in program design. As Bob Barton used to say: "Systems
    programmers are high priests of a low cult."

    "One way to think about progress in software is that a lot of it has
    been about finding ways to /late-bind/, then waging campaigns to
    convince manufacturers to build the ideas into hardware. Early
    hardware had wired programs and parameters; random access memory was
    a scheme to late-bind them. Looping and indexing used to be done by
    address modification in storage; index registers were a way to
    late-bind. Over the years software designers have found ways to
    late-bind the locations of computations--this led to base/bounds
    registers, segment relocation, page MMUs, migratory processes, and
    so forth. Time-sharing was held back for years because it was
    "inefficient"-- but the manufacturers wouldn't put MMUs on the
    machines, universities had to do it themselves! Recursion late-binds
    parameters to procedures, but it took years to get even rudimentary
    stack mechanisms into CPUs. Most machines still have no support for
    dynamic allocation and garbage collection and so forth. In short,
    most hardware designs today are just re-optimizations of moribund
    architectures."

Perhaps it's time for such a thing to be attempted.  If done well enough 
it could be the proof that late-binding is something much-needed in 
operating system and not just their applications.



     wrote:

>Hi All,
>I am developing an object oriented OS code-named "ikbocs".
>1) What are the pros and cons of the following languages interms of  
>Effectiveness on System Programming, Object Orientedness etc ?
>(Simula, Smalltalk, Modula-3, Eiffel, Sather, C++)
>I suppose Java is not suitable for Sys. Programming.
>
>2) Which OOP language would be better for OS development?
>
>TIA
>KingIshu
>  
>

-- 
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>

Re: OOP Language for OS Development

[Steven Wurster]

JKop <NULL@NULL.NULL> wrote in message news:<XHvic.5501$qP2.13349@news.indigo.ie>...
> 
> Why the hell would you want automatic polymorphism? There's times 
> when I want functions NOT to be polymorphic!
> 

Automatic polymorphism is needed to support the Open Closed Principle.
 But it can be turned off in Eiffel by declaring a routine as frozen. 
Similar to final in Java, which also has automatic polymorphism.

Oh, and, nice attitude.

Re: OOP Language for OS Development

[Steven Wurster]

Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<cnok80hcftjhc71pifh1r2pruaemjp135m@4ax.com>...
> 
> It's an LSP violation.  Code written to deal with base classes can be
> broken by new derivatives that can't accept the arguments that the
> base can.  This makes it hard to follow the Open Closed Principle
> which says that you should try to make modules extensible without
> having to change them.  
> 

Remember that it's not required for a descendant class to covariantly
redefine arguments in Eiffel.  It is an option, however.  And, yes,
doing it can lead to problems.  In fact, we have a name for it in
Eiffel.  It's called a CATcall, where CAT stands Changing Availability
or Type.  That is, where a descendant routine either changes its
availability (i.e. becomes less visible) or its argument types.  The
Eiffel community knows about this, and knows how to deal with it. 
And, no, a compiler cannot reasonably detect where CATcalls lead to
LSP violations.

But, I'd rather use Eiffel with that 'hole' than languages that have
less power and less support for the OCP, among their other faults.

Steve

Re: OOP Language for OS Development

[Hyman Rosen]

Thomas Gagn� wrote:
> Perhaps it's time for such a thing to be attempted.

Intel 432, Symbolics Lisp machines, probably a host of others.
Such things have been attempted, and are now consigned to the
ash heaps of history.

It should be obvious why. When you have good, fast general
purpose hardware, you can implement all sorts of cockamamie
ideas on it, and if something doesn't work out, you can try
something else. When you start implementing those ideas in
hardware and they don't work out, you're left with a useless
boat anchor.

Re: OOP Language for OS Development

[Hyman Rosen]

Anthony Weissenberger wrote:
> Hyman Rosen wrote:
>> In Eiffel, Derived::Foo(Derived) overrides Base::Foo(Base).
> 
> Your first statement is incorrect. You can decide whether it's 
> Derived::Foo (Derived) or Derived::Foo (Base). If you do implement the 
> former, you will indeed get an error. If you implement the latter, no 
> errors are generated.

So what's your point? All OO languages let you do the latter.
But only Eiffel allows the former, and it indeed can cause errors
at runtime. What exactly do you think is incorrect about what I said?

> Could you provide a scenario where you would need to have both the base 
> and derived class existing in the program, and you would need to 
> implement Derived::Foo (Derived) overriding Base::Foo (Base)?

Beats me. Ask the Eiffel guys, since it's their theory.

> Do you have any references which support your claims?

Sure. <http://www2.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf>
is a paper with Bertrand Meyer as one of the coauthors, dated 2003,
in which they are still talking about how to get compilers to do safe
covariance.

Re: OOP Language for OS Development

[Hyman Rosen]

Georg Bauhaus wrote:
> O.K., though that will require another non-local private function?

It could, if that code was complicated enough.
It all just turns into a static boolean anyway,
either explicit or by the compiler. If Eiffel
wants to nominate it into a first-class language
feature, bully for it.

Re: OOP Language for OS Development

[Hyman Rosen]

Steven Wurster wrote:
> Explain why.  Don't just say it's 'hideous' without giving rationale.

If I see code which says 'f(1) + f(2)' I would be very surprised to
hear that the compiler was tossing out the f(2) and just reusing the
f(1). It's not that you can't do the same thing in C++ using statics,
but having it as a language feature just strikes me as weird. At least
Ada does it right, by only eliding calls with the same arguments for
Pure methods.

> Why?  You need to provide your reason for your opinion.  Selective
> exporting is way ahead of the public/protected/private of C++ and
> Java.

It's only ahead if you think that such hiding is valuable and necessary.
I think some people have made a religion of it, and they need to stop
thinking of their code as some sacred virgin who must be defended from
the impure advances of everyone else's code, and just get the work done.
The world isn't going to end if someone gets to fiddle around with the
private bits.

Re: OOP Language for OS Development

[Hyman Rosen]

Brian_Heilig wrote:
> You missed the constrained generic parameter. G -> T means that G is
> the generic type and it must conform to T. I don't think C++ templates
> can emulate constrained generics yet, but I could be wrong.

They sort-of can, because there are ways to do the checks at compile time,
but no one really cares. Most C++ folks consider it a mistake to try to
limit generic parameters in this way, because it limits the usability of
templates for absolutely no reason. If the template happens to work for
some class that doesn't conform to T, why should it be prevented from doing
so?

> C++ will never reach the expressive power of Eiffel, but then again,
> you can't make an Eiffel compiler solve factorials, so maybe you win?

Yeah, whatever.

Re: OOP Language for OS Development

[Robert C. Martin]

On 24 Apr 2004 18:25:38 -0700, stevenwurster@lycos.com (Steven
Wurster) wrote:

>But, I'd rather use Eiffel with that 'hole' than languages that have
>less power and less support for the OCP, among their other faults.

I completely understand that point of view.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
           -- Daniel Parker

Re: OOP Language for OS Development

[Alexander E. Kopilovich]

Thomas Gagn? wrote:

> was suggested by Alan Kay years ago: 
> <http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html#coda>
>
>    "Hardware is really just software crystallized early. It is there to
>    make program schemes run as efficiently as possible. But far too
>    often the hardware has been presented as a given and it is up to
>    software designers to make it appear reasonable. This has caused
>    low-level techniques and excessive optimization to hold back
>    progress in program design. As Bob Barton used to say: "Systems
>    programmers are high priests of a low cult."

The latter is certainly true, but crowds of low priests of several relatively
high cults constitute much more notorious problem.

>    "One way to think about progress in software is that a lot of it has
>    been about finding ways to /late-bind/, then waging campaigns to
>    convince manufacturers to build the ideas into hardware. Early
>    hardware had wired programs and parameters; random access memory was
>    a scheme to late-bind them. Looping and indexing used to be done by
>    address modification in storage; index registers were a way to
>    late-bind. Over the years software designers have found ways to
>    late-bind the locations of computations--this led to base/bounds
>    registers, segment relocation, page MMUs, migratory processes, and
>    so forth. Time-sharing was held back for years because it was
>    "inefficient"-- but the manufacturers wouldn't put MMUs on the
>    machines, universities had to do it themselves! Recursion late-binds
>    parameters to procedures, but it took years to get even rudimentary
>    stack mechanisms into CPUs. Most machines still have no support for
>    dynamic allocation and garbage collection and so forth. In short,
>    most hardware designs today are just re-optimizations of moribund
>    architectures."

Interesting quotation - it makes quite obvious that late/early binding is
a dynamic form of static notion of generalization/specialization.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: OOP Language for OS Development

[Alexander E. Kopilovich]

Hyman Rosen wrote:

> Thomas GagnО©╫ wrote:
> > Perhaps it's time for such a thing to be attempted.
>
> Intel 432, Symbolics Lisp machines, probably a host of others.
> Such things have been attempted, and are now consigned to the
> ash heaps of history.
>
> It should be obvious why. When you have good, fast general
> purpose hardware, you can implement all sorts of cockamamie
> ideas on it, and if something doesn't work out, you can try
> something else. When you start implementing those ideas in
> hardware and they don't work out, you're left with a useless
> boat anchor.

Yes. Ironically enough, this is exactly about the same thing - late/early
binding, is this case (of building ideas into hardware) in almost literal,
material sense.



Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: OOP Language for OS Development

[Isaac Gouy]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<2dFic.16950$eK3.5881@nwrdny01.gnilink.net>...
> Thomas Gagn� wrote:
> > Perhaps it's time for such a thing to be attempted.
> 
> Intel 432, Symbolics Lisp machines, probably a host of others.
> Such things have been attempted, and are now consigned to the
> ash heaps of history.

Google "Smalltalk On A Risk" SOAR

Re: OOP Language for OS Development

[Cesar Rabak]

Isaac Gouy escreveu:
> Hyman Rosen <hyrosen@mail.com> wrote in message news:<2dFic.16950$eK3.5881@nwrdny01.gnilink.net>...
> 
>>Thomas Gagn� wrote:
>>
>>>Perhaps it's time for such a thing to be attempted.
>>
>>Intel 432, Symbolics Lisp machines, probably a host of others.
>>Such things have been attempted, and are now consigned to the
>>ash heaps of history.
> 
> 
> Google "Smalltalk On A Risk" SOAR

Perhaps more sucessful with "Smalltalk On A Risc"?

Re: OOP Language for OS Development

[Thomas Gagné]

The SOAR report was published 1984, nine years before Kay's comments in 
1993.  I doubt Kay was unfamiliar with SOAR and so conclude he was 
disappointed in the progress hardware has made in that area.

-- 
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>

Re: OOP Language for OS Development

[Berend de Boer]

>>>>> "Brian" == Brian Heilig <heilig@iname.com> writes:

    Brian> is probably the show stopper.  I'm pretty sure it is
    Brian> impossible to write an entire OS completely in
    Brian> Eiffel. 

You can't do it in C either. You always need a bit of assember to
access the hardware.

    Brian> one priority Eiffel may not be for you.  SmartEiffel and
    Brian> ISE Eiffel generate very efficient code, but I don't think
    Brian> it meets the demands of a CPU scheduler, for example.

That's more related to multi-threading. Which Eiffel can do, and there
is even a SCOOP version of SmartEiffel.

-- 
Regards,

Berend.

  ** you're welcome to the #eiffel irc channel on irc.freenode.net

Re: OOP Language for OS Development

[Christopher Browne]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]

In the last exciting episode, Thomas Gagn� <tgagne@wide-open-west.com> wrote:
> Of course, that may not be required.  But let's look at two languages
> on opposite sides of the spectrum--C and Smalltalk.
>
> If the OS was written in Smalltalk then its imaginable the natural
> instructions might be Smalltalk's.  Would C programs be compiled
> into Smalltalk opcodes?  That would be interesting.

This phenomenon was actually seen with Symbolics Lisp Machines.

They were "natively" programmed in Lisp (something fairly close to
Common Lisp), and the hardware was specifically attuned to that.

There was indeed a C compiler for Symbolics; it generated "Lisp
Machine assembly language," which is pretty much equivalent to your
suggestion of C being compiled into Smalltalk opcodes.

This form of C was certainly different from what is traditional; there
was no notion of "numeric" pointers; it used Lisp 'pairs' to represent
pointers.  That doesn't break C, although it doubtless breaks code
that assumes that pointers are objects that may be manipulated
arithmetically...

What was discovered was that it cost _WAY_ too much to keep
redesigning these CPUs every other year.  It is certainly
spectacularly costly for AMD and Intel to create each successive
generation of their chips, but they can amortize the costs across many
millions of chips.  Lisp Machines didn't have the quantities of sales.

Symbolics stopped designing hardware; they wrote some Alpha microcode
to let them get an efficient pseudo-instruction set on Alpha
processors, which was a sound idea, but they faded into oblivion for
other reasons.

It seems pretty clear to me that the Intel Itanium "EEPIC" approach,
which requires even smarter static compilation, is likely to be a vast
mistake in the long run as far as general purpose use is concerned.
It'll be nice stuff if you deploy all your apps in source code form so
that you can recompile in the target environment, to get a static
optimum, but it's terrible if the goal is to deploy precompiled
binaries on a diverse set of hosts.

But to get some _actual improvements_ to architectures that are usable
for OSes strikes me as troublesome.  All the 'popular' systems these
days are based on C (or something vanishingly nearby), and it would
take jumping to an implementation language as esoteric as Smalltalk,
Lisp, or ML in order to get an OS able to make much real advantage out
of special instructions.

And the result is a system SO different that you likely have to start
over from scratch in terms of building system utilities, compilers,
data storage, and such; a big enough project to daunt most would-be
participants.  It's a lot easier to grab a Linux/BSD kernel and do
something in a Unix-like userspace.
-- 
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/advocacy.html
Lisp Users:
Due to the holiday next Monday, there will be no garbage collection.

Re: OOP Language for OS Development

[Christopher Browne]

Oops! Berend de Boer <berend@xsol.com> was seen spray-painting on a wall:
>>>>>> "Brian" == Brian Heilig <heilig@iname.com> writes:
>
>     Brian> is probably the show stopper.  I'm pretty sure it is
>     Brian> impossible to write an entire OS completely in
>     Brian> Eiffel. 
>
> You can't do it in C either. You always need a bit of assember to
> access the hardware.

The challenge in any language is that you need to build several things
that require "stepping outside the language."

- As you say, there's a need to get at assembler procedures in order
  to access hardware.

- There's a need to manage context switching, to manage processes;
  that likely mandates some assembler.  The fact that some languages
  support threading is unhelpful, because that normally requires
  some "outside context." 

- Ditto for memory management; the more the language integrates that,
  the more difficult it is likely to be to use the language to 
  implement memory management.

C is pretty good for the purpose since its primitives _aren't_ much
more than a sort of "high level assembly language."

Languages that assume a garbage-collected memory management scheme are
likely to be particularly challenging ways to do this...
-- 
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/advocacy.html
"Those who doubt the importance  of  a convenient notation should  try
writing a LISP interpreter in COBOL  or doing long division with Roman
numerals." -- Hal Fulton

Re: OOP Language for OS Development

[Isaac Gouy]

Cesar Rabak <crabak@acm.org> wrote in message news:<408C5166.7010903@acm.org>...
> Isaac Gouy escreveu:
> > Hyman Rosen <hyrosen@mail.com> wrote in message news:<2dFic.16950$eK3.5881@nwrdny01.gnilink.net>...
> > 
> >>Thomas Gagn� wrote:
> >>
> >>>Perhaps it's time for such a thing to be attempted.
> >>
> >>Intel 432, Symbolics Lisp machines, probably a host of others.
> >>Such things have been attempted, and are now consigned to the
> >>ash heaps of history.
> > 
> > 
> > Google "Smalltalk On A Risk" SOAR
> 
> Perhaps more sucessful with "Smalltalk On A Risc"?

More successful, yes ;-)

Re: OOP Language for OS Development

[Berend de Boer]

>>>>> "Christopher" == Christopher Browne <cbbrowne@acm.org> writes:

    Christopher> The challenge in any language is that you need to
    Christopher> build several things that require "stepping outside
    Christopher> the language."

    Christopher> - As you say, there's a need to get at assembler
    Christopher> procedures in order to access hardware.

    Christopher> - There's a need to manage context switching, to
    Christopher> manage processes; that likely mandates some
    Christopher> assembler.  The fact that some languages support
    Christopher> threading is unhelpful, because that normally
    Christopher> requires some "outside context."

This is just bootstrapping: the initial part, Eiffel+assembler
boot into the basic kernel. The next part can be normal Eiffel with
the multi-threading support replaced/supported by what your kernel
supports.

That is what SCOOP supports anyway: installable/replaceable
multi-threading using instructions in your .ace file. That's the whole
point of SCOOP that threading is a setting, not something a programmer
should be trusted with to get always right.


    Christopher> - Ditto for memory management; the more the language
    Christopher> integrates that, the more difficult it is likely to
    Christopher> be to use the language to implement memory
    Christopher> management.

You just compile in a different gc.


    Christopher> C is pretty good for the purpose since its primitives
    Christopher> _aren't_ much more than a sort of "high level
    Christopher> assembly language."

Yep, my Linux system locks up now and then when just using mplayer.

-- 
Regards,

Berend.

  ** you're welcome to the #eiffel irc channel on irc.freenode.net

Re: OOP Language for OS Development

[Philippe Ribet]

Brian_Heilig wrote:

> Eiffel Cons (related to OSes):
> There is no turnkey Eiffel compiler for you to use for operating
> systems. All the current compilers are system-oriented, that is, they
> generate systems, which for example have command-line arguments and
> garbage collectors. Unless I'm mistaken this is probably the show
> stopper.
Using SmartEiffel should not be a problem. -no_main option may help.
The garbage collector can be turned off. Then the memory job is limited 
to se_malloc/se_realloc.

> I'm pretty sure it is impossible to write an entire OS completely in
> Eiffel. Number one reason, Eiffel has no method for declaring
> interrupt handlers. The good news is that Eiffel integrates with other
> languages easily (C for example which has an interrupt keyword).
> If efficiency is your number one priority Eiffel may not be for you.
> SmartEiffel and ISE Eiffel generate very efficient code, but I don't
> think it meets the demands of a CPU scheduler, for example.
I did some testing on computationnal code (matix multiplication). Code 
generated by SmartEiffel had exactly the same performance as the same C 
program. But never forget, each time you need extreme performance or 
very specific instructions, you can use C code (inline or external 
function call). This mean you can use assembler too when you really need 
(context swith, hardware access).

-- 
Philippe Ribet



                          The README file said
               "Requires Windows 95, NT 4.0, or better."
                     So... I installed it on Linux!

Re: OOP Language for OS Development

[Georg Bauhaus]

In comp.lang.eiffel Philippe Ribet <p.ribet@tele2.fr> wrote:
:  But never forget, each time you need extreme performance or 
: very specific instructions, you can use C code (inline or external 
: function call).

Is SmartEiffel just using the C calling convention (allowing a host
of languages) or must it be a C program at the other end?
(Proven and efficient matrix multiplication is not always written
in C.)


-- Georg

Re: OOP Language for OS Development

[Brian_Heilig]

Philippe Ribet...
> Using SmartEiffel should not be a problem. -no_main option may help.
> The garbage collector can be turned off. Then the memory job is limited 
> to se_malloc/se_realloc.

So you could, for example, write the really low level stuff in
assembly, write the bulk of the OS in Eiffel, and then use CECIL to
bridge the two? What I'm asking is, if you were writing an OS in
Eiffel, is that what you might do?

If that's all it takes then I highly recommend Eiffel for OS
development. The more I think about it the better it sounds.

Brian

Re: OOP Language for OS Development

[Brian_Heilig]

JKop:
> Why the hell would you want automatic polymorphism? There's times 
> when I want functions NOT to be polymorphic!

It's not FORCED polymorphism. The bottom line is that with automatic
polymorphism you get BETTER performance, because you get polymorphism
only when you need it. Also, as Steve said, it allows you to override
any feature you want without having to put `vitrual' before that
feature's name in the parent.

Brian

Re: OOP Language for OS Development

[Preben Randhol]

On 2004-04-30, Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> wrote:
> In comp.lang.ada Brian_Heilig <heilig@iname.com> wrote:
>> Right, but I believe Eiffel is the best choice except for the
>
> a proprietary language can never be a "best choice", IMHO.
>

Is Eiffel proprietary ?

See second paragraph:

   http://archive.eiffel.com/doc/eiffel.html

3rd table:

   http://archive.eiffel.com/doc/manuals/technology/oo_comparison/page.html

-- 
Preben Randhol -------- http://www.pvv.org/~randhol/

()  "Violence is the last refuge of the incompetent"
/\                                   - Isaac Asimov

Re: OOP Language for OS Development

[Philippe Ribet]

Georg Bauhaus wrote:
> In comp.lang.eiffel Philippe Ribet <p.ribet@tele2.fr> wrote:
> :  But never forget, each time you need extreme performance or 
> : very specific instructions, you can use C code (inline or external 
> : function call).
> 
> Is SmartEiffel just using the C calling convention (allowing a host
> of languages) or must it be a C program at the other end?
> (Proven and efficient matrix multiplication is not always written
> in C.)
> 
You can either inline real C code or call an external function. For an 
external function, C syntax is used to describe parameters only, then 
you link with an object file where this function is compiled into 
(original language can be Fortran, it works fine).

-- 
Philippe Ribet



                          The README file said
               "Requires Windows 95, NT 4.0, or better."
                     So... I installed it on Linux!

Re: OOP Language for OS Development

[Steven Wurster]

Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> wrote in message news:<c6tk6v$amm$1@news.BelWue.DE>...
> In comp.lang.ada Brian_Heilig <heilig@iname.com> wrote:
> > Right, but I believe Eiffel is the best choice except for the
> 
> a proprietary language can never be a "best choice", IMHO.

As I'm sure others will tell you before it shows up on my newsreader,
Eiffel is not a proprietary language.  It's controlled by a non-profit
consortium (NICE), and is undergoing ECMA standardization.  It is true
that the extensions that ISE implements in their products tend to get
added to the language proper.

Java, on the other hand, is proprietary.  It's controlled by Sun,
unless something else has changed recently.  And I believe people are
developing OSs with that language.

Steve

Re: OOP Language for OS Development

[Richard Riehle]

"Berend de Boer" <berend@xsol.com> wrote in message
news:uoepftndp.fsf@xsol.com...
>
> That's more related to multi-threading. Which Eiffel can do, and there
> is even a SCOOP version of SmartEiffel.
>
Is there a currently working version of SCOOP?   What platform?

Richard Riehle

Re: OOP Language for OS Development

[Dr Chaos]

On Sun, 25 Apr 2004 02:42:07 GMT, Hyman Rosen <hyrosen@mail.com> wrote:
> Brian_Heilig wrote:
>> You missed the constrained generic parameter. G -> T means that G is
>> the generic type and it must conform to T. I don't think C++ templates
>> can emulate constrained generics yet, but I could be wrong.
> 
> They sort-of can, because there are ways to do the checks at compile time,
> but no one really cares. Most C++ folks consider it a mistake to try to
> limit generic parameters in this way, because it limits the usability of
> templates for absolutely no reason. 

If the programmer puts it there, usually there is a reason.

> If the template happens to work for
> some class that doesn't conform to T, why should it be prevented from doing
> so?

At some point, C programmers learned many years ago that

   *( (OhWhatTheFuck*) p) = whatever; 

can often seem clever, but is not wise. 

>> C++ will never reach the expressive power of Eiffel, but then again,
>> you can't make an Eiffel compiler solve factorials, so maybe you win?
> 
> Yeah, whatever.

Eiffel doesn't REQUIRE the type constraint.

Re: OOP Language for OS Development

[Berend de Boer]

>>>>> "Richard" == Richard Riehle <adaworks@earthlink.net> writes:

    Richard> Is there a currently working version of SCOOP?  What
    Richard> platform?

Yes, for SmartEiffel, Linux pthreads:

  http://cs.anu.edu.au/~Richard.Walker/eiffel/scoop/

-- 
Regards,

Berend.

  ** you're welcome to the #eiffel irc channel on irc.freenode.net

Re: OOP Language for OS Development

[Ged]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<3AFic.17011$eK3.5247@nwrdny01.gnilink.net>...
> [...]
> If the template happens to work for
> some class that doesn't conform to T, why should it be prevented from doing
> so?
> 
Because in Eiffel its all about the contract.

When the interface accepts paramaters to conform to T the objects
author is taking on a responsibility to ensure that the feature will
always accept a paramater that conforms to T.  The compiler will do
everything it can to help the author meet that commitment.

This means that when the author of another objects uses this object,
he can make sure that he meets the type requirements expressed in the
interface and then move on.

The contract works for both the programmers.  The client programmer
can be confident that future updates to the library are not going to
break his code.  The library programmer can be update code confident
that he will not cause any damage to his clients.

This extra effort helps to avoid situations like this one,
http://www.kuro5hin.org/story/2004/2/15/11942/2702, where Microsoft
developers are forced to code around the dependancy that Borland had
upon a bug.

In summary, you have at least 3 levels:

- Should always work. 
- Happens to works now, but may change. 
- Does not work. 

The middle grey area can be a source of future problems, and should be
avoided.  This is why somebody should be prevented from doing
something that happens to work.

Of course, how much benefit you attach to this all depends upon the
domain you work within.  For some it is essential, for others it is
nuisance.

Re: OOP Language for OS Development

[Thomas Gagné]

Ged wrote:

>Hyman Rosen <hyrosen@mail.com> wrote in message news:<3AFic.17011$eK3.5247@nwrdny01.gnilink.net>...
>  
>
>>[...]
>>If the template happens to work for
>>some class that doesn't conform to T, why should it be prevented from doing
>>so?
>>
>>    
>>
>Because in Eiffel its all about the contract.
>
>When the interface accepts paramaters to conform to T the objects
>author is taking on a responsibility to ensure that the feature will
>always accept a paramater that conforms to T.  The compiler will do
>everything it can to help the author meet that commitment.
>  
>
What' the difference between that and any other statically type-checked 
language?  Does the compiler remember what the programmer said the type 
was and complain if they change it?

-- 
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
<http://gagne.homedns.org/~tgagne/>

Re: OOP Language for OS Development

[Ged]

Thomas Gagn� <tgagne@wide-open-west.com> wrote in message news:<oLWdnfhCGNiYQwXdRVn-jw@wideopenwest.com>...
> Ged wrote:
> 
> >Hyman Rosen <hyrosen@mail.com> wrote in message news:<3AFic.17011$eK3.5247@nwrdny01.gnilink.net>...
> >  
> >
> >>[...]
> >>If the template happens to work for
> >>some class that doesn't conform to T, why should it be prevented from doing
> >>so?
> >>
> >>    
> >>
> >Because in Eiffel its all about the contract.
> >
> >When the interface accepts paramaters to conform to T the objects
> >author is taking on a responsibility to ensure that the feature will
> >always accept a paramater that conforms to T.  The compiler will do
> >everything it can to help the author meet that commitment.
> >  
> >
> What' the difference between that and any other statically type-checked 
> language?  Does the compiler remember what the programmer said the type 
> was and complain if they change it?

The original question was 'If the template happens to work [...] why
should it be prevented from doing so?'

The key difference between Eiffel and other statically type-checked
languages is design by contract, explicitly distinguishing between
'correct use' and 'what happens to work.'  If the pre-conditions are
met, then the post conditions are guaranteed.

Of course, the compiler cannot enforce all of this.  However, it can
provide a lot of support.