subject:"Jira $PUP\-5648$ Add Iterable type and runtime object"

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
I updated the PR to only cover the Iterable type and created PUP-5729 and PUP-5730 to cover the new reverse_each and step functions. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren assigned an issue to Henrik Lindberg 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-5648 
 
 
 
  Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 

Change By:
 
 Thomas Hallgren 
 
 
 

Assignee:
 
 Henrik Lindberg 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title

Henrik Lindberg commented on PUP-5648

Re: Add Iterable type and runtime object

Thanks for splitting up the work into several tickets. Helps focusing on one thing at the time.
Agree on your suggestion that a cap function is best as coming after the unbound (it pulls at most n times).
Regarding the difference in opinion about Iterator - I like to think that objects of type T for which an Iterable[T] can be created are different than an instance of Iterable[?] even if asking for an Iterable for an Iterable. The only thing I want is to be able to tell an actual Iterable apart from the others. I cannot do that with:

$x =~ Iterable

Since that would be true for both an Array (and a bunch of others), as well as Iterable.
I think I would need the type_of function, and then check if the type == Iterable. So, how do you tell them apart?

Add Comment

This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
That's pretty much the same question as $x =~ Data, isn't it? You'll need to check if it's an Array, as well as Data. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
Why don't you consider Iterable to be completely abstract? I really want to do that because I can see no gain in exposing the internal workings of the iterative functions. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
If I do this: 
 
 
 
 
 
 
$a = [1,2,3].reverse_each
 
 
 
 
 
 
 
then, $a is bound to a instance of Iterable, and it is no longer a pure implementation concern as the instance of Iterable that wraps the Array knows it is in "reverse". It is not abstract, there is an actual instance, and it is not the same as an Array. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
I think it is important to have a defined way in Ruby to check for the type of Iterable in such a way that it does not have to have a priory knowledge of all possible kinds of iterables. This, if you are writing functions for communication, if you are in JRuby/Java land etc. Using the Puppet type system would be nice , i.e. having an Iterator type), but checking against a ruby "marker module" would also be fine. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
There is never anything that is an instance of Data floating around in the system - that type is completely abstract. That is not the case for Iterable, and that is precisely why I want to be able to tell them a part. 
I am fine if it is encoded in Iterable actually, but it is kind of ugly. I.e. Iterable[T, true] could mean what I called Iterator such that all of these are true: 
 
 
 
 
 
 
[1,2,3] =~ Iterable 
 
 
 
 
[1,2,3] =~ Iterable[Any, false] 
 
 
 
 
[1,2,3] !~ Iterable[Any, true]
 
 
 
 
 
 
 
