headers
Nicholas Clark | 14 Nov 2007 21:47

parentheses and context (was Re: state and START)

On Sat, Sep 08, 2007 at 01:48:39PM +0100, Nicholas Clark wrote:
> Have I got this correct?
> 
>     state  <at> a = foo();	# Implicit START block around call and initialisation
>     state ( <at> a) = foo();	# Implicit START block around call and initialisation
>     (state  <at> a) = foo();	# foo() called every time, assignment every time

Um. That seemed to scare everyone away. If it's rephrased like this:

    my  <at> a = foo();	# What context is foo called in?
    my ( <at> a) = foo();	# What context is foo called in? Is it the same?
    (my  <at> a) = foo();	# What context is foo called in? Is it the same?

Are the three calls in the same context? Or two (or even three) different
contexts?

Nicholas Clark
Permalink | Reply | 2 comments |
headers
Jonathan Scott Duff | 15 Nov 2007 03:09
Picon

Re: parentheses and context (was Re: state and START)

On Nov 14, 2007 2:47 PM, Nicholas Clark <nick <at> ccl4.org> wrote:

> On Sat, Sep 08, 2007 at 01:48:39PM +0100, Nicholas Clark wrote:
> > Have I got this correct?
> >
> >     state  <at> a = foo(); # Implicit START block around call and
> initialisation
> >     state ( <at> a) = foo();       # Implicit START block around call and
> initialisation
> >     (state  <at> a) = foo();       # foo() called every time, assignment
> every time
>
> Um. That seemed to scare everyone away. If it's rephrased like this:
>
>    my  <at> a = foo();      # What context is foo called in?
>    my ( <at> a) = foo();    # What context is foo called in? Is it the same?
>    (my  <at> a) = foo();    # What context is foo called in? Is it the same?
>
> Are the three calls in the same context? Or two (or even three) different
> contexts?
>

My two cents:  foo() looks like it's always in list context, but as far as
START goes, I'd think the first two call foo() only once while the third
calls it every time (just as you have it written).

Now, someone tell me if I'm right or wrong and why  :-)

Nicholas Clark
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
chromatic | 21 Nov 2007 06:30
Favicon

Parrot 0.5.0 "Caulked Snack" released!

Jack had avoided looking into his sons' faces during this Oration, because he
reckoned they'd not wish to be seen with tears streaming down their faces.  
But looking up at Jimmy now he saw dry eyes and a quizzical if impatient 
phizz.  Turning the other way, he saw Danny gazing distractedly at the White 
Tower.

...

"Before you embark on a new life overseas, assuming that is your fate," Jack 
said, "find Eliza and tell her she is my true love."  And then he jerked the 
chains loose from the restraining grip of first Jimmy, then Danny.  He leaned 
forward, pushed off against the rail with both feet, and launched himself 
into space above London.  His cloak spread in the wind of his flight like the 
wings of an eagle, revealing, to anyone who might be gazing up into the sky, 
a lining made from cloth-of-gold that glistered in the rays of the setting 
sun like the chariot of Apollo.  He was on his way down.

-- Neal Stephenson, The System of the World

On behalf of the Parrot team, I'm proud to announce Parrot 0.5.0 "Caulked 
Snack." Parrot (http://parrotcode.org/) is a virtual machine aimed at running 
all dynamic languages.

Parrot 0.5.0 is available from the CPAN (soon), or follow the download
instructions at http://parrotcode.org/source.html.  For those who would like 
to develop on Parrot, or help develop Parrot itself, we recommend using 
Subversion or SVK on the source code repository to get the latest and best 
Parrot code.

Parrot 0.5.0 News:
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Fuller | 28 Nov 2007 18:06
Picon
Gravatar

xml and perl 6

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
Permalink | Reply | 87 comments |
headers
Nicholas Clark | 28 Nov 2007 19:12

Re: xml and perl 6

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 roughly that the core consists only of
the mechanisms for getting and installing other extension modules - anything
that doesn't need to be in the core, isn't.

This slim core intentionally won't be useful for that much, other than the
basis for building larger Perl 6 distributions aimed at broad types of tasks.
The idea being that an ISP would install the "web serving" distribution,
which would be bundled with the sorts of modules appropriate for that task,
but not burned with the sorts of modules useful for bioinformatics.

The aim is to avoid the problem that Perl 5 finds itself in, where things
once added to the core can never be removed, and 15 years later you find
that there are several generations of "this is current" modules in the
distribution that are a maintenance burden. Usually a burden that falls on
volunteers.

Nicholas Clark
Permalink | Reply | 85 comments |
headers
James Fuller | 28 Nov 2007 19:28
Picon
Gravatar

Re: xml and perl 6

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 profile capability was the result.

With Ant's latest incarnation, they finally have a good model for
extensibility and have been successful at segregating axiomatic
functionality to the core and relegating extensions to external
libraries.

I completely agree that this is also good approach for Perl 6 .... but
I would weakly argue that XML ubiquity is fast making it the 'text'
format of the day and perl having many text processing facilities
built into its core might want to reconsider some basic premises about
how it perceives XML.

A few things I could imagine; native XML data type (and whatever that
means at this late stage) ....

xml parser, xpath processor built into Perl6 core making it very
quick, since we are late stage I would call this an optimization ;),

I can even see in a moment of madness a nod to  'whatever' programming
and embed some triple inference processing deep into perl6.....

making perl 6 XML-neutral is a mistake. imho.
(Continue reading)

Permalink | Reply | 81 comments |
headers
Andy Armstrong | 28 Nov 2007 19:39
Gravatar

Re: xml and perl 6

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
Permalink | Reply | 2 comments |
headers
James Fuller | 28 Nov 2007 19:42
Picon
Gravatar

Re: xml and perl 6

On Nov 28, 2007 7:31 PM, C.J. Adams-Collier <cjcollier <at> gmail.com> wrote:
> On Wed, 2007-11-28 at 18:12 +0000, 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 module.
> > >
> > > thoughts?
> >
> > If I remember the plan correctly, it's roughly that the core consists only of
> > the mechanisms for getting and installing other extension modules - anything
> > that doesn't need to be in the core, isn't.
> >
> > This slim core intentionally won't be useful for that much, other than the
> > basis for building larger Perl 6 distributions aimed at broad types of tasks.
>
> James,
>
> Perhaps you should create a "distribution" for xml processing?  If there
> is not yet a Standard Operating Procedure for creating a perl 6
> distribution, I think the community would benefit from the creation of
> such.  Start small, with only enough to do a simple XML processing task.
> Allow for inheritence/extension of the distribution.

I see these 'distributions' as deployment profiles.

It would be very easy to package up (more akin to customizing a linux
distro) perl6 with all those lovely XML pm tweaking here and there,
etc.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Geoffrey Broadwell | 28 Nov 2007 19:50

Re: xml and perl 6

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 single XML processor could
possibly be "best" in all circumstances anyway.  We should not canonize
a single XML processor (now especially) by putting it in the core.

As Nicholas pointed out, it's unlikely that "vanilla" will be the Perl 6
flavor that any vendor actually ships.  But I definitely want to be able
to choose between strawberry and chocolate, and perhaps a new flavor of
my own (or my company's) design.  I really do not want to always get
"Baskin-Robbins in a blender" because everything's in core.

The grammar engine is core.  A *particular* grammar is not.

-'f
Permalink | Reply | 77 comments |
headers
James Fuller | 28 Nov 2007 19:52
Picon
Gravatar

Re: xml and perl 6

On Nov 28, 2007 7:39 PM, Andy Armstrong <andy <at> hexten.net> 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, here are  2 interesting examples of
representing XML in a programming context

http://en.wikipedia.org/wiki/E4X

and

http://en.wikipedia.org/wiki/XQuery

there is lots to learn here.

J
Permalink | Reply | 1 comment |

Gmane