What does this mean in S03?

[John M. Dlugosz]

"Strings, arrays, lists, sequences, captures, and tree nodes can all be pattern 
matched by regexes or by signatures more or less interchangably."


How can captures me matched by regexes?  Does this mean that there is really an 
isomorphism between Signatures and Regexes?

Re: static types, checking, conversions

[Thom Boyer]

Mark J. Reed wrote:

It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page).  I therefore assume that they have done so, but
others would benefit by doing likewise. :)
  
Could you be a little more specific on where to find information on 
JavaScript's proposed system of type constraints?


The firefox.com developers page 
(http://developer.mozilla.org/en/docs/Main_Page) has several links on 
JavaScript topics. The most promising one leads to 
http://developer.mozilla.org/en/docs/JavaScript, and, while that page 
has info on quite a few different versions of JavaScript, version 2 is 
not one of them. Of course, I'm only guessing that JavaScript 2 is what 
you might have meant by Javascript:TNG. (I can't find any mention of TNG 
or "Next Generation" on either of those pages, either.)

=thom

Parrot 0.6.1 "Bird of Paradise" Released

[jerry gay]

Aloha!

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

Parrot 0.6.1 can be obtained via 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.6.1 News:
- Specification
  + drafted pdd29_compiler_tools.pod
  + updated pdd28_character_sets.pod draft
  + updated pdd19_pir.pod draft
- Languages
  + c99: added independent C pre-processor
  + HQ9+: reimplemented with PCT
  + Lua:
. reimplementation with PCT, using PAST and POST
. behavior aligned wih 5.1.3
  + Rakudo:
. implemented basic I/O, including '$*IN', '$*OUT', '$*ERR', 'prefix:='
. implemented simple typing and runtime type checking
. added basic multi-method dispatch
. expanded named argument handling, including Pair and colonpairs
. added 'Whatever' and 'Capture' classes
. implemented 'handles' trait verb
. added 'loop' statement
. implemented 'given', 'when', 'for', 'while', 'until' statement modifiers
. implemented Hash methods '.keys' and '.values'
. fixed bug to get '.WHAT' working correctly
. initial implementation of 'eval'
- Compilers
  + NQP:
. created a bootstrapped build, see 'make boot'
. added 'infix:<', 'infix:<=', 'infix:>', 'infix:>=' relational operators
. added 'postfix:++', 'postfix:--' operators
  + PCT:
. added methods specifying default behaviors in PAST, reducing repeated code
. improved symbol table lookup
  + PGE:
. removed deprecated code including: P6Regex, P6Grammar, PAST-pm
- Miscellaneous
  + notable speedups during compilation and execution of parrot and HLLs
  + pdb (the parrot debugger) can now catch parrot exceptions
  + better detection of glibc and gettext during configuration
  + various bugfixes, code cleanups, deprecations, and coding standard fixes


Mahalo to all our contributors for making this possible, and our
sponsors for supporting this project.

Enjoy!
~jerry

Re: static types, checking, conversions

[Mark J. Reed]

I apologize for the vagueness; I was away from browser when I sent
that. Go to http://www.ecmascript.org for the nitty gritty on
ECMAScript 4th Edition, a.k.a. "JavaScript 2", which is what I was
talking about.  White papers, specs, reference interpreter.

The link from the Firefox developers page
(http://developer.mozilla.org/en/docs/Main_Page, which you get to by
clicking the "Developer" tab on http://www.firefox.com) is called "The
Truth about Javascript", and leads to slides from Brendan Eich's talk
at last year's Ajax Experience West conference
(http://developer.mozilla.org/presentations/eich-ajax-experience-2007/).
 Embedded within the slides is discussion about what went into the
design of "Javascript 2", and a link over to the
http://www.ecmascript.org site (as well as other interesting stuff).

Re: static types, checking, conversions

[Mark J. Reed]

It would behoove @Larry to examine the optional type constraints
system proposed for Javascript:TNG (see link from firefox.com
developers page).  I therefore assume that they have done so, but
others would benefit by doing likewise. :)



On 4/15/08, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> John M. Dlugosz wrote:
> > This needs to be fleshed out.  Decisions need to be made.
>  > Anyone want to discuss it with me?
>
> I want to. But give me time. Meanwhile you could read
> e.g. .
> This deals with F-bounded polymorphism in a tutorial
> style. A generalisation of that is Constraint Bounded
> Polymorphism as given in the papers of the WASP Group
> at . Another inspiration
> is the CDuce language  which is
> built around semantic subtyping.
>
> My point is that Perl 6 so far has defined a syntax
> for type markup but hardly defined how typing works
> ---I remember the "pain but no gain" thread. It might
> actually be the case that optional typing means that
> you need a module that implements it.
>
> I personally see types as the semantics of the code
> with the added benefit of being machine readable and
> thus can assist you in reasoning about the code.
> A type system is a tool just like an IDE allows you
> to browse the code, e.g. jumping to the definition of
> a class or all invocations of a method etc.
>
> There are two fundamental type errors in Perl 6:
>1) a) no or b) ambiguous targets for dispatch
>2) non-bindable args in non-dispatch position
> 1a and 2 can be easily avoided with slurpy Any
> protos. So the only remaining offender is 1b. And
> that might be pragmatized to just call them all.
> So we sort of end up with the impossibility of
> type errors :)
>
> Your concerns so far have been with the typing of
> assignment and binding. The former is easy because
> it involves the creation of a new value. Thus one
> can dispatch $x = $y on the container type of $x
> and the value type of $y and store the result in
> $x. So here you get an error of type 1 if any.
> Binding is more complicated because there is no
> new value involved but you want two containers
> to share a value. This is where Larry's view concept
> comes in to avoid the invariance problem of rw
> containers. OTOH the synopsis say that binding
> replaces the container, so
>
>my Int $x = 13;
>my Str $y = 'foo';
>
>$y := $x;
>$y = 42; # OK, type of $y now Int
>
> but that contradicts the fact that binding happens
> when functions are called
>
>sub foo (Dog $d) { say $d; }
>
>my Int $x = 23;
>foo $x;  # $d := $x makes type of $d Int and prints 23?
>
> Note also that binding is specced only for scalars so far.
> Not for elements of an array or hash!
>
>
> Regards, TSa.
> --
>
> The Angel of Geometry and the Devil of Algebra fight for the soul
> of any mathematical being.   -- Attributed to Hermann Weyl
>

-- 
Sent from Gmail for mobile | mobile.google.com

Mark J. Reed <[EMAIL PROTECTED]>

Re: static types, checking, conversions

[TSa]

HaloO,

John M. Dlugosz wrote:

This needs to be fleshed out.  Decisions need to be made.

> Anyone want to discuss it with me?

I want to. But give me time. Meanwhile you could read
e.g. .
This deals with F-bounded polymorphism in a tutorial
style. A generalisation of that is Constraint Bounded
Polymorphism as given in the papers of the WASP Group
at . Another inspiration
is the CDuce language  which is
built around semantic subtyping.

My point is that Perl 6 so far has defined a syntax
for type markup but hardly defined how typing works
---I remember the "pain but no gain" thread. It might
actually be the case that optional typing means that
you need a module that implements it.

I personally see types as the semantics of the code
with the added benefit of being machine readable and
thus can assist you in reasoning about the code.
A type system is a tool just like an IDE allows you
to browse the code, e.g. jumping to the definition of
a class or all invocations of a method etc.

There are two fundamental type errors in Perl 6:
  1) a) no or b) ambiguous targets for dispatch
  2) non-bindable args in non-dispatch position
1a and 2 can be easily avoided with slurpy Any
protos. So the only remaining offender is 1b. And
that might be pragmatized to just call them all.
So we sort of end up with the impossibility of
type errors :)

Your concerns so far have been with the typing of
assignment and binding. The former is easy because
it involves the creation of a new value. Thus one
can dispatch $x = $y on the container type of $x
and the value type of $y and store the result in
$x. So here you get an error of type 1 if any.
Binding is more complicated because there is no
new value involved but you want two containers
to share a value. This is where Larry's view concept
comes in to avoid the invariance problem of rw
containers. OTOH the synopsis say that binding
replaces the container, so

  my Int $x = 13;
  my Str $y = 'foo';

  $y := $x;
  $y = 42; # OK, type of $y now Int

but that contradicts the fact that binding happens
when functions are called

  sub foo (Dog $d) { say $d; }

  my Int $x = 23;
  foo $x;  # $d := $x makes type of $d Int and prints 23?

Note also that binding is specced only for scalars so far.
Not for elements of an array or hash!


Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl

Re: New specdoc available

[Moritz Lenz]

John M. Dlugosz wrote:
> Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote:
>> John M. Dlugosz wrote:
>>   
>>> I posted my current work at 
>>> http://www.dlugosz.com/files/specdoc.pdf
>>> and .odt.
>>> 
>>
>> 3.1.1 Normalization uses a constant without a sigil - is that really
>> allowed?
>>   
> Yes, it's in the Synopses.
> 
> 
>> 3.1.2 BOM - can you detect UTF-32 U+FEFF painlessly? If so, you could
>> allow that
>> 3.1.3 The =encoding is used only for POD in perl 5. And if you force it
>> to be on the first line, you forbid #!/usr/bin/perl lines. What about
>> 'use encoding('ISO-8859-1');' instead? Any other thoughts?
>>   
> No problem if it can read that 'use' line in the first place.
> 
> Does a BOM also interfere with #!/usr/bin/perl ?

Sadly, yes.
I used vim with
:set nobinary fileencoding=utf-8 bomb
:w

./foo.pl
bash: ./foo.pl: cannot execute binary file

moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/



signature.asc
Description: OpenPGP digital signature

RE: Idea: infer types of constants

[Miller, Hugh]

 

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
>Behalf Of Mark J. Reed
>Sent: Monday, April 14, 2008 2:05 PM
>To: Jonathan Worthington
>Cc: David Green; Perl6
>Subject: Re: Idea: infer types of constants
>
>On Mon, Apr 14, 2008 at 2:32 PM, Jonathan Worthington
>>  my Dog $fifi .= new(); # works in Rakudo too ;-)
>
>And even in Pugs! :)  Doesn't help with literals, though, e.g.
>
>my Float $approx_pi = 3.14;
>
>
>
>--
>Mark J. Reed <[EMAIL PROTECTED]>
>

What about the type support (system) one sees in ML ? (e.g., the way it
assigns automatically types can be assigned, does not require specific
types when they are not needed, flags incompatibilities, etc.) Do those
things not fit well with Perl's approaches and aims ? 

Re: Idea: infer types of constants

[Jonathan Worthington]

TSa wrote:

Jonathan Worthington wrote:

Miller, Hugh wrote:

Was that private communication or on another mailing list?
It was also sent to perl6-language, through I was on the To or Cc line 
too, so I guess that's how I got it but the list, somehow, didn't. Not 
sure why the original message I replied to didn't actually make it to 
the list, though.



That should be $CALLER::a because $OUTER::a is the outer
lexical scope where foo is defined. 

Yup, sorry, brain only half working at this time of day. :-)

And I think that this reaching out to the caller should taint foo in 
some way.
Sure, but from what I can see that still doesn't help us infer types at 
compile-time if what foo means can be modified at runtime.


Jonathan

Re: Idea: infer types of constants

[Jonathan Worthington]

Miller, Hugh wrote:

What about the type support (system) one sees in ML ? (e.g., the way it
assigns automatically types can be assigned, does not require specific
types when they are not needed, flags incompatibilities, etc.) Do those
things not fit well with Perl's approaches and aims ? 
  
They don't really fit with Perl 6 too well. For example, suppose we 
tried to type inference this:


my $a = 42;
foo();
my $b = $a;

What is the type of $b? Well, we can't actually infer that because foo 
might be:


sub foo() {
   $OUTER::a = "oh hi, i iz not int!"
}

And because subs can be wrapped at runtime, or symbol tables can be 
diddled, or other such fun, we probably can't safely look at foo at 
compile time in the general case to make sure our inference is correct 
too, because foo might not be the foo we thought it was at compile time 
by the time we reach runtime.


From what I can see, making a language where the types are inferable, 
like ML, can almost involve doing the language design on a knife edge. 
You need the inference to not only be decidable, but also reasonably 
efficient, and a subtle feature interaction can hurt this (I think ML 
nearly had one of these when ref types and let statements interacted in 
a way that could compromise type safety - I'm rusty on the details). And 
if I'm remembering correct, there are contrived programs you can write 
that make the ML checker go exponential order in the size of the code too.


Jonathan

Re: Idea: infer types of constants

[TSa]

HaloO,

Jonathan Worthington wrote:

Miller, Hugh wrote:


Was that private communication or on another mailing list?


What is the type of $b? Well, we can't actually infer that because foo 
might be:


sub foo() {
   $OUTER::a = "oh hi, i iz not int!"
}


That should be $CALLER::a because $OUTER::a is the outer
lexical scope where foo is defined. And I think that this
reaching out to the caller should taint foo in some way.


Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl

Re: shape trait and Hash

[TSa]

HaloO,

John M. Dlugosz wrote:

More globally, nothing is said much about parameters to types.

> It shows an example like  Array[of=>T] but never discusses the
> syntax of defining parameterized types or anything.  Is there

a paper or discussion on that I could read?


Essentially the direct indexing of a name with [] and {} is
reserved for type theoretical things. And one paper that makes
use of this is Theory.pod from Luke. Apart from that the
current design doesn't say much about the type system ;(


Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl

shape trait and Hash

[John M. Dlugosz]

In S02 it is writ, "The key type of a hash may be specified as a shape 
trait--see S09."

However, S09 is rather brief on hashes, and although it shows using a type 
inside the curlies, it never talks about shape traits or anything else.

Am I do understand that it pretty much does all the same stuff that Array does?

More globally, nothing is said much about parameters to types.  It shows an 
example like  Array[of=>T] but never discusses the syntax of defining 
parameterized types or anything.  Is there a paper or discussion on that I 
could read?

Thanks,
--John

Re: Idea: infer types of constants

[TSa]

HaloO,

John M. Dlugosz wrote:

Then the declaration

  my ::T $x = whatever;

should use the exact same generic mechanism!  At worst, it needs


I would expect that this works by binding ::T to the type of whatever.



  my Any ::T $x = whatever;


Any here is optional.


and it will introduce the T symbol at that point based on the actual 
type of what gets initialized.


Yes. But the problem is that this does *not* fix the constraint
of $x to be T from there on! Or does it?

   my ::T $x = 'blahh';  #  ::T ::= Str

   my T $y = 'blubb';

   $x = 23; # legal
   $y = 42; # illegal

So perhaps one needs

   my ::T T $x = 'blahh';

to constrain $x to the type of the rhs.


Regards, TSa.
--

The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being.   -- Attributed to Hermann Weyl