Re: Lessons to learn from ithreads (was: threads?)

[Tim Bunce]

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?

[Tim Bunce]

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.)
> 
>  
> 
> 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 optimize {
> ...
> }
> 
> (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?)

[Tim Bunce]

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  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.

Re: Lessons to learn from ithreads (was: threads?)

[Tim Bunce]

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?)

[Tim Bunce]

On Wed, Oct 13, 2010 at 04:00:02AM +0200, Leon Timmermans wrote:
> On Wed, Oct 13, 2010 at 12:46 AM, Tim Bunce  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.)

Lessons to learn from ithreads (was: threads?)

[Tim Bunce]

On Tue, Oct 12, 2010 at 03:42:00PM +0200, Leon Timmermans wrote:
> On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg  
> 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.

Ruby Fibers (was: threads?)

[Tim Bunce]

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.

Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]

[Tim Bunce]

This thread reminded me of something I'd posted a while ago:

---snip---
Date: Wed, 26 Nov 2008 14:23:11 +
From: Tim Bunce 
To: Richard Hainsworth , 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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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.

Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk

[Tim Bunce]

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: .

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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.

Looking for help updating Perl 6 and Parrot part of Perl Myths talk

[Tim Bunce]

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: Rukudo-Star => Rakudo-lite?

[Tim Bunce]

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?

[Tim Bunce]

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 ~ ">"'
>   
>   $ 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

[Tim Bunce]

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 C if the invocant is an instance ..."

Tim.

Re: Files, Directories, Resources, Operating Systems

[Tim Bunce]

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

[Tim Bunce]

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: globs and trees in Perl6

[Tim Bunce]

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: Query regarding Java/perl interface

[Tim Bunce]

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.

[Tim Bunce]

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=120621&view=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]

[Tim Bunce]

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.

Re: Synposis 26 - Documentation [alpha draft]

[Tim Bunce]

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

Perl 6 implmenentation of the Java JDBC API?

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

On Sat, Jul 02, 2005 at 01:06:02AM +0100, Tim Bunce wrote:
> Once upon a time I said:

I'm back now and, after digesting a small mountain of non-DBI related
emails, I'll start digesting all your replies and getting up to speed
with Perl 6.

Many thanks to all who replied on and off-list.

Tim.

Re: DBI v2 - The Plan and How You Can Help

[Tim Bunce]

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%20Info&selfund=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=source&hl=en
> > 
> > and wrote
> > 
> >   http://search.cpan.org/~timb/DBI/Roadmap.pod
> > 
> > which yielded:
> > 
> >   
> > https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Det
> > ails&selfund=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 
> > *fo

DBI v2 - The Plan and How You Can Help

[Tim Bunce]

Once upon a time I said:

  
http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d7b404a003?dmode=source&hl=en

and wrote

  http://search.cpan.org/~timb/DBI/Roadmap.pod

which yielded:

  https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Details&selfund=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

[Tim Bunce]

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

[Tim Bunce]

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 C/C.)

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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: printf-like formatting in interpolated strings

[Tim Bunce]

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: Type Conversion Matrix, Pragmas (TAKE 4)

[Tim Bunce]

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 C, 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 C becomes a C<0>.
> 
>   my Int $a = undef;
>   my int $b = $a; # $b is now C<0>, NOT C

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 .   
> 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 C.  One proposed syntax to  
> declare the method of coercion/conversion might be:
> 
> class Foo {
> ...
> 
> to int {...}  # or C?
> }
> 
> 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

[Tim Bunce]

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?

[Tim Bunce]

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

[Tim Bunce]

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: Perl 6, The Good Parts Version

[Tim Bunce]

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: 6PAN (was: Half measures all round)

[Tim Bunce]

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: Please rename 'but' to 'has'.

[Tim Bunce]

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: Loop controls

[Tim Bunce]

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 C block that would do this.
> [...]
> > This will be called a C block. It goes inside the loop block.
> [...]
> > This will be called a C block. It goes inside the loop block.
> [...]
> > C 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: Apocalypse 4 : The Strange Case of the STRANGE CASE

[Tim Bunce]

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)

[Tim Bunce]

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)

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

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

[Tim Bunce]

On Thu, Feb 01, 2001 at 04:02:31PM +, Tim Bunce wrote:
> of the Foo interface (one SX and one pure-perl, for example).

s/SX/XS/ of course.

Tim.

Re: Really auto autoloaded modules

[Tim Bunce]

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

[Tim Bunce]

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: Language WG report, August 16th 2000

[Tim Bunce]

On Wed, Aug 16, 2000 at 05:23:04PM +1000, [EMAIL PROTECTED] wrote:
> OK, weekly report.  Ugh.

Shouldn't these to go -announce as well?

Tim.

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Tim Bunce]

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 ?

[Tim Bunce]

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: what will be in Perl6 ?

[Tim Bunce]

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: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))

[Tim Bunce]

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: Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))

[Tim Bunce]

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.

Tim.

Re: type-checking [Was: What is Perl?]

[Tim Bunce]

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: type-checking [Was: What is Perl?]

[Tim Bunce]

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: Summary...tell me where I'm worng...

[Tim Bunce]

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.

Re: What's Perl?

[Tim Bunce]

On Tue, Aug 01, 2000 at 10:34:51PM +0900, Simon Cozens wrote:
> On Tue, Aug 01, 2000 at 07:29:05AM -0600, Tom Christiansen wrote:
> > I suggest that the language list discuss this very matter: what 
> > Perl really *is*, so that we know the tenets and principles against
> > which proposals can be measured.
>  
> Let's do that. Here's my opening gambit:
> 
> Well, enough clowning around.  Perl is, in intent, a cleaned up and
> summarized version of that wonderful semi-natural language known as
> "Unix".
>  -- Larry Wall in <[EMAIL PROTECTED]>

I agree with the sentiment. I'd also note

  "Unix is really very simple,
   but it takes a genius to understand that."

I think it ws Dennis Richie who said something like that (or one of the
other original unix architects, I couldn't find it on the web).

Tim.

Re: formats and localtime

[Tim Bunce]

On Tue, Aug 01, 2000 at 06:31:45AM -0700, Randal L. Schwartz wrote:
> 
> I disagree with keeping the same name as a Unix function, but having a
> radically different calling sequence or return value.  If you want a
> new interface, *name* a new interface.

Amen!

Tim.

Re: Summary...tell me where I'm worng...

[Tim Bunce]

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: RFC: On-the-fly tainting via $^T

[Tim Bunce]

On Mon, Jul 31, 2000 at 10:42:54PM -0700, Nathan Wiger wrote:
> Dan Sugalski wrote:
> > 
> > > existence of a $^T variable for controlling tainting in the same way
> > > that $^W controls warnings. 
> >
> > So put in an RFC. :)
> 
> Dan-
> 
> Ask and ye shall receive...in POD format ala Tim...

I think this is more perl6-language than perl6-internals.

Tim.