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

Void Safety Strangeness

Expand Messages
  • marvin_littlewood_426716
    Hello! I am compiling with the following settings: Transitional syntax Types are attached by default Source code is void safe I think on the whole, the Void
    Message 1 of 4 , Oct 1, 2008
    • 0 Attachment
      Hello!
      I am compiling with the following settings:
      Transitional syntax
      Types are attached by default
      Source code is void safe

      I think on the whole, the Void safety changes have improved my code.
      It took a little while to figure this problem out though!!

      Having obtained the following error message:
      BEGINS---------->
      Error code: VUAR(2)
      Type error: non-conforming actual argument in feature call.
      What to do: make sure that type of actual argument conforms to type
      of corresponding formal argument.

      Class: EUNIT_RUNNER_STRING_STREAM
      Feature: readint
      Called feature: read (convertor: STRING_TO_NUMERIC_CONVERTOR; type:
      INTEGER_32; caller, type_name: STRING_8): BOOLEAN from
      EUNIT_RUNNER_STRING_STREAM
      Argument name: convertor
      Argument position: 1
      Actual argument type: STRING_TO_INTEGER_CONVERTOR
      Formal argument type: STRING_TO_NUMERIC_CONVERTOR
      Line: 538
      do
      -> if read (ctoi_convertor,
      {NUMERIC_INFORMATION}.type_integer, "read_integer", "INTEGER") then
      last_integer := ctoi_convertor.parsed_integer
      ENDS------------>

      The resolution turns out to be:
      BEGINS---------->
      local
      convertor: like ctoi_convertor
      do
      convertor := ctoi_convertor
      if convertor /= Void then
      if read (convertor,
      {NUMERIC_INFORMATION}.type_integer, "read_integer", "INTEGER") then
      last_integer :=
      convertor.parsed_integer
      end
      end
      end
      ENDS------------>

      Which suggests that the error message should have read:

      Actual argument type: ?STRING_TO_INTEGER_CONVERTOR
      Formal argument type: STRING_TO_NUMERIC_CONVERTOR

      Is my interpretation correct?

      It is worth adding the following listing:

      ctoi_convertor: STRING_TO_INTEGER_CONVERTOR
      -- Convertor used to parse string to integer
      or natural
      -- (from PLAIN_TEXT_FILE)
      -- (export status {NONE})
      once
      create Result.make
      Result.set_leading_separators
      (internal_leading_separators)
      Result.set_leading_separators_acceptable
      (True)
      Result.set_trailing_separators_acceptable
      (False)
      end

      And stating that this problem recurs for {ANY}.io suggesting that
      there may actually be a misinterpretation of "once" functions.

      BTW I totally agree with Helmut Brandl when he said that it should be
      possible to delegate initialisation of attached types to a command
      feature during initialisation. I hate having to copy-paste code.

      IMHO one other "nice" feature in the project settings dialog might be
      to allow Standard Syntax and separately to allow ISE Extensions (such
      as Indexing). I realise this results in more combinations but it
      seems clearer and is how other compilers address the issue.

      Kind regards

      Mark
    • marvin_littlewood_426716
      ... wrote: Hello again! ... A better solution turns out to be to redefine ctoi_convertor as an attached type by copying the code
      Message 2 of 4 , Oct 1, 2008
      • 0 Attachment
        --- In eiffel_software@yahoogroups.com, "marvin_littlewood_426716"
        <marvin_littlewood_426716@...> wrote:

        Hello again!

        In my previous post, I said:

        > The resolution turns out to be:
        > BEGINS---------->
        > local
        > convertor: like ctoi_convertor
        > do
        > convertor := ctoi_convertor
        > if convertor /= Void then
        > if read (convertor,
        > {NUMERIC_INFORMATION}.type_integer, "read_integer", "INTEGER") then
        > last_integer :=
        > convertor.parsed_integer
        > end
        > end
        > end
        > ENDS------------>

        A better solution turns out to be to redefine ctoi_convertor as an
        attached type by copying the code into the class in question and
        adding a redefine clause.

        Kind regards

        Mark
      • Helmut Brandl
        Hello Mark, according to the ECMA standard your code seems to be correct and I don t understand the error VUAR in that context either. The query ctoi_converter
        Message 3 of 4 , Oct 1, 2008
        • 0 Attachment
          Hello Mark,

          according to the ECMA standard your code seems to be correct and I don't
          understand the error VUAR in that context either.

          The query ctoi_converter returns an attached type
          (STRING_TO_NUMERIC_CONVERTER) and you passed that as an actual argument
          to the routine, which expects an attached type.

          The resolution seems to be strange as well, because you make a void test
          with a variable of an attached type which should not be necessary.

          So from my analysis the problem is not in your code but in the compiler.

          By the way, thanks for supporting my request to allow delegation of
          initialization in creation procedures.

          Regards
          Helmut

          The Eiffel Compiler: http://tecomp.sourceforge.net
          Download: http://www.sourceforge.net/projects/tecomp

          marvin_littlewood_426716 wrote:
          > Hello!
          > I am compiling with the following settings:
          > Transitional syntax
          > Types are attached by default
          > Source code is void safe
          >
          > I think on the whole, the Void safety changes have improved my code.
          > It took a little while to figure this problem out though!!
          >
          > Having obtained the following error message:
          > BEGINS---------->
          > Error code: VUAR(2)
          > Type error: non-conforming actual argument in feature call.
          > What to do: make sure that type of actual argument conforms to type
          > of corresponding formal argument.
          >
          > Class: EUNIT_RUNNER_STRING_STREAM
          > Feature: readint
          > Called feature: read (convertor: STRING_TO_NUMERIC_CONVERTOR; type:
          > INTEGER_32; caller, type_name: STRING_8): BOOLEAN from
          > EUNIT_RUNNER_STRING_STREAM
          > Argument name: convertor
          > Argument position: 1
          > Actual argument type: STRING_TO_INTEGER_CONVERTOR
          > Formal argument type: STRING_TO_NUMERIC_CONVERTOR
          > Line: 538
          > do
          > -> if read (ctoi_convertor,
          > {NUMERIC_INFORMATION}.type_integer, "read_integer", "INTEGER") then
          > last_integer := ctoi_convertor.parsed_integer
          > ENDS------------>
          >
          > The resolution turns out to be:
          > BEGINS---------->
          > local
          > convertor: like ctoi_convertor
          > do
          > convertor := ctoi_convertor
          > if convertor /= Void then
          > if read (convertor,
          > {NUMERIC_INFORMATION}.type_integer, "read_integer", "INTEGER") then
          > last_integer :=
          > convertor.parsed_integer
          > end
          > end
          > end
          > ENDS------------>
          >
          > Which suggests that the error message should have read:
          >
          > Actual argument type: ?STRING_TO_INTEGER_CONVERTOR
          > Formal argument type: STRING_TO_NUMERIC_CONVERTOR
          >
          > Is my interpretation correct?
          >
          > It is worth adding the following listing:
          >
          > ctoi_convertor: STRING_TO_INTEGER_CONVERTOR
          > -- Convertor used to parse string to integer
          > or natural
          > -- (from PLAIN_TEXT_FILE)
          > -- (export status {NONE})
          > once
          > create Result.make
          > Result.set_leading_separators
          > (internal_leading_separators)
          > Result.set_leading_separators_acceptable
          > (True)
          > Result.set_trailing_separators_acceptable
          > (False)
          > end
          >
          > And stating that this problem recurs for {ANY}.io suggesting that
          > there may actually be a misinterpretation of "once" functions.
          >
          > BTW I totally agree with Helmut Brandl when he said that it should be
          > possible to delegate initialisation of attached types to a command
          > feature during initialisation. I hate having to copy-paste code.
          >
          > IMHO one other "nice" feature in the project settings dialog might be
          > to allow Standard Syntax and separately to allow ISE Extensions (such
          > as Indexing). I realise this results in more combinations but it
          > seems clearer and is how other compilers address the issue.
          >
          > Kind regards
          >
          > Mark
          >
          >
          >
        • marvin_littlewood_426716
          Hello Helmut! ... Many thanks for your analysis - I was beginning to wonder if I had lost my abilities to program Eiffel! I recommend using Void safety and the
          Message 4 of 4 , Oct 2, 2008
          • 0 Attachment
            Hello Helmut!

            <helmut.brandl@...> wrote:
            >
            > according to the ECMA standard your code seems to be correct and I
            > don't understand the error VUAR in that context either.
            > ...
            > So from my analysis the problem is not in your code but in the
            > compiler.

            Many thanks for your analysis - I was beginning to wonder if I had
            lost my abilities to program Eiffel!

            I recommend using Void safety and the standard/transitional syntax to
            determine where problems are likely to be but to leave the settings
            on "obsolete syntax", non-attached objects by default and no Void
            safety because it is not clear what breaks a compile - incorrect code
            or an incorrect compiler.

            I found that some of the changes (most due to the type of issue I
            highlighted) forced semantic alterations which broke the program when
            it ran in "obsolete" mode.

            I think I will post a bug report.

            >
            > By the way, thanks for supporting my request to allow delegation of
            > initialization in creation procedures.
            >

            Pleasure.

            I think that ECMA should have followed a C++ standardisation maxim:
            that as little old code should break as possible, when making a
            change.

            That said: I think the ideals behind Void Safety are spot on. It
            seemed stupid writing (or more importantly forgetting to write) a
            whole set of pre/post-conditions and invariants effectively of
            the form:

            x_exists: x /= Void

            when other languages provide reference types to handle exactly this
            situation.

            Kind regards

            Mark
          Your message has been successfully submitted and would be delivered to recipients shortly.