[Prev][Next][Index][Thread]
Re: Thanks for your reply Bruce
Shawn wrote:
> > For the same reason that there exist compilers for C++, FORTRAN, Ada,
> > Scheme, Eiffel (and many other languages) that produce output in C rather
> > than in machine code or assembly language:
> >
> > - it's easier
>
> Benefit then to using Dylan ? Because its simpler to learn and utilize ?
We're not talking about languages and their benefits (Dylan wins...), we're
talking about compiler technology.
Functional Developer is a full, thoroughbred Dylan to native machine code
compiler. It parses, produces an intermediate representation, then reduces this
to assembler for the platform it's on. It does it very well, too, by all
accounts. Once it's done this, it uses a third party linker, either GNU or MS
to link the code with any other code libraries that are needed, and make the
final executable.
For those with more limited resources, there is a different way of doing things
that is available. It has nothing to do with the language being implemented,
it's a resource issue. The language is parsed, and intermediate representation
is produced, this is reduced to assembler then linked, all the same steps as
before. The difference is that the intermediate representation is C. C makes a
good intermediate representation because C compilers are ubiquitous, C is a
well understood language for implementors (the end users don't have to know
it's even there...), and C compilers have been around long enough that they do
a good job of optimizing code.
End-users need never see the C code, they need never know the C compiler is
being used (in theory...). The C compiler is just a convenient object code
producer, we are not interested in reading or working with C. Translating Dylan
to C is not the aim, compiling Dylan is. There are Lisp, Eiffel and other
compilers that work in the same way.
> >
> > - every machine in the world has a C compiler
>
> Then why not just use one of them ?
Because we want to use a Dylan compiler. I don't want to go into langauge war
teritory, so I'll stick with tautology...
>
>
> >
> > - you don't need to worry about instruction set styles and encodings and
> > register architectures on jillions of different machines (or even on one)
> >
> > - you don't need to worry about instruction selection and scheduling and
> > so forth either.
> >
> > - you don't need to worry about runtime conventions such as how to call
> > functions and which registers to save and so forth
> >
> > - you don't have to worry about how to call OS functions and standard
> libraries
> >
> >
> > The C compiler already knows all that stuff. Someone worked hard on it.
> >
> >
>
> Then there is an advantage to using the C code relating to portability,
> functionality, and speed optimizations ? It would be to much work too make an
>
> optimized Dylan compiler for every situation ?
For a group of volunteers working on code from an academic project, yes.
> > > I would think C/C++ to Dylan would be more useful ? Can this take C
> > > and go the other way ?
>
> This is an important topic I think, Eiffel has a C/C++ legacy interface as
> well as Dolphin, why not Dylan ?
Functional Developer can link quite happily to COM objects, and both FD and
Gwydion Dylan have elegant systems for interfacing to C code and normal
libraries/shared libraries. As other posters have already pointed out, C++
interoperability is a real minefiled for any language. Different C++ compilers,
ANSI or not, cannot talk to each other without an object model shim. The name
mangling and vTables are different.
Dylan handles all this as well as can be expected, better even for C,
especially if the C++ programmer knows what extern "c" does. Since d2c compiles
to C as an intermediate representation, a notional d2c++ could link to C++
compiled using the same compiler, but this isn't planned as far as I know.
> I can see the benefits above in being able
> to use existing C tools to aid in efficient programming from Dylan, but what
> about all the code written in C++ that could be used in the Dylan.
It can't be used in other C++ code either, unless it's COM in which case FD has
no problem, or a well-structured shared library in which case d2c has no
problem.
> I have
> about five different rendering libraries all optimized for speed that can
> not be used in Dylan because they are coded in C++. This is a waste to have
> to rewrite them in Dylan.
OpenGL can be used with no problem form FD and d2c. It's a waste to rewrite
rendering libraries now full stop.
> >
> > The C output isn't intended to be human-readable (although d2c takes some
> > care to preserve function and variable names etc in the generated code --
> > much better than, say, CFront -- the original C++ compiler -- did).
> >
> > You don't use d2c to convert your Dylan program to C and then work on it
> > some more in C. You program in Dylan. d2c compiles Dylan into C, and
> > then automatically calls the C compiler to produce a runnable program.
> > You usually never even look at the C code.
>
> Please excuse my ignorance on programming details, I am not a professional
> programmer with years of experience. I REALLY like Dylan and I am very happy
> using it, but I see so many other languages trying to bridge the barrier
> between C++ and themselves. Dylan is extremely weak (unless I have missed
> something) when it comes to integrating with the most popular one of all
> C++.
C++ interoperability is a problem the C++ community has not yet addressed. I
can call C or Pascal or Dylan code from other languages with no problem. C++
has only itself to blame.
> >
> >
> > The problem of taking a program in one language and turning it into a
> > human readable, idiomatic, maintainable program in another programming
> > language is a *much* harder one. Well beyond the current state of the
> > art, I'd say.
>
> I am not asking for a direct translation of C++ to Dylan in human readable
> form, just the same thing as the D2C, a compilation of a C++ project with
> headers etc. to a useable module that can be easily called and used in Dylan
> without having to manually code 100+ header files into Dylan equivalents.
Compile it as a COM object or write a procedural front end. I know neither is
ideal, but it's doable. The same advice would apply to C++ compilers from
different vendors or other language compilers.
>
>
> Please I am not trying to be rude its just ignorance on my part, why can we
> not use SWIG to generate interfaces or something similar automatically ?
You can use melange or the FD equivalent to generate Dylan imports for C code.
C++ is an interoperability minefield: source won't compile with ANY other
langauge unless it has a procedural front-end, object code won't work WITH
OTHER C++ COMPILERS, never mind other language compilers, without an object
model shim or a procedural front end.
This is probably one reason why Apple have stuck with Procedural front ends to
all their modern, internally object-oriented systems.
> I looked at SWIG but you need to be well versed in both C++ and Dylan to make
>
> it work, I am trying to stay away from C++ and just concentrate on Dylan.
Does SWIG do Dylan? I'm ignorant as to what SWIG is...
- Rob.
Follow-Ups:
References: