Using Objective-C or x (Re: Hurd direction)

[exa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


[This message is an extension of my short suggestion about using linguistic 
support for portability on the bug-hurd list.]

If you used a language with object and message passing semantics, it might 
become a lot easier to make hurd portable.

Candidates:

  1) Obj-c 
  2) Cilk
  3) Custom language extension, new language (like inferno?)
  4) Going C++ (better std lib, still message passing requires lang. 
extension a la Charm++ which is _not_ a fantastic thing). Might be feasible 
since we have a much better std lib now. [*]

Things not to do:

  1) Corba
  2) A "Component Object Model"

Using another language of course does not remove, by itself, complications in 
the present architecture (part of which is dependency on mach)

The candidates have been ordered in order of decreasing feasibility. Many 
people know obj-c and we have a front end in GCC. Cilk is pretty nice, and 
used by some hackers at MIT (and elsewhere presumably). Both are extensions 
to C, so transition is relatively easy. A custom language might be perfected 
but takes time. Extending C++ (in a good way) is very difficult.

What is the advantage of using a concurrent class based[+] (following 
Cardelli's definition) language?
  * shorter/cleaner/better code
  * portability to alternative message passing systems (change the backend)

Regards,

[*] I'm aware that kernel people despise C++. I can't do much about that 
except to point out that if you use C++ right it might be a viable option and 
stdlib, virtual methods, type-checking, genericity, etc. can all be used to 
advantage in modern os code.
[+] Cilk is not class based IIRC, and I don't think Obj-C is concurrent... :)

On Tuesday 17 July 2001 10:35 pm, Farid Hajji wrote:
>
> Hmmm... that seems overoptimistic right now. The Hurd is very closely
> tied to Mach at the moment. Porting it to other uKernels like say, L4,
> would require IMHO a total redesign of some crucial parts. This looks
> more like a 0.x to 1.x (or even 1.x -> 2.x) transition!
>
> Of course, I don't mean a Hurd/Mach-Emulation/L4 port or something
> like this, but a true Hurd/L4 or Hurd/<some_other_uKernel> port.
>
> This said, I have no idea about the FSF's policy w.r.t. bumping version
> numbers of the Hurd.


- -- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7VKCJfAeuFodNU5wRAhHdAKCFvxlJw5jpzTsEmFn9HlFg1oNq8QCdHMBV
DMI/pFbLKC8AjdfOPYP3Nw0=
=7q8/
-----END PGP SIGNATURE-----