Re: Graphic GUI C

On 2009-06-26, James Kuyper <jameskuyper@xxxxxxxxxxx> wrote:
Tim Harig wrote:
On 2009-06-25, jameskuyper <jameskuyper@xxxxxxxxxxx> wrote:
Tim Harig wrote:
I don't know of any C compiler targeted for the CLI; and, I don't know how
such a thing would work since the CIL is fundimentally based in object
technology. C++ != C.
I'm not sure what you're suggesting by that last comment. Almost every
feature of C90, and (in the latest C++ standard, several of the new
features in C99) is also a feature of C++. If there's any feature of C
that can't be implemented in CLI, it seems to me that the
corresponding C++ feature would also not be implementable.
Yes, seeing as C++ was origionally a superset, it is generally possible to
implement C from inside of C++ code. It is a far greater problem to
implement C++ from inside of C code.
I have no doubt that it would be possible to create a compiler that that
could produce CIL bytecode; but, how would you interact with .Net objects?

So, you're not saying that a C compiler targeted at CLI would be
impossible, or even necessarily difficult, but only that CLI offers some
features that are not in the the C language itself? That doesn't seem as

Yes precisely.

serious a problem as implied by your original comment above. I don't
expect the C language and the C standard library to do everything;
nothing is more commonplace than the need for one or more libraries in
addition to the C standard library, to access additional features of a
given platform.

The challange is not just to create an interface but to do so in a way that
would be natural for both the C langauge and the .Net environment. A large
part of the promise of the .Net Framework is that it works almost
identically between different languages. The object interactions for an
algorithm should look identical even if the control structures of two
languages diverge.

Jscript, VBscript, Python, and any other language used for client side
scripting inside of a web browser look almost identical. Where their
varius control models diverge, the data models are all based on the same
DOM objects. The same is true inside of WSH where all of the functionality
is provided by the WScript or CScript objects. In the end, the langauges
are just convinient means to manipulate the objects.

..Net is equivilant. Powershell and C# both access and use the framework in
an almost identical way even though they both have extremely different
structures of logical flow and syntactic sugar. If a C library and
implementation cannot accurately recreate not only the functionallity but
the esthetic style present in the other .Net langauges, then it is an
outsider to the platform.

How difficult would it be to define a library, separate from the C
standard library, that provided access to those extra CLI features
through a C interface? You'd probably want the compiler to be on
intimate terms with this other library, so that it could inline calls
that correspond directly to CLI bytecode. There's probably other way to
do this, such as language extensions, but I prefer a library if it's at
all feasible to provide the functionality in that form.

I suspect you would need a runtime marshalling agent operating between
*any* C only interface. It would handle transparent remapping of things
which could not be known when the C code was compiled.

It may then still be necessary to add some syntactic sugar as an
extension to the C stanard to match the calling convention used by the
other .Net languages. I have seen some very object oriented C; but, I
cannot foresee anything which could express the .Net framework
relationships on more then a functional level using function based
calling conventions.

In the end, you spend a momentus amount a work while risking creating
langauge that is neither C nor .Net. It is likely that you would have
reaped better results by using a language that by its object oriented
nature already fits nicely into the framework.

I am very fond of the C langauge; but, I do not suppose that it is perfect
for everything. A hammer can drive a screw; but, it is no replacement for
a screwdriver.
.

Relevant Pages

  • Re: Reddit Guys on the Pros and Cons of Lisp
    ... >> I never have to do that with Java. ... > language features, etc. ... They either have the feature or they don't. ... > libraries doing almost the same - for those languages. ...
    (comp.lang.lisp)
  • Re: 3GL vs. 4GL [was: Re: LSP and subtype]
    ... But that doesn't mean the language designers shouldn't ... exceptions directly or limiting the use of the feature. ... that there is plenty of room for foot-shooting in all sufficiently ... problems where you'd really want to have language support but most other stuff can be expressed pretty nicely in libraries in many languages. ...
    (comp.object)
  • Re: 3GL vs. 4GL [was: Re: LSP and subtype]
    ... But that doesn't mean the language designers shouldn't ... >>> exceptions directly or limiting the use of the feature. ... > Whether libraries are useful is not relevant. ...
    (comp.object)
  • Re: 3GL vs. 4GL [was: Re: LSP and subtype]
    ... But that doesn't mean the language designers shouldn't ... exceptions directly or limiting the use of the feature. ... necessarily bound closely to hardware computational models. ... 3GL like C++, Java, C# augmented with appropriate libraries? ...
    (comp.object)
  • Re: Binding or not binding
    ... But I will really like to be more active using and promoting Ada. ... In general, the conventional wisdom is that you should simply bind to existing libraries and as a general rule, this usually makes sense. ... However, having said that, the net is full of libraries in a variety of languages implemented natively in that language and the existence of these native libraries is sometimes what makes people call those languages "good". ... So, if my goal is to just get some work done, and I need the functionality of some library, and the functionality is non-trivial, I'll usually go the binding route. ...
    (comp.lang.ada)