Re: Lessons to learn from ithreads (was: threads?)
On Fri, Oct 15, 2010 at 11:04:18AM +0100, Tim Bunce wrote: On Thu, Oct 14, 2010 at 11:52:00PM -0400, Benjamin Goldberg wrote: From: tim.bu...@pobox.com So I'd like to use this sub-thread to try to identify when lessons we can learn from ithreads. My initial thoughts are: - Don't clone a live interpreter. Start a new thread with a fresh interpreter. - Don't try to share mutable data or data structures. Use message passing and serialization. If the starting subroutine for a thread is reentrant, then no message passing is needed, and the only serialization that might be needed is for the initial arguments and for the return values (which will be gotten by the main thread via join). As for starting a new thread in a fresh interpreter, I think that it might be necessary to populate that fresh interpreter with (copies of) data which is reachable from the subroutine that the thread calls... reachability can probably be identified by using the same technique the garbage collector uses. This would provide an effect similar to ithreads, but only copying what's really needed. To minimize copying, we would only treat things as reachable when we have to -- for example, if there's no eval-string used a given sub, then the sub only reaches those scopes (lexical and global) which it actually uses, not every scope that it could use. Starting an empty interpreter, connected to the parent by some 'channels', is simple to understand, implement and test. I was recently reminded of the ongoing formal specification of Web Workers, which fits that description quite well: http://www.whatwg.org/specs/web-workers/current-work/ Since no one seems to have mentioned it in the thread I thought I would. From the intro: This specification defines an API for running scripts in the background independently of any user interface scripts. This allows for long-running scripts that are not interrupted by scripts that respond to clicks or other user interactions, and allows long tasks to be executed without yielding to keep the page responsive. Workers (as these background scripts are called herein) are relatively heavy-weight, and are not intended to be used in large numbers. For example, it would be inappropriate to launch one worker for each pixel of a four megapixel image. The examples below show some appropriate uses of workers. Generally, workers are expected to be long-lived, have a high start-up performance cost, and a high per-instance memory cost. Tim. In contrast, I suspect the kind of partial-cloning you describe above would be complex, hard to implement, hard to test, and fragile to use. It is, for example, more complex than ithreads, so the long history of ithreads bugs should server as a warning. I'd rather err on the side of simplicity. Tim.
Re: threads?
On Sun, Oct 17, 2010 at 01:18:09AM +0200, Carl Mäsak wrote:
Damian (), Matt ():
Perhaps we need to think more Perlishly and reframe the entire question.
Not: What threading model do we need?, but: What kinds of non-sequential
programming tasks do we want to make easy...and how would we like to be
able to specify those tasks?
I watched a presentation by Guy Steele at the Strange Loop conference on
Thursday where he talked about non-sequential programming. One of the
interesting things that he mentioned was to use the algebraic properties of
an
operation to know when a large grouping of operations can be done
non-sequentially.
For example, we know that the meta reduction operator could take very large
lists
and split them into smaller lists across all available cores when
performing certain
operations, like addition and multiplication. If we could mark new
operators that
we create with this knowledge we could do this for custom operators too.
This isn't
a new idea, but it seems like it would be a helpful tool in simplifying
non-sequential
programming and I didn't see it mentioned in this thread yet.
This idea seems to be in the air somehow. (Even though all copies of
the meme might have its roots in that Guy you mention.)
http://irclog.perlgeek.de/perl6/2010-10-15#i_2914961
Perl 6 has all the prerequisites for making this happen. It's mostly a
question of marking things up with some trait or other.
our multi sub infix:+($a, $b) will optimizeassociativity {
...
}
(User-defined ops can be markes in exactly the same way.)
All that's needed after that is a reduce sub that's sensitive to such
traits. Oh, and threads.
Minimizing the overhead of such a mechanism would be crucial to making
it beneficial for use on non-massive data sets.
For this kind of thing to work well we'd need to have multiple threads
able to work in a single interpreter.
Tim.
Re: Lessons to learn from ithreads (was: threads?)
On Thu, Oct 14, 2010 at 11:52:00PM -0400, Benjamin Goldberg wrote: From: tim.bu...@pobox.com So I'd like to use this sub-thread to try to identify when lessons we can learn from ithreads. My initial thoughts are: - Don't clone a live interpreter. Start a new thread with a fresh interpreter. - Don't try to share mutable data or data structures. Use message passing and serialization. If the starting subroutine for a thread is reentrant, then no message passing is needed, and the only serialization that might be needed is for the initial arguments and for the return values (which will be gotten by the main thread via join). As for starting a new thread in a fresh interpreter, I think that it might be necessary to populate that fresh interpreter with (copies of) data which is reachable from the subroutine that the thread calls... reachability can probably be identified by using the same technique the garbage collector uses. This would provide an effect similar to ithreads, but only copying what's really needed. To minimize copying, we would only treat things as reachable when we have to -- for example, if there's no eval-string used a given sub, then the sub only reaches those scopes (lexical and global) which it actually uses, not every scope that it could use. Starting an empty interpreter, connected to the parent by some 'channels', is simple to understand, implement and test. In contrast, I suspect the kind of partial-cloning you describe above would be complex, hard to implement, hard to test, and fragile to use. It is, for example, more complex than ithreads, so the long history of ithreads bugs should server as a warning. I'd rather err on the side of simplicity. Tim.
Re: Lessons to learn from ithreads (was: threads?)
Earlier, Leon Timmermans wrote: : * Code sharing is actually quite nice. Loading Moose separately in a : hundred threads is not. This is not trivial though, Perl being so : dynamic. I suspect this is not possible without running into the same : issues as ithreads does. On Fri, Oct 15, 2010 at 01:22:10PM +0200, Leon Timmermans wrote: On Wed, Oct 13, 2010 at 1:13 PM, Tim Bunce tim.bu...@pobox.com wrote: If you wanted to start a hundred threads in a language that has good support for async constructs you're almost certainly using the wrong approach. In the world of perl6 I expect threads to be used rarely and for specific unavoidably-bocking tasks, like db access, and where true concurrency is needed. I agree starting a large number of threads is usually the wrong approach, but at the same time I see more reasons to use threads than just avoiding blocking. We live in a multicore world, and it would be nice if it was easy to actually use those cores. I know people who are deploying to 24 core systems now, and that number will only grow. Processes shouldn't be the only way to utilize that. We certainly need to be able to make good use of multiple cores. As I mentioned earlier, we should aim to be able to reuse shared pages of readonly bytecode and jit-compiled subs. So after a module is loaded into one interpreter it should be much cheaper to load it into others. That's likely to be a much simpler/safer approach than trying to clone interpreters. Another important issue here is portability of concepts across implementations of perl6. I'd guess that starting a thread with a fresh interpreter is likely to be supportable across more implementations than starting a thread with cloned interpreter. Also, if we do it right, it shouldn't make much difference if the new interpreter is just a new thread or also a new process (perhaps even on a different machine). The IPC should be sufficiently abstracted to just work. (Adding thread/multiplicity support to NYTProf shouldn't be too hard. I don't have the time/inclination to do it at the moment, but I'll fully support anyone who has.) I hate how you once again make my todo list grow :-p Well volunteered! ;) Tim.
Ruby Fibers (was: threads?)
On Tue, Oct 12, 2010 at 07:22:33AM -0700, Damian Conway wrote: What we really need is some anecdotal evidence from folks who are actually using threading in real-world situations (in *any* languages). What has worked in practice? What has worked well? What was painful? What was error-prone? And for which kinds of tasks? And we also need to stand back a little further and ask: is threading the right approach at all? Do threads work in *any* language? Are there better metaphors? I've not used them, but Ruby 1.9 Fibers (continuations) and the EventMachine Reactor pattern seem interesting. http://www.igvita.com/2009/05/13/fibers-cooperative-scheduling-in-ruby/ http://www.igvita.com/2010/03/22/untangling-evented-code-with-ruby-fibers/ There's also an *excellent* screencast by Ilya Grigorik. It's from a Ruby/Rails perspective but he gives a good explanation of the issues. He shows how writing async code using callbacks rapidly gets complex and how continuations can be used to avoid that. Well worth a look: http://blog.envylabs.com/2010/07/no-callbacks-no-threads-ruby-1-9/ Tim. p.s. If short on time start at 15:00 and watch to at least 28:00.
Lessons to learn from ithreads (was: threads?)
On Tue, Oct 12, 2010 at 03:42:00PM +0200, Leon Timmermans wrote: On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg ben-goldb...@hotmail.com wrote: If thread-unsafe subroutines are called, then something like ithreads might be used. For the love of $DEITY, let's please not repeat ithreads! It's worth remembering that ithreads are far superior to the older 5005threads model, where multiple threads ran with an interpreter. [Shudder] It's also worth remembering that real O/S level threads are needed to work asynchronously with third-party libraries that would block. Database client libraries that don't offer async support are an obvious example. I definitely agree that threads should not be the dominant form of concurrency, and I'm certainly no fan of working with O/S threads. They do, however, have an important role and can't be ignored. So I'd like to use this sub-thread to try to identify when lessons we can learn from ithreads. My initial thoughts are: - Don't clone a live interpreter. Start a new thread with a fresh interpreter. - Don't try to share mutable data or data structures. Use message passing and serialization. Tim.
Re: Lessons to learn from ithreads (was: threads?)
On Wed, Oct 13, 2010 at 04:00:02AM +0200, Leon Timmermans wrote: On Wed, Oct 13, 2010 at 12:46 AM, Tim Bunce tim.bu...@pobox.com wrote: So I'd like to use this sub-thread to try to identify when lessons we can learn from ithreads. My initial thoughts are: - Don't clone a live interpreter. Start a new thread with a fresh interpreter. - Don't try to share mutable data or data structures. Use message passing and serialization. Actually, that sounds *exactly* like what I have been trying to implementing for perl 5 based on ithreads (threads::lite, it's still in a fairly early state though). My experience with it so far taught me that: * Serialization must be cheap for this to scale. For threads::lite this turns out to be the main performance bottleneck. Erlang gets away with this because it's purely functional and thus doesn't need to serialize between local threads, maybe we could do something similar with immutable objects. Here micro-optimizations are going to pay off. Being able to optionally define objects as structures in contiguous memory could be a useful optimization. Both for serialization and general cache-friendly cpu performance. Just a thought. * Code sharing is actually quite nice. Loading Moose separately in a hundred threads is not. This is not trivial though, Perl being so dynamic. I suspect this is not possible without running into the same issues as ithreads does. If you wanted to start a hundred threads in a language that has good support for async constructs you're almost certainly using the wrong approach. In the world of perl6 I expect threads to be used rarely and for specific unavoidably-bocking tasks, like db access, and where true concurrency is needed. Also, it should be possible to share read-only bytecode and perhaps read-only jit'd executable pages, to avoid the full cost of reloading modules. * Creating a thread (/interpreter) should be as cheap as possible, both in CPU-time as in memory. Creating an ithread is relatively expensive, specially memorywise. You can't realistically create a very large number of them the way you can in Erlang. Erlang has just the one kind of concurrency mechanism: the thread so you need to create lots of them (which Erlang makes very cheap). We're looking at two concurrency mechanisms for perl6: Heavy-weight O/S thread+interpreter pairs (as above), and lightweight async behaviours within a single interpreter (eg continuations/fibers). Those lightweight mechanisms are most like Erlang threads. They'll be cheap and plentiful, so they'll be far less need to start O/S threads. Tim. Leon (well actually I learned a lot more; like about non-deterministic unit tests and profilers that don't like threads, but that's an entirely different story) (Adding thread/multiplicity support to NYTProf shouldn't be too hard. I don't have the time/inclination to do it at the moment, but I'll fully support anyone who has.)
Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]
This thread reminded me of something I'd posted a while ago: ---snip--- Date: Wed, 26 Nov 2008 14:23:11 + From: Tim Bunce tim.bu...@pobox.com To: Richard Hainsworth rich...@rusrating.ru, perl6-language@perl.org Subject: Re: Files, Directories, Resources, Operating Systems On Wed, Nov 26, 2008 at 12:40:41PM +0100, Mark Overmeer wrote: We should focus on OS abstraction. [...] the design of this needs to be free from historical mistakes. And avoid making too many new ones. There must be useful prior art around. Java, for example, has a FileSystem abstraction java.nio.file.FileSystem http://openjdk.java.net/projects/nio/javadoc/java/nio/file/FileSystem.html which has been extended, based on leasons learnt, in the NIO.2 project (JSR 203: More New I/O APIs for the JavaTM Platform (NIO.2) APIs for filesystem access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagrams.) which enables things like being able to transparently treat a zip file as a filesystem: http://blogs.sun.com/rajendrag/entry/zip_file_system_provider_implementation See http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf Tim. p.s. I didn't know any of that when I started to write this look for prior art email, but a little searching turned up these examples. I'm sure there are more in other realms, but NIO.2 certainly looks like a rich source of good ideas derived from a wide range of experience. ---snip--- See http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf plus http://java.sun.com/developer/technicalArticles/javase/nio/ There are many hard-learnt lessons in there that we can benefit from. At the very least the APIs give us things to think about. Tim.
Berkeley Orders Of Magnitude project
This struck me as interesting... http://highscalability.com/blog/2010/6/18/paper-the-declarative-imperative-experiences-and-conjectures.html The Declarative Imperative: Experiences and Conjectures in Distributed Logic http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-90.pdf Tim.
Re: r29770 - docs/Perl6/Spec
On Wed, Feb 17, 2010 at 11:02:58PM +0100, pugs-comm...@feather.perl6.nl wrote: Author: lwall New Revision: 29770 Modified: docs/Perl6/Spec/S04-control.pod +resumed that the stack is unwound the the phasers called. the the Tim.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
I gave the talk at OSSBarcamp in Dublin last weekend and it went well. My sincere thanks to everyone who contributed. The slides are available at: http://www.slideshare.net/Tim.Bunce/perl-myths-200909 The graphs and stats charting the continuing growth of perl and the perl community were surprising (and delighting) even to me. The presentation was even featured on the slideshare.net home page for a while. Yeah! I'll be giving the talk again at HighLoad++ in Moscow in a couple of weeks time, and possibly again at IPW09 in Pisa later in October (though it's not been scheduled yet). So I'd be grateful for any feedback on the talk. Corrections, improvements, extra data etc. Thanks again! Tim. p.s. I've already fixed the suprious reference to CPANTS.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
On Mon, Sep 14, 2009 at 03:07:40PM -0700, Darren Duncan wrote: pp 22-23 - You might want to update the screen captures related to Moose, both its search.cpan page and dependency graph, since its moved a long way from 2008; on the other hand, the existing captures are still quite representative, which is the point, so maybe nothing to do here. Already on my if I have time list. pg 52 - Still have XXX for count of Perl 5.10.1 core, bundled tests. Done. Perl 5.10.1 has 92,697 core tests +142,101 more for bundled libraries etc. pg 56 - Newest Perl versions 5.10.1, 5.8.9 not in graph. Updated to the latest, which also has more platforms. http://matrix.cpantesters.org/?dist=DBI+1.609 I don't know if you're going for visual consistency between the Perl 5 and Perl 6 sections, but in the former, the section dealing with each myth ended with the title of that myth with busted superimposed. Now even if you're not going for the multi-screen transition, you should at least mark the end of each section with busted. Another if I have time. (The Perl 6 portion was a bit of a bolt-on originally.) pg 73 - I suggest having Rakudo first in the list and Pugs second They're in a vagely cronological order, in line with the whirlpool metaphor on the previous pages. Generally speaking with your metrics, it is valuable to distinguish of a project's code lines from its documentation lines (or blank lines). I'll probably drop mention of code lines and focus on projects, using the nice graph of projects known to proto that Moritz generated. (Counting lines of perl 6 code, even non-doc-non-blank lines, isn't very useful when talking to an audience who don't appreciate the expressive power of the language.) pg 80 - You already recognized the need to update the graph. And of course, when you do, you would be sure to mention that any significant dip starting through 2008 was due to lots of sub-projects splitting off. And the Rakudo commits graph that shows up 5 slides later shows where some of those went. I've still not found an update to that graph, or even any details about where it came from originally. Once again great work. And its particularly good that you're backing up what you say in general with data, so its easier to trust, verify, and convince. And graphs are easy to absorb / make an impact. Thanks for all the feedback Darren. I hope you're going to post another draft between now and the talk, so people can review it again post changes. Possibly not before Dublin (on Saturday) but certainly before Moscow (3 weeks away). Tim.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
On Tue, Sep 15, 2009 at 09:40:46AM +1000, Damian Conway wrote: Darren Duncan wrote: So another proposal I have is to add to the slideshow mentions of the Enlightened and Modern Perl movements and where one can go to read more, this being supplemental to PBP. With that suggestion I'd whole-heartedly concur. I'm covering that with a slide based on chromatic's blog post http://www.modernperlbooks.com/mt/2009/07/milestones-in-the-perl-renaissance.html (I've taken a few minor liberties with the dates, so don't get picky.) Milestones in the Perl Renaissance 2001: Lexical file-handles, Test::Simple 2002: Module::Build, Test::Builder, 2003: PAR, Perl 5.8.1 2004: Perl 6 Apocalypse 12 (Roles), CPANTS 2005: PPI, Perl::Critic 2006: CPAN Testers, Moose, Strawberry Perl 2007: Devel::Declare, local::lib 2008: Padre, Enlightened Perl Organization 2009: Iron Man Blogging Challenge with a speaker note of All this happened after the Perl 6 project was announced. Modern Perl, 21st Century Perl, is very different to 20th Century Perl. Tim.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
On Mon, Sep 14, 2009 at 03:46:54PM +0200, Carl Mäsak wrote: Tim (): I'd be grateful for feedback on any of the slides, but I'm especially interested in updates for: page 73 - Perl 6 implementations I've added Mildew, with links, to the SMOP line anything I should add / change / remove? What's the status of KindaPerl6? I think Elf could very well be added to those. page 77 - quantity of code writen in Perl 6 are there any other significant perl6 codebases? Again, Elf is a nice, large example. :) Got a url? (I've not been keeping up with perl6 as much as I'd like) Depending on what you mean by significant, I'd also like to direct your attention towards SVG::Plot, proto, Gamebase, CSV, Druid, Form, HTTP::Daemon, Perl6::SQLite and Web.pm. All of those can be downloaded via proto. I'd really appreciate a list of significant perl6 projects, with a few words of description of each, that I could put on a slide. (Similar to the Many gems on CPAN ... on page 18.) The goal being to give a sense that there are significant projects being implemented in perl6. Anything else I should add, change or remove? I'm especially interested in verifyable metrics showing effort, progress, or use. Ideally graphical. Any interesting nuggets that fit with the theme will be most welcome. Moritz++ and I were talking about making a graph showing the increase of Perl 6 projects lately. Proto's project.list contains all the pertinent history, so half an hour with git-log and SVG::Plot ought to be able to produce something nice. If no-one else takes that as a hint, I might look at it soonish. :) Moritz has come up trumps on that one. Tim.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
On Tue, Sep 15, 2009 at 04:46:33PM +0200, Carl Mäsak wrote: Tim (), Carl (), Tim (): I'd be grateful for feedback on any of the slides, but I'm especially interested in updates for: page 73 - Perl 6 implementations I've added Mildew, with links, to the SMOP line anything I should add / change / remove? What's the status of KindaPerl6? I think Elf could very well be added to those. page 77 - quantity of code writen in Perl 6 are there any other significant perl6 codebases? Again, Elf is a nice, large example. :) Got a url? (I've not been keeping up with perl6 as much as I'd like) This one here seems a good introduction: http://perl.net.au/wiki/Elf. Ah, cool. I'll include Elf on the Multiple Implementations page. Depending on what you mean by significant, I'd also like to direct your attention towards SVG::Plot, proto, Gamebase, CSV, Druid, Form, HTTP::Daemon, Perl6::SQLite and Web.pm. All of those can be downloaded via proto. I'd really appreciate a list of significant perl6 projects, with a few words of description of each, that I could put on a slide. (Similar to the Many gems on CPAN ... on page 18.) The goal being to give a sense that there are significant projects being implemented in perl6. The list I gave above was my subjective, somewhat hasty traversal of projects.list, filtering on what I consider significant (meaning that people use it today or it holds some promise). Here's the same list, with a one-sentence (also subjective) description of each project: [...] It's entirely possible that I've forgotten some important module above, so don't hesitate to pipe up if one comes to mind. Thanks. On Tue, Sep 15, 2009 at 06:04:15PM +0200, Raphael Descamps wrote: Some XML related stuff: XML parser: http://github.com/fperrad/xml/ Tree manipulation: http://github.com/wayland/Tree/tree/master Thanks. Any reason they're not known to proto? Tim.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
On Tue, Sep 15, 2009 at 12:15:10PM -0400, Nathan Gray wrote: On Mon, Sep 14, 2009 at 12:15:05PM +0100, Tim Bunce wrote: You can find my current draft at http://files.me.com/tim.bunce/65oikg (2.3MB PDF) page 73 - Haskell should be spelled with two Ls Thank you! I kept wondering if that was spelt right but never got round to checking. (The Mac's spell checker wan't to change it to Hassle :) Tim.
Looking for help updating Perl 6 and Parrot part of Perl Myths talk
I'm working on an update to my Perl - Baseless Myths and Startling Realities talk. (Which I'll be giving in Dublin, Moscow and Pisa in the few weeks!) I got great help on the Perl 5 portion of the talk when I asked via my blog http://blog.timbunce.org/2009/08/13/help-me-update-my-perl-myths-talk-for-2009/ but I've not had any input for the later slides on Perl 6 and Parrot. You can find my current draft at http://files.me.com/tim.bunce/65oikg (2.3MB PDF) It's worth reading just to see the great health and vigour of the Perl community. The updated CPAN graphs are quite amazing in themselves. I'd be grateful for feedback on any of the slides, but I'm especially interested in updates for: page 73 - Perl 6 implementations I've added Mildew, with links, to the SMOP line anything I should add / change / remove? What's the status of KindaPerl6? page 77 - quantity of code writen in Perl 6 are there any other significant perl6 codebases? page 80 - graph of parrot commits and releases I don't have a url for that graph. Do you? Is it maintained? Can anyone update it for me? Can anyone produce a similar one for rakudo? page 81 - size of parrot test suite I can update the basic number myself, but how many runcores are considered useful? page 85 - Rakudo test progress I've just updated this to the latest myself. Anything else I should add, change or remove? I'm especially interested in verifyable metrics showing effort, progress, or use. Ideally graphical. Any interesting nuggets that fit with the theme will be most welcome. Thanks! Tim.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
On Mon, Sep 14, 2009 at 05:49:41PM +0400, Richard Hainsworth wrote: For the slides on Rakudo, I would suggest adding the modules that are associated with proto as measure of code written in perl6. There is a list of 27 projects. proto in itself is an interesting installer. I wasn't aware of proto. Interesting. I'd be grateful if someone could find out how many lines of perl6 code are in each of those projects. I don't think I'll have time this week. Also, the number of tests written for perl6 is substantial (18,000 vs 1,400 for Ruby - your figure). I think jruby has a larger test suite that's being adopted as the ruby test suite. If sometone knows more about this, or ruby testing in general, please send me an email. Tim.
Re: Rukudo-Star = Rakudo-lite?
On Sun, Aug 09, 2009 at 10:19:44AM -0500, Patrick R. Michaud wrote: On Sun, Aug 09, 2009 at 04:30:07PM +0400, Richard Hainsworth wrote: Referring to Patrick's blog about an official 'useable' version of Rakudo, a suggestion: Since Rakudo* (not sure how it is to be written) is intended to be a cut-down version of perl6.0.0 that is useable, how about Rakudo-lite? Hmmm, that's a very reasonable name. Over the past few days I've become a little attached to Rakudo Star, but I agree that Rakudo light might be a bit more descriptive. I'll have to mull it over a while. Perhaps it's worth asking what we might call the release after that one. Rakudo not-quite-so-lite? I like Rakudo Star. It doesn't try to be descriptive. It's just a name. Tim.
Re: Not a bug?
On Sun, Jan 11, 2009 at 04:41:12PM -0800, Ovid wrote:
I really don't think this is a bug, but it did confuse the heck out of me at
first. This *is* expected behavior due to how {} is interpolated in strings,
yes?
$ perl6 -e 'my $foo = foo;say ~ $foo ~ '
foo
$ perl6 -e 'my $foo = foo;say { ~ $foo ~ }'
~ foo ~
I presume string interpolation is, er, set-up, at compile-time.
So it only happened here because { ~ $foo ~ } was rewritten to
{$foo} at compile-time. And if { and } were replaced with
variables, for example, then the interpolation wouldn't have happened.
Right?
Tim.
Re: r24769 - docs/Perl6/Spec
On Mon, Jan 05, 2009 at 05:54:50PM +0100, pugs-comm...@feather.perl6.nl wrote: Author: moritz Date: 2009-01-05 17:54:50 +0100 (Mon, 05 Jan 2009) New Revision: 24769 +=item can + + our Bool multi method can ($self:, Str $method) + +If there is a multi method of name C$method that can be called on +C$self, then closure is return has C$self bound to the position +of the invocant. + +Otherwise an undefined value is returned. then closure is return has ? perhaps: then the closure that is returned has ? If it returns a closure then isn't Bool the signature wrong? Before someone 'fixes' that, though, couldn't can() just return a Bool, and move the 'give me a closure' to another method? Ignoring the performance cost of needlessly creating closures for simple boolean usage, 'can' doesn't seem like a good name for a 'give me a closure' method. +=item clone + + our multi method clone (::T $self -- T) + our multi method clone (::T $self, *%attributes -- T) + +The first variant retuns an independent copy of C$o that is equivlant +to C$o. typos variant returns and equivalant +The second variant does the same, but any named arguments override an +attribute during the cloning process. perhaps: any named arguments are applied to $self as attributes, overriding any attributes with the same names. Makes it clearer that the attributes aren't applied to nested elements. +=item isa + + our Bool multi method isa ($self:, $type) + +Returns true if a the invocant an instance of class C$type, or typos Returns CTrue if the invocant is an instance ... Tim.
Re: Files, Directories, Resources, Operating Systems
On Wed, Nov 26, 2008 at 12:40:41PM +0100, Mark Overmeer wrote: We should focus on OS abstraction. [...] the design of this needs to be free from historical mistakes. And avoid making too many new ones. There must be useful prior art around. Java, for example, has a FileSystem abstraction java.nio.file.FileSystem http://openjdk.java.net/projects/nio/javadoc/java/nio/file/FileSystem.html which has been extended, based on leasons learnt, in the NIO.2 project (JSR 203: More New I/O APIs for the JavaTM Platform (NIO.2) APIs for filesystem access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagrams.) which enables things like being able to transparently treat a zip file as a filesystem: http://blogs.sun.com/rajendrag/entry/zip_file_system_provider_implementation See http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf Tim. p.s. I didn't know any of that when I started to write this look for prior art email, but a little searching turned up these examples. I'm sure there are more in other realms, but NIO.2 certainly looks like a rich source of good ideas derived from a wide range of experience.
Re: globs and trees in Perl6
On Wed, Oct 01, 2008 at 11:24:04PM -0400, Brandon S. Allbery KF8NH wrote: On 2008 Oct 1, at 22:23, Timothy S. Nelson wrote: On Wed, 1 Oct 2008, Brandon S. Allbery KF8NH wrote: On 2008 Oct 1, at 22:14, Timothy S. Nelson wrote: Hi all. I've enjoyed(?) reading over the February/March thread entitled Musings on operator overloading. I've brought a few thoughts along; if they're old news, please tell me here to do more reading on it :). The Perl6 way to do this is grammars; using an XML grammar to pull data out of an XML document is one of Larry's favorite examples. Ok, great. While I see how this does a great job of converting the string of data into a plex, it doesn't solve the problem of selecting the data from the plex in a glob-like (or XPath-like) fashion, which is what I'm talking about here. Have I missed something that will do that? I could have sworn there was a short and elegant example of using a grammar to extract arbitrary information from an XML document, but I don't see it in the documentation. I recall Trey Harris showing such an example on IRC but not in a logged channel; maybe he'll see this message and jump in, or if not I'll see if I can get him to write another example. The key point Brandon is making, that I'm not sure you're answering, is that he wants to extract elements of a tree-like data structure (think DOM), not simply from a string representation of a structure (such as an XML document in a string). Thinking in terms of grammars, I'd ask the question: could grammars be used to match tree-like data structures? I think the current answer is no. Grammars are too tightly bound to the concept of a position in a linear string. But I have a nagging suspicion that this is a very powerful idea. Applying the expressive power of a grammar-like mechanism to search, backtrack, and match within a tree-like data structure. Is this new or has anyone discussed it before? Tim.
Re: globs and trees in Perl6
On Thu, Oct 02, 2008 at 07:01:39PM +1000, Timothy S. Nelson wrote: On Thu, 2 Oct 2008, Tim Bunce wrote: On Wed, Oct 01, 2008 at 11:24:04PM -0400, Brandon S. Allbery KF8NH wrote: On 2008 Oct 1, at 22:23, Timothy S. Nelson wrote: On Wed, 1 Oct 2008, Brandon S. Allbery KF8NH wrote: On 2008 Oct 1, at 22:14, Timothy S. Nelson wrote: Hi all. I've enjoyed(?) reading over the February/March thread entitled Musings on operator overloading. I've brought a few thoughts along; if they're old news, please tell me here to do more reading on it :). The Perl6 way to do this is grammars; using an XML grammar to pull data out of an XML document is one of Larry's favorite examples. Ok, great. While I see how this does a great job of converting the string of data into a plex, it doesn't solve the problem of selecting the data from the plex in a glob-like (or XPath-like) fashion, which is what I'm talking about here. Have I missed something that will do that? I could have sworn there was a short and elegant example of using a grammar to extract arbitrary information from an XML document, but I don't see it in the documentation. I recall Trey Harris showing such an example on IRC but not in a logged channel; maybe he'll see this message and jump in, or if not I'll see if I can get him to write another example. The key point Brandon is making, that I'm not sure you're answering, You probably mean OtherTim (ie. me) instead of Brandon here :). Yeap, sorry Tim. is that he wants to extract elements of a tree-like data structure (think DOM), not simply from a string representation of a structure (such as an XML document in a string). Thinking in terms of grammars, I'd ask the question: could grammars be used to match tree-like data structures? I think the current answer is no. Grammars are too tightly bound to the concept of a position in a linear string. I think Grammars would be great for turning a string into a tree. But I agree with you in that I don't see how they apply to what I'm talking about :). But I have a nagging suspicion that this is a very powerful idea. Applying the expressive power of a grammar-like mechanism to search, backtrack, and match within a tree-like data structure. Is this new or has anyone discussed it before? Not sure what you mean by backtrack in this context; I was envisioning that the thing return an array of tree nodes (although, now that I think about it, it could be useful as an iterator too :) ). But that doesn't seem to be quite what you're thinking, and so I'd be interested in hearing more about that too. I'm suggesting that the same kind of logic used to find those sequences of characters in a string that match a pattern (including backtracking http://perldoc.perl.org/perlre.html#Backtracking) could be applied to finding those sub-trees in a tree-like data structure which match a pattern. Like applying XPath to an XML DOM, only more general and taken further. By more general and taken further I'm thinking of the same kind of evoltion from simple regular expressions in perl5 to grammars in perl6. An XPath query is like a perl5 regular expression. The grammar concept in perl6 has taken the perl5 regular expression mini language and extended it up into the perl6 langauge as classes with method calls and features like hypothetical variables. But perl6 grammars are tied to the concept of searching through a sequence of characters. At any point the grammar is trying to match against the current character position with lookahead or lookbehind. I'm imagining a way of expressing a search through a tree-like data structure with the same kind of richness and features as grammars (methods, backtracking, hypothetical variables etc). Instead of matching against current character position you'd be matching the current node. Perhaps I'm just daydreaming, or perhaps I'm thinking of bringing an extended form of the Parrot Tree Grammar Engine to perl6: TGE is a tool for transforming trees. Think of it as a good old-fashioned substitution, but instead of taking and returning strings, it takes and returns trees. http://search.cpan.org/~pmic/parrot-0.7.1/compilers/tge/TGE.pir I've not looked at it closely enough to tell. Tim.
Re: Query regarding Java/perl interface
On Wed, Jun 20, 2007 at 12:53:32PM +0800, Agent Zhang wrote: On 6/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi I am sameer and am new to this group. It would realy help if any body can let me know is there a book or reference guiode where in i can get help regarding the perl/java interface and also about the tool named Java perl lingo. Java perl lingo, or JPL, was the name for some very early work done by Larry Wall to integrate Java and Perl5. As far as I know it was abandoned a few years ago. For the Java to Perl 5 interface, see Inline::Java on CPAN: http://search.cpan.org/dist/Inline-Java/ Inline::Java seems to be the main form of integration with perl5 these days. See http://search.cpan.org/~timb/JDBC/lib/JDBC.pm for an example. Tim. For a Java to Perl 6 API translator, see Java::Javap: http://search.cpan.org/perldoc?Java::Javap The author's journals may be helpful too: http://use.perl.org/~philcrow/journal Cheers, agentz
Re: Perl 6 Microgrants. Now accepting proposals.
On Wed, Mar 21, 2007 at 11:04:29PM -0400, Jesse Vincent wrote: I'm pleased to announce the inaugural Perl 6 Microgrants program. Best Practical Solutions (my company) has donated USD5,000 to The Perl Foundation to help support Perl 6 Development. Leon Brocard, representing The Perl Foundation's grants committee, will work with me to select proposals and evaluate project success. We'll be making USD500 grants to worthy Perl 6 related efforts. We're hoping to fund a range of Perl 6-related projects over the life of the grant program. Accepted grants might be for coding, documentation, testing or even writing articles about Perl 6. The program isn't tied to any one implementation of Perl 6 -- We're interested in seeing proposals related to Pugs, Perl 6 on Parrot, Perl 6 on Perl 5 or any other Perl 6 implementation. Generally, we're interested in seeing projects that can be completed in 4-6 calendar weeks. Submitting a grant proposal --- To submit a grant proposal, please email us at perl6- [EMAIL PROTECTED] with the following information: * A two to three paragraph summary of the work you intend to do * A quick bio - Who are you? Is there opensource work you've done that we should have a look at? * A brief description of what success will mean for your project - How will we know you're done? * Where (if anywhere) you've discussed your project in the past * Where you'll be blogging about your progress. (Twice-weekly blog posts are a requirement for getting your grant money) We'll be accepting proposals on a rolling schedule. We expect to pay out these first 10 grants over the course of the summer. Depending on how things go, we'll then either find more money for more grant programs or we'll wind up the program and move on to other endeavors. We're really excited to get rolling. Submit your proposals early and often. Don't let somebody else beat you to the punch ;) I'd like to suggest an idea for *someone else* to submit a proposal for: As part of the work on DBI2 I want to create a Perl API that closely matches the JDBC API. I need a tool that can parse the java .h files that that define the JDBC API, e.g., http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/Statement.h?revision=120621view=markup and generate roughly equivalent Perl 6 (roles etc). Some knowledge of Java would be helpful to get a reasonable initial mapping of concepts from Java to Perl, but that's bound to evolve over time - hence the need for a tool to do, and redo, the translation. [ I'd probably then use the tool to also generate implementation code that bridges the Perl6 JDBC with the Perl5 JDBC module on CPAN. That would give Perl6 a working JDBC API. (The next step might be to parse the Java code of the JDBC test suite and translate that to Perl6...) ] There are two parts to this: a Java parser (good enough for at least the JDBC .h files), and a Perl6 code (role) generator. They could be combined, but I'd like the Java parser to be reusable by others. Here's a related idea: write a tool that reads BNF grammar, such as http://java.sun.com/docs/books/jls/third_edition/html/syntax.html http://java.sun.com/docs/books/jls/third_edition/html/grammars.html and writes a parser in Perl 6 for that grammar. Anyone interested in those ideas? Tim. p.s. The .h files for JDBC can be found here http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/ http://gcc.gnu.org/viewcvs/trunk/libjava/javax/sql/ p.p.s. The funding for these could come from the DBI Development fund (which hasn't been used for anything yet) and so not impact the donation from Best Practical Solutions.
Re: Synposis 26 - Documentation [alpha draft]
On Thu, Oct 12, 2006 at 02:55:57PM +1000, Damian Conway wrote: Dave Whipp wrote: I'm not a great fan of this concept of reservation when there is no mechanism for its enforcement (and this is perl...). What makes you assume there will be no mechanism for enforcement? The standard Pod parser (of which I have a 95% complete Perl 5 implementation) will complain bitterly--as in cyanide--when unknown pure-upper or pure-lower block names are used. That's going to cause pain when people using older parsers try to read docs written for newer ones. Would a loud warning plus some best-efforts fail-safe parsing be possible? Tim. The whole point of reserving these namespaces is not to prevent users from misusing them, but to ensure that when we eventually get around to using a particular block name, and those same users start screaming about it, we can mournfully point to the passage in the original spec and silently shake our heads. ;-) Damian
Re: Synposis 26 - Documentation [alpha draft]
On Thu, Oct 12, 2006 at 03:57:01PM -0700, Jonathan Lang wrote: Tim Bunce wrote: Damian Conway wrote: Dave Whipp wrote: I'm not a great fan of this concept of reservation when there is no mechanism for its enforcement (and this is perl...). What makes you assume there will be no mechanism for enforcement? The standard Pod parser (of which I have a 95% complete Perl 5 implementation) will complain bitterly--as in cyanide--when unknown pure-upper or pure-lower block names are used. That's going to cause pain when people using older parsers try to read docs written for newer ones. If I understand you correctly, the pain to which you're referring would come from the possibility of a name that's reserved by the newer version of Pod, but not by the older version. Yes. Wouldn't the simplest solution be to let a Pod document announce its own version, much like Perl can? How would that actually help? The old parser still wouldn't know what new keywords have been added or how to parse them. Tim.
Perl 6 implmenentation of the Java JDBC API?
On Tue, May 16, 2006 at 11:59:48PM +0100, Tim Bunce wrote: That's partly why I added the following idea to The Perl Foundation's Summer of Code project list (http://www.perl.org/advocacy/summerofcode/ideas.html): Reimplement the DBI v1 API in Pugs Design an implementation of the DBI API in Perl 6 using Pugs. The goal is to maintain the familiar DBI API while radically refactoring the internals to make best use of Perl 6 and so enable greater functionality and extensibility. (Likely mentor: Tim Bunce) Trying to come up with both a new architecture and a new API was too much. A great deal can be achieved by radically refactoring the internals while keeping the same old API (i.e. don't move the goal posts). I'm sure a new API will naturally emerge from this work, but it won't be the primary goal. One of the issues facing a Perl 6 implementation of the DBI is how to implement drivers. Specifically the DBI-DBD API and the supporting framework to enable drivers to be written with little effort as possible. The current DBI-DBD API is essentially undocumented and only a few brave souls have ventured into it to produce drivers. We need to do better. The 'DBDI' project was started a couple of years ago to define a new DBI-DBD API with a focus on Parrot. The goal being a database API (and drivers) for Parrot that could be shared by all languages targeting Parrot. That project was ahead of it's time and floundered. I came to the conclusion a year or so ago that rather than try to create a new Driver API from scratch we should simply adopt an existing one. The most widely know object oriented database API that's a close fit to the DBI's needs and most database client APIs is the Java JDBC API. It's also suitable as a Parrot API, which is a key goal for DBDI. So I'm specifying that the DBI-DBD API will be based closely on JDBC. How close? Very close. Specifically, closely enough that we can refer users JDBC documentation and only document differences and (inevitable) extensions. Although a key goal is a Parrot API it makes most sense to work with Pugs at this stage. So, is anyone interested in working on mapping the JDBC API to Pugs and implementing an underlying framework for drivers to use? Tim.
DBI2 reborn with DBI1 facade
On Sat, May 13, 2006 at 04:34:19PM -0500, Jonathan Scott Duff wrote: Apparently it's my lot in life to think about dbdi once a year as it was almost exactly 1 year ago that I asked the following: 1. Is this list alive? 2. Is anyone working on the dbdi? So, consider this my annual ping on the subject. Only now I've got a third question: 3. What can your average programmer-type person do to help? I understand that parrot maturity was a a bit of a problem before, but maybe it's far enough along now that isn't a problem? It's certainly a lot further, and so is Pugs and thus Perl 6. On Sat, May 13, 2006 at 06:21:26PM -0700, Darren Duncan wrote: I don't know whether it was meant to replace dbdi-dev@perl.org or not, but there is a newer dbi2-dev@perl.org list now that you may want to check out. 'DBDI' relates to the interface to db drivers that's 'underneath' the DBI (and similar db abstraction layers). The idea is that Parrot needs something like DBDI so all the languages targeting Parrot can share db drivers. 'DBI2' relates to evolving the DBI API. Initially to redesign the API, but now with a new interim mission... That said, it has next to no traffic as well; waiting for something, I presume. Real Life (tm), in the form of a new baby, and $work have hampered by ability to devote time to these activities. That's partly why I added the following idea to The Perl Foundation's Summer of Code project list (http://www.perl.org/advocacy/summerofcode/ideas.html): Reimplement the DBI v1 API in Pugs Design an implementation of the DBI API in Perl 6 using Pugs. The goal is to maintain the familiar DBI API while radically refactoring the internals to make best use of Perl 6 and so enable greater functionality and extensibility. (Likely mentor: Tim Bunce) Trying to come up with both a new architecture and a new API was too much. A great deal can be achieved by radically refactoring the internals while keeping the same old API (i.e. don't move the goal posts). I'm sure a new API will naturally emerge from this work, but it won't be the primary goal. I'm delighted to say that Szilakszi Bálint has submitted a proposal and it looks like it'll be accepted (on May 23rd) and I'll be the mentor. Audrey is keen to help, which is a big plus. So, we're about to have a fire lit under us when Bálint gets going and needs design input! I think the dbi2-dev mailing list is the best place for most discussion related to this, though some Perl 6 issues may need input from perl6-language. Tim.
Class::Role, Class::Roles, and run-time role composition for Perl5
The Class::Role and Class::Roles modules on CPAN implement a form of compile-time Perl6 role composition for Perl5. Neither supports run-time role composition, as-in: http://dev.perl.org/perl6/doc/design/syn/S12.html#Roles The does operator returns the object so you can nest mixins: $fido does Sentry does Tricks does TailChasing does Scratch; Unlike the compile-time role composition, each of these layers on a new mixin with a new level of inheritance, creating a new anonymous class for dear old Fido, so that a .chase method from TailChasing hides a .chase method from Sentry. To help with DBI v2 I need a Perl5 implementation of roles that supports run-time role composition. I figure it just needs to generate a new class with @ISA set to ref($random_object), link-in the methods, then rebless $random_object into it. Plus a cache to avoid setting up a new class if it's already generated one for ref($random_object)+$role_name. I'd work on it myself but I'm busier than usual at the moment[1] and I don't know which of Class::Role or Class::Roles I should add it to. If no one volunteers I'll have a go in a week or three. Tim. [1] Our second child will be arriving 'any day'.
Re: Perl 6 Summary for 2005-08-15 through 2005-08-22
On Mon, Aug 22, 2005 at 09:43:41PM -0400, Matt Fowles wrote: Java on Parrot Tim Bunce asked some preliminary questions about Java on Parrot. I provide preliminary answers, and Nattfodd and Autrijus posted links to related work. The important question of what it should be called remained unraised. I vote for Jot. http://xrl.us/g8b9 For the record, my interest isn't so much Java ON Parrot as Java WITH Parrot. Bidirectional interface between the Parrot VM and a linked-in Java VM. Tim.
Re: DBI v2 - The Plan and How You Can Help
On Tue, Aug 16, 2005 at 03:58:54PM -0400, John Siracusa wrote:
On 8/16/05, Tim Bunce [EMAIL PROTECTED] wrote:
I was a little dissapointed that there wasn't greater focus on using
Perl6 features - especially as it would have helped kick-start my own
understanding of Perl6 topics that I expect to be significant (such as
Roles and Pairs, to pick two at random). Perhaps the community of
Perl6+DBI users is too small at this point.
I'm afraid that DBI2 for Perl 6 will fall into the trap that I sometimes
feel like DBI1 fell into: the curse of being designed before the idioms and
Best Practices of API design in the language have been established.
I think it'll take years, and much actual production experience building
Perl 6 modules before the community learns what works and what doesn't for a
Perl 6 API (let alone implementation). So trying to pin down a properly
Perl-6-ish API before Perl 6 is even through the language design process
strikes me as a Very Bad Idea.
I remember the early years of Perl 5 development, when a new feature was
added there'd be a period of over-zealous use followed by a hangover as
all the problems and edge-cases became apparent.
With Perl 6 there's going to be some almighty hangovers :)
That could explain why there were so few Perl 6 related suggestions: no one
knows how to design a good Perl 6 API yet, and any guess is very likely to
be wrong. Instead, suggestions have focused on what we do know: DBI in Perl
5 and Perl 5 API design. In that spirit, here's my suggestion: no more
configuration through magic/tied hashes. (e.g., $dbh-{'AutoCommit'} = 1)
(Probably goes without saying, but I wanted to make sure someone said it ;)
Hey, it seemed like a good idea at the time :)
(Actually it's still a good idea in many ways, especially in relation to
its behaviour for unknown driver-private attributes and DBI version skew.
But it does need rethinking for DBI2.)
Anyway, it maybe worthwhile to have a DBI 1.99 first, and then maybe a 1.999
after that. Basically, get one or two willing DBD authors who will help you
to test and then throw away the first two attempts at a Perl 6 DBI API.
Then at least you'll have some confidence when you commit to a DBI 2.0
API...which will be several years after Perl 6 is released, I hope.
It'll be DBI 2 as DBI 1 still has a very long life ahead of it, but
it'll be DBI 2.0.00xxx for quite a while :)
Of course, *someone* has to go first so we can all learn what works best
in Perl 6. I'm just saying that maybe DBI, which took the bullet in Perl 5
to some degree, is under no obligation to do so again. (This assumes that
we'll have some way to use Perl 5 DBI within Perl 6 to tide us over, of
course...)
I'm in no great rush as one of my core assumptions is that DBI v1 will
be available in Perl 6 via either Ponie or direct embedding of libperl5.so.
Tim.
Re: DBI v2 - The Plan and How You Can Help
On Tue, Aug 16, 2005 at 01:16:19PM -0700, Darren Duncan wrote: At 4:04 PM +0100 8/16/05, Tim Bunce wrote: I was a little dissapointed that there wasn't greater focus on using Perl6 features - especially as it would have helped kick-start my own understanding of Perl6 topics that I expect to be significant (such as Roles and Pairs, to pick two at random). Perhaps the community of Perl6+DBI users is too small at this point. One way that the Perl 6 thought process can be started is in considering the design principles laid out in Damian's new Best Practices book. I said to Damian at OSCON that I thought the practices he was putting forward were intended to get people thinking now in Perl 5 about ways of doing things that will be the natural way of doing them in Perl 6; he said something along the lines that I had good insight. So these practices are probably some good things to keep in mind as we move forward. Yeap. I'm awaiting delivery of that one, plus several others including MJDs Higher Order Perl. Now, speaking specifically in Perl 6 terms ... I suggest that DBI v2 has a more formal separation between interface and implementation. The parts of DBI can be grouped into these categories: 1. Role definitions for the public behaviour/API that DBI-using apps see. 2. Role definitions for the behaviour/API that DBI drivers/engines must have. 3. Class definitions that implement #1 and invoke #2. 4. Class definitions having a generic implementation of #2 or parts thereof, which a driver/engine can complete or override. 5. Basic utility classes that exist to the side of the above, which such as DBI drivers can optionally use to do some common things without rolling their own. 6. A basic test suite. I agree entirely - except for the word basic in item 6 :) One of the key things missing from DBI 1 was a test suite that could be reused to test/validate different drivers. Note that what you've described is essentially just what JDBC is. Only JDBC has a comprehensive driver test/validate suite. At the moment I'm thinking in terms of a Parrot-level DBDI modeled on JDBC, with a thin Perl6-specific DBI layered on top. Other languages targeting Parrot would have their own thin language adaption layers. I also recommend expelling some parts of the DBI distro into their own distros and/or leaving them to third parties. A prime example is the proxy server/client stuff; that should be a separate project. I'd like to see someone do a stateless proxy sometime (as I've outlined previously) and I'll be ensuring there's a serializable RowSet object available - but, yes, such things should be separate. Tim.
Re: DBI v2 - The Plan and How You Can Help
On Tue, Aug 16, 2005 at 12:12:02PM -0700, Dean Arnold wrote: Tim Bunce wrote: And nobody mentioned JDBC as a potential model. Odd that. I was sorely tempted to do so (and did mention it a few times in my posts, along w/ ODBC and ADO.NET), but there are some things about JDBC which rub me the wrong way (e.g., explicit set/get methods for every data type no true binding support; the lame bulk interface; etc.). I'm not crazy about all the DataSource business, either. I think all those are fixable for Perl/Parrot. Same for the painful need for try catch every few lines. But the threading support, the Factory pattern presented by Statement classes, the nice separation of metadata from statements/resultsets/connections, and XA would certainly be nice models to follow. That's what I'm thinking. Not only nice but also well proven and widely understood. One area of concern I have is the ability to subclass. I've been struggling w/ trying to subclass+extend JDBC the same way I subclass DBI for some things, and haven't found any app-neutral solutions just yet (trying to wrap another JDBC driver and expose its driver specific methods seems to require a lot of extra heavy lifting). There are lots of people who have problems or complaints about subclassing the DBI :) Tim.
Re: DBI v2 - The Plan and How You Can Help
On Sat, Jul 09, 2005 at 10:25:32PM +1000, Adam Kennedy wrote: In particular, the DBI must not mandate impossible levels of support from the drivers. It will benefit you nothing if the DBI is immaculate and wonderful and incredibly all-singing and all-dancing, but no-one can write a driver for it because the requirements cannot be met by the actual DBMS that Perl + DBI needs to work with. I concur. Like CPAN as a whole, DBI's strength is in it's complete and near universal coverage of all databases, and insanely great (and occasisionally greatly insane) drivers that do strange and wonderful things. If we start sacrificing drivers by raising the bar too high, DBI as a whole suffers. Anyone proposing new features for DBI needs to be extremely careful of CYJ syndrome. Can't You Just (or sometimes Could You Just) syndrome is described here. http://c2.com/cgi/wiki?CouldYouJust http://www.oreillynet.com/pub/wlg/3593 http://c2.com/cgi/wiki?JustIsaDangerousWord Go read them now. I'll wait... That's a significant part of what happened to perl5-porters in The Bad Years. Many more talkers than doers and much use of we could do ... when the doing would clearly have to be done by someone else. I have an increasing suspicion that having open design processes like the Tim's call for comments plays a big part in it as well. Did I ever say we'd have an open design process? :-) I just called for suggestions, proposals, and random thoughts. It's my job to mix those in with my own random thoughts and try to distill something reasonably coherent and Practical. Then we'll go round the loop a few (dozen) times kicking the tires and mixing metaphors till enough people are happy enough. (I get the casting vote on behalf of the silent majority :) I was a little dissapointed that there wasn't greater focus on using Perl6 features - especially as it would have helped kick-start my own understanding of Perl6 topics that I expect to be significant (such as Roles and Pairs, to pick two at random). Perhaps the community of Perl6+DBI users is too small at this point. And nobody mentioned JDBC as a potential model. Odd that. Still, I'm sure things will liven up once I've put an initial sketch together... Tim.
Translating (or at least parsing) Java interface definitions
Anyone done any work on parsing Java interface definitions? And, ideally, translating them into roughly equivalent Perl 6? Tim.
Re: DBI v2 - The Plan and How You Can Help
On Thu, Jul 07, 2005 at 08:32:47AM -0500, Jones Robert TTMS Contractor wrote: When I go to the donation page and attempt to make a donation, the drop-down box does not give DBI as a valid recipient. Is it possible several people may not have donated as they noticed the same results, or maybe they did and it all went into the Perl Development Fund instead? The Perl Foundation default donation page doesn't list the DBI Development Fund (for various reasons). To get that option you can use http://dbi.perl.org/donate/ which will redirect you[1] Thank you. Tim. [1] https://donate.perlfoundation.org/index.pl?node=Contribution%20Infoselfund=102 -Original Message- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Friday, July 01, 2005 7:06 PM To: perl6-language@perl.org; dbi-users@perl.org Subject: DBI v2 - The Plan and How You Can Help Once upon a time I said: http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d7b404a003?dmode=sourcehl=en and wrote http://search.cpan.org/~timb/DBI/Roadmap.pod which yielded: https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Det ailsselfund=102 (A little over $500 of that I effectively put in myself.) My *sincere* thanks to all those who donated to the fund, especially individuals. I had hoped for more corporate response with less from individuals and I'm touched by the personal generosity shown. I've not drawn any money from it yet and doubt that I will myself. (I'm considering suggesting that the Perl Foundation make payments from the fund to people making specific contributions to the DBI. I'm thinking especially of work on a comprehensive test harness. But I'll see how the developments below pan out before making specific arrangements.) So, that lead to: http://groups-beta.google.com/group/perl.dbi.dev/browse_frm/th read/ef14a9fc0a37441f/fb8fe20a86723da0#fb8fe20a86723da0 Which sums up fairly well where I'm at: DBI v1 will rumble on for Perl 5 and DBI v2 will be implemented for Perl 6. --- digression --- At this point I'd like to make a slight digression to highlight the amazing work going on in the Perl 6 community at the moment. Especially Autrijus' Pugs project which has brought Perl 6 to life. Literally. Take a look at: http://pugscode.org/talks/yapc/slide1.html http://use.perl.org/~autrijus/journal and especially: http://use.perl.org/~autrijus/journal/24898 Yes, that really is Perl 6 code using the DBI being executed by Pugs. That's great, and I was truly delighted to see it because it takes the pressure off the need to get a DBI working for Perl 6 - because it already is working for Perl 6. At least for Pugs. (The Ponie project is also likely to provide access to Perl 5 DBI from Perl 6 by enabling future versions of Perl 5 to run on Parrot.) --- digression --- I have recently come to an arrangement that will enable me to put some worthwhile development time into DBI (still very much part-time, but enough to give it focus and move forward). My initial goals are: 1. to work on a more detailed specification for the DBI v2 API that takes advantage of appropriate features of Perl 6. 2. to work on a more detailed specification for the DBDI API http://groups-beta.google.com/group/perl.perl6.internals/msg/c fcbd9ca7ee6ab4 3. to work on tools to automate building Parrot NCI interfaces to libraries (such as database client libraries, obviously :) But I'm hoping you'll join in and help out. I've kept an eye on Perl 6 and Parrot developments but I'm no expert in either. What I'd like *you* to do is make proposals (ideally fairly detailed proposals, but vague ideas are okay) for what a Perl 6 DBI API should look like. Keep in mind that the role of the DBI is to provide a consistent interface to databases at a fairly low level. To provide a *foundation* upon which higher level interfaces (such as Class::DBI, Tangram, Alzabo etc. in Perl 5) can be built. So, if you have an interest in the DBI and Perl 6, put your thinking cap on, kick back and dream a little dream of how the DBI could be. How to make best use of the new features in Perl 6 to make life easier. Then jot down the details and email them to me (or to dbi-users@perl.org if you want to kick them around in public for a while first). I'm about to fly off for two weeks vacation (in a few hours), blissfully absent of any hi-tech gear beyond a mobile phone. When I get back I'll gather up your emails and try to distill them into a coherent whole. Have fun! Tim.
DBI v2 - The Plan and How You Can Help
Once upon a time I said: http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d7b404a003?dmode=sourcehl=en and wrote http://search.cpan.org/~timb/DBI/Roadmap.pod which yielded: https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Detailsselfund=102 (A little over $500 of that I effectively put in myself.) My *sincere* thanks to all those who donated to the fund, especially individuals. I had hoped for more corporate response with less from individuals and I'm touched by the personal generosity shown. I've not drawn any money from it yet and doubt that I will myself. (I'm considering suggesting that the Perl Foundation make payments from the fund to people making specific contributions to the DBI. I'm thinking especially of work on a comprehensive test harness. But I'll see how the developments below pan out before making specific arrangements.) So, that lead to: http://groups-beta.google.com/group/perl.dbi.dev/browse_frm/thread/ef14a9fc0a37441f/fb8fe20a86723da0#fb8fe20a86723da0 Which sums up fairly well where I'm at: DBI v1 will rumble on for Perl 5 and DBI v2 will be implemented for Perl 6. --- digression --- At this point I'd like to make a slight digression to highlight the amazing work going on in the Perl 6 community at the moment. Especially Autrijus' Pugs project which has brought Perl 6 to life. Literally. Take a look at: http://pugscode.org/talks/yapc/slide1.html http://use.perl.org/~autrijus/journal and especially: http://use.perl.org/~autrijus/journal/24898 Yes, that really is Perl 6 code using the DBI being executed by Pugs. That's great, and I was truly delighted to see it because it takes the pressure off the need to get a DBI working for Perl 6 - because it already is working for Perl 6. At least for Pugs. (The Ponie project is also likely to provide access to Perl 5 DBI from Perl 6 by enabling future versions of Perl 5 to run on Parrot.) --- digression --- I have recently come to an arrangement that will enable me to put some worthwhile development time into DBI (still very much part-time, but enough to give it focus and move forward). My initial goals are: 1. to work on a more detailed specification for the DBI v2 API that takes advantage of appropriate features of Perl 6. 2. to work on a more detailed specification for the DBDI API http://groups-beta.google.com/group/perl.perl6.internals/msg/cfcbd9ca7ee6ab4 3. to work on tools to automate building Parrot NCI interfaces to libraries (such as database client libraries, obviously :) But I'm hoping you'll join in and help out. I've kept an eye on Perl 6 and Parrot developments but I'm no expert in either. What I'd like *you* to do is make proposals (ideally fairly detailed proposals, but vague ideas are okay) for what a Perl 6 DBI API should look like. Keep in mind that the role of the DBI is to provide a consistent interface to databases at a fairly low level. To provide a *foundation* upon which higher level interfaces (such as Class::DBI, Tangram, Alzabo etc. in Perl 5) can be built. So, if you have an interest in the DBI and Perl 6, put your thinking cap on, kick back and dream a little dream of how the DBI could be. How to make best use of the new features in Perl 6 to make life easier. Then jot down the details and email them to me (or to dbi-users@perl.org if you want to kick them around in public for a while first). I'm about to fly off for two weeks vacation (in a few hours), blissfully absent of any hi-tech gear beyond a mobile phone. When I get back I'll gather up your emails and try to distill them into a coherent whole. Have fun! Tim.
PLEAC - Programming Language Examples Alike Cookbook
So far http://pleac.sourceforge.net/ has comparative Perl Cookbook example for these languages: - perl, 100.00% done (naturally, since they're from the book) - python, 63.43% done - ruby, 62.43% done - guile, 30.00% done - merd, 28.86% done - ada, 26.00% done - tcl, 25.00% done - ocaml, 24.71% done - haskell, 20.86% done - pike, 23.29% done - java, 14.29% done - pliant, 9.43% done - commonlisp, 6.29% done - c++, 3.43% done - forth, 2.00% done - erlang, 1.86% done - php, 1.71% done - R, 1.43% done - masd, 0.57% done - nasm, 0.29% done You can see from this graph http://pleac.sourceforge.net/pleac_evolving.png that both python and ruby are steadily gathering examples, and that ocaml and pike have shown a recent spurt of activity. The maintainer, Guillaume Cottenceau [EMAIL PROTECTED], is very happy to accept perl6 versions of Perl Cookbook examples. As soon as the first arrives he'll rename perl to perl5 and start a new perl6 language category and start tracking contributions. More useful golf practice for Pugs fans! There must be some Perl Cookbook examples it can already execute... Tim.
Re: Synopsis 9 draft 1
On Thu, Sep 02, 2004 at 04:47:40PM -0700, Larry Wall wrote: =head1 Compact structs A class whose attributes are all low-level types can behave as a struct. all low-level types or all low-level *sized* types? (I'm wondering about char arrays, string and pointers.) I presume a char[n] array within a structure could be represented as an array of int8. That might be uncomfortable to work with. And that a pointer would be... what? Some platforms has odd sizing issues for pointers. Perhaps a voidp type is needed? (Which would just be an intN where N is sizeof(void*)*8.) If a class whose attributes are all low-level types can behave as a struct, is that class then also considered a low-level type? (So other structs can be composed from it.) I think that's important because it allows you to avoid having to build too much into the base perl6 language. Semantics like turning an array of int8 with a string with or without paying attention to an embedded null, can be provided by classes that implement specific behaviours for low level types but can still be considered low level types themselves. (Access from outside the class is still only through accessors, though.) Whether such a class is actually stored compactly is up to the implementation, but it ought to behave that way, at least to the extent that it's trivially easy (from the user's perspective) to read and write to the equivalent C structure. Is there some syntax to express if the struct is packed or needs alignment? (Perhaps that would be needed per element.) Certainly there's a need to be able match whatever packing and alignment the compiler would use. (I'm not (yet) familiar with Parrot's ManagedStruct and UnManagedStruct types but there's probably valuable experience there.) That is, when byte-stringified, it should look like the C struct, even if that's not how it's actually represented inside the class. (This is to be construed as a substitute for at least some of the current uses of Cpack/Cunpack.) Whether elements are packed or not for byte stringification is, perhaps, orthognal to whether they're packed internally. Network i/o would prefer packed elements and structure interfacing would need aligned elements. Tim.
Re: FW: Periodic Table of the Operators
On Mon, Jun 07, 2004 at 10:52:32PM +0100, David Cantrell wrote: My console can be any of several platforms - in the last couple of weeks it has been a Linux box, a Windows PC, a Mac, a Sun workstation, and a real vt320 attached to a Sun. My mail sits on a hosted Linux box. To read it, I sometimes ssh in to the machine and read it using mutt in screen. At other times I read it using Mozilla Thunderbird over IMAP. In Thunderbird, the odd characters show up. But when I'm using a terminal session, I have found that the only practical way of getting consistent behaviour wherever I am is to use TERM=vt100. Windows is, of course, the main culprit in forcing me to vt100 emulation. I can recommend PuTTY for windows. Secure, small[1], fast, featureful and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/ I'm using it now to ssh from a windows laptop to read email using mutt in screen. Tim. [1] So small it easily fits on a floppy. I keep a copy on my USB memory drive.
Re: A12: Strings
On Tue, Apr 20, 2004 at 10:51:04PM -0700, Larry Wall wrote: Yes, that's in the works. The plan is to have four Unicode support levels. These would be declared by lexically scoped declarations: use bytes 'ISO-8859-1'; use codepoints; use graphemes; use letters 'Turkish'; Note these just warp the defaults. Underneath is still a strongly typed string system. So you can say use bytes and know that the strings that *you* create are byte strings. However, if you get in a string from another module, you can't necessarily process it as bytes. If you haven't specified how such a string is to be processed in your worldview, you're probably going to get an exception. You might anyway, if what you specified is an impossible downconversion. So yes, you can have use bytes, but it puts more responsibility on you rather than less. You might rather just specify the type of your particular string or array, and stay with codepoints or graphemes in the general case. To the extent that we can preserve the abstraction that a string is just a sequence of integers, the values of which have some known relationship to Unicode, it should all just work. : Is that right, or would there be a key_type property on hashes? More to : the point, is it worth it, or will I be further slowing down hash access : because it's special-cased in the default situation? Hashes should handle various types of built-in key strings properly by default. What is properly for string? Is it to hash the sequence of integers as if they're 32 bits wide even if they're less? Is that sufficient? Tim.
Re: printf-like formatting in interpolated strings
On Mon, Jun 16, 2003 at 05:48:58PM +0100, Simon Cozens wrote: But then I'm one of those freaks who likes the idea of keeping core Perl 6 generic, extensible, clean and small, and letting all the clever stuff go into extensions, a heretical position which is way out of favour with the more influential listfolk, so feel free to ignore my opinion. FWIW I agree with you completely, and strongly. If it can be outside the core it should be, unless there's a very good reason why not. But I guess I'm far from being an influential listfolk these days... I console myself with a high level of trust in the core design team. Tim [wandering off into the sunset to ruminate on DBI issues...]
Re: printf-like formatting in interpolated strings
Perhaps someone could post a summary of how the issue has been tackled in other languages that support a similar concept. I've not seen one (but then I've not been paying attention, so forgive me if it's need done already, and perhaps point me to a url). Tim.
Re: Type Conversion Matrix, Pragmas (TAKE 4)
On Tue, Jun 10, 2003 at 12:04:14PM -0700, Michael Lazzaro wrote:
*: (undefness and properties lost)
Using/converting an uppercase type as/to a lowercase (primitive)
type is silently allowed. If you're sending an Int to something that
requires an Cint, you know that the 'something' can't deal with the
undef case anyway -- it doesn't differentiate between undef and zero.
Thus, you meant to do that: it's an intentionally destructive
narrowing, and the Cundef becomes a C0.
my Int $a = undef;
my int $b = $a; # $b is now C0, NOT Cundef
I'm not sure what silently allowed means here (compile time perhaps?)
but I'd certainly want that to generate the traditional Use of undefined
value warning (controlable via the perl6 equiv of the warnings pragma,
but defaulting to enabled).
F: (float to int)
Historically, accidentally using a float as an int can be a
significant source of errors. Proposed pragma variants:
use strict conversions allow = num_to_int ; # which is the default?
use strict conversions warn = num_to_int ;
use strict conversions fail = num_to_int ;
I don't see a problem with compile time warnings by default *if*
there's an easy way for the developers to express the fact that
they know what they're doing (easier, that is, than wrapping the
assignment in a { use strict conversions allow ... } block).
Something like a cast function would fit: $int = int($num);
N: (numeric range)
This one is a giant pain. Converting, say, an Int to an int will,
in fact, fail to do the right thing if you're in BigInt territory, such
that the number would have to be truncated to fit in a standard int.
But 99% of the time, you won't be working with numbers like that, so it
would seem a horrible thing to disallow Int -- int and Num -- num
conversions under the remote chance you *might* be hitting the range
boundary. Then again, it would seem a horrible thing to hit the range
boundary and not be informed of that fact. Thus, deciding the default
state here will be a challenge:
use strict conversions allow = Int_to_int ; # which is the default?
use strict conversions warn = Int_to_int ;
use strict conversions fail = Int_to_int ;
use strict conversions allow = Num_to_num ; # which is the default?
use strict conversions warn = Num_to_num ;
use strict conversions fail = Num_to_num ;
Same as above. I could live with a compile time warning if it's
trivial to silence it for a particular assignment.
But I'd also like separate control over the detection and behaviour
of underflow / overflow / loss of precision etc at runtime.
So if I assign an int a value that's too big (from a Int, or Num,
or untyped scalar), I would like to know about it. Similarly for num.
(v) Alternative Pragma Form
An alternative pragma form could possibly allow finer control over
every individual possible conversion. The disadvantage of this form is
that it would be very difficult to correctly set each of the 100
cells of the matrix, or even the 14 critical cells that most often
change:
Perhaps it would be better to think in terms of styles of coding
or policies, and aim to meet those needs with simple pragmas
(implemented on top of a more general mechanism).
Basically, do both. The simple forms could just be an interface to
the more general.
(vi) Conversions of User Defined Types/Classes
It may be useful to allow the same level of pragma-based control for
user-defined types and classes. For example, a given class Foo may
wish to be silently convertable to an Cint. One proposed syntax to
declare the method of coercion/conversion might be:
class Foo {
...
to int {...} # or Cas int {...}?
}
However, users of such a class could adjust the warning level of the
given conversion using the alternate syntax given above (v):
use strict conversions warn { Foo = int };
For
my int $int = $foo;
isn't the int() method (vtable entry) called on $foo? (effectively)
So the $foo object is asked to provide an int for assigment to $int.
So the Foo class gets to decide how to do that.
In which case what you're proposing requires either
- the compiler to write the code to pass extra flags to the int method
- the compiler to write call a different int method (eg, int_warn())
- for the int method to look at the calling context to get flags
Please correct me if I'm wrong (which I could easily be as I've not
been following any of thise closely).
I think this is an important topic because it may reflect back on
how the specific Int/Num/Str classes should also be handled.
Tim [quite possibly talking nonsense]
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote: Sean O'Rourke [EMAIL PROTECTED] wrote: languages/perl6/README sort of hides it, but it does say that If you have Perl = 5.005_03, $a += 3 may fail to parse. I guess we can upgrade that to if you have 5.6, you lose. I notice that DBI no longer supports Perl releases 5.6. Not true. The DBI supports 5.5.3. The most recent release announcement did say: NOTE: Future versions of the DBI may not support for perl 5.5 much longer. : If you are still using perl 5.005_03 you should be making plans to : upgrade to at least perl 5.6.1, or 5.8.0. Perl 5.8.0 is due to be : released in the next week or so. (Although it's a point 0 release, : it is the most throughly tested release ever.) But that's just a shot across the bows alerting people to think about upgrading. I'm unlikely to actually require 5.6.1 for quite some time yet. Tim.
Re: What's MY.line?
On Thu, Jul 11, 2002 at 02:29:08PM -0400, Dan Sugalski wrote: At 7:18 PM +0100 7/11/02, Dave Mitchell wrote: On Thu, Jul 11, 2002 at 10:41:20AM -0400, Dan Sugalski wrote: The place where you'll run into problems in where you have multiple variables of the same name at the same level, which you can do in perl 5. can it? Yes. can you give an example? [localhost:~] dan% perl my $foo = 12; print $foo; my $foo = ho; print $foo; 12ho[localhost:~] dan% Of course it's a -w warning now: my variable $foo masks earlier declaration in same scope at - line 3. and I can imagine it becoming a mandatory warning in later versions of perl5 (and/or perhaps in future they'll be a way to enable warnings relevant to migration to perl6). Tim.
Re: Perl 6, The Good Parts Version
On Wed, Jul 03, 2002 at 01:23:24PM -0400, Michael G Schwern wrote: I'm also trying to think of more bits to throw in. Particularly in terms of the OO system, this being a conference about OO. From what I've heard so far, Perl 6's OO system will be largely playing catch up with other languages. Don't forget Apocalypse 5. Personally I believe the elegant and thorough integration of regular expressions and backtracking into the large-scale logic of an application is one of the most radical things about Perl 6. Tim.
Re: Perl 6, The Good Parts Version
On Wed, Jul 03, 2002 at 05:13:01PM -0400, Michael G Schwern wrote: On Wed, Jul 03, 2002 at 09:20:01PM +0100, Dave Mitchell wrote: On Wed, Jul 03, 2002 at 01:23:24PM -0400, Michael G Schwern wrote: Hopefully the Cabal [2] can debunk that. [snip] [2] Of which there is none. and http://www.perlcabal.com/ doesn't exist, right? ;-) Not Found The requested URL / was not found on this server. TINPC/1.3.14 Server at www.perlcabal.com Port 80 *snort* :) Odd how that text isn't what it seems... Tim.
Re: 6PAN (was: Half measures all round)
On Thu, Jun 13, 2002 at 12:00:13AM +0300, [EMAIL PROTECTED] wrote: |On 6/4/02 12:22 PM, David Wheeler wrote: | I think that if we can agree to forego backwards compatibility, we might | also be in a better position to set up a CP6AN with much better quality | control. All of the most important modules will be ported very quickly | (e.g., the DBI), Actually I doubt that complex extensions with lots of XS/C code will get ported very quickly since the work involved may be considerable. That's one of the reasons I've put so much effort into making DBI::PurePerl a viable tool. It'll automatically give people a working Perl6 DBI (for pure-perl drivers) as soon as there's a working perl5-to-perl6 translator. Tim.
Re: Loop controls
On Fri, Apr 26, 2002 at 10:29:58AM -0400, Aaron Sherman wrote:
On Thu, 2002-04-25 at 18:20, Damian Conway wrote:
Miko O'Sullivan wrote:
before { ... } # run before first iteration,
# only if there is at least one iteration
Larry is still considering allowing a CFIRST block that would do this.
[...]
This will be called a CNEXT block. It goes inside the loop block.
[...]
This will be called a CLAST block. It goes inside the loop block.
[...]
Celse blocks to accomplish this.
This bothers me. Traditionally, all-caps keywords in Perl have indicated
compile-time constructs that may relate only loosely to the code around
them (e.g. BEGIN, END).
Actually all-caps keywords in Perl have indicated code blocks that perl
will call implicitly:
TIEHASH
TIEARRAY
STORE
FETCH
etc
Which seems to fit well enough with the perl6 usage.
Tim.
Re: Please rename 'but' to 'has'.
On Fri, Apr 26, 2002 at 11:33:06AM -0400, Dan Sugalski wrote: At 2:26 PM +0100 4/26/02, Nicholas Clark wrote: On Tue, Apr 23, 2002 at 01:25:15PM -0400, Dan Sugalski wrote: At 12:36 PM -0400 4/23/02, Buddha Buck wrote: OK, but that limits you to the, um, 24 standard levels of precedence. What do you do if you don't think that that's enough Internally precedence is going to be stored as a floating-point number. Dunno how it'll be exposed at the language level, but at least there'll be more than just 20 or so levels. Why store precedence as floating point rather than integer? [Or did I miss a design document} Because, while you may run into problems fitting something in between 1.001 and 1.002, it's not a problem to fit something between 3 and 4. Floating point precedence is a problem at the edge, but integer precedence makes things potentially difficult for user-added operators if you want to fit things between the standard operators. Is it worth it? For perl at least I thought Larry has said that you'll be able to create new ops but only give them the same precedence as any one of the existing ops. Why not use a 16 bit int and specify that languages should use default precedence levels spread through the range but keeping the bottom 8 bits all zero. That gives 255 levels between '3' and '4'. Seems like enough to me! Floating point seems like over-egging the omelette. Tim. p.s. I missed the start of this thread so I'm not sure why this is a parrot issue rather than a language one. I also probably don't know what I'm talking about :)
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
Early on in the life of Perl 5 Larry adopted the convention that subroutines that Perl calls automatically for you should have all-caps names[*]. I'm not uncomfortable with the apparent try/CATCH inconsistency. I suspect that having CATCH etc. be lowercase would create a greater inconsistency in the 'big picture'. (Plus you'd get into problems with NEXT vs next etc.) Tim. [*] Historical note: This actually came about partly because the DBI ties a hash ref into the same class that the hash is blessed into. Perl's tie FETCH method used to be called fetch, but that clashed with the DBI's own fetch method. On Tue, Jan 22, 2002 at 05:40:47PM +, Andy Wardley wrote: I was reading Apocalypse 4 and was perturbed by the strange and inconsistent looking use of UPPER and lower case in various keywords. Now before anyone rushes to assist me in understanding the logic, I should say that we've already thrashed this out on the London.pm mailing list and several people (Hi Piers :-) have re-iterated the reasoning being the use of upper vs lower case. In a nutshell, UPPER CASE is reserved for special Perl blocks that should stand out to the user due to the fact that they represent exception flow control. It's a good, logical and consistent argument for sure, but sorry, I don't buy it. We end up with peculiarities like 'try/CATCH'. Even if 'try' is a keyword and 'CATCH' is a special block, I can't see any valid reason for having them different case. Same with 'last/NEXT' - they're so similar in concept that the implementation details should not matter. By this argument, I could claim that the correct capitalisation of knife and FORK is based on the rule cutting things are in lower case, spiking things are in UPPER CASE. It's consistent and logical, but common sense should tell you that it's plain wrong. INIT, DESTROY, AUTOLOAD, etc., all make sense to me. They really are special blocks that normally only occur once in a file. But CATCH and NEXT are part of normal syntax. I don't think they're any more unusual in their flow control than try, while, loop or foreach. I think this needs a rethink. What do other people think? A
Re: Flexible parsing (was Tying Overloading)
On Sat, Apr 28, 2001 at 03:44:25PM -0700, Larry Wall wrote: Dan Sugalski writes: : I hadn't really considered having a separate module for each type of site : policy decision. Er, neither had I. Each site only has one policy file. I just want it named after the actual site, not some generic name like Policy. I think policy files are inherently non-portable, so they should be named that way. FYI, the module list has said this for several years: : If developing modules for private internal or project specific use, : that will never be released to the public, then you should ensure that : their names will not clash with any future public module. You can do : this either by using the reserved Local::* category or by using an : underscore in the top level name like Foo_Corp::*. Tim.
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote: I don't get it. The first and foremost duty of Perl 6 is to parse and execute Perl 6. If it doesn't, it's not Perl 6. I will call this the Prime Directive. Great, but don't loose sight of the fact that a key feature of "Perl 6", as far as Larry's sketched it out, is the ability to dynamically alter the parser in both dramatic and subtle ways. Following your lead, I will call this the Prime Language Feature :) People seem to think that telling Perl 5 apart from Perl 6 is trivial. My reading of Larry's comments is that it will be _made_ trivial at the file scope level. If the file doesn't start with Perl 6 thingy then it's Perl 5. Period. Truly detecting Perl5ness is hard: you will have to in essence replicate the Perl 5 parsing, and we all know the amount of hair in that code. We really want to include such a hairball in our new beautiful code? My reading of Larry's comments is that it won't be "in" our ``new beautiful code''? [Umm, pride before a fall?] That beautiful code will be beautifully _open_ to _external_ extensions. And that is how I imagine that Perl 5 support should be implemented. The parser is, ooops, the parsers are (plural) going to be in perl, remember. Thinking about the 5-6 migration and coexistence is good and useful, but since that doesn't advance the Prime Directive, I disagree. thinking about it *too* much now or fighting over the niggly details is somewhat wasted effort. Now this I agree with. It's quite staggering how much hot air has been generated from Larry's first significant outline. Much of it missing, or casually disregarding, key points of deep or subtle meaning. I'm reminded of the long threads about bignum support that seemed to be lost in the details of _a_ bignum implementation rather than focusing on the design of a generic type extension mechanism that would then enable multiple bignum implementations to coexist. Tim.
Re: Larry's Apocalypse 1
On Mon, Apr 09, 2001 at 12:58:23PM -0400, Andy Dougherty wrote: Let's leave -e alone for now and worry about handling specific incompatibilities when we in fact have some specific incompatibilities to worry about. Amen. Tim.
Re: Really auto autoloaded modules
On Mon, Feb 05, 2001 at 11:35:59AM -0500, Dan Sugalski wrote:
At 02:17 PM 2/5/2001 -0200, Branden wrote:
I think that, if you want this behavior, a module that implements it
would be just fine. (Why muck with "use"?) To use a module name
that seems like it could fit this purpose:
use autoload { Bar = 'http://www.cpan.org/modules/Bar' },
{ Baz = 'ftp://my.local.domain/perl-modules/Baz', VERSION =
2 };
Very good idea indeed!!! Append the wishlist to add this module to perl6's
standard library!!!
Very *bad* idea. It sounds nice, but using a remote module without any sort
of control is just begging for trouble.
True. But perl6 shouldn't stand in the way of making silly things possible.
Tim.
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 11:47:43AM -0500, John Porter wrote: And isn't this rather off-topic for this list? Sounds more like an internals thing... No. I think this is an area where the language should lead. I also think we need to define what an 'interface definition' should look like and/or define before we go much further. Tim.
Re: Really auto autoloaded modules
On Thu, Feb 01, 2001 at 10:14:20AM -0500, Dan Sugalski wrote: Since everyone's spinning aimlessly around, I'll throw out something for everyone to think about, and perhaps we can get a PDD out of it. One of the features of perl 6 is going to be the ability to automatically use a module if one or more preregistered functions are used in your source. So, for example, if we pull out the socket routines into a separate module but your code uses one of the socket routines, we automagically use the socket module. The fact that it's separate is completely invisible to your program. The module loaded can define the routines as either regular perl subs or opcode functions (the difference is in calling convention mainly) and could be the standard mix of perl or compiled code. Would someone care to take a shot at formalizing the system? We need a way to register these functions, track the module version (if any) they're in, and stuff like that. (Including, I'm sure, things I've forgotten) Don't forget that it should tie in with the concept of defining 'interfaces' so use Foo qw(bar); may actually just load an interface definition and that definition can be (lazily) bound to one of several alternative implementations of the Foo interface (one SX and one pure-perl, for example). Basically I'm saying that transparent autoloading should be an attribute of the interface definition. Tim.
Re: Undermining the Perl Language
On Sun, Oct 01, 2000 at 11:49:51AM -0700, Randal L. Schwartz wrote: David I was primarily addressing the issue of the P5P allowing the David language to be controlled by corporate presence through a David purchased pumking, and not taking responsibility for the David language sufficient to protect it against corruption (technical David and political), and choosing rather to follow the man rather David than look where they're going. I've no idea why Sarathy was David deposed, but I have a pretty big suspicion. [...] Please take your paranoia elsewhere. I think if you actually sat down and had lunch with each of the parties involved, and those further out but well-informed, you'd find a consistent view of reality that doesn't match ANY of your delusions. To be a contribution to the community, you must have some higher degree of trust than you are demonstrating. If you can't manage that on your own, seek assistance elsewhere. FWIW, I agree entirely with Randal here. Tim.
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
On Tue, Aug 15, 2000 at 09:25:34AM -0700, Larry Wall wrote: [EMAIL PROTECTED] writes: : Yep. Or more generally "Standardize Perl on all platforms to one : common time epoch" and reccommend the Unix epoch since it's so : widespread. :-) Oh, gee, where's your sense of history? (As in creating our own. :-) Maybe we should invent our own epoch, like the year 2000. Or use a really standard one, like the year 0 AD (aka 1 BC). I have this horror that people will still be using 1970 as the epoch in the year 31,536. I tend to thing this whole epoc thing is overblown. Few people would know what this time was just by looking at it: 966421517 So what does it matter if that time was represented by another string of digits? What difference does it _really_ make what epoc is used, so long as it's fully integrated into the language and interfaces along with appropriate conversions to other epocs? I tend to think that perl time should not break when presented with Larry's date of birth :-) We also need to avoid the unixtime 2038 bug, one way or another.. Tim. p.s. For reference, Oracle DATE type can handle all dates from January 1, 4712 BC to December 31, 4712 AD. Oracle also supports a very wide range of date formats and can use one of several calendars (Arabic Hijrah, English Hijrah, Gregorian, Japanese Imperial, Persian, ROC Official (Republic of China) and Thai Buddha).
Re: what will be in Perl6 ?
On Thu, Aug 03, 2000 at 08:21:38AM -0400, Joshua N Pritikin wrote: On Wed, Aug 02, 2000 at 11:40:09PM +0100, [EMAIL PROTECTED] wrote: On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: http://windows.oreilly.com/news/hejlsberg_0800.html Impressive. Quite deeply impressive. Careful! Don't be overwhelmed by the marketing spin. I wasn't. Don't underestimate the perl community. I don't. Tim.
Re: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
On Wed, Aug 02, 2000 at 11:25:52AM +0100, Tim Bunce wrote: On Wed, Aug 02, 2000 at 12:16:33AM -0400, Dan Sugalski wrote: I'd actually like to see some work on the shared memory and IPC stuff on the language list--it'd be nice to have them in as mostly-primitives, though in a more platform-neutral way. "mostly-primitives" sounds like a fudge. Like the hacks used to get 'lock' into the perl5. perl6 shouldn't need 'mostly-primitives'. From a language perspective, I have a scheme to allow us to yank all the cruft (sockets, shm, messages, localtime...) out into separate libraries, yet pull them in on demand without needing a use. Why worry about a use? Larry is thinking long and hard about 'interface definition' issues. Specificaly in relation to enabling multiple versions of a module to co-exist and, importantly, enabling multiple alternate implementations of the same interface. Let's wait and see where that goes first. Thinking about that some more, I can imagine that... a) The 'use' of an 'interface definition' could optionally just define stubs that will trigger the 'use' of a module to implement it when first called. b) An 'interface definition' could cover multiple modules (or, more strictly, multiple interface definitions for those modules). Thus a single 'use' of an 'interface definition' thingy could save many lines of individual 'use' statements. Tim.
Re: type-checking [Was: What is Perl?]
On Tue, Aug 01, 2000 at 09:25:33PM +, Nick Ing-Simmons wrote:
Alan Burlison [EMAIL PROTECTED] writes:
No, I disagree. Perl gains a lot of its expressive power from being lax
about typing. I suspect it will also impose an unacceptable overhed for
the vast majority who don't want it - at the very least every variable
access will have to check an 'are you typed' flag.
Cross posted to internals ('cos it is...)
We should consider using "vtables" to avoid the cost of the conditional
branches (and running out of flag bits).
Thus this function would call variables "type check" "method" -
which for normal case would be pointer to blue-white-hot "NoOp" function
which is near always in-cache, for a typed var it could be a slow
as you wanted...
I agree with all this.
Tim.
Re: type-checking [Was: What is Perl?]
On Tue, Aug 01, 2000 at 10:47:24PM +0100, Alan Burlison wrote: I suspect reorganising the data structures to be cache friendly would gain more benefit than avoiding a few inline bit twiddles. We should do both. Tim.
Re: what will be in Perl6 ?
On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: raptor writes: : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html That's a good summary of what we've been thinking. Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who aspires to be a Perl designer. http://windows.oreilly.com/news/hejlsberg_0800.html Impressive. Quite deeply impressive. Tim.
Re: Summary...tell me where I'm worng...
On Tue, Aug 01, 2000 at 07:03:42AM -0400, Grant M. wrote: Just trying to catch up. This is where I understand the discussion stands: INTERNALS(?) modular language: Scanner/Symbol Table/Parser/Executor Internals. Standard Functions separate from core (moving to language?) Some of each. Modules Separate from everything (definitely language) Yes. Strict(er) DataTypes: Automatic Type Conversion(?) (internal or language?) Native Size Allocation (Internal or language?) Language for now. Items still under general discussion: Formats (probably language if it stays) Garbage Collection (internals?) RegEx (internals?) Yes, Yes, Yes. localtime() (arrays start at 0 or 1) (language) Yes. Backward compatibility in general (who knows) Script Backward compatibility = language. XS Backward compatibility = here (later) if someone volunteers to write the code to make old XS code work with the new APIs. If someone could just tell me where these discussions go (as many aren't really defined yet) I would be grateful. Also, I'd say "if in doubt then it's not for perl6-internals, at least not for now". I'd also say there's not much point at the moment in discussing details of implementing features that we're not pretty sure will be in the language. I think there's _lot's_ of valuable work we can do here we can do here prior to the language being firmed up. If we start getting into details of other things we won't make progress on the basics, like vtable interfaces for SV and libraries, analysis of GC implementations etc. We need to be pretty sure of most of those kind of issues by the time the language gets firmed up. Tim.
Re: Summary...tell me where I'm worng...
On Tue, Aug 01, 2000 at 05:23:27PM +0200, Dominic Dunlop wrote: At 15:19 +0100 2000-08-01, Tim Bunce wrote: RegEx (internals?) Yes, Yes, Yes. I could argue for regex being language too: If the language group is going to give each of perl's reserved words (and much else besides) the third degree so as to decide whether it should stay in the core, be cast into outer darkness, or end up somewhere in between, then I'd say that the same should be done for the language supported by the regex engine. Yes. Yes. Yes. Tim.
