Interfacing C/C++ to Modula-3/Oberon Re (2): Use of Modula-3 
Author Message
 Interfacing C/C++ to Modula-3/Oberon Re (2): Use of Modula-3

Quote:


> > The biggest problem with translating C into Wirthian languages
> > is the address arithmetic.  Stepping up and down arrays with
> > foo++, and so on, has no logical counterpart in Wirthian lang-
> > uages.

> I sincerely doubt that *p++ et al really is the problem. Good commercial
> support and painless use of C (and C++) interfaces is a problem. I am
> one of those C++ programmers that now and again look at other languages.
> The number one thing that puts me off is interfacing with existing
> libraries, the ever changing OS technologies of Mac OS and Windows, etc.
> This has to be absolutely painless! The ++ thing is practically
> irrelevant. These days I find that proper indexes more often than not
> actually is faster than *p++ so there is no longer any excuse to use
> this ugliness even in C or C++ and certainly not in prettier languages.
> The Oberon family has the added disadvantage of being both OS and
> language. If they want out they must decide whether Oberon is a language
> or an OS. As a combination it will never leave the lab. For both, if
> alternatives are to take off they must interface to code written in C
> and C++ smoothly. That is key.

Acutally Oberon has progressed far beyond the "language/OS only" stage
and is no longer any more tied to its "system" roots than C is tied to
Unix.  (Of course Unix's huge and growing popularity has made it an
asset to C rather than a handicap.)  Using BlackBox Component Pascal
(formerly Oberon/F) you can create DLLs, stand-alone apps and OLE
clients/servers as well COM objects.  POW (Programmers Oberon Workbench)
can also create EXE's and DLLs.  There is a version of POW called
BlueGnu which includes an Oberon compiler and a Gnu C++ compiler.  
Even if your not interested in Oberon, BlueGnu is good for the C++
compiler itself.  And even System 3 for Windows can now create DLL's
and EXE's, though the interface your left with is "non-standard".  
In the Unix world there are several stand-alone Oberon compilers.
One of the best ones is OOC.  There is a GUI library called Visual
Oberon that runs on top of it.  

- Show quoted text -

Quote:
> An outsiders suggestion and sketch on how: I think it needs a language
> extension of some kind. One might look at C++ use of extern "C" {...}
> extern "Pascal" {...}, extern "Ada" {...} etc. Something along the lines
> of...

>   MODULE EXTERN_C ModuleName; (* or EXTERN_CPP or whatever... *)

>   (* this is a pseudo module that is extendable.
>      there are many of them. add as needed.
>      like C++ namespaces. the compiler will have to merge
>      all available incarnations.

>      it can and should be precompiled as any module

>      all names introduced by #include belong to ModuleName
>      and can be used as any ordinary name

>      ( Mapping C (or C++) to Modula is perhaps impossible, I don't know.
>        what about typedef? union? and...
>        dear compiler vendor: have fun dealing with #macros -
>        the #ugliest language feature known to mankind )
>   *)

>   #include <foo.h>   // basically the entire module declaration
>   #include "bar.h"   //   would be valid C (or perhaps even C++)

>   END.

I haven't tried statically linking C or C++ to Oberon or Modula-3, but
I have linked dynamic libraries written in C++ to Oberon and it really
isn't that hard.  Most Oberon compilers support some kind of name
aliasing so you don't have to worry about different naming conventions.
(For example, C supports underscore, but it's not part of the Oberon
language definition, though some compilers support it.)  The convention
you show of "including" C code directly into Oberon or Modula-3 is
probably undesireable.  I've seen many ugly things done using the
C pre-processor including dropping an entire C program into the middle
of the code instead of just the header information.  A better solution
IMHO is what is already available to Modula/Oberon programmers.  There
is a program called H2D which takes a C/C++ header file and translates
it into a definition file that can be used in Modula-2 or as a psuedo-module
in Oberon.  I think this approach is better because 1) you're protected
from "funky use" of the C pre-processor and 2) you can see the actual
Modula code and hand-tweak it where necessary.

Quote:
> Until it's that easy I think better alternatives to C and C++ will have
> a real hard time (unless they like Java (even looks like C - ugh) define
> totally new markets). Manual editing of these modules is definitely out.
> It will never happen. Automatic translation to proper Modula-X or
> Oberon-N just isn't good enough. Can't risk missing important OS
> technologies and third party libraries. It has to be totally
> transparent.

>  - Lars

Automatic translation plus manual tweaking is really the only safe
way to go.

.



Sun, 11 Mar 2001 03:00:00 GMT  
 Interfacing C/C++ to Modula-3/Oberon Re (2): Use of Modula-3

Quote:

> Acutally Oberon has progressed far beyond the "language/OS only" stage
> and is no longer any more tied to its "system" roots than C is tied to
> Unix.

Good.

Quote:
> > An outsiders suggestion and sketch on how: [...]
> The convention
> you show of "including" C code directly into Oberon or Modula-3 is
> probably undesireable.  I've seen many ugly things done using the
> C pre-processor including dropping an entire C program into the middle
> of the code instead of just the header information.  A better solution
> IMHO is what is already available to Modula/Oberon programmers.  There
> is a program called H2D which takes a C/C++ header file and translates
> it into a definition file that can be used in Modula-2 or as a psuedo-module
> in Oberon.  I think this approach is better because 1) you're protected
> from "funky use" of the C pre-processor and 2) you can see the actual
> Modula code and hand-tweak it where necessary.

Maybe I was unclear (a quick sketch, thinking out loud, not a thoroughly
worked out proposal). This is not intended to be textual #inclusion as
it is done in C or C++. I certainly don't want introduce #macros into
Modula-i/Oberon-j.

It is supposed to be a much more transparent version of the automatic
conversion you describe above (H2D). Much more transparent.

It should be "compiled", not necessarily by the ordinary compiler, but
the result should be a proper, compiled definition "module" or rather a
"pseudo module" for everything "C" without a user having to wade through
tons of header files, deciding what can be skipped, what depends on
what, what goes into which module, etc, etc...

The language extension would be that this "module" is open for extension
such that its definition module doesn't have to be compiled (converted)
all at once. Need more headers, compile another and merge. The extension
would probably also affect the type system to accommodate for foreign
memory layout, perhaps restrictions on inheritance, be considered unsafe
(pointer checks, array checks,...), etc for the "C" stuff.

This is one crucial difference between what you describe and I have seen
in other incarnations. There is a fundamental mismatch between a
language with a module system and one without. I think that the nice
languages of the world has to ease up a bit and accommodate for the de
facto standard (C and C++) if they want to be part of the game. I hope
they do want that. The other difference is that it really must be fully
transparent, complete and painless so that one can use existing
C-libraries without any manual translation of its headers.

I realize that proponents of cleaner languages consider this like
swearing in church, but isn't it better to give up some in order to gain
critical mass? The unsafe and ugly C stuff will be properly encapsulated
in a C-MODULE of its own and wont pollute the rest. One wouldn't even
have to look at the C stuff. You'd have to do that with actual source
translation.

It is true that it is hard to implement. Especially generating
precompiled Modula/Oberon definition modules from code that contains
#define (one important goal is to get rid of #define it should certainly
NOT be allowed to propagate its misery outside the module). Even more
difficult when they must be open for extension. There is no natural
mapping between module in Modula/Oberon and #include. Note that it is
not easier to this do by hand as you suggest and that is a big problem
for acceptance of these languages (and they are not widely accepted are
they?). If it is possible to write a C compiler then it should be
possible to implement the above or something along those lines (with
some exceptions for the most grotesque uses of #define (as if there is
any use of #define that isn't grotesque;))

Quote:
> > Until it's that easy I think better alternatives to C and C++ will have
> > a real hard time (unless they like Java (even looks like C - ugh) define
> > totally new markets). Manual editing of these modules is definitely out.
> > It will never happen. Automatic translation to proper Modula-X or
> > Oberon-N just isn't good enough. Can't risk missing important OS
> > technologies and third party libraries. It has to be totally
> > transparent.

> >  - Lars

> Automatic translation plus manual tweaking is really the only safe
> way to go.

Good enough for a few, but I think many find it insufficient. These
languages are not widely used are they? IMHO this is sad. The Wirth
heritage deserves better and there is a need for something better. That
better language will certainly not replace C within the forseeable
future. This will simply not happen. The better language must be able to
coexist side by side, peacefully and transparently even though the
adaption and cooperation wont come from the C side. It has to come from
the other side or C (and its derivatives) will continue to rule
unchallenged.

 - Lars

--



Mon, 12 Mar 2001 03:00:00 GMT  
 Interfacing C/C++ to Modula-3/Oberon Re (2): Use of Modula-3

Quote:

> [snip]

> Maybe I was unclear (a quick sketch, thinking out loud, not a thoroughly
> worked out proposal). This is not intended to be textual #inclusion as
> it is done in C or C++. I certainly don't want introduce #macros into
> Modula-i/Oberon-j.

> It is supposed to be a much more transparent version of the automatic
> conversion you describe above (H2D). Much more transparent.

> It should be "compiled", not necessarily by the ordinary compiler, but
> the result should be a proper, compiled definition "module" or rather a
> "pseudo module" for everything "C" without a user having to wade through
> tons of header files, deciding what can be skipped, what depends on
> what, what goes into which module, etc, etc...

> [snip]

> [...] These [Wirth] languages are not widely used are they? IMHO this is
> sad. The Wirth heritage deserves better and there is a need for something
> better. That better language will certainly not replace C within the
> forseeable future. This will simply not happen. The better language must
> be able to coexist side by side, peacefully and transparently even though
> the adaption and cooperation wont come from the C side. It has to come
> from the other side or C (and its derivatives) will continue to rule
> unchallenged.

Yes! Right on! This is exactly the way I feel, and the way I would have
expressed it if I had the (language) power to do so. It even pained me
to have to cut the quote to make my "me too" reply acceptable for the
newsgroup. Thank you, Lars. This is the stuff I dream about.

Luc
--
"All Cretans are evil liars" -- Cretan philosopher
"Ich bin ein Kretenzer" -- Flemish philocreter



Tue, 13 Mar 2001 03:00:00 GMT  
 Interfacing C/C++ to Modula-3/Oberon Re (2): Use of Modula-3

Quote:

> > The convention
> > you show of "including" C code directly into Oberon or Modula-3 is
> > probably undesireable.  I've seen many ugly things done using the
> > C pre-processor including dropping an entire C program into the middle
> > of the code instead of just the header information.  A better solution
> > IMHO is what is already available to Modula/Oberon programmers.  There
> > is a program called H2D which takes a C/C++ header file and translates
> > it into a definition file that can be used in Modula-2 or as a psuedo-module
> > in Oberon.  I think this approach is better because 1) you're protected
> > from "funky use" of the C pre-processor and 2) you can see the actual
> > Modula code and hand-tweak it where necessary.