We currently have the type_of in stdlib. I would like that function in puppet (or that we had an operator that means type_of. If we have that, then it would be perfectly ok to do this: 
 
 
 
 
 
 
$x.type_of == Type[Iterable]
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
I don't agree at all. Depending on implementation, this might well be true (it won't be with the current implementation, but that's beside the point): 
 
 
 
 
 
 
[3.2.1] == [1,2,3].reverse_each 
 
 
 
 
[1,2,3].reverse_each =~ Array
 
 
 
 
 
 
 
My point is, you shouldn't make no other assumption about what the result of an iterative function is other than: 
 
 
 
 
 
 
[1,2,3].reverse_each ~= Iterable
 
 
 
 
 
 
 
If you do, the you lock your code into one specific implementation and we don't want to add implementation specifics into the Puppet spec. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
If we add type promotion / transformation yes, than we never need to know the type in the Puppet Language. An implementor of a function in Ruby should expect certain methods to be there if it is one or the other. We must deliver something that ruby is_a? Array since we have specified that Puppet Array is represented by Ruby Array. Hence, the conversion must be considered when matching against types in a a dispatcher, and the invocation logic must handle the type transformation. The transformation must also kick in when serializing. (It is both serialized and deserialized as an array, and if the Iterable is unbound it is an error to serialize it, or transform it into an Array. 
As long as that is not handled, we should not have any functions that returns an implementation of an Iterable other than the already supported concrete data types (e.g. instances of Array). The same rationale as for lambda (you are not allowed to return one since it is not first order in the language. (For lambda, when we have a sane stack implementation, we can implement the call operation or a call function). Same thing here. 
At the same time, we are in no particular hurry. It is very nice to have but no one is screaming for it. I can imagine adding the type first without exposing the functions to the puppet language.. 
The idea of representing the "iterator" is that you would not have to do all that yet. It is defined what it is, and the operators does not support it, and there is no promotion. Serialization must however be handled or they will for sure end up in catalogs with completely weird behavior as the result. This does not hide the implementation details completely, but to a very large degree, as the "iterator" type would include all such implementations whatever they may be (they must share some Ruby method API, but that is all). (I tried to find a synonym to Iterator, but found none, and Iterable/Iterator, sort of goes hand in hand (Enumerble and Enumerator in Ruby terminlogy). I do agree that it is not an Iterator in the sense of a Java Iterator as it does not hold iteration state, the actual iterator in puppet is the function that drives the iteration. 
At the same time, I would rather have the nice and opaque implementation. Do you want to do it that way? If so, we do not release this as a feature until all parts are ready - say Puppet 5.0.0 (I don't think this has high enough priority for 4.4.0 to push out some of the other things (and 4.4.0 is not far away)). 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
I am thinking about Iterator as a type. It's not "operations" on it that I'm reacting to. It's conceptual. What an iterator is compared to an iterable. In my world there's a distinct difference between the two in that an iterator is something that knows where it's at. An iterable doesn't. I see no other reason why we would ever expose an iterator type than to make that distinction. 
Now I understand your times sample. For a function like that, I'd prefer something that could be chained. Your sample would then be: 
 
 
 
 
 
 
fib.limit(5) |$n, $f| { notice "Fib[$n] = $d" }
 
 
 
 
 
 
 
or, perhaps using the term 'cap'? 
 
 
 
 
 
 
fib.cap(5) |$n, $f| { notice "Fib[$n] = $d" }
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)

Jira (PUP-5648) Add Iterable type and runtime object

2016-01-20 Thread Henrik Lindberg (JIRA)

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
I think each should require a block. 
I don't mind naming the iterator function iterable (if we end up without an Iterator type. 
I don't understand why you think there is a next on an Iterator, Iterator would simply be a type, nothing else, there are no operations on it. 
The last example with times invented the times function as something that iterates that many times and can accept an unbound iterable/iterator from which it picks values. It can be viewed as a zip that joins two sequences and stops when the first sequence stops; its actual design would probably be different (it is just an example of a "capping" function). 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
Totally agree that each without a block is more or less a no-op. I added it to satisfy your remark on symmetry only. I don't mind leaving that out. 
I like the iterator function when it must be called with a block, albeit I think that perhaps that too, should be called iterable since that is what I think it returns. 
I read what you wrote about Iterator but I don't agree. You can get the next element with next and that changes the state of the iterator instance. Compare to Ruby's Enumerator. Whether you then can ask it has_next? or simply get a StopIteration exception is just an implementation detail. You cannot do next on an Enumeration. 
I don't understand you last example with 5.times(fib). We have no times function but Puppet defines the Ruby times as the default enumerable for a positive integer. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren assigned an issue to Henrik Lindberg 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-5648 
 
 
 
  Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 

Change By:
 
 Thomas Hallgren 
 
 
 

Assignee:
 
 Thomas Hallgren Henrik Lindberg 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

2016-01-20 Thread Henrik Lindberg (JIRA)

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg assigned an issue to Unassigned 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-5648 
 
 
 
  Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 

Change By:
 
 Henrik Lindberg 
 
 
 

Assignee:
 
 Henrik Lindberg 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

2016-01-20 Thread Henrik Lindberg (JIRA)

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
So, what is the result of this (assuming type_of function returns the type)? 
 
 
 
 
 
 
$a = [1,2,3].each() 
 
 
 
 
notice type_of($a)
 
 
 
 
 
 
 
I can see this either being Array[Integer] (since it is iterable already), or Iterable[Integer]. I fact, I wonder why you ever need to call each without a block since it is more or less a no-op. Sure, if it returns an instance of Iterable it is different, but then again, it really has no effect. 
The reverse_each is different naturally. 
The implementation of next should not be a stepping function on an "iterator", it is a function that raises a signal to "got to next" in the current ongoing iteration (like the next method in Ruby) - the same can be achieved with regular conditional logic (but with more if-the-else spaghetti). 
I think we are talking past each other. The reason I wanted two types was to be able to tell an actual Iterable apart from something that is iterable (e.g. an Array). For that purpose I invented Iterator. In fact, the implementation as it is would work by having the type system simply calculate that: 
 
 
 
 
 
 
Array < Iterable == true 
 
 
 
 
Iterator < Iterable == true 
 
 
 
 
Array < Iterator == false
 
 
 
 
 
 
 
By using instances of Iterable as (for what I called Iterator instances), there is no way to tell them apart in Puppet. I am

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
I would consider the Iterator runtime type as an implementation detail that shouldn't be exposed in PL. In fact, I think that would be plain wrong to do that since the general idea of the Iterable[T] is that it should describe any runtime type that is iterable and yields elements of type T. The reason it's great is that we don't care about the implementation. 
All iterative functions must instead accept an Iterable argument (today they accept Any) and not care if the actual implementation is an iterator, enumerator, or other type. Instead, each, reverse_each, filter, map, reduce, and step can all be called directly on an Array, String, Iterator or anything else that is an instance of an Iterable. 
The important thing, not covered by the PR in it's current shape, is that the Iterable type recognizes the full set of iterable objects which means that the PIterableType#instance? and PIterableType#assignable? must be enhanced. 
Example: 
 
 
 
 
 
 
[1,2,3].reverse_each
 
 
 
 
 
 
 
This function, when called without a block, takes an Iterable as an argument and returns a new Iterable that will yield each element of the given argument in reverse order. The internal implementation might be an iterator. Then again, it might not. It all depends on it's argument, an Array responds to reverse_each which returns a ruby Enumerator which in itself is Iterable. The important thing is that we can consider the argument and return type to be Iterable, not that it is an Iterator, i.e. the specific implementation of Iterable is irrelevant. 
The each function should of course change so that it can be called without a block to make it symmetrical. 
An iterator function would behave exactly like each when called without a block. I don't think we need that. It makes a lot of sense the way the fib_iterator example is written though, and the return type of that function (once it can be declared) must of course be an Iterable[Integer] so that one then can do: 
 
 
 
 
 
 
5.fib_iterator.reverse_each |$x| { notice $x }
 
 
 
 
 
 
 
Regarding serialization/interpolation of an Iterable. I think that's up to the actual

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
Another important aspect that to consider is that an Iterable doesn't retain the notion of a current position whereas an Iterator does. 
 
 
 
 
 
 
$c = [1,2,3].iterator 
 
 
 
 
$c.next 
 
 
 
 
# Now what does this mean? 
 
 
 
 
$c.each |$x| { notice($x) }
 
 
 
 
 
 
 
I don't think those two concepts mix in a good way. If we decide to introduce the concept of an Iterator, then it should be for the purpose of supporting the iteration state which in turn is somewhat contradictory to declarative programming. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Thomas Hallgren commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
Pushed a W.I.P. commit for review (not intended to be merged) where the Iterable#instance? and Iterable#assignable? has been imlemented, the each can be called without a block, and all functions acting on an Iterable now uses the Iterable type instead of Any in the declaration of its first parameter. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
As suggested in comments on the PR, I think we need two types for this: 
 

Iterator - i.e. an instance where the specifics of the iteration has been abstracted (except the type of "each").
 

Iterable - matches all instances that for which an iterator can be created - ie. Collection, String, Integer, Type[Integer], Iterator. (I can think of extensions here; Type[Enum], Type[Variant], Type[Tuple] - i.e. all types that have an interesting iterable aspect).
 
 
Further, I think they both need to be parameterized, such that an Iterable[Integer] does not match a String (since it is an Iterable[String]. 
I also think we need to prevent Iterator instances from being serialized. (This makes it impossible for someone to do this: 
 
 
 
 
 
 
notify { example: message => [1,2,3].reverse_each() }
 
 
 
 
 
 
 
That will fail when the catalog is produced when an Iterator is not serializeable. 
Likewise, string interpolation of an Iterator must be defined: it should either fail, shrinkwrap (as if join("") was used), or separate entries as if join(", ") was used. 
Since the iterative functions (e.g. each) requires that a block is given, they cannot be used to produce an Iterator. The PR contains the reverse_each which can. This is not quite symmetrical. How about having the two functions: 
 

iterator - returns a normal "each" iterator
 

reverse_iterator - returns an iterator that yields elements in revere order.
 
 
We could allow the functions to directly function as "each" iterators as a convenience/shorthand for "each", but I am not sure that is a good idea. If instead, they just return an iterator, if you want "each" behavior, you would simply call each. (Alternatively, change each to allow it to return an Iterator) - but I think having separate functions makes it less likely hat a beginner gets into trouble by forgetting the lambda and then ending up with a mysterious error; calling the new functions implies that you know what you are doing).

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg assigned an issue to Thomas Hallgren 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-5648 
 
 
 
  Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 

Change By:
 
 Henrik Lindberg 
 
 
 

Assignee:
 
 Thomas Hallgren 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
Coming back to the proposed function iterator(). I think that it should not accept a block for now. Later it could accept one, but it would be a block that is called to produce values. For that to work, we must also add a yield, break, next functions, and some way to deal with size of unbound iteration (and how to handle reverse). In the example below, size is capped by giving it to the iterator as an argument. 
This mechanism would provide an alternative to writing recursive functions. Here is fibonacci as an iterator (the iterator/lambda is like a reduce operation where the block yields to the block given when each, map, etc. operates on the iterator. 
 
 
 
 
 
 
function fib_iterator($n = 10) { 
 
 
 
 
  iterator($n) | $prev, $n | { 
 
 
 
 
if $prev == 0 {  
 
 
 
 
  yield(1) 
 
 
 
 
  [1 1] 
 
 
 
 
} else { 
 
 
 
 
  $next = $prev[0] + $prev[1] 
 
 
 
 
  yield($next) 
 
 
 
 
  [$prev[1], $next]

Jira (PUP-5648) Add Iterable type and runtime object

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg commented on  PUP-5648 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Add Iterable type and runtime object  
 
 
 
 
 
 
 
 
 
 
Also, as commented on the PR, there are too many features being delivered in the same PR. I prefer additional tickets for the new functions, as well as for the modified behavior of existing functions. This ticket can be used for the type(s).  One reason for splitting this up is that they should be released noted separately, they all need (different) documentation work, etc. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.

Jira (PUP-5648) Add Iterable type and runtime object