Re: Better sort spec?
On Fri, Dec 12, 2008 at 11:49:37PM -0500, Uri Guttman wrote: : so you have not discovered something new in perl or perl6 regarding : sorting. it has been covered and in depth but never properly integrated : into the p6 docs. It will be more useful if you comment relative to the existing design found in: http://svn.pugscode.org/pugs/docs/Perl6/Spec/S29-functions.pod Larry
Re: What does a Pair numify to?
On Mon, Dec 15, 2008 at 04:43:51PM -0700, David Green wrote: I can't really think of a great example where you'd want to numify a pair, but I would expect printing one to produce something like a = 23 (especially since that's what a one-element hash would print, right?). Nope, would print a\t23\n as currently specced. Larry
Re: What does a Pair numify to?
On Mon, Dec 15, 2008 at 10:26 PM, Larry Wall la...@wall.org wrote: On Mon, Dec 15, 2008 at 04:43:51PM -0700, David Green wrote: I can't really think of a great example where you'd want to numify a pair, but I would expect printing one to produce something like a = 23 (especially since that's what a one-element hash would print, right?). Nope, would print a\t23\n as currently specced. The point, though, is that stringification of a pair incorporates both the key and the value into the resulting string. This is an option that numification doesn't have. As well, I'm pretty sure that a\t23\n doesn't numify. I'm beginning to think that Pairs shouldn't, either; but if they do, they should definitely do so by numifying the value of the pair. -- Jonathan Dataweaver Lang
Re: What does a Pair numify to?
HaloO,
Moritz Lenz wrote:
The counter example is if you want to print a pair:
.say for %hash.pairs.sort: { .value };
In that case it would be nice to have the key appear in the stringification.
I see no problem as long as say gets a pair as argument. Then it can
print the key and value separated with a tab. More problematic are
string concatenations of the form
say the pair is: ~ (foo = $bar);
which need to be written so that say sees the pair
say the pair is: , (foo = $bar);
and not a string that only contains the value of the pair. I'm not
sure if the parens are necessary to pass the pair to say as argument
to be printed instead of a named argument that influences how the
printing is done.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Working with files wish list
On Tue, 16 Dec 2008, jason switzer wrote:
You can already easily mix it in using 'does':
$fstab = open('/etc/fstab', :r);
$fstab does WhitespaceTrim;
I don't think it's really necessary to include that into open(),
though it might be useful syntactic sugar.
I haven't spent the time to understand mix-ins yet, but this does look like
a feasible (clean) idea. However, how do you specify one/more filters? For
example, say you want to :rw a file. How can you provide an input filter and
an output filter (or multiples of either)? Can you layer filters if done
with mix-ins? If so, how do you specify direction?
I've had somewhat related ideas in the past, but they always involved
feed operators somehow. I don't think I've got enough of a grip on things to
suggest specifics, but I thought I'd throw the idea into the mix.
Also, if the wishlist covers filesystems as well as files (ie.
opendir-type stuff), my wishlist involves having general tree-manipulation
stuff that works with filesystems just as well as with XML; we could use
XPath-like globs on filesystems, which would completely replace eg.
File::Find, among other things. So you could ask for
/path/to/directory/child::*, which would get you the children, but not the
parent .. or the self .. I've actually started code in this direction
(ie. of a role, not the IO side of things), but stopped while waiting on the
further development of Rakudo (ie. operator overloading).
Anyway, just some thoughts thrown into the mix.
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: Support for ensuring invariants from one loop iteration to the next?
On 2008-Dec-6, at 7:37 am, Aristotle Pagaltzis wrote:
Funnily enough, I think you’re onto something here that you didn’t
even notice: [...]
if we had a NOTFIRST (which would run before ENTER just as FIRST
does, but on *every* iteration *except* the first), then we could
trivially attain the correct semantics and achieve all desired
results:
repeat {
@stuff = grep { !.valid }, @stuff };
NOTFIRST {
.do_something( ++$i ) for @stuff;
}
} while @stuff;
The really nice thing about this is that the blocks are nested, so
that any variable in scope for the invariant enforcement will also
be in scope in the NOTFIRST block without the user ever having to
arrange another enclosing scope.
Oh, yes! So what if we had LOOP $n {} that executed on the nth
iteration? LOOP 0 {} at the beginning would be like FIRST {}, LOOP
* {} at the end would be like LAST {}, and LOOP 1..* {} would give
us the NOTFIRST block. Presumably you could have multiple LOOP blocks
too.
(Actually, you couldn't quite do FIRST/LAST using LOOP $n, because
FIRST/LAST occur outside ENTER/LEAVE, whereas LOOP would occur
inside. But perhaps you could have LOOP blocks inside ENTER/LEAVE
blocks?)
-David
Proposal: Make @a and @@a different variables
Hi,
One of the hardest features in Perl 6 is the slice context. It is
undoubtfully usefull, since it provides semantics to acces each
iteration of a map, for instance.
But there's one thing in the spec that makes not only slices, but the
lists themselves considerably harder to implement, and that is the idea
that a slice is a view of a list.
my @@a = map { $^a == 2 ?? 1,2,3 !! () }, 1, 2, 3;
say @a[0]; # this should print 1.
say @@a[0]; # this should print ().
say @a[1]; # this should print 2.
say @@a[1;0]; # this should print 1.
That happens because '@a' and '@@a' are the same variable, just
different views of that variable.
That being said, we should note that this example looks simple because
we have almost no lazyness implied (since there's an assignment in the
first line), every list access requires the evaluation of the flatenning
of the list.
my @@a = ((),(1,2,3),());
# the following will require a flatenning to get the actual index
say @a[3];
This looks much more complicated when you have a lazy list...
my @a == map { $^a == 2 ?? 1,2,3 !! () }, 1, 2, 3;
# the line below will require two map iterations to get a value,
# and at that time, there will be three values available
say @a[0];
# having to support a slice view here will require the lazy list
# to always be a lazy slice, and each access will require a flatenning
# of the values already obtained to only then decide if it has to
# obtain more items
say @a[2];
This all makes me think that it would be much easier if the slice
existed on its own, which would mean:
# this will provide only a flatenned view
my @a == map { $^a == 2 ?? 1,2,3 !! () }, 1, 2, 3;
# and this will provide a slice view
my @@a == map { $^a == 2 ?? 1,2,3 !! () }, 1, 2, 3;
# but @a and @@a are different values
@a =!= @@a :test;
# and trying to get the slice on @a will fail
say @a[0;1]; # fail
# and you still can flatten the slice if you want to...
# and it can preserve the lazyness
my @b == @@a;
# or enforce a mostly eager level
my @c = @@a;
So, what do you think?
daniel
Re: Proposal: Make @a and @@a different variables
HaloO, Daniel Ruoso wrote: That being said, we should note that this example looks simple because we have almost no lazyness implied (since there's an assignment in the first line), every list access requires the evaluation of the flatenning of the list. my @@a = ((),(1,2,3),()); Mustn't that be written as (();(1,2,3);()) to produce a three element outer view? # the following will require a flatenning to get the actual index say @a[3]; Could we not shift the problem into a more complicated form of the size of the array? Here it has size 0+3+0 but each of the summands could be lazy and hence infinite or at least finite with unknown value. In any case the flat view @a has to step at most the first iterator in the array whereas @@a can look beyond that when indexed with a slice, that is something with semicolon in it. An out of bounds access like @a[3] can be answered without flattening, right? In general I'm in favor of making @a and @@a distinct because otherwise the first @ in @@a feels like an operator instead like a twigil that belongs to the variable like $ belongs to $a which is also distinct from @a. Since one could also go with a shaped @a I think the choice of @@a versus @a is a bit like the choice between a @a and an anonymous array in a $ var ala $a = [] which can be handled through $a almost like @a. @a =!= @@a :test; BTW, what does the :test mean there? Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: What does a Pair numify to?
TSa wrote: I see no problem as long as say gets a pair as argument. Then it can print the key and value separated with a tab. More problematic are string concatenations of the form say the pair is: ~ (foo = $bar); which need to be written so that say sees the pair say the pair is: , (foo = $bar); and not a string that only contains the value of the pair. I'm not sure if the parens are necessary to pass the pair to say as argument to be printed instead of a named argument that influences how the printing is done. That's a good point. Is there an easy way to distinguish between passing a pair into a positional parameter vs. passing a value into a named parameter? My gut instinct would be to draw a distinction between the different forms that Pair syntax can take, with foo = $bar being treated as an instance of the former and :foo($bar) being treated as an instance of the latter. That is: say 'the pair is: ', foo = $bar; would be equivalent to: say 'the pair is: ', foo\t$bar\n; while: say the pair is: , :foo($bar); would pass $bar in as the value of the named parameter 'foo' (which, I believe, would cause 'say' to squawk, as its signature doesn't allow for a named parameter 'foo'). -- Jonathan Dataweaver Lang
Re: What does a Pair numify to?
Moritz Lenz wrote: Off the top of my head, see S06 for the gory details: my $pair = a = 'b'; named(a = 'b'); named(:ab); named(|$pair); positional((a = 'b')); positional((:ab)); positional($pair); As you say: the gory details, emphasis on gory. But if that's the way of things, so be it. -- Jonathan Dataweaver Lang
Re: Proposal: Make @a and @@a different variables
Em Ter, 2008-12-16 às 18:47 +0100, TSa escreveu:
# the following will require a flatenning to get the actual index
say @a[3];
Could we not shift the problem into a more complicated form
of the size of the array? Here it has size 0+3+0 but each of the
summands could be lazy and hence infinite or at least finite with
unknown value.
The number of summands might be also unknown. i.e.: map.
when you have
my @a == map { ... } == something()
you can't really know how many elements you have in the first
dimension...
In any case the flat view @a has to step at most the first iterator in
the array
I'm not sure I see what you mean, but I presume you mean the first
iteration. In that case, if that iteration returns an empty capture, it
will continue iterating until it returns at least one item. But that
iteration can then return several items which need to be stored in the
lazy list.
whereas @@a can look beyond that when indexed with a slice, that is
something with semicolon in it.
Or the iterations of map and grep...
An out of bounds access like @a[3] can be answered without flattening,
right?
I consider counting the number of items in the inner dimension to be (a
simplified) flattening, think of:
my @@a == map { $^a == 2 ??
map { $^b == 2 ??
map { $^c == 2 $b == 2 $a == 2 ?? (1,2,3)
!! () }, 1, 2, 3
!! () }, 1, 2, 3
!! () }, 1, 2, 3;
That would result in
(();(();(1,2,3);());())
Which is considerably more complex than the first example and have the
following example slice accesses:
@@a[1]; # returns (();(1,2,3);())
@@a[1;1]; # returns (1,2,3)
@@a[1;1;0] # returns 1
Trying to access @a[0] would result in a recursive flattening until it
gets to the element that would otherwise be accessed by the slice
@@a[1;1;0]
So it's not just a matter of counting 0-3-0, because to get the first 0,
you need to recursively flatten the inner dimmension until you realize
it's really empty.
If we allow that to be flattened at the beginning, it will simply
consume the iterator until it gets an element.
In general I'm in favor of making @a and @@a distinct because
otherwise the first @ in @@a feels like an operator instead like
a twigil that belongs to the variable like $ belongs to $a which
is also distinct from @a.
That's an important point. I think it would be consistent that '@@a'
should be the variable name, just as '@a', '$a' or any other. Specially
since '@@' is not a sigil and a twigil, but a sigil of two characters.
Since one could also go with a shaped @a I think the choice of @@a
versus @a is a bit like the choice between a @a and an anonymous array
in a $ var ala $a = [] which can be handled through $a almost like @a.
I'm not sure I understood that, but I think you're saying that slice
context could be seen just as a regular context, as scalar and list
context, which is something that I agree.
@a =!= @@a :test;
BTW, what does the :test mean there?
This is the proposed syntax for integration of test-driven-development
in the language built-ins.
daniel
Re: Out of CONTROL...?
On Mon, Dec 08, 2008 at 02:32:14PM -0600, Patrick R. Michaud wrote:
: A very interesting question came up on #perl today, so I'm
: forwarding it to p6l for discussion/decision.
:
: Given the following code:
:
: sub foo() { return 1; }
: sub bar() { warn oops; }
:
: {
: CONTROL { ... }
: foo();
: bar();
: }
:
: S04 seems to clearly indicate that the CONTROL block above would
: be invoked by the Cwarn exception thrown by bar(). The #perl6
: question is, do the same semantics apply for Creturn -- i.e.,
: would the return exception thrown in foo() also invoke the
: CONTROL block in the caller?
:
: Both interpretations have validity, which is why I'm bringing
: it here for further reflection and guidance.
foo()'s implicit CONTROL handles the return after checking that the
exception's target context happens to match ?ROUTINE, so the outward
search for a handler terminates at that point. Doing it the other way
would make it impossible to optimize return into a goto end-of-routine.
Unlike warn, return is normal control flow, and we need to be careful
not to mandate largely useless overhead.
Larry
Re: Resume from exception
On Mon, Dec 15, 2008 at 03:06:44PM -0700, Stephen Weeks wrote:
: do {
: die 'some text';
: say 'after the exception';
: CATCH {
: say 'caught the exception';
: ...; # what goes here?
: }
: }
:
: My proposal is to call .resume() on the exception object.
It could just be .thrower.leave, if .thrower can return the ?ROUTINE
of fail() or equivalent. Note that fail() has not been exited yet,
so it can be left via a simple .leave without requiring continuation
support. That's one of the reasons we don't unwind the stack while
we're running exception handlers. Not every VM will provide efficient
continuation support.
That doesn't answer the question of whether resumption *should*
be allowed from a failure that isn't expecting it to continue.
The control flow may well be written such that returning from fail() is
just going to mess things up worse, if the user is not expecting fail()
to return. On the other hand, returning from warn() is expected, and
other such routines might have such expectations as well. And the
Resumable role is just moving the arbitrary decision elsewhere,
I suspect. In the absence of an obvious peg to hang the decision on,
it's going to have to be a process of negotiation between broken code
and exception handlers.
Maybe we just make it easy to leave warnings and other known resumables
with a .resume, and for the dicey cases force the exception handler to
do a caller scan to find the correct fail() to leave if it wants to go
to that trouble. And we presume that if it goes to that much trouble
to handle an exception, it knows somehow that leaving the fail() is
appropropriate. But just as likely it will want to throw a 'last',
'next', or 'redo' exception to some outer loop, or maybe enter some
kind of safe mode, if it's a spacecraft. So I think the exception
handlers have to be trusted to make the final determination of how
to handle exceptions, which seems reasonable. Engineers who write
bad exception handlers will lose control of their work.
Larry
Re: Proposal: Make @a and @@a different variables
I think I'm fine with making them separate. Recursive lazy flattening seems too evil; slice and list contexts should not try to do the work of captures. Thanks. Larry
Re: Proposal: Make @a and @@a different variables
TSa wrote:
HaloO,
Daniel Ruoso wrote:
That being said, we should note that this example looks simple because
we have almost no lazyness implied (since there's an assignment in the
first line), every list access requires the evaluation of the flatenning
of the list.
my @@a = ((),(1,2,3),());
Mustn't that be written as (();(1,2,3);()) to produce a three
element outer view?
Aye, it must.
@a =!= @@a :test;
BTW, what does the :test mean there?
We discussed the option to change our testing syntax from
ok(@a =!= @@a, '@a and @aa mean different things')
to
@a =!= @@a :ok('@a and @aa mean different things')
or maybe with :test instead of :ok.
I'll open a thread about that in January, in the hope that the outcome
will enable me to draft S24.
Cheers,
Moritz
Re: What does a Pair numify to?
Jon Lang wrote: That's a good point. Is there an easy way to distinguish between passing a pair into a positional parameter vs. passing a value into a named parameter? Off the top of my head, see S06 for the gory details: my $pair = a = 'b'; named(a = 'b'); named(:ab); named(|$pair); positional((a = 'b')); positional((:ab)); positional($pair); Cheers, Moritz
Re: Support for ensuring invariants from one loop iteration to the next?
On Tue, 16 Dec 2008, David Green wrote:
On 2008-Dec-6, at 7:37 am, Aristotle Pagaltzis wrote:
Funnily enough, I think you?re onto something here that you didn?t even
notice: [...]
if we had a NOTFIRST (which would run before ENTER just as FIRST does, but
on *every* iteration *except* the first), then we could trivially attain
the correct semantics and achieve all desired results:
repeat {
@stuff = grep { !.valid }, @stuff };
NOTFIRST {
.do_something( ++$i ) for @stuff;
}
} while @stuff;
The really nice thing about this is that the blocks are nested, so that any
variable in scope for the invariant enforcement will also be in scope in
the NOTFIRST block without the user ever having to arrange another
enclosing scope.
Oh, yes! So what if we had LOOP $n {} that executed on the nth iteration?
LOOP 0 {} at the beginning would be like FIRST {}, LOOP * {} at the end
would be like LAST {}, and LOOP 1..* {} would give us the NOTFIRST block.
Presumably you could have multiple LOOP blocks too.
(Actually, you couldn't quite do FIRST/LAST using LOOP $n, because FIRST/LAST
occur outside ENTER/LEAVE, whereas LOOP would occur inside. But perhaps you
could have LOOP blocks inside ENTER/LEAVE blocks?)
Or, instead of having a new block, just add the iterator indicator to
the NEXT block, and get rid of ENTER and LEAVE. That way, you'd have this
sequence:
- FIRST {}
- NEXT 0 {} # Replaces ENTER
- NEXT 1..* {} # Does NOTFIRST
- NEXT * {} # Replaces LEAVE
- LAST {}
Would that do it?
The difficulty to my mind would be sequencing the NEXT blocks; does
the NEXT 1..* run before or after NEXT 2..(*-2) ? Maybe we need a NEXT stack.
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: Support for ensuring invariants from one loop iteration to the next?
How do you compute '*'? That is, how do you know how many more iterations you have to go before you're done? Should you really be handling this sort of thing through an iteration count mechanism? How do you keep track of which iteration you're on? Is it another detail that needs to be handled behind the scenes, or is the index of the current iteration available to the programmer? (Remember, we're dealing with 'while' and 'loop' as well as 'for'.) -- Jonathan Dataweaver Lang
Re: Support for ensuring invariants from one loop iteration to the next?
On Tue, 16 Dec 2008, Jon Lang wrote: How do you compute '*'? That is, how do you know how many more iterations you have to go before you're done? In some cases, it won't have to be computed, in some cases it won't be computeable (which should be an error). I'd say it'd be fair enough to say that 1..(*-1) should be an error in non-bounded(?) loops (ie. while). Just figure things out when we can, and when we can't, give an error. Should you really be handling this sort of thing through an iteration count mechanism? How do you keep track of which iteration you're on? Is it another detail that needs to be handled behind the scenes, or is the index of the current iteration available to the programmer? (Remember, we're dealing with 'while' and 'loop' as well as 'for'.) I'd say track it if necessary, kinda like the regex variables in Perl5 that imposed a performance hit. Have a magic variable that tracks the loop count if: - The variable is referred to anywhere - Any of the NEXTs require it It seems like the NEXT queue I suggested is already specced (although without the iterator count thingies). I'm also starting to wonder what we do with the return values of the NEXT blocks :). :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Working with files wish list
On Tue, Dec 16, 2008 at 7:04 AM, jason switzer jswit...@gmail.com wrote: I hadn't seen a Nameable role mentioned yet, so I wasn't able to understand any such concept. The list was not meant to be exhaustive. There are a lot more roles that have something to do with IO but were missing: Asynchronous IO, Datagram sockets, and more (specially when you add in platform specific stuff). The whole idea is that almost any operation you can do on one kind of handle can be done on some other kind too. There is a lot of overlap between seemingly unrelated types of handles. In this case, files and unix domain sockets are created and used in rather different ways, but both have a place in the filesystem, so it would be appropriate that they share the interface for retrieving that location. That is a good idea, but the idea is so general that anything can be nameable and thus the specificity of the role could quickly become lost. I was suggesting specific naming functionalities be added to the File role. If you want to abstract that, that's fine, but beware that something like Nameable can be too broad of a role (maybe just IONameable?). I agree Nameable isn't the best name. How about Locatable? Having said that, I suppose a generic Nameable role providing a human readable designation to a handle (as opposed to one for computers) would be useful too, if only for error messages. I haven't spent the time to understand mix-ins yet, but this does look like a feasible (clean) idea. However, how do you specify one/more filters? For example, say you want to :rw a file. How can you provide an input filter and an output filter (or multiples of either)? Can you layer filters if done with mix-ins? Stacking can be done: $fstab does WhitespaceTrim does TranslateKlingon; I'm not sure if this is the best way to approach the problem though. This is a power drill, a screwdriver will also do in many cases. If so, how do you specify direction? That would be a problem with this approach. You'd probably need separate roles for readers and writers. Regards, Leon Timmermans
6PAN idea
Hi all. I've been working on some stuff that's vaguely, tangentially CPAN-related. My basic assumption is that there's going to be some kind of packaging system written around 6PAN. One thing I've been working on recently is a (Perl 5) object that models package metadata. In theory, it should be able to model the metadata from a .rpm, a .deb, a CPAN package, or whatever. Then you read the data using a metadata input class, and write it using a metadata output class. This would mean that eg. CPAN metadata could be turned into RPM metadata, but also vice versa. Debian would naturally be convertible into either of these. The model isn't CPAN-specific, but relying on such a setup would save work for everyone. Thoughts? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: r24325 - docs/Perl6/Spec
On Mon, Dec 15, 2008 at 11:18:54PM -0500, Mark J. Reed wrote: On Mon, Dec 15, 2008 at 5:41 PM, Moritz Lenz mor...@faui2k3.org wrote: I know at least of infix:cmp(Num $a, Num $b) (which does the same as Perl 5's =) and infix:cmp(Pair $a, Pair $b) (which does $a.key cmp $a.key || $a.value cmp $b.value), so numbers and pairs DWIM. Hm. Rakudo doesn't let me cmp pairs at all currently: (a = 2) cmp (a = 10) Multiple Dispatch: No suitable candidate found for 'cmp', with signature 'PP-I' It does now: say (a = 2) cmp (a = 10); -1 S02:1600 somewhat implies that comparison of pairs is based on keys by default, then on values if keys are equal. Rakudo implements this behavior. In particular, one can now quickly print out a hash sorted by key using C .say for %hash.sort : my %hash = parrot speaks your language Z 1..4; .say for %hash.sort; language4 parrot 1 speaks 2 your3 Pm
Re: 6PAN idea
On 2008 Dec 16, at 23:00, Timothy S. Nelson wrote: One thing I've been working on recently is a (Perl 5) object that models package metadata. In theory, it should be able to model the metadata from a .rpm, a .deb, a CPAN package, or whatever. Then you read the data using a metadata input class, and write it using a metadata output class. This would mean that eg. CPAN metadata could be turned into RPM metadata, but also vice versa. Debian would naturally be convertible into either of these. The model isn't CPAN-specific, but relying on such a setup would save work for everyone. Thoughts? You might want to look at alien first, to get an idea of what can be done --- and what can't. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH
Re: 6PAN idea
On Tue, 16 Dec 2008, Brandon S. Allbery KF8NH wrote: On 2008 Dec 16, at 23:00, Timothy S. Nelson wrote: One thing I've been working on recently is a (Perl 5) object that models package metadata. In theory, it should be able to model the metadata from a .rpm, a .deb, a CPAN package, or whatever. Then you read the data using a metadata input class, and write it using a metadata output class. This would mean that eg. CPAN metadata could be turned into RPM metadata, but also vice versa. Debian would naturally be convertible into either of these. The model isn't CPAN-specific, but relying on such a setup would save work for everyone. Thoughts? You might want to look at alien first, to get an idea of what can be done --- and what can't. Good idea. Just to clarify some things: - The package I'm talking about only models metadata; it doesn't worry about the rest of the stuff - My idea was to support all reasonable metadata (within reason, but I haven't yet run across anything I think unreasonable), and then emit warnings when metadata isn't supported by a particular backend. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Support for ensuring invariants from one loop iteration to the next?
On 2008-Dec-16, at 6:21 pm, Timothy S. Nelson wrote:
Or, instead of having a new block, just add the iterator indicator
to the NEXT block, and get rid of ENTER and LEAVE. That way, you'd
have this sequence:
- FIRST {}
- NEXT 0 {} # Replaces ENTER
- NEXT 1..* {} # Does NOTFIRST
- NEXT * {} # Replaces LEAVE
- LAST {}
Would that do it?
Not quite -- the idea is that you could put the LOOP block anywhere in
the body of the loop, and it would execute at that point. NEXT and
friends always occur at the end (or beginning) of their block.
Nor would it work to take an existing block like NEXT and allow it to
be positioned in the middle of the body, because it wouldn't be
possible to duplicate what they already do -- in this example, the
NEXT wouldn't get executed when next if something() occurs:
loop
{
next if something();
a;
NEXT { ... }
b;
}
On Tue, 16 Dec 2008, Jon Lang wrote:
How do you compute '*'? That is, how do you know how many more
iterations you have to go before you're done?
In some cases, it won't have to be computed, in some cases it won't
be computeable (which should be an error). I'd say it'd be fair
enough to say that 1..(*-1) should be an error in non-bounded(?)
loops (ie. while).
That sounds right to me. Does 'for @foo' take a snapshot of @foo, or
can you change the bounds by changing @foo while the loop is running?
In which case trying to count back from * might be an error for
anything except constant bounds.
-David
