Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-5648

Add Iterable type and runtime object

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: PUP 4.3.1
    • Fix Version/s: PUP 4.4.0
    • Component/s: None
    • Labels:
      None
    • Template:
    • Story Points:
      2
    • Sprint:
      Language 2016-01-13, Language 2016-01-27, Language 2016-02-10
    • Release Notes:
      New Feature
    • Release Notes Summary:
      Hide
      Two new types where added to the puppet type system; Iterable[T], a type for values that an iterative function can operate on (i.e. a sequence of type T), and Iterator[T] an abstract Iterable that represents a lazily applied iterative function (that produces a sequence of T). In practice an Iterable that is also an Iterator describes a value that can not be assigned directly to attributes of resources; to assign the values an Iterator must first be iterated over to construct a concrete value like an Array).

      Values of type Array, Hash, String, Integer, Iterator, and the types Type[Enum], Type[Integer] are Iterable,

      An introduction to Iterables will be available in predocs, and the specification will be updated in separate tickets linked to this ticket)
      Show
      Two new types where added to the puppet type system; Iterable[T], a type for values that an iterative function can operate on (i.e. a sequence of type T), and Iterator[T] an abstract Iterable that represents a lazily applied iterative function (that produces a sequence of T). In practice an Iterable that is also an Iterator describes a value that can not be assigned directly to attributes of resources; to assign the values an Iterator must first be iterated over to construct a concrete value like an Array). Values of type Array, Hash, String, Integer, Iterator, and the types Type[Enum], Type[Integer] are Iterable, An introduction to Iterables will be available in predocs, and the specification will be updated in separate tickets linked to this ticket)

      Description

      Commit 3a9db247c432d469e625d4abf7bee8e747178af9 regressed support for "descending" ranges, where the "max" is less than the "min":

      notice Integer[5, 1]
      Integer[5, 1].each |$x| {
        notice $x
      }
      

      This is expected to output:

      Notice: Scope(Class[main]): Integer[5, 1]
      Notice: Scope(Class[main]): 5
      Notice: Scope(Class[main]): 4
      Notice: Scope(Class[main]): 3
      Notice: Scope(Class[main]): 2
      Notice: Scope(Class[main]): 1
      

      This is because having a maximum less than a minimum treats the range as being in "descending" order.

      Instead, this is the actual output:

      Notice: Scope(Class[main]): Integer[1, 5]
      Notice: Scope(Class[main]): 1
      Notice: Scope(Class[main]): 2
      Notice: Scope(Class[main]): 3
      Notice: Scope(Class[main]): 4
      Notice: Scope(Class[main]): 5
      

      It appears the min and max are silently being swapped when the max < min.

      Related: I believe the compiler should error if a type is given a max argument less than a min argument when the type does not support a "descending" semantic, e.g. Callable[1, 0] should error rather than silently swapping the min and max.

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  peter.huene Peter Huene
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Zendesk Support