Loading ...
Sorry, an error occurred while loading the content.

Re: Improving external C

Expand Messages
  • Dominique Colnet
    ... Good. ... Can you remember me how to access to this external C documentation (to see if this is a really scary spec. ;-). ... Yes ... Yes too. ... The
    Message 1 of 5 , Mar 1, 2001
    • 0 Attachment
      Thomas Aglassinger writes:
      > On 27-Feb-01, Dominique Colnet wrote:
      >
      > >> I started to implemented external "C" according to ETL3. [...]
      > >
      > > First, have a look in the EIFFEL_PARSER class to see what happens
      > > with NATIVE_C_PLUS_PLUS and NATIVE_WITHOUT_CURRENT. Then, most
      > > modification should be localized in NATIVE_WITHOUT_CURRENT.
      >
      > Ok, that helped. I eventually came up with something that basically
      > works, at least for the "C struct ..." stuff.
      Good.
      >
      > However, I'm extremely unhappy about BM's current proposal. Unlike
      > the external "C++", external "C" is very incomplete, inconsistent,
      > and sometimes illogical and dangerous. Of course, it's a very early
      > proposal.
      Can you remember me how to access to this external "C" documentation
      (to see if this is a really scary spec. ;-).
      >
      > Point is, I'm not sure how I should go ahead. The implementation is
      > basically solved, it's the specs that make me scratch my head.
      >
      > During the last days, I spent more time compiling a list of issues
      > than toying with the source. But now I'm not sure where to go with
      > it. It's definitely off-topic for this SE mailing list. Talkitover
      Yes
      > has a group about ETL3, but seems to be dead (some people already
      > raised issues about external "C", but not that anything would have
      > come from this). And comp.lang.eiffel might result into too much
      > noise.
      Yes too.
      >
      > I want to avoid ending up in any NICE-esque discussions, I just want
      > a basically sensible implementation soon because the limited
      > external "C" in SE annoyed me since day one of using it. But I also
      > don't want to establish any premature de-facto standards with a
      > design based on "because it seemed as a good idea at that time".
      >
      > Any suggestions?
      The goal of this work, IMHO, is not really to improve the C interface.
      From my point of view, c_inline_c allow you to make nearly what you
      with the C interface.
      The most important goal is to make SmallEiffel external "C" compatible
      with ISE external "C".
      If the external "C" spec. is really scary, we can also decide not to
      be compatible. If this spec. is not so bad, I think it is better to be
      compatible even if the spec is not perfect from our point of view.
      Best regards,

      --
      --------------------------------------------------------------
      Dominique.Colnet@... -- UHP (Nancy 1) -- INRIA Lorraine
      http://SmallEiffel.loria.fr -- The GNU Eiffel Compiler
      POST: Loria, B.P. 239,54506 Vandoeuvre les Nancy Cedex, FRANCE
      Voice:+33 0383593079 Mobile: +33 0665362381 Fax:+33 0383413079
    • Thomas Aglassinger
      ... http://SmallEiffel.loria.fr/Mailing-list/msg03188.html (See the end of the message; before it refers to the old ISE implementation) ... ETL3 has a C
      Message 2 of 5 , Mar 1, 2001
      • 0 Attachment
        On 01-Mar-01, Dominique Colnet wrote:
        > Thomas Aglassinger writes:
        >> On 27-Feb-01, Dominique Colnet wrote:
        >>
        >> However, I'm extremely unhappy about BM's current proposal.
        >> Unlike the external "C++", external "C" is very incomplete,
        >> inconsistent, and sometimes illogical and dangerous.
        >
        > Can you remember me how to access to this external "C" documentation
        > (to see if this is a really scary spec. ;-).

        http://SmallEiffel.loria.fr/Mailing-list/msg03188.html

        (See the end of the message; before it refers to the old ISE
        implementation)

        > The goal of this work, IMHO, is not really to improve the C
        > interface. From my point of view, c_inline_c allow you to make
        > nearly what you with the C interface.

        ETL3 has a "C inline", which would be very powerful, but IMHO
        currently is by far the worst part of the specs.

        > The most important goal is to make SmallEiffel external "C"
        > compatible with ISE external "C".

        Be aware that there are currently two ISE-syntaxes:

        The old one, which is even more cryptic than C (kinda "design goal:
        dethrone Larry Wall"). I don't care about that one.

        The new one, as described in ETL3 is a lot more legible, and tries
        to address many issues of the old one. Basically, I like it a lot,
        and intend to implement it. It's just that it has many problems,
        which I think most of them can be solved, if someone would actually
        care to try it.

        > If the external "C" spec. is really scary, we can also decide not to
        > be compatible. If this spec. is not so bad, I think it is better to
        > be compatible even if the spec is not perfect from our point of
        > view.

        Definitely. I'm not intending some macho-"I'm smarter than all of
        you together" stuff. ;-)

        Regards, Thomas.
      Your message has been successfully submitted and would be delivered to recipients shortly.