Re: IO Multiplexing
On Nov 12, 2:21 pm, stefa...@cox.net (Stefan O'Rear) wrote: On Thu, Nov 11, 2010 at 05:47:46PM -0800, Ben Goldberg wrote: I would like to know, is perl6 going to have something like select (with arguments created by fileno/vec), or something like IO::Select (with which the user doesn't need to know about the implementation, which happens to be done with fileno/vec/select), or only an event loop. I will be unhappy if Perl 6 doesn't provide all three. However, the spec in question doesn't really exist. The IO synopsis is garbage and should be deleted and rewritten from scratch by someone who knows what they're talking about. I would recommend that there NOT be any sort of fileno exposed to the user, unless he goes out of the way to get it -- any function (in particular, posix functions) should simply take a perl filehandle, and that function in turn would pull out the fileno (or fail appropriately, if the filehandle doesn't have a fileno). If users want to know if filehandles correspond to the same underlying file, then there could be a method -- perhaps $fh.uses_same_desciptor($fh2), or somesuch. This goes without saying. One caveat - it should be possible to pass integer file descriptors. For functions in the posix module, sure; but for everywhere else, if the user wants to pass integer file descriptors to a function which is expecting an IO object, maybe not. But it should be easy (maybe even trivial) to create a new IO object from an integer file descriptor. If there's a select() builtin (and I'd much rather that there not be -- it should be hidden away in a class, like perl5's IO::Select), I'd very much hope that it would take and return Sets of filehandles, not vec packed strings. I'd prefer there not be one[**] Absolutely not. TIMTOWDI. There will be a select() function (in the POSIX module, not the default namespace!), and it will take parameters as close as possible to POSIX.1's definition. Perl without system calls is not Perl. I'm totally fine with discouraging casual use, though, which is why it shouldn't be in the default namespace. +1 :) If there's something like perl5's IO::Select, it should be able to just work regardless of whether the perl filehandles are sockets, regular files, or user-created pure-perl filehandles (which might never block, or which might use one or more normal filehandles internally, which in turn might potentially block). This is what I'd prefer. That is a good doctoral thesis topic. Require that IO objects provide a uniform interface by means of which the multiplexer object can determine blockability. Any user-defined IO handle which doesn't wait on external events will never block, and it can say so. A user defined IO handle which waits on a built in IO handle can say what handle it will need to wait upon, and what operation it will need to wait for. A user defined IO handle which waits for a signal can say what signal it is waiting for. A user defined IO handle which waits for a condition variable can say what variable it's waiting on, and what kind of state change it's looking for. Given the complexity of looking for other things (in particular, IPC that doesn't use streams), the simple solution is to require that they write a class for it, and have that class (internally) create a kernel thread which will block on the desired IPC, and write a byte to a pipe... this allows the perl level IO handle to say to the multiplexer that it's waiting on the read end of that pipe. This is roughly the same technique that we would use to safely detect signals. Lastly, if perl6 has an efficient enough built-in event loop, and sufficiently lightweight coroutines (or maybe I should say fibers?), then we might not need to have any kind of explicit multiplexing. TIMTOWDI. Perl without system calls is not Perl. Yeah, but if it's more efficient to not directly use those system calls, then what's the point of having them? For example, any time user code does a read operation on a handle that isn't (from the user code's point of view) in nonblocking mode, the filehandle implementation would tell the the event loop to yield to it when the handle becomes readable, then it would yield to the event loop, then (once it gets back control) read from the handle.[*] This is why S16 is junk - too much blue-sky thinking, not enough pragmatism and practical experience. S16 has almost nothing in it about actual IO (it does talk about how STDIN, STDOUT, STDERR, and ARGV will be replaced with $*IN, $*OUT, $*ERR, and $*ARGFILES, and how they will be dynamically overrideable). Did you mean to say S32::IO? While S32::IO describes what methods and roles IO objects will have/ do, the only thing it says about multiplexing is that both of perl5's select() operators will disappear. It's fairly obvious that select() / select(EXPR) will be replaced with the dynamically overrideable $*IN. (Not that
Packed arrays and assignment vs binding
Hi, Per S09, we can write in Perl 6: my int @x; And the idea is that we get a packed array - conceptually, a single lump of memory allocated and and storing a bunch of ints contiguously. Contrast this to: my Int @x; Where we get an array of scalar containers, each of which is only allowed to contain an Int (strictly, something that Int.ACCEPTS(...) hands back true on). In the latter case, it's fairly clear how these differ: @x[0] = 1; @x[0] := 1; In the first, we look up the container in slot 0 or the array and assign a 1 into it. In the second, we bind a 1 directly into the slot. There's no container any more (so any future assignment attempts will fail, for example). With packed arrays, however, I'm less clear what they mean. Since the point of a packed array is compact storage, there's no chance to actually have containers. Thus does assignment to a slot in a compact array ever make sense? There's not a container to look up and store things in. While I can happily convince myself that: @x[0] := 1; # works, just sticks 1 into the appropriate location @x[0] = 1; # dies, can't assign when there's no container Actually makes sense, I can also somewhat see users not liking it. So my questions are: 1) What semantics would users expect? Is it OK to say no, you can't assign in this case? 2) If proposing that both should work, what, roughly, would that look like at an implementation level? When answering (2), consider that: @x[0] = 42; Currently really means: infix:=(@x[0], 42); That is, we really do look up the container and then perform an operation in it. So if you de-sugar it all, it's kinda like: VAR(@x[0]).STORE(42) So just saying oh, just given assignment semantics like binding ones is not so simple, since it'd seem that we do not get anything we could call .STORE on back from @x[0] from a natively typed array. Any thoughts? (Same questions/answers apply for natively typed attributes in objects, or at least I'd be very surprised if they are different.) Thanks, Jonathan
Re: Packed arrays and assignment vs binding
Jonathan (): Per S09, we can write in Perl 6: my int @x; And the idea is that we get a packed array - conceptually, a single lump of memory allocated and and storing a bunch of ints contiguously. Contrast this to: my Int @x; Where we get an array of scalar containers, each of which is only allowed to contain an Int (strictly, something that Int.ACCEPTS(...) hands back true on). In the latter case, it's fairly clear how these differ: @x[0] = 1; @x[0] := 1; In the first, we look up the container in slot 0 or the array and assign a 1 into it. In the second, we bind a 1 directly into the slot. There's no container any more (so any future assignment attempts will fail, for example). With packed arrays, however, I'm less clear what they mean. Since the point of a packed array is compact storage, there's no chance to actually have containers. Thus does assignment to a slot in a compact array ever make sense? There's not a container to look up and store things in. While I can happily convince myself that: @x[0] := 1; # works, just sticks 1 into the appropriate location @x[0] = 1; # dies, can't assign when there's no container Actually makes sense, I can also somewhat see users not liking it. So my questions are: 1) What semantics would users expect? Is it OK to say no, you can't assign in this case? By this point in the email, you have me convinced that only binding makes sense in the 'int'-with-a-lowercase-'i' case. So if you ask me, it is OK to say no, you can't assign in this case. // Carl
Re: Packed arrays and assignment vs binding
On Sat, Nov 13, 2010 at 06:09:00PM +0100, Jonathan Worthington wrote: ... With packed arrays, however, I'm less clear what they mean. Since the point of a packed array is compact storage, there's no chance to actually have containers. Thus does assignment to a slot in a compact array ever make sense? There's not a container to look up and store things in. While I can happily convince myself that: @x[0] := 1; # works, just sticks 1 into the appropriate location @x[0] = 1; # dies, can't assign when there's no container Actually makes sense, I can also somewhat see users not liking it. So my questions are: 1) What semantics would users expect? Is it OK to say no, you can't assign in this case? 2) If proposing that both should work, what, roughly, would that look like at an implementation level? I have already come up with exactly the same conclusion on my own. +1 Also, given my int $x, $x := 5 should work, but not $x = 5. -sorear signature.asc Description: Digital signature
Re: IO Multiplexing
On Fri, Nov 12, 2010 at 06:59:59PM -0800, Ben Goldberg wrote: (snip plea to paint the bikeshed fuchsia) The design of the I/O system will be chosen by the first person to implement it. If you want any say in the matter, you need to be that person. Bonus points if you also port at least one app to prove that your system is usable. -sorear signature.asc Description: Digital signature
Re: Packed arrays and assignment vs binding
On 11/13/2010 06:09 PM, Jonathan Worthington wrote: With packed arrays, however, I'm less clear what they mean. Since the point of a packed array is compact storage, there's no chance to actually have containers. Thus does assignment to a slot in a compact array ever make sense? There's not a container to look up and store things in. While I can happily convince myself that: @x[0] := 1; # works, just sticks 1 into the appropriate location @x[0] = 1; # dies, can't assign when there's no container Actually makes sense, I can also somewhat see users not liking it. Indeed. As a user I think of the = operator as put the thing on the RHS into the var (or array slot) on the LHS. I don't care about the underlying container model. I just care that 1) the RHS now contains a 1 2) I don't get any spooky action at a distance. I'd like those two points to remain the same for packed arrays. So my questions are: 1) What semantics would users expect? Is it OK to say no, you can't assign in this case? see above 2) If proposing that both should work, what, roughly, would that look like at an implementation level? When answering (2), consider that: @x[0] = 42; Currently really means: infix:=(@x[0], 42); That is, we really do look up the container and then perform an operation in it. So if you de-sugar it all, it's kinda like: VAR(@x[0]).STORE(42) So just saying oh, just given assignment semantics like binding ones is not so simple, since it'd seem that we do not get anything we could call .STORE on back from @x[0] from a natively typed array. Any thoughts? (Same questions/answers apply for natively typed attributes in objects, or at least I'd be very surprised if they are different.) I don't have a good idea right now; just consider that whatever ends up storing a 1 into the array also might need to do a coercion; after all an Int is not an int. Maybe the two things (handling of assignment and coercion) are somehow related? Do we always know at compile time that a certain container is natively typed? if yes, maybe we can automagically rewrite assignment to binding at compile time... If nobody comes up with a practical idea on how to solve it, I'd grumpily accept only binding for storing things in a natively typed container. We'd need a *VERY* good error message in that case. Cheers, Moritz
Re: Packed arrays and assignment vs binding
Jonathan Worthington wrote: In the latter case, it's fairly clear how these differ: @x[0] = 1; @x[0] := 1; In the first, we look up the container in slot 0 or the array and assign a 1 into it. In the second, we bind a 1 directly into the slot. There's no container any more (so any future assignment attempts will fail, for example). I'll have to beg to differ. My understanding of it is as follows: the first case works as you describe. The second case differs, though, because there is no way to bind a variable directly to a value; variables can only be bound to containers. So the interpreter creates a new item container, assigns 1 to it, and binds the zero slot to it. Mind you: when the optimizer gets its hands on this, it'll probably just simplify it to the first case, as the two are functionally equivalent. The distinction only really matters when you're binding to an already-existing container (e.g., @x[0] = $foo vs. @x[0] := $foo). With packed arrays, however, I'm less clear what they mean. Since the point of a packed array is compact storage, there's no chance to actually have containers. Thus does assignment to a slot in a compact array ever make sense? There's not a container to look up and store things in. Assignment makes perfect sense: the compact storage is the container (which is bound to @x), and you assign a value to a slot in that container. What doesn't make sense is binding a slot of a packed array to some other container: @x[0] := $foo; # this should die. The only way I can see this working is if perl first converts the packed array into a normal array, and then binds slot 0 to $foo. -- Jonathan Dataweaver Lang
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/7/10 23:19 , Jon Lang wrote:
1 -- 2 -- 3
Would be a Bag containing three elements: 1, 2, and 3.
Personally, I wouldn't put a high priority on this; for my purposes,
Bag(1, 2, 3)
works just fine.
Hm. Bag as [! 1, 2, 3 !] and Set as {! 1, 2, 3 !}, with the outer bracket by
analogy with arrays or hashes respectively and the ! having the mnemonic of
looking like handles? (I have to imagine there are plenty of Unicode
brackets to match.)
- --
brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzfCfcACgkQIn7hlCsL25W5DACgzX15js/a8QRcE64QIvAax0kc
b1AAn0G+eXfNN9+spB7vvybnAnbn1nFI
=EZJL
-END PGP SIGNATURE-
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
Brandon S Allbery KF8NH wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/7/10 23:19 , Jon Lang wrote:
1 -- 2 -- 3
Would be a Bag containing three elements: 1, 2, and 3.
Personally, I wouldn't put a high priority on this; for my purposes,
Bag(1, 2, 3)
works just fine.
Hm. Bag as [! 1, 2, 3 !] and Set as {! 1, 2, 3 !}, with the outer bracket by
analogy with arrays or hashes respectively and the ! having the mnemonic of
looking like handles? (I have to imagine there are plenty of Unicode
brackets to match.)
That saves a singlr character over Bag( ... ) and Set( ... ),
respectively (or three characters, if you find decent unicode bracket
choices). It still wouldn't be a big enough deal to me to bother with
it.
As well, my first impression upon seeing [! ... !] was to think
you're negating everything inside? That said, I could get behind
doubled brackets:
[[1, 2, 3]] # same as Bag(1, 2, 3)
{{1, 2, 3}} # same as Set(1, 2, 3)
AFAIK, this would cause no conflicts with existing code.
Or maybe these should be reversed:
[[1, 1, 2, 3]] # a Set containing 1, 2, and 3
{{1, 1, 2, 3}} # a Bag containing two 1s, a 2, and a 3
{{1 = 2, 2 = 1, 3 = 1}} # another way of defining the same Bag,
with explicit counts.
OTOH, perhaps the outermost character should always be a square brace,
to indicate that it operates primarily like a list; while the
innermost character should be either a square brace or a curly brace,
to hint at thye kind of syntax that you might find inside:
[[1, 1, 2, 3]] # a Set containing 1, 2, and 3
[{1, 1, 2, 3}] # a Bag containing two 1s, a 2, and a 3
[{1 = 2, 2 = 1, 3 = 1}] # another way of defining the same Bag,
with explicit counts.
Yeah; I could see that. The only catch is that it might cause
problems with existing code that nests square or curly braces inside
of square braces:
[[1, 2, 3], [4, 5, 6], [7, 8, 9]] # fail; would try to create Set
from 1, 2, 3], [4, 5, 6], [7, 8, 9
[ [1, 2, 3], [4, 5, 6], [7, 8, 9] ] # creates 3-by-3 array
...so maybe not.
It should never be more than two characters on either side; and
there's some benefit to using square or curly braces as one of them,
to hint at proper syntax within. Hmm... how about:
|[1, 2, 3]| # Set literal
|[1=true, 2=true, 3=true]| # technically possible; but why do it?
|{1, 1, 2, 3}| # Bag literal
|{1=2, 2=1, 3=1}| # counted Bag literal
--
Jonathan Dataweaver Lang
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
Jonathan Lang ():
As well, my first impression upon seeing [! ... !] was to think
you're negating everything inside? That said, I could get behind
doubled brackets:
[[1, 2, 3]] # same as Bag(1, 2, 3)
{{1, 2, 3}} # same as Set(1, 2, 3)
AFAIK, this would cause no conflicts with existing code.
Or maybe these should be reversed:
[[1, 1, 2, 3]] # a Set containing 1, 2, and 3
{{1, 1, 2, 3}} # a Bag containing two 1s, a 2, and a 3
{{1 = 2, 2 = 1, 3 = 1}} # another way of defining the same Bag,
with explicit counts.
OTOH, perhaps the outermost character should always be a square brace,
to indicate that it operates primarily like a list; while the
innermost character should be either a square brace or a curly brace,
to hint at thye kind of syntax that you might find inside:
[[1, 1, 2, 3]] # a Set containing 1, 2, and 3
[{1, 1, 2, 3}] # a Bag containing two 1s, a 2, and a 3
[{1 = 2, 2 = 1, 3 = 1}] # another way of defining the same Bag,
with explicit counts.
Yeah; I could see that. The only catch is that it might cause
problems with existing code that nests square or curly braces inside
of square braces:
[[1, 2, 3], [4, 5, 6], [7, 8, 9]] # fail; would try to create Set
from 1, 2, 3], [4, 5, 6], [7, 8, 9
[ [1, 2, 3], [4, 5, 6], [7, 8, 9] ] # creates 3-by-3 array
...so maybe not.
It should never be more than two characters on either side; and
there's some benefit to using square or curly braces as one of them,
to hint at proper syntax within. Hmm... how about:
|[1, 2, 3]| # Set literal
|[1=true, 2=true, 3=true]| # technically possible; but why do it?
|{1, 1, 2, 3}| # Bag literal
|{1=2, 2=1, 3=1}| # counted Bag literal
After skimming all those suggestions, I have yet another proposal:
let's not add anything, creating marginal gain with lots of extra
syntax.
That saves a singlr character over Bag( ... ) and Set( ... ),
respectively (or three characters, if you find decent unicode bracket
choices). It still wouldn't be a big enough deal to me to bother with
it.
+1. Let's leave it at that.
// Carl
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
Carl Mäsak wrote:
Jonathan Lang ():
That saves a singlr character over Bag( ... ) and Set( ... ),
respectively (or three characters, if you find decent unicode bracket
choices). It still wouldn't be a big enough deal to me to bother with
it.
+1. Let's leave it at that.
That said, I do think that Bag( ... ) should be able to take pairs, so
that one can easily create a Bag that holds, say, twenty of a given
item, without having to spell out the item twenty times. Beyond that,
the only other syntax being proposed is a set of braces to be used to
create Bags and Sets, as part of the initiative to make them nearly as
easy to use as lists. In essence, you'd be introducing two operators:
circumfix:|[ ]| and circumfix:|{ }|, as aliases for the respective
Set and Bag constructors. As I said, it's not a big deal - either
way.
Really, my main issue remains the choice of sigil for a variable
that's supposed to hold baggy containers.
--
Jonathan Dataweaver Lang
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
Jon Lang wrote:
That saves a singlr character over Bag( ... ) and Set( ... ),
respectively (or three characters, if you find decent unicode bracket
choices). It still wouldn't be a big enough deal to me to bother with
it.
As well, my first impression upon seeing [! ... !] was to think
you're negating everything inside? That said, I could get behind
doubled brackets:
[[1, 2, 3]] # same as Bag(1, 2, 3)
{{1, 2, 3}} # same as Set(1, 2, 3)
snip
I prefer to have the mnemonic that {} means unordered and that [] means ordered,
so please stick to [] meaning arrays or ordered collections, an {} meaning
unordered collections, so set and bag syntax should be based around {} if either.
This said, I specifically think that a simple pair of curly braces is the best
way to mark a Set.
So:
{1,2,3} # a Set of those 3 elements
... and this is also how it is done in maths I believe (and in Muldis D).
In fact, I strongly support this assuming that all disambiguation eg with hashes
can be specified.
{a=1,b=2} # a Hash of 2 pairs
{:a1, :a2} # we'll have to pick a meaning
{} # we'll have to pick a meaning (Muldis D makes it a Set; %:{} is its Hash)
{;} # an anonymous sub or something
{a=1} # Hash
{1} # Set
{1;} # anonymous sub or something
But keep that simple an let nesting work normally, so:
{{1}} # a Set of 1 element that is a Set of 1 element
{{a=1}} # a Set with 1 Hash element
{[1]} # a Set with 1 Array element
[{1}] # an Array with 1 Set element
In certain cases, we can always still fall back to this:
Set() # empty Set
Hash() # empty Hash
Set(:a1) # if that's what we wanted
As for bags, well I think that is where we could get fancier.
But *no* doubling up, as we don't want to interfere with nesting.
Instead, it is common in maths to associate a + with set syntax to refer to
bags instead.
So, does Perl already ascribe a meaning to putting a + with various bracketing
characters, such as this:
+{1,2,2,5} # a Bag of 4 elements with 2 duplicates
+{} # an empty Bag, unless that already means something
So would the above try to cast the collection as a number, or take the count of
its elements, or can we use something like that?
But I would recommend something along those lines.
I suppose then if +{} works for bags we could alternately use -{} for sets but I
don't really like it.
-- Darren Duncan
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
On Sun, Nov 14, 2010 at 12:12 AM, Jon Lang datawea...@gmail.com wrote: Carl Mäsak wrote: Jonathan Lang (): That saves a singlr character over Bag( ... ) and Set( ... ), respectively (or three characters, if you find decent unicode bracket choices). It still wouldn't be a big enough deal to me to bother with it. +1. Let's leave it at that. That said, I do think that Bag( ... ) should be able to take pairs, so that one can easily create a Bag that holds, say, twenty of a given item, without having to spell out the item twenty times. Doesn't the xx operator cover this? Eirik
Re: Packed arrays and assignment vs binding
I understand everything you've written except the following: On Nov 13, 2010, at 12:09 PM, Jonathan Worthington wrote: Hi, ... my Int @x; Where we get an array of scalar containers, each of which is only allowed to contain an Int (strictly, something that Int.ACCEPTS(...) hands back true on). @x[0] = 1; @x[0] := 1; In the first, we look up the container in slot 0 or the array and assign a 1 into it. In the second, we bind a 1 directly into the slot. There's no container any more (so any future assignment attempts will fail, for example). ... Jonathan What's a 1? If it's not an Int, I don't know what it is. If it is an Int, I don't understand how you could bind it into a packed array. Could you shed some light on that?
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
Darren Duncan wrote:
Jon Lang wrote:
That saves a singlr character over Bag( ... ) and Set( ... ),
respectively (or three characters, if you find decent unicode bracket
choices). It still wouldn't be a big enough deal to me to bother with
it.
As well, my first impression upon seeing [! ... !] was to think
you're negating everything inside? That said, I could get behind
doubled brackets:
[[1, 2, 3]] # same as Bag(1, 2, 3)
{{1, 2, 3}} # same as Set(1, 2, 3)
snip
I prefer to have the mnemonic that {} means unordered and that [] means
ordered, so please stick to [] meaning arrays or ordered collections, an {}
meaning unordered collections, so set and bag syntax should be based around
{} if either.
This said, I specifically think that a simple pair of curly braces is the
best way to mark a Set.
So:
{1,2,3} # a Set of those 3 elements
... and this is also how it is done in maths I believe (and in Muldis D).
In fact, I strongly support this assuming that all disambiguation eg with
hashes can be specified.
That would be great.
{a=1,b=2} # a Hash of 2 pairs
{:a1, :a2} # we'll have to pick a meaning
My preference would be for this to be a Set that contains two items in
it, both of which are pairs. IIRC, there's already behavior along
these lines when it comes to pairs.
{} # we'll have to pick a meaning (Muldis D makes it a Set; %:{} is its
Hash)
Is there any difference between an empty Set and an empty Hash? If
so, is one more general than the other? Just as importantly, what
does {} do right now?
{;} # an anonymous sub or something
{a=1} # Hash
{1} # Set
{1;} # anonymous sub or something
Sets built from multi-dimensional arrays migt be a problem:
{1, 2, 3: 4, 5, 6}
But keep that simple an let nesting work normally, so:
{{1}} # a Set of 1 element that is a Set of 1 element
{{a=1}} # a Set with 1 Hash element
{[1]} # a Set with 1 Array element
[{1}] # an Array with 1 Set element
In certain cases, we can always still fall back to this:
Set() # empty Set
Hash() # empty Hash
Set(:a1) # if that's what we wanted
As for bags, well I think that is where we could get fancier.
But *no* doubling up, as we don't want to interfere with nesting.
Instead, it is common in maths to associate a + with set syntax to refer
to bags instead.
So, does Perl already ascribe a meaning to putting a + with various
bracketing characters, such as this:
+{1,2,2,5} # a Bag of 4 elements with 2 duplicates
+{} # an empty Bag, unless that already means something
So would the above try to cast the collection as a number, or take the count
of its elements, or can we use something like that?
I'd expect +{...} to count the elements.
--
Jonathan Dataweaver Lang
