Paul Hodges wrote:
But on this general note, is there any current organization or location
where small problems are being parcelled out? I'd love to help, but my
time is as limited as everyone's If I could get small bites of work
to do, maybe I could contribute something useful.
Anyone reque
It also helps that you consistently make incisive observations and
contributions to conversations, even if they are a little tart
sometimes. :)
But on this general note, is there any current organization or location
where small problems are being parcelled out? I'd love to help, but my
time is as
duh. I'll learn to finish reading all the posts before adding my own
*someday*.
--- Darren Duncan <[EMAIL PROTECTED]> wrote:
> At 10:23 AM +0300 12/11/07, Richard Hainsworth wrote:
> >Darren Duncan wrote:
> >>At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote:
> >>>Equally, Something to replace
At 10:23 AM +0300 12/11/07, Richard Hainsworth wrote:
Darren Duncan wrote:
At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote:
Equally, Something to replace CGI or DBI will be essential to the
uptake of P6. I would far prefer to have a skilled and resourceful
professional, such as yourself or
On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote:
> I download pugs and parrot from
> SVN repositories, written tests - one of which still hangs the
> compilation of pugs. Indeed the test I wrote for pugs concerned the
> ability of pugs to use existing CPAN modules. I have tried parro
A great relief. Fantastic.
Where should I be looking to see what is happening. Is there some form
of coordination of this module writing activity?
Darren Duncan wrote:
At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote:
Equally, Something to replace CGI or DBI will be essential to the
uptak
At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote:
Equally, Something to replace CGI or DBI will be essential to the
uptake of P6. I would far prefer to have a skilled and resourceful
professional, such as yourself or Damian Conway write these modules
than leave it to enthusiastic amateurs su
Why thank you Mr. Chromatic!
In between all my other activities, I have been trolling along this list
from its inception, and followed eagerly every Appocalpse, Exegisis and
Synopsis as soon as they came on line. I download pugs and parrot from
SVN repositories, written tests - one of which st
On Saturday 08 December 2007 06:50:48 Richard Hainsworth wrote:
> Surely, some concentrated thought by the inventive and resouceful minds of
> who lead this project should go into language utilisation and
> popularisation.
My goodness, @Larry's pretty darn busy trying to build the core kernel of
Larry Wall wrote:
On Sun, Dec 02, 2007 at 07:43:25PM -0800, Peter Scott wrote:
: I do feel strongly that we need some sort of solution to this so that Perl
: 6 is not merely an outstanding framework that leaves all domain-specific
: extensions to the end user.
Perl 6 as a language doesn't addres
Larry Wall wrote:
Now, it might well be that a Perl standards body could specify a
mininum suggested set of modules for any distribution to enhance
interoperability, but we haven't got to that point yet, I don't think.
This would be great though!!
Even if it is afterward, it is still a lot b
On Sun, Dec 02, 2007 at 07:43:25PM -0800, Peter Scott wrote:
: I do feel strongly that we need some sort of solution to this so that Perl
: 6 is not merely an outstanding framework that leaves all domain-specific
: extensions to the end user.
Perl 6 as a language doesn't address this (except to ke
On Mon, Dec 03, 2007 at 12:09:48PM +, Smylers wrote:
: This isn't something which needs to influence language design -- in the
: sense that it doesn't need to be sorted before the design can be final
: and Perl 6 released.
Well, and to the extent that it needs to influence language design, it
Peter Scott writes:
> I do feel strongly that we need some sort of solution to this so that
> Perl 6 is not merely an outstanding framework that leaves all
> domain-specific extensions to the end user.
OK.
> Can we find a way to make and maintain some recommendations in a way
> that people can f
On Fri, 30 Nov 2007 03:57:58 -0700, David Green wrote:
> Part of a solution is search.cpan.org -- if you can figure out which
> of the 870 XML modules will be useful to you. Another part is asking
> on newsgroups or lists -- if you can figure out which of the 870
> opinions offered is knowledge
By the time this got written, I see James has bowed out of the
discussion with some words about 'architectural break points'. Even so,
my two-penniworth:
JF gave some examples of how he would like xml to be 'a part of core'.
For clarity, I use xml and I have designed a language to describe
fi
On Nov 30, 2007 10:57 AM, David Green <[EMAIL PROTECTED]> wrote:
> Maybe some kind of "Advisory Board" would help, where people (who
> might be experts in various ways) can offer informed recommendations
> on what modules make a good fit for what circumstances. Ultimately,
> if this is something w
On 11/29/07, James Fuller wrote:
well, if my previous posts didn't attract flames this post
certainly will ;)
Nah, this is getting into the interesting language part!
(Technically, it should be perl6+xml-language... but then the goal of
perl6 is to be infinitely flexible, so I guess it is
On 11/29/07, James Fuller wrote:
but by making some fundamental xml processing available by the core
(like file access, regex, and a host of other fundamental bits n
bobs), u do promote a common and systematic approach to working with
XML in all perl modules.
As everyone else and his dog has
On 11/29/07, Luke Palmer wrote:
I think you are falling into a classic builtin trap. [...]
Please, you, everyone, forget about the word "core". It is an
implementation detail.
Yes! Though it's a natural mistake because people assume that The
CORE(TM) in Perl6 means something similar to the
>>A programming language is made by humans and subject to the same evolutions
>>and bugs and in the end is alive and will die.
>>A programming language should evoluate, try to respond quickly to the
>>actual environment in order to survive or expand.
>>
>>
>
>Have you *seen* how much time p5p
cdumont wrote:
> By listening to you all, we shouldn't even think to implement file access...
I think I'd argue that most file-access features should indeed be
considered "non-core". This doesn't mean that we shouldn't think to
implement them -- or that they wouldn't be part of almost every Perl-
cdumont wrote:
> By listening to you all, we shouldn't even think to implement file access...
I think I'd argue that most file-access features should indeed be
considered "non-core". This doesn't mean that we shouldn't think to
implement them -- or that they wouldn't be part of almost every Perl-
Thanks to all for taking the time to respond at a minimum the
discussion has taught me where perl 6 is headed and where the major
architectural brake points currently are.
gl, Jim Fuller
Danny Brian skribis 2007-11-29 10:57 (-0700):
> Perhaps a pro XML-er can weigh in. Unlike many others on this list, I
> use XML for almost everything. I think the point is what you're
> saying here above, Jim. The benefits you describe of a native XML data type
> boil down to a) encouraging a commo
> and to answer specifically the question;
>
> 'What would you be able to do with it that you couldn't do if it were
> a module ?'
>
> there is no difference in usage.
Perhaps a pro XML-er can weigh in. Unlike many others on this list, I
use XML for almost everything. I think the point is what you
On Thursday 29 November 2007 07:07:18 James Fuller wrote:
> I have been arguing that having some simple functionality, provided by
> the core, would potentially harmonize usage across modules and promote
> better understanding of code, in general, through consistent usage.
That didn't work for Fi
On Thursday 29 November 2007 03:21:18 cdumont wrote:
> By listening to you all, we shouldn't even think to implement file
> access...
Please drop the sarcasm.
> A programming language is made by humans and subject to the same evolutions
> and bugs and in the end is alive and will die.
> A progra
On Wed, Nov 28, 2007 at 07:52:31PM +0100, James Fuller wrote:
: On Nov 28, 2007 7:39 PM, Andy Armstrong <[EMAIL PROTECTED]> wrote:
: > On 28 Nov 2007, at 18:28, James Fuller wrote:
: >
: > > A few things I could imagine; native XML data type (and whatever that
: > > means at this late stage)
:
--- Alex Kapranoff <[EMAIL PROTECTED]> wrote:
> Â ×òâ, 29/11/2007 â 07:18 +0100, James Fuller ïèøåò:
> > On Nov 28, 2007 8:46 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > > On Wednesday 28 November 2007 10:59:30 James Fuller wrote:
> > > > I do not nec. agree with 'a particular grammer is not' part
HaloO,
James Fuller wrote:
On Nov 29, 2007 1:15 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:
So to bring some perspective back into this discussion, I'd like to
ask you, what would it mean to you for there to be an XML type in
core? That is,
from a user's perspective, disregarding implementation
On Thu, Nov 29, 2007 at 10:20:00AM -0500, Mark J. Reed wrote:
> The module could even, I suppose, insert a filter into the compiler so
> that your proposed literal syntax would work, but I don't really see
> the advantage of that over this:
>
> my $doc = Document.new(< here
> END
Or even:
my
On Nov 29, 2007 10:07 AM, James Fuller <[EMAIL PROTECTED]> wrote:
> Once again, the point is that I would like to manage and process XML
> using native types, structures and xml aware operators, from within
> perl. If I inherit XPATH, then I get 90% of everything I need.
But what do you mean "nat
On Nov 29, 2007 3:44 PM, Smylers <[EMAIL PROTECTED]> wrote:
> What makes you so sure that nobody will come up with a better way of
> working with XML
there is power in everyone doing the same thing ... this is a
variation of lingua franca design pattern.
For example, would we say that the reason
James Fuller writes:
> by making some fundamental xml processing available by the core, u do
> promote a common and systematic approach to working with XML in all
> perl modules.
Why is that a good thing?
What makes you so sure that nobody will come up with a better way of
working with XML
In P
On Nov 29, 2007 1:15 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:
> language? What would you be able to do with it that you couldn't do
> if it were a module
> (arguments such as "use it without putting 'use XML::Foo' at the top"
> considered valid)?
and to answer specifically the question;
'What
On Nov 29, 2007 1:15 PM, Luke Palmer <[EMAIL PROTECTED]> wrote:
> This has become quite the flame war. There seem to be two sides of
> the argument, you arguing one, everybody else arguing the other.
good to see there is passion underlying perl 6 development ;)
> So to bring some perspective bac
Hi Jim,
This has become quite the flame war. There seem to be two sides of
the argument, you arguing one, everybody else arguing the other.
So to bring some perspective back into this discussion, I'd like to
ask you, what would it mean to you for there to be an XML type in
core? That is,
from a
James Fuller writes:
> my claim is that XML is significantly common place,
Yes, but the question isn't whether it's common place _now_ -- but
whether it still will be in a couple of decades time.
We know from experience that adding some modules to Perl 5 a decade ago
is now a maintenance burden,
On Nov 29, 2007 12:01 PM, Smylers <[EMAIL PROTECTED]> wrote:
> So, to make a claim for any 'domain-specific' functionality to be added
there are plenty of core perl functions that you or I will use rarely
(both in perl 5 and perl 6).
my claim is that XML is significantly common place, that any ne
I guess what should be in the core or not is not something
that should not be debated here.
In fact, perl 6 is supposed to be the *community language*
so instead of saying 'I' use this one but don't use this one,
so I don't see why it should be implemented into perl,
the *community* should decide
James Fuller writes:
> On Nov 28, 2007 8:46 PM, chromatic <[EMAIL PROTECTED]> wrote:
>
> > On Wednesday 28 November 2007 10:59:30 James Fuller wrote:
> >
> > > I do not nec. agree with 'a particular grammer is not' part of the
> > > core ... if that grammar is so common to every problem (like reg
On Nov 29, 2007 6:40 AM, James Fuller <[EMAIL PROTECTED]> wrote:
> I would argue that XML is slightly evolved 'text' and I would like to
> see my fav programming language treat it as a first class citizen
> internally.
I think you are falling into a classic builtin trap. The idea is that when
you
--- James Fuller <[EMAIL PROTECTED]> wrote:
> From another point of view, there must be a reason why most languages
> have not decided as treating XML as a first class citizen.
I've had several positions where we do moderately large-scale stuff and
don't touch XML; I use strings, floats, and ints
On 11/29/07, James Fuller <[EMAIL PROTECTED]> wrote:
> I understand that there can be different distros customized to certain
> problem domains, but as explained I see XML as common to all those
> problem domains.
I have a fulltime Perl programming job. I also spend a lot of my free
time with Perl
On Nov 29, 2007 7:45 AM, Alex Kapranoff <[EMAIL PROTECTED]> wrote:
> В Чтв, 29/11/2007 в 07:18 +0100, James Fuller пишет:
> > On Nov 28, 2007 8:46 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > > On Wednesday 28 November 2007 10:59:30 James Fuller wrote:
> > > > I do not nec. agree with 'a particular
В Чтв, 29/11/2007 в 07:18 +0100, James Fuller пишет:
> On Nov 28, 2007 8:46 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > On Wednesday 28 November 2007 10:59:30 James Fuller wrote:
> > > I do not nec. agree with 'a particular grammer is not' part of the
> > > core ... if that grammar is so common to
On Nov 28, 2007 8:48 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-28 at 19:59 +0100, James Fuller wrote:
> > XML Parser is what I am talking about
>
> OK -- do you want an event-based parser? Do you want a DOM parser? Do
> you want a simplified tree generator parser? Do yo
On Nov 28, 2007 8:46 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Wednesday 28 November 2007 10:59:30 James Fuller wrote:
>
> > I do not nec. agree with 'a particular grammer is not' part of the
> > core ... if that grammar is so common to every problem (like regex is)
> > then why not include it?
At 6:06 PM +0100 11/28/07, James Fuller wrote:
there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps
before Perl 6 is fully baked its time to review what could live in the
core versus an external module.
thoughts?
cheers, Jim Fuller
I want to state agreement with others that thi
On Wed, 2007-11-28 at 18:12 +, Nicholas Clark wrote:
> On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote:
> > there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps
> > before Perl 6 is fully baked its time to review what could live in the
> > core versus an external m
On Wed, 2007-11-28 at 11:46 -0800, chromatic wrote:
> The criterion for including a module in the core is "Is this necessary to get
> and install other modules?" not "Why not include this module?"
WELL SAID.
-'f
On Wed, 2007-11-28 at 19:59 +0100, James Fuller wrote:
> XML Parser is what I am talking about
OK -- do you want an event-based parser? Do you want a DOM parser? Do
you want a simplified tree generator parser? Do you care about memory
limitations? Run time?
Does the parser need to be robust a
On Wednesday 28 November 2007 10:59:30 James Fuller wrote:
> I do not nec. agree with 'a particular grammer is not' part of the
> core ... if that grammar is so common to every problem (like regex is)
> then why not include it?
Because it's not necessary for getting and installing other extension
On Nov 28, 2007 7:50 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> Not too put too strong a bias on it, but:
>
> XML processors are a dime a dozen. There is no way for us to know *now*
> what the "best" XML processor(s) will be a decade from now, and Perl 6
> is intended to be a very long te
On Nov 28, 2007 7:39 PM, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> On 28 Nov 2007, at 18:28, James Fuller wrote:
>
> > A few things I could imagine; native XML data type (and whatever that
> > means at this late stage)
>
> What might that mean at any stage?
from a syntactic point of view, h
Not too put too strong a bias on it, but:
XML processors are a dime a dozen. There is no way for us to know *now*
what the "best" XML processor(s) will be a decade from now, and Perl 6
is intended to be a very long term language. And frankly there are
enough different use cases to ensure that no
On Nov 28, 2007 7:31 PM, C.J. Adams-Collier <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-11-28 at 18:12 +, Nicholas Clark wrote:
> > On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote:
> > > there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps
> > > before Perl 6 is full
On 28 Nov 2007, at 18:28, James Fuller wrote:
A few things I could imagine; native XML data type (and whatever that
means at this late stage)
What might that mean at any stage?
--
Andy Armstrong, Hexten
all makes good sense,
to make a poor analogy (and to make my point);
the java build tool, Apache Ant went through the same sort of cycle
(at a much smaller scale) whereby initial architecture forced a lot of
extraneous functionality into the core hard to maintain and
limited deployment profi
On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote:
> there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps
> before Perl 6 is fully baked its time to review what could live in the
> core versus an external module.
>
> thoughts?
If I remember the plan correctly, it's rou
61 matches
Mail list logo
