Re: thought: C, dynamic types, and closures



Rod Pemberton wrote:
"Laurent Deniau" <laurent.deniau@xxxxxxx> wrote in message news:f6fqh2$hij$1@xxxxxxxxxxxxxxxxxxx
You might be interested by the C Object System:

http://cern.ch/laurent.deniau/html/cos-oopsla07-draft.pdf


I'm sure that your paper was intended for a audience different from me. But, they still may have some of the same questions and thoughts
I had. I wrote them down as I read, and then I recommented them to
point out first time misunderstandings.

thanks for your comments. I start by the end ;-)

8) From the web-page: http://ldeniau.web.cern.ch/ldeniau/oopc.html

"I have developed some frameworks to explore various object models and simplify object oriented programming in C"

Why?

"The motivation to develop such frameworks on top of the C language may not be obvious. While many new languages appear each year with new syntax and little new concepts, I prefer to try to lift C up to the level of other high level languages. C is portable, efficient, widely available and standardized. This is probably why it is also the reference for other languages when memory and speed efficiency matter and why most languages have a Foreign Function Interface to C.
Still many virtual machines, interpreters, compilers or operating systems are written in C. If one often blame C to be a low level language similar to a super assembler, it should be worthwhile to raise C to the level of the other high level OO languages (and beyond?). This is the aim of the following frameworks entirely written in ISO C."

Finally, the rational behind the .pdf, but it wasn't in the .pdf (or
I missed it the way things were stated...). It would've answered many of the questions I asked...

You are absolutely right and since I wrote the web page months before
the paper, I forgot that its content could highlight the motivations. I will include this point into the next version of the paper, that is the manual. But for the moment, I am completely rewriting an cleaning the macros of COS during my spare time.

1) "[Copyright notice will appear here once preprint option is removed.]"

Well, you just "distributed" it to the whole Internet without a copyright notice...

Because it was intented for OOPSLA which provide a stylesheet with
copyright on first non-draft release of the paper. Next version will not
be for OOPSLA and will be under the GPL.

2) Given

"COS is developed in the hope to solve fundamental programming problems related to applied metrology [12, 13]."

and

"COS is a small framework entirely written in portable C99 which provides programming paradigms like objects, classes, metaclasses, generics, multimethods, delegation, exceptions, contracts and closures.",

why an enhanced language instead of a specialized library? Don't answer that. At that point, I thought you were talking about an extended C language, i.e., compiler grammar or parser/lexer modification, and not a library and/or set of includeable files needed to implement object oriented paradigms...


4) "1. Motivation The C Object System (COS) is a small framework which adds an object-oriented layer to the C programming language [1,
2] using its programmable capabilities1 while following the principles of simplicity of OBJECTIVE-C [4, 5, 6] and of extensibility of CLOS [7, 8, 9]. It is legitimate to ask what yet-another object-oriented language can bring to the community?"

Why no specific mention or comparison to C++?

Because of space available. I have been using C++ for 15 years and I couldn't mention C++ without saying a lot of things (first long paper version got a complete section on C++). Since it was not essential to understand what is COS, I removed it to fulfill the 18 pages constraint.

Why do I need C Object
System instead of C++, Objective-C, especially if not solving metrological problems? I.e., is this too specialized an adaptation of C to be of widespread use?

It can of course be used for any project. But I did not want to say that COS is the solution for to all problems, so I focused the paper on what I know.

If so, why not a library and/or set of
includable files not tied to a specific compiler implementation? (again, I had the same incorrect interpretation as above...) Doesn't
an extended language go against some of your stated design goals, i.e., portability? (again, misunderstanding about how you implemented extensions).

;-)

5) "Table 1. COS keywords and alternate keywords."

[Table 1. adds roughly 81 keywords to language.]

I see no mention of how the language extensions affect the C grammar
which is LALR(1) except for if vs. if-else and typedef's. I.e., are
they useable with grammars for yacc/flex or bison/lex? (even here,
I hadn't figured out you weren't extending the compiler per se).

It seems that the reviewers got the same view of the paper as yours (points 2 to 5) since most of the questions I reveived were on compilers/languages comparisons. Nothing about design, C or flexibility/extensibility of projects...

6) Also, are you recreating C++ functionality with keywords: TRY,CATCH,THROW? What about "3. Classes" and "3.3 Class inheritance"?
Since C++ is object oriented, wouldn't it have been a better starting point?

The C++ *language* is much more complex than the C language and extending C++ with dynamic types while being compatible with all the existing features is not easy. Exceptions are just a small part of the framework and do not justify the use of a language with native exception support as a start. And up to now, C++ is far less portable and compatible than C.

7) "Ooc preprocessor Despite of its age, it is one of the most impressive framework[s] available on this topic [40]. It comes with the ooc preprocessor written in AWK."

Huh, the ooc preprocessor comes with the occ preprocessor? I.e., awkward language...or something missing? And, framework needs an s.

Right, it should be corrected.

Many thanks for your interesting feedback.

a+, ld.
.



Relevant Pages

  • Writing a managed compiler framework, suggestions/feedback?
    ... I'm writing a managed compiler framework primarily focused on the .NET ... Common Language Infrastructure, ... came to the various pre-compilation functions of a language's compiler. ...
    (comp.compilers)
  • Re: Who owns C#?
    ... type_info,bad_cast,bad_typeid and exception). ... In C# the language and framework are much more closely entwined because ... everything derives from System.Object and the compiler must know this ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Bye bye CF.Net for Delphi dev?
    ... deliver it in a readily usable form for .NET developers. ... believe the Delphi language could offer great things on the .NET platform, ... It's also a framework. ... abstracts them from the Windows OS. ...
    (borland.public.delphi.non-technical)
  • Re: Who owns C#?
    ... Framework or whatever you want to call it. ... defined ONLY in the library and not referenced by the C++ LANGUAGE spec. ... now you're comparing apples to oranges. ... The compiler is not the language. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Who owns C#?
    ... now you're comparing apples to oranges. ... The compiler is not the language. ... framework" in C++ and C. ...
    (microsoft.public.dotnet.languages.csharp)