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.
--- 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 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
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
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 new
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,
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
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 back
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 would
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
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 why
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 native?
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(END);
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
--- 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
of the
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)
:
:
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
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
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're
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 common
Author: larry
Date: Thu Nov 29 12:31:14 2007
New Revision: 14469
Modified:
doc/trunk/design/syn/S05.pod
Log:
Clarification suggested by dlocaus++.
Modified: doc/trunk/design/syn/S05.pod
==
---
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
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-6
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-6
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 spends on
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
26 matches
Mail list logo