> Maybe I was unclear (a quick sketch, thinking out loud, not a thoroughly
> worked out proposal). This is not intended to be textual #inclusion as
> it is done in C or C++. I certainly don't want introduce #macros into
> Modula-i/Oberon-j.

> It is supposed to be a much more transparent version of the automatic
> conversion you describe above (H2D). Much more transparent.

Then perhaps we are closer to the same idea than I thought.  I would
definitely agree that H2D needs to be improved.  And we probably need
different versions of H2D for M2, M3 and Oberon.  Right now it's sort
of "one translator fits all" so there is little hope of the translation
coming out right the first time.  I would still, however, prefer to
see the actual translated code rather than to have this part of the
process hidden from me.  Call me a skeptic, but I have my doubts about
how good this process can be when done "automagically".  For one thing
even if we considered the Modula languages stable, C++ is a moving
target.  Besides macros we now have templates to deal with.  By the
way, some years ago I did the equivalent of C++ templates in C using
macros.  This was before C++.  I know, completely off the subject
but I've never had the opportunity to brag about that before now. :-)

One other advantage I see to having the actual definition module is
for debugging and documentation purposes.  When trying to figure
out how a program is put together I would rather be able to look
at the definition module in M2/M3 form than to have to switch back
and forth between Modula and C++ modes.  I know sometimes that's
not possible.  At times you have to look at the "guts" of a library
to figgure things out.  But if all I needed to look at were interfaces,
I'd prefer them to be uniform.

That being said, I suppose a programming enviornment could be configured
to handle both options.  One could perhaps do the "include <c_header.h>"
and the enviornment could spit out a definition file, or try to handle
everything itself.  If things didn't work right it could then go ahead
and spit out the definition file and let the programmer try to fix it.

Quote:
> This is one crucial difference between what you describe and I have seen
> in other incarnations. There is a fundamental mismatch between a
> language with a module system and one without. I think that the nice
> languages of the world has to ease up a bit and accommodate for the de
> facto standard (C and C++) if they want to be part of the game. I hope
> they do want that. The other difference is that it really must be fully
> transparent, complete and painless so that one can use existing
> C-libraries without any manual translation of its headers.

That can possibly work provided that the C/C++ programs are restricted
to some kind of standard.  I know that I've personally done some "ugly"
things with C/C++ that would be hard to handle via automatic translation.
But even the ugliest C/C++ programs could be wrapped in a "pretty package"
that an auto-translator might have a prayer of handling.  In fact isn't
that what CORBA is supposed to be about?  I believe there is a CORBA
idl compiler for Modula-3, but someone correct me if I'm wrong.

Quote:
> I realize that proponents of cleaner languages consider this like
> swearing in church, but isn't it better to give up some in order to gain
> critical mass? The unsafe and ugly C stuff will be properly encapsulated
> in a C-MODULE of its own and wont pollute the rest. One wouldn't even
> have to look at the C stuff. You'd have to do that with actual source
> translation.

Well there you have it.  Perhaps the Modula community needs to specify
a "wrapper format" for C/C++ modules which can be auto-translated.

Quote:
> It is true that it is hard to implement. Especially generating
> precompiled Modula/Oberon definition modules from code that contains
> #define (one important goal is to get rid of #define it should certainly
> NOT be allowed to propagate its misery outside the module). Even more
> difficult when they must be open for extension. There is no natural
> mapping between module in Modula/Oberon and #include. Note that it is
> not easier to this do by hand as you suggest and that is a big problem
> for acceptance of these languages (and they are not widely accepted are
> they?). If it is possible to write a C compiler then it should be
> possible to implement the above or something along those lines (with
> some exceptions for the most grotesque uses of #define (as if there is
> any use of #define that isn't grotesque;))

If it seems I'm suggesting that hand-translation is EASY let me be the
first to say that it's EXTREMELY TEDIOUS!  I wouldn't think about trying
to translate a large C/C++ header file without using the H2D utility.
But still I had to make some changes to it to get everything to work
right.

Quote:
> > Automatic translation plus manual tweaking is really the only safe
> > way to go.

> Good enough for a few, but I think many find it insufficient. These
> languages are not widely used are they? IMHO this is sad. The Wirth
> heritage deserves better and there is a need for something better. That
> better language will certainly not replace C within the forseeable
> future. This will simply not happen. The better language must be able to
> coexist side by side, peacefully and transparently even though the
> adaption and cooperation wont come from the C side. It has to come from
> the other side or C (and its derivatives) will continue to rule
> unchallenged.

>  - Lars

For me its not simply a question of "good enough".  I'd love it if the
entire process was completely automatic.  But unless the C/C++ code is
restricted someone the task of creating the "perfect automatic translator"
will be a daughting one.  Of course I could talk about the difficulties
of interfacing C and Java, but we all know that Java became popular
without having to really compete directly with C.

On the other hand one of the reasons given for Python's popularity is
it's ease of interfacing with other tools such as C.  But I know too
little about python to be able to comment on it much.  From my
understanding Python, though it has Modula-3 influences, is closer to
being a scripting language like Tcl and hence the issues in intefacing
it to C are probably much different than that of interfacing a compiled
language like Modula-3 or Oberon.  But I could be wrong.



Tue, 13 Mar 2001 03:00:00 GMT  
 Interfacing C/C++ to Modula-3/Oberon Re (2): Use of Modula-3

The OOC/oo2c compiler offers two ways for using other languages:

Generation of a definition module that directly maps to the underlying
froeign language source. E.g. replacing struct by RECORD etc. While
this is nice you will get problems when the foreign code conatains for
example defines. You will also get problems,w hen you want to extent the
classes defined in your definition module by inheritence, since the
foreign objects are not prepared for it (c struct miss the type information
needed by the oberon code). To solve this, OOC implements "FOREIGN" modules,
which lets you define real oberon objects and map them into constructs
undertsnadable by the foreign language. For example the low level oo2c
io stuff uses foreign modules to map the POSIX io routines implemented
in C onto real Oberon objects. These objects are full Oberon objects, they
can be inherited garbage collected etc. By using foreign modules you can
also solve the problem defines or OS specific code (for example different
includes depending on the UNIX flavour used) within the foreign module, thus
hiding such details from the rest of the Oberon code. Possible uses:
Interfacing database drivers from different vendors, implementing CORBA by
writing wrapper modules for an existing CORBA implementation, using full
OO features of Oberon, but reducting CORBA implementation by writing
interfaces.As mentioned in another mail, this technic is the future for
oberon, reusing and encapsulating existing solutions and thus enlarging
the existing man power of the oberon community.

--
Gru?...
       Tim.      



Mon, 19 Mar 2001 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Modula 2 for Macs - CS instruction

2. Teaching Ada in CS-1/2 (instead of Pascal/Modula)

3. Modula-2, Modula-3, C or C++

4. Report on defect in M2 vs C (Was Modula-2, Modula-3, C or C++)

5. Report on defect in M2 vs C (Was Modula-2, Modula-3, C or C++)

6. Report on defect in M2 vs C (Was Modula-2, Modula-3, C or C++)

7. Modula-2, Modula-3, C or C++

8. to CS: or not to CS: in F-PC assembler

9. translation tools C to Modula-2 and Modula-2 to C

10. Modula-2 for cp/m-80 (was: turbo Modula-2)

11. Report on defect in M2 vs C (Was Modula-2, Modula-3, C o

12. MODULA-2 (OR MODULA-3) GRAMMAR

 

 
Powered by phpBB® Forum Software