Getting Started - Synopsis

[John M. Dlugosz]

I've read copies of the Synopsis documents that I've found on the web 
somewhere.  How do I synchronize with the life copies, and hack on them?

--John

Getting Started - What to try?

[John M. Dlugosz]

I've installed the Win32 build of Pugs, but is appears to be incomplete.  How 
do I get the "real thing"?  I've also heard that Pugs is in stasis, so is this 
still a good way to write stuff and learn today?

Likewise, how do I get synched up with the Parrot implementation?  I understand 
the most official grammar is being developed there.  Is there a grammar-checker 
tool that will help me to validate proposed Perl 6 code fragments, even if I 
can't execute it yet?

In general, what are the various repositories and version-control systems used? 
 What ought I install and get working to join up with the Perl 6 community?

--John

S02 questions and comments

[John M. Dlugosz]

I'm reading S02.pod with version information:
  Last Modified: 17 Mar 2008
  Number: 2
  Version: 130

Meta-question 1: what is the succinct way to report this?  Is the "Version 130" 
enough?

Meta-question 2: Does this belong on a different mailing list?  I'm also 
including the documented file maintainer as a direct recipient.

3: I copied the file from  
which I'm told is the up-to-date home.  When I ran pod2html, I got a warning 
that 'encoding' is an unknown directive, and also see that the HTML title is 
simply "TITLE".  Do I need a special version of pod2html, or how do I run it 
properly?

4: "Whitespace is not allowed between a variable name and its subscript. 
However, there is a corresponding dot form of each subscript"
The use of "however" looks like it is meant to imply that the dot form allows 
you to add space.  I think this wording is leftover from the "long dot" 
explanation, but now is out of place.  I suggest dropping the "However," from 
the sentence.

I'm also wondering, in general, why we still have the dot forms of the 
subscripting (and other postfix operators) when the long-dot has been replaced 
by the unspace concept.  

--John

S02 questions and comments - unspace

[John M. Dlugosz]

"Any contiguous whitespace (including comments) may be hidden from the parser 
by prefixing it with \. ... using unspace lets you line up postfix 
operators:"

%hash\  .{$key}
@array\ .[$ix]
$subref\.($arg)


What does the dotted form have to do with this?  It just confuses the example.

%hash\   {$key}
@array\  [$ix]
$subref\ ($arg)

Then, explain that 

"the dotted form can further help line up on arbitrary boundaries, since 
the unspace requires at least two characters.  If you need to shift the postfix 
over by only one character, use a dot.

%hash\ {$key}
@array.[$ix]
$subref($arg)

If you wish to use dots on all the lines for consistency, you might end up with 
something like:

%hash\  .{$key}
@array\ .[$ix]
$subref\.($arg)

As a special case to support this, a backslashed dot where a postfix is 
expected is considered a degenerate form of unspace. 
ORIGINAL TEXT CONTINUES



"Whitespace is not allowed before the parens, but there is a corresponding .() 
operator, plus the ``unspace'' forms that allow you to insert optional 
whitespace and comments between the backslash and the dot:"

The dotted form is not required to use unspace to insert optional whitespace.  
State that this is the same as the deal with subscripts, and xref the thing I 
opened this note with.

-

MyType\ .::\ .{'$foo'}  # same thing with unspaces


That is the same thing with unspaces AND dots.

MyType\ ::\ {'$foo'}  # same thing with unspaces

could be added to the list, right?

--

You can also use the :key($value) form to quote the keys of option pairs. To 
align values of option pairs, you may use the ``unspace'' postfix forms:

:longkey\  .($value)
:shortkey\ .
:fookey\   .{ $^a <=> $^b }


Same thing - that is using unspace AND using dots.


:longkey\  ($value)
:shortkey\ 
:fookey\   { $^a <=> $^b }


--

I think that concludes my "unspace rant".  That is, my confusion on reading the 
S02 on unspace being linked with dots, I presume to be documentation relics and 
I recall a much earlier discussion on "long-dot" which did link the concepts.  
Proceeding on that assumption, I constructively noted the offending passages 
and suggested changes in the text.

I hope that helps the effort, as well as my own understanding.

--John

podhtml.pl

[John M. Dlugosz]

> From: Agent Zhang
> IMHO pod2html is old and broken in various ways. I think you should
> use the tools provided by Pod::Simple instead. For the Synopses on
> feather, we're using the podhtml.pl script (based on
> Pod::Simple::HTML):

> http://svn.pugscode.org/pugs/util/podhtm.pl

> Hopefully you may find it useful :)

> Cheers,
> -agentzh

Thanks, that works.  I tweeked the style sheet to use preferred fonts, and also 
this tip I'd like to pass along:

CODE:hover {
background-color: yellow;
}

That makes it easy to isolate a code fragment from the surrounding text, 
especially when it is followed by punctuation belonging to the sentence.  It 
only highlights when I mouse-over it, and is otherwise non-intrusive.

--John

--
Protect yourself from spam, 
use http://sneakemail.com

Question on your last change to S02

[John M. Dlugosz]

 The context in which a subscript is evaluated is no longer controlled
 by the sigil either.  Subscripts are always evaluated in list context.
+(More specifically, they are evaluated in a variant of list context
+known as I context, which preserves dimensional information
+so that you can do multi-dimensional slices using semicolons.  However,
+each slice dimension evaluates its sublist in normal list context,
+so functions called as part of a subscript don't see a slice context.
+See S09 for more on slice context.)


So a function can only supply values for one dimension?  Given
  @array[foo;bar]
each function is called in list context and returns a list for one of the 
dimensions.  But what if you wanted a function to replace the literal subscript 
in:
  @array[1,2;1;3]
  @array[foo]  # what does foo return to be equiv to the first line?
My guess is that I could write
  @array[@@ foo]
or in a mixed example
  @array[1;@@ foo;2]  # foo returns (1;1)

In any case, examples such as these would help.

--John

Buf/Str conversion functions

[John M. Dlugosz]

In S02, "If a buf type is initialized with a Unicode string value, the string 
is decomposed into Unicode codepoints,...If any other conversion is desired, it 
must be specified explicitly."

In S29, there is nothing about functions in Buf, and nothing about functions 
that convert or initialize Str.  Just where would this be, anyway?  The concept 
of "initialization" is not a strong concept distinct from assignment like in 
C++.  Any relationship between using the class name as a typecast, or defined 
assignment operators, is not specified (unless I overlooked it in a Snn I've 
not studied in detail yet).

Anyway, I expect to see a function using Buf as a list operator that takes a 
Str, or an assignment operator with similar parameters, that also takes named 
parameters as conversion and error options.

In whatever form, is anyone working on the definition of these functions?  
That's something I might work on, having been bothered by issues with existing 
conversion functions.

In any case, would an example look something like this:
   my Buf $buf = $str :size(32) :precomposed :err(\&callme);
where the adjectives are applied as arguments to the assignment operator?

Or would it require calling Buf.new?  Or is there a pre-defined relationship to 
the arguments taken by .new and the assignment?

--John

muse on Compact Structs, pack/unpack

[John M. Dlugosz]

#[ are there people paying attention to these issues on other mailing lists? ]

= on Compact structs
revision 1, initial posting

What functions serialize/deserialize to the C view?

If these are to be member functions, they would be applicable only if the 
struct is compact, and erroneous to call otherwise.  It seems like a compact 
struct ought to have a role supported for that purpose, and to make a compact 
struct you declare that role.  This would then allow the compiler to check at 
compile-time that all the properties were indeed native types, things also 
supporting the compact role, or declared to be non-state data.

Any class could be forced to be compact regardless of contents if it explicitly 
supplied the serialization functions.  

There are some cases where a memory layout can be variable, such as a 
polymorphic type.  The top-level class can read just the first few bytes, 
determine the correct variant, and create an instance of that.  The class would 
hold a pointer to the variant, and not appear to be a compact struct, except 
for the custom logic implemented in the pack/unpack functions.

A structure may be variable length, having a length-prefixed string or other 
array, immediately followed by other fields.  Having a @list of things as an 
attribute would normally render it non-compact, but it could have other 
properties attached that tell it how to read/write that list, in the spirit of 
IDL.  If nothing is available that work in this case, then attaching a custom 
reader/writer property to just that attribute would do the trick, something 
sourly missing in systems such as .NET Serialization.

class example_record 
   does Compact 
   is finalized
   {
   has Str $.name
  is rw
  should serialize (:length_prefix(2), :encoding(UTF16), 
padding => {:char("\0", 
:strip} );
   has int16 $.val is rw;
   has Str $!presentation_cache;  # private, not included in compact 
struct I/O
   method presentation () returns Str
  {
  unless defined $!presentation_cache {
 ... # compute it
 }
  return $!presentation_cache;
  }
   }

I'm not entirely sure from S12, so I'd like confirmation on this:  The 
availability of trait 'serialize' is a role nested inside role Compact, so it 
is available (with this meaning) in this scope.

My example uses a mundane int16, which knows to pack/unpack as 2 bytes.  But it 
also has a length-prefixed string, which is explained using the trait, so the 
class as a whole is still able to pack/unpack.  It also has private data, which 
by default is ignored by the pack/unpack logic and does not interfere with its 
ability.

This is what I envision for a class that can take the place of pack/unpack in a 
declarative way.  I've used pack/unpack for disk-based records and wished that 
the P5 ability was extensible to my own codes to go with already-defined 
packable structures.  I've also used .NET serialization and found its 
declarative ability to be lacking to the point where it is often easier to 
write the function from scratch.

Meanwhile, how do I use it?

my Buf $temp = $record;
$stream.print ($temp);

$stream.print (Buf $record);

That is a bit baroque.  Two issues here: is 'print' still the only way to 
output?  I think 'print' would convert all arguments to string form, so 
printing an int16 would format the number into text.  It also deals with 
encoding issues.  Printing a Buf would seem to turn that Buf back into a Str 
using all the rules set up for that.

So how about a binary output function, 'write'?  It will imply binary output, 
so knowing this can help hide the differences between text/binary on platforms 
that have it.  It will convert its arguments to Buf by default.

$stream.write ($record);  # just what I need

my int16 $x = 42;
$stream.write ($x);  # emits 2 bytes, exactly as stored in the primitive
$stream.print ($x);  # emits characters "4" and "2" in the proper 
encoding

So as mentioned at the start of this muse, where do the functions live?  It is 
stated that the type name used as a listop is a conversion function.  Is that 
special syntax that knows to look for some way to accomplish that?  I'll 
proceed on this assumption, and basic C++ ideas as a strawman, that it looks 
for things in each of the two classes (coming and going) and built-in rules, 
perhaps a chain of things.

Suppose that one of the places it looks is 

multi conversion: () { ... }

that can take adjectives to control the conversion, or additional positional 
arguments.

This is supplied by the Compact role, whose implementation handles common 
adverbs and invariant logic.  But it calls another function, pack, for the 
basic packin

Re: muse on Compact Structs, pack/unpack

[John M. Dlugosz]

Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote:  

$stream.print (Buf $record);

> $stream.print($record.pack) # I would think?

Thank you so much for the reply.  I was beginning to wonder if Perl 6 
interest is dead, or if there is another secret lair for current 
enthusiasts that I'm unaware of.


A .pack member function on a Compact struct is indeed my first gut 
feeling, but at the end of the section he states specifically that 
packing is triggered by coercing  to a Buf type.


Since nothing is sacred, I would propose that .pack is more sensible as 
the basic mechanism, to be used when doing this explicitly.  And a 
conversion operation to Buf can be provided that simply calls .pack().


--John

Re: muse on Compact Structs, pack/unpack

[John M. Dlugosz]

I take that as encouragement, and confirmation that this is the right 
place to post (and archive) my musings.  HOPEFULLY I can get questions 
answered too.


I credit the success of C++, in part, to Stroustrup's personal training 
of the first gurus.  He would explain things that made me see the 
underlying principles, and "the way" of C++.  Eventually I was given 
early drafts of the 2.0 spec, and I had a talent for spotting 
inconsistencies in the technical docs.  My commentary and feedback 
contributed to the eventual published ARM, and the first year of the 
ANSI process.


Having done that before, I find the Perl 6 technical docs to be in 
relative disarray and imprecise.  A sticking point such as the subscript 
question really bugs me and I have a hard time moving forward.  An 
answer of "not sure; that section needs work" is fine, with or without 
"what do you propose?".


I'm on a sabbatical now, and learning Perl 6 is one of my priorities.  I 
was hoping to accomplish more during my month in China, but had less 
down-time then feared.  But I caught up to the current S\d\d files and 
started organizing my wetware.


I have other "musings" I've filed away, thinking it may clear up some as 
I integrate the other documents and discussions in the archives, and 
because I don't want to overload the discussion board.


So excuse my manic period; posting around the clock is due to jet lag.  
I hope my "fresh eyes" and analysis can make a contribution.  But I 
don't want to re-invent something that is already done, so please steer 
me in the right direction when I'm NOT exploring the frontier but have 
merely missed the path.


--John
(literally not sure if it was AM or PM; wife laughed when I asked for 
pancakes)



Larry Wall larry-at-wall.org |Perl 6| wrote:

On Tue, Apr 01, 2008 at 12:25:50PM -0500, John M. Dlugosz wrote:
  
Thank you so much for the reply.  I was beginning to wonder if Perl 6 
interest is dead, or if there is another secret lair for current 
enthusiasts that I'm unaware of.



Sorry, many of us have to live under budgetary constraints of time
and health and energy (not to mention money), and we'll need just
a bit more advance notice if we're to schedule our vacations and/or
manic periods to coincide with your current productive period.  :)

'Course, if you happen to know any billionaires who want to drop a wad
on our sorry society, I'm sure we can all figure out a few ways to use
money as a proxy for other forms of happiness...

Personally, my brain is rather occupied with a Hard Problem at my
$dayjob, not to mention thinking about Longest Token Matching and Taxes
and Family and Church, and all the Speeches I'll have to give in the
coming few months if the Doctors don't lock me up Somewhere Safe...

In general, however, I do eventually get around to thinking about
topics raised on this mailing list.  But I do not have an ADHD brain,
and switching topics is a high-overhead activity for me, so I prefer
to think about things when I have enough time to think about them
thorougly.  Long treatises particularly take a while to digest, so
to the extent that you have been splitting things up into separate
topics, I appreciate it greatly.  It also helps me keep track of
which bits I've responded to and which I haven't yet.

I admit that I also like to sit back and let other people pick the
low fruit so I don't have to spend time doing it.  Over the short
term, sometimes what I do looks an awful lot like doing nothing... :)

Larry

  

"our" methods?

[John M. Dlugosz]

In S29, there are definitions like

   our Capture method shape (@array: ) is export

But in S12 there is no mention as to what an "our" method is.  It states that 
"my" is used to make private methods, and "^" to make class methods.

I think this is a doc relic and should be fixed globally in that file.

Re: Question on your last change to S02

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

Now my question: could slice context be a runtime feature that acts
before the dispatch to &postcircumfix:<[ ]> by retrieving the shape
of the @array and handing it over to &foo as context, capture the
shape of the slice returned and hand over the remaining shape as
context to &bar? Since relying on the order of &foo and &bar in the
source is bad, an even more elaborate scheme can be used that queries
&foo and &bar before the actual call which slots they intend to fill
in the pending slice operation.


The plot thickens!

Consider the user-defined index translation functions, or the 
differential indexing feature.  Both use * inside the subscript.


If you have

   @array[$a;*-2;$c]

the * has to know to map to a function to retrieve the length of the 
proper dimension.  If it can't count semicolons at compile-time, it 
can't rely on parser magic and it has to call a function at run time.  
Forget the funny syntax, and what we're really looking at is:


   @array[ $a ; dimlen() - 2 ; $c ]

Even if you want to be charitable and say the parser actually expanded 
the * to


   dimlen (@array)

(without re-evaluating the expression if the array is not a simple 
variable name), then it still doesn't know what position it is in.


Just off the cuff, I think it might use the array target and index 
position as context variables, or to save the overhead of always setting 
those, another magic syntax inside the subscript could be used to 
indicate its own position.  So, the * expands to:


   dimlen (@array, $?SLICEPOS)

and this makes it clear how to call your own functions thusly.  So you 
could write


   @array[ @@(foo(42)) ; bar(@?SLICETARGET, $?SLICEPOS) ; $baz ]

and it would supply the proper value after knowing how many dimensions 
were returned from foo in slice context.  The use of @?SLICETARGET 
allows you to refer to the @array even if it is the result of an 
expression, without re-evaluating it, or worse if it is a return value 
or temporary object.  It would be handy to have when writing a macro. 

Hopefully, the grammar for implementing * in subscripts is clean enough 
that you could write a macro that did something similar for your own 
construct.  There should be no magic that is not available to the 
programmer as well.


--John

S09 editorial fixes

[John M. Dlugosz]

I just finished another pass on S09, and in this posting I note editorial 
issues with the file that can easily be corrected.  This is as opposed to 
subjects for deep discussion, which I'll save for later and individual posts.

= on Mixing subscripts
"Within a C<.[]> indexing operation..."
Why the dot?  The examples don't use a dot, and this makes it sound like the 
dot is involved and that is confusing.  I see that C<.{}> was also mentioned 
earlier.  

= on PDL support

The term "PDL" is never defined.  A one-sentence introduction and href would be 
nice.

I first encountered it elsewhere in the docs, and did not know what it was.  I 
found it quickly on Wikipedia.  So to be more constructive, I'd suggest,

"PDL (Perl Data Language, see 
L) is an extension in Perl 5 
with a significant user base.  The following sections discuss how PDL may look 
in Perl 6.  This may inspire certain support in the core language, and at least 
shows what needs to be possible to achieve in an extension."

= on The semicolon operator

"Another thing that's not going to fly easily is simply dropping out terms" 
to the end of the section.

That is out of place.  The transition is wrong, and it does not express 
something that is unique to this topic.  I think it is a relic.

= on Parallelized parameters and autothreading

use autoindex;
do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] };

Shouldn't those be semicolons?  Ditto for subsequent examples.
Also, what does the "do" do?  I think it is only meaningful if there was 
something using this block's return value.  I suspect it is a relic of p5 
notation.

= on Autovivification

"Note that assignment implicitly binds a copy..."
Does assignment do binding?  I thought it would change the value in the 
existing container using its assignment function, not create a new container!  
Is this just poor wording?

Yes, the same section concludes, "Assignment doesn't look like binding, but 
consider that it's really calling some kind of underlying set method on the 
container, which must be mutable in order to change its contents."

I suggest changing to read "implicitly makes a copy..."




--John

Re: "our" methods?

[John M. Dlugosz]

I understand. Thank you.

This ought to be mentioned in S12. Perhaps after the treatment on "my",
explain that "our" is the default, but saying it explicitly allows the
return type to be first.

--John

Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:
> John M. Dlugosz 提到:
>   
>> In S29, there are definitions like
>>our Capture method shape (@array: ) is export
>> But in S12 there is no mention as to what an "our" method is.  It states 
>> that "my" is used to make private methods, and "^" to make class methods.
>> I think this is a doc relic and should be fixed globally in that file.
>> 
>
> S02/"Return types":
>
> "
> If a subroutine is not explicitly scoped, it belongs to the current
> namespace (module, class, grammar, or package), as if it's scoped with
> the C scope modifier. Any return type must go after the name:
> "
>
> So this line:
>
> our Capture method shape (@array: ) is export
>
> is really the same as:
>
> method shape (@array: ) of Capture is export
>
> The prefixing of "our" is there to make the return ("of") type stand out.
>
> Cheers,
> Audrey
>
>
>   

Re: muse on Compact Structs, pack/unpack

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

On Tue, Apr 01, 2008 at 09:27:48PM -0500, John M. Dlugosz wrote:
  
Having done that before, I find the Perl 6 technical docs to be in relative 
disarray and imprecise.



Indeed, I welcome all the help I can get on making things more precise.
My own tendency is to emphasize vigor over rigor, so I welcome any
balance on that score.  And please don't be discouraged by any of my
traditional morning grumpiness.  I don't need a jet to get jet lagged.  :)

Larry

  
During ANSI/ISO standardization, they basically took every phrase and 
made it more and more exact.  It went from understandable to leagaleze 
over a period of years, with sentences growing more and more detail.  I 
could still follow it having come to it gradually.


Hypertext could remedy that. 


--John

Re: S09 editorial fixes

[John M. Dlugosz]

Regarding the text just before where you rewrote,

then the compiler adds defaults for you, something like:

-> $x = @foo.shape[0].range,
   $y = @foo.shape[1].range { @foo[$x;$y] }

where each such range is autoiterated for you.

That doesn't really work. If you used these defaults instead of
autoindex, with a real example like

-> $i, $j, $k, $l { @c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l] }();

the same Range object is used in all occurances of the variable.

As an aside, the use of a Range value in a subscript that is written as
a simple scalar variable will make a mess of the compiler's determining
that it was supposed to be a single value not a slice! I think it would
not turn into a list but would fail as not being a number. In any case,
if * worked between lists as returned by the slices, it would not do
anything like the implied iteration would do, and it would not be
stuffed back into the @c in any semblance of an answer.

So, the example of @foo[$x;$y] is pointless, and saying that it uses a
Range as the default does not illustrate what it really means.

So, (1) use an example that has the salent features of a dependant and a
defining occurance of the index; and (2) show (near) equivilent code
that is correct.

My stab at it: (please check)

"
-> $x, $y { @foo[$x;$y] = f($x)[EMAIL PROTECTED] }

becomes

for @foo.shape[0].range Z @foo.shape[1].range-> $x, $y { @foo[$x;$y] =
f($x)[EMAIL PROTECTED] }

where the iteration limits on the variables are determined by their use
in subscripts. For the exact rules of which subscript usage is deemed to
be the defining occurance, see the PDL docs.
"

I have more thoughts on this feature, but I'll save it for later. I
think it will jell more after I digest some of Larry's posts today.

--John



Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:
> John M. Dlugosz 提到:
>
>   
>> = on Parallelized parameters and autothreading
>>
>> use autoindex;
>> do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] };
>>
>> Shouldn't those be semicolons?  Ditto for subsequent examples.
>> Also, what does the "do" do?  I think it is only meaningful if there was 
>> something using this block's return value.  I suspect it is a relic of p5 
>> notation.
>> 
>
> No, something more subtle is going on -- the "do STATEMENT" notation
> sees a stand-alone block in statement position, so it's automatically
> called with no arguments.
>
> Here is a rewrite of that section starting from line 1044 onward.
> Sanity-check before I check it in?
>
> "
> In the abstract (and often in the concrete), this puts an implicit
> loop around the block of the closure that visits all the possible
> subscript values for that dimension (unless the parameter is actually
> supplied to the closure, in which case the supplied value is used as
> the slice subscript instead).
>
> This implicit loop is assumed to be parallelizable.
> So to write a typical tensor multiplication:
>
> Cijkl = Aij * Bkl
>
> you can simply call a closure with no arguments, allowing the C
> pragma to fill in the defaults:
>
> use autoindex;
> -> $i, $j, $k, $l { @c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l] }();
>
> or you can use the C syntax to execute a stand-alone closure,
> which also implicit loops:
>
> use autoindex;
> do -> $i, $j, $k, $l {
> @c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l]
> }
>
> or even use placeholder variables instead of a parameter list:
>
> use autoindex;
> do { @c[$^i; $^j; $^k; $^l] = @a[$^i; $^j] * @b[$^k; $^l] };
>
> That's almost pretty.
> "
>
>
>   

Re: S09 editorial fixes

[John M. Dlugosz]

Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:
>
> I guess the wording in the last parenthesized parens is insufficiently
> explicit, and maybe we should change it to say that it's really a syntax
> error to use placeholder blocks in statement positions.  Sounds reasonable?
>
> Cheers,
> Audrey
>   
Looks like it's already been processed, but I agree. If you have a block
that is not executed immediatly and is not being assigned to anything
either, that is always a compile-time warning. If your variables are
typed and you get a Code where you expected a result, that would be a
compile-time error since it knows the types never match.

And finally, the case of making a block "not bare" by using
placeholders, but not be used in a situation where they could be bound
to anything and then called (including the subsequent examples of suffix
loop statement modifiers) should be an error. So saying it is wrong in
statement position is not accurate, since there could be loop suffixes.

--John

Re: Question on your last change to S02

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

Now, you'll ask how *-2 works.  If you do math on a Whatever object,
it just remembers that offset until the Whatever is given a meaning,
which, in this case, is delayed until the subscripting operator
decides what the size of the next dimension is.  At a lower level than
the subscript it probably ends up being some kind of a fallback
multi that binds to a Whatever type for that dimension, as the
subscripting operator processes through each dimension in its @@ array.
Or maybe it's just a case in a switch.  In any case, the subscriptor
knows the next "top" dimension, so it can know the size at that point.

  


I see.  The *-2 isn't resolved to a number right away, but evaluates to 
a "whatever-2" object, that is passed.  The subscripting implementation 
knows what is going on when it gets to that.


That means that ordinary uses will not require knowledge about the 
dimensions and context, as it is handled all inside the subscripting code.


But constructs that generate loops around that expression will have to 
know.  This certainly includes the autoindexing thing being discussed in 
another thread.  But I'm also thinking of junctions.  Junctions thread 
through the subscript, it is writ.  A junction, like a range, can use * 
for an endpoint, can it not?


Writing  @foo[$x;2..*;$y] >>*<< blah blah
will serve up the slice first, using the mechanism described above.  But 
the similar

$n=all(2..*); @foo[$x;$n;$y] * blah blah
is described as creating a loop around the * operator.  I guess it would 
convert to the first one and see what the subscripter gave back?  Is 
that still possible if multiple junctions are present?


--John

Re: Question on your last change to S02

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

At compile time the subscript parser really only knows how
many dimensions are referred to by how many semicolons there
are.  A subscript that is explicitly cast to @@ is known to be
multidimensional, and interpolates the returned List of Capture into
the outer List of Capture, and the compiler can make no compile-time
assumptions about how far down the dimension list any subsequent
dimensional sublists will end up.

  

What I still want to know is:
When does .[] provide a single item, rather than a list (a list that 
might contain only one item)?


   $x = @array[$n];   # I expect $x holds the single result, not a list 
of one item!

   $x = @array[foo()];  # what about now?

--John

S12 edits on Methods

[John M. Dlugosz]

"If you declare an explicit invocant for an Array type using an array 
variable..."
Suggest:
"
The invocant may be given a sigil other than the C<$> "item" sigil using the 
same rules as binding variables to class types as described in S02 under "Names 
and Variables".  For example, if the class does the C role, it may 
be declared with the C<@> "array" sigil.

Naturally, declaring an explicit invocant for an Array type lets you use it in 
the usual way, such as using it in list context to produce its elements.
"

The word "self" is described as a keyword and as a function.  Be stronger about 
defining it.  I suggest,
"
Within the lexical scope of any method, the C keyword behaves as a 
function that returns the invocant in item context.  It is improper to use this 
pseudo-function in any manner other than to call it directly.  In particular, 
an implementation is not required to support taking a Capture to the function.  
Note, however, that you may I it from a closure.

Also note that, as is usual with Perl, the existance of keywords do not 
preclude the use of identifiers with the same name.  Although this is usually 
considerd bad form to make a variable named C<$if>, defining your invocant to 
be C<$self> is not deemed to be in bad taste.  However, defining C<@self> (or 
other sigil forms other than item) could indeed confuse someone reading the 
code, and is discouraged.
"

Per conversation with Audry, I suggest adding the following before "Private 
methods are...".

"
Methods, like any other kind of C, behave as if defined with C by 
default, if no scope modifier is used.  This is described in S06 under "Named 
subroutines".  However, it may be desirable to use the C keyword 
explicitly, as it offers the ability to put the return type before the method 
name, in the C style.
"

Conceptual questions about Objects

[John M. Dlugosz]

After reading S12, I have many many notes about things that need to 
be tightened up or places that open more questions then provide answers.


But, a lot of it boils down to a core set of issues.  Can y'all explain 
these to me?  Help me see the core concepts, and I can work out the 
details and submit draft text back for review.  So consider answering 
this for me well as an investment .


A method can refer to private attributes etc. in other objects than 
self.  This is unlike Smalltalk and like C++.  Which objects?  
Obviously, those that _have_ them in the first place.  Does the variable 
used as the invocant, or return value if it is an expression, have to be 
statically typed as being of the identical class?  Or does it apply that 
constraint implicitly at run-time?  If the former, note that in C++ it 
must be the identical class, NOT a derived class, even though that is 
simple to work around, because that is a conceptual point.


If class C { has $.a; ... }, then I understand that members may refer to 
$.a directly but outside of the scope of members defined in the class 
they can only be reached by accessors, a() as a method call.


But, it is also stated that in derived and trusted classes, and even in 
the class itself, $.a is an accessor call?  As opposed to $!a which is 
the direct access to the attribute.  Is this accessor different from the 
function form used outside the class?  Why keep the variable syntax?


I'm getting a picture of 3 forms of access:  Really direct, direct but 
asking the class to access it rather than knowing how storage works, and 
indirect that may involve your own code to do other things besides just 
get/set the attribute.  But I think the middle one can be handled 
invisibly by the compiler -- it's no different from a tied hash.


How private is private?  I wonder if what you've called private things 
are really more like "protected" in C++ (accessible by the derived 
class) and that 'my' attributes are really private, as are submethods.  
It's all confused.  Who is allowed to access what?


Meanwhile, I'm concerned about lvalue subs as rw accessors, but I'll 
table that for now.


--John

Re: Conceptual questions about Objects

[John M. Dlugosz]

chromatic chromatic-at-wgz.org |Perl 6| wrote:

It shouldn't be.
  

So you are saying that in the example of

   class C {
  has $.a;
  method a ($self:)
 {
 side_effect();
 return $self.a;
 }
  } # end C

   class D is C {
  method foo ($self:)
 {
 # ...
 $x = $self.a;
 # ...
 }
  } # end D

that the variable-notation access in foo will call the explicit accessor 
method C::a?  I suppose the use of $self.a in method a would be an 
infinite loop, and must be $self!a to work.


In that case, why allow the variable-name form at all? 

Why keep the variable syntax? 



Uniform access principle.  See also "Why Java programmers fetishize their 
IDEs, reason #482: autogeneration of metric boat-loads of accessors/mutators 
at just the click of a button."


  
That seems to be saying that using the method-call form is preferred, as 
it abstracts whether it is a real hard attribute or not.  Since my 
question was why keep the variable-name form, I think we are not 
understanding each other.




I'm getting a picture of 3 forms of access:  Really direct, direct but
asking the class to access it rather than knowing how storage works, and
indirect that may involve your own code to do other things besides just
get/set the attribute.  But I think the middle one can be handled
invisibly by the compiler -- it's no different from a tied hash.



That really depends on how much external syntax you want to change if you 
change the internal representation of an object.  For me, that's 
approximately none.
  
I don't understand that sentence at all.  Again, "invisibly by the 
compiler" sounds like what you want. 

Re: Conceptual questions about Objects

[John M. Dlugosz]

Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:

John M. Dlugosz wrote:

A method can refer to private attributes etc. in other objects than
self. This is unlike Smalltalk and like C++. Which objects? Obviously,
those that _have_ them in the first place.


Correct, though those classes also has to trust the calling class:

class MyClass { has $!attr; trusts YourClass }
class YourClass {
method foo (MyClass $obj) {
$obj!MyClass::attr; # Access to $obj's private attr
}
}

So, do classes trust their derived classes by default?  Is trust itself 
inherited?


In this example, as in S12, why do you have to specify the MyClass:: 
prefix?  I thought you would only need this to refer to a specific class 
in the ISA list and not necessarily the one defined in or visible in the 
declared class.


That is, a derived class, assuming it was trusted, could use 
$self!BaseName::attr to prevent confusion with something named self!attr 
that ordinarily hides it.


And a syntax question for you:  Above, I just assumed $self is the 
explicitly-named invocant.  How do you access the attribute if using the 
self keyword, which does not have a sigil?  If it has $!attr and has 
@!attr, that is important.  I realize this is not an issue when using 
method calls (including accessor functions) on self.



Does the variable used as the invocant, or return value if it is an 
expression,

> have to be statically typed as being of the identical class?

The $obj above must be evaluated to an object of class MyClass.

AFAICS, the spec doesn't really say if a derived class needs to 
explicitly trust YourClass for it to be used this way:


class MyDerivedClass is MyClass {};
YourClass.foo(MyDerivedClass.new(attr => 1)); # Not sure if this works.
"the spec doesn't say"  hence my confusion.  So will Larry rule on that, 
or should we discuss it in detail, or should I just make up something in 
my proposed doc edit?


If your example does work, it means that in general the BUILD can comb 
arguments out for each class in the hierarchy, rather than only being 
allowed to specify arguments to defined constructors for the base 
classes, as in C++.  Is that good or bad?  Just how would you say the 
latter, anyway?



If class C { has $.a; ... }, then I understand that members may refer to
$.a directly but outside of the scope of members defined in the class
they can only be reached by accessors, a() as a method call.


Well, $.a is exactly the same as $(self.a) -- see S12/"are just 
shorthands of C" for the definition.


Methods in class C may call $!a, which is the private accessor method.
Outside the scope, private methods of class C are invisible.

OK, I think I'm beginning to see. 
$.x is not "variable-like", but a shortcut for $(self.x()), and always 
is.  You don't name an object with this form, ever, as it only works on 
self. 

That is why the ! forms don't have a "unary form".  It could certainly 
be explained better in the document.  Your retelling is already helpful.





But, it is also stated that in derived and trusted classes, and even in
the class itself, $.a is an accessor call?


Well, $.a is merely shorthand for $(self.a) so derived classes can 
call it just fine.  However in trusted classes, $.a wouldn't make much 
sense,

as you need to use either $obj.a or $obj!YourClass::a there.


Is this accessor different from the
function form used outside the class? Why keep the variable syntax?


Because it's jolly convenient, especially in interpolated strings, I 
suppose:


say "My position is $.x - $.y - $.z";


I'm getting a picture of 3 forms of access: Really direct, direct but
asking the class to access it rather than knowing how storage works, and
indirect that may involve your own code to do other things besides just
get/set the attribute. But I think the middle one can be handled
invisibly by the compiler -- it's no different from a tied hash.


The middle one is not that different from the first one, because from 
an implementation viewpoint, once YourClass trusts MyClass, then code 
in MyClass might as well have knowledge about how the storage works.

But it looks like there is no middle one.

Besides "how the storage works", I'm thinking of the multiple-base 
composition issues.  The attribute may be stored in different places 
depending on the concrete type, and the method is called on a type 
derived from the one it is written in.





How private is private? I wonder if what you've called private things
are really more like "protected" in C++ (accessible by the derived
class) and that 'my' attributes are really private, as are submethods.
It's all confused. Who is allowed to access what?


No, private methods are not accessible from derived classes, unless 
the base class explicitly trusts them -- See L12/"the exclamation form 
may be used only in the actual class, not in derived classes".


Cheers,
Audrey

Re: Conceptual questions about Objects

[John M. Dlugosz]

Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote:


A method is defined within a role or class, as is an attribute.  A 
private attribute can generally be referenced only by a method 
declared in the same role or class as said attribute.


I think that's not right.  A private attribute defined in a role becomes 
a private attribute of the composed class, so may be referred to from 
other roles or the main class definition.  In contrast, a "my" variable 
inside the role is private to that role's block.  Though it is put into 
the object's attribute list (the scope is per-instance), it has no name 
outside of the block.



A method can reference its own role's/class's private attributes for 
any objects of that role/class, regardless of whether said object is 
the current method call's invocant or not.

OK, taking "class" only, not "role".




If a role or class is composed into another class or is subclassed, the
(for example) subclass can not reference the private attributes of its 
parent class.


As an exception to the above, if a particular class says that it 
"trusts" a particular other class (using "trusts Otherclass;" as a 
trait), then the trusted class can also reference the privates of the 
first class.
OK, trust is not implicit on derived classes.  Is that because there is 
no rule that says it is, or is there a mention of that somewhere in the 
official docs?

Re: Conceptual questions about Objects

[John M. Dlugosz]

I understand your example.  In fact, it further clarifies your earlier note.

But that's not what I meant.  I was thinking that access was through a 
variable, not understanding the real point of the syntax.


Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:

John M. Dlugosz wrote:

That seems to be saying that using the method-call form is preferred, as
it abstracts whether it is a real hard attribute or not.


Er, it is not so.

The $.foo notation is good not only for calling accessors, but also as 
a way to specify context when calling oneself's methods.  Consider:


class Foo {
method bar ($x, $y) { ... }
method baz (
$.bar: 1, 2;
@.bar: 3, 4;
}
}

Here we are simply typing $.bar as a shorthand of $(self.bar), and 
@.bar as @(self.bar), as well as supplying them with arguments; they 
do not mandate that there exists a "bar" attribute for our class.


In other words, there needs to be no real hard attribute "bar", no 
matter if you call the "bar" method as self.bar(), $.bar(), or simply 
$.bar.


Cheers,
Audrey

Re: Conceptual questions about Objects

[John M. Dlugosz]

Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:

"Every Idiot declaration... "
Sorry, must be a font problem

Seriously,
Does this mean that the access of private attributes from trusted 
classes is a "different form"?  And that's why you need the qualified 
syntax when I think it should not be necessary in all cases?  Or should 
that passage really say "not in non-trusted classes, including derived 
classes"?


--John


John M. Dlugosz wrote:


OK, trust is not implicit on derived classes. Is that because there is
no rule that says it is, or is there a mention of that somewhere in the
official docs?


There is.  S12 Line 561:

Every I declaration also declares a corresponding private
I storage location, and the exclamation form may be used
only in the actual class, not in derived classes.

Cheers,
Audrey

Re: Conceptual questions about Objects

[John M. Dlugosz]

Ryan Richter ryan-at-tau.solarneutrino.net |Perl 6| wrote:

You've declared method a twice here. 


According to S12, "You may write your own accessors to override any or all of the 
autogenerated ones."



has $!a;
method a { $!a }

The variable is always really the $! form.

  



I'm catching on.

Re: Conceptual questions about Objects

[John M. Dlugosz]

Many thanks.

Larry Wall larry-at-wall.org |Perl 6| wrote:

self!BaseName::attr should work, assuming BaseName trusts us.

  
Because it is an accessor function, not a syntax to reference a variable 
in another scope.  Got it.


But see my q's to Audrey.  Why does it need the qualified name if the 
same class as $obj's declared type, and just how is that being parsed 
and/or implemented?



See S12:680 and following for how to pass protoobjects representing
partial construction without having to actually create intermediate
objects.

  
OK, I didn't understand what that was about when I read it.  Now I see 
it as analogous to the base/member syntax in C++.


I suppose any object would do, it doesn't have to be "but undefined", or 
created using that Class{hash} syntax?

Every class maintains its own concrete, which is of no business to
anyone else, including derived classes.  There is nothing like
protected in Perl 6.  The closest you can get to it is "trusts",
and that's independent of class hierarchy.
  
It is my understanding that even Bjarne thinks "protected" is a bad idea

these days...
  


OK, so what is the more general mechanism of providing different 
interfaces to different sets of trusted consumers?  There is the 
"protected interface" that I document to explain how a derived class is 
to extend the functionality, and it has access to things the caller 
doesn't, besides just being able to override functions.  If there is no 
special mechanism just for derived classes, I suppose you must have 
something better in mind.


For example, sometimes a particular module (namespace, whatever) might 
need a special insider interface, because they work together.  But not 
total trust like its own implementation!  Another contract, distinct 
from the public interface contract.  That's a good name for it: multiple 
contracts.  "trusted" hands out access to all private instance data, 
which is a special case.


Oh, and in C++, friendship can be granted to a function as well as to a 
class.  I suppose there is less need in Perl 6 since a global function 
can be written as a method and exported.  But consider a function that 
operates on two different objects; it can only be the method of one.  I 
don't need to make the whole other class trusted, just this one function.


Also, since classes can be re-opened, anyone can grab trust from any 
class anyway, just by declaring a new method inside that class.


--John

understanding STD.pm

[John M. Dlugosz]

OK, you got me.  What is the "¢" used for?  For example, .

I only see that character as used in this manner (a variable name?), never 
defined (e.g. as a variable or parameter) anywhere.

--John

Re: postfix and postcircumfix

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

On Wed, Apr 02, 2008 at 06:08:55PM -0700, Jon Lang wrote:
: In "Question on your last change to S02", Larry Wall wrote:
: >  (By the way, you'll note the utility of being able to talk about a
: >  postfix by saying .[], which is one of the reasons we allow the optional
: >  dot there. :)
: 
: Can I take this as an indication that the rules for postcircumfix

: operators are an extension of the rules for postfix operators?

Yes, postcircumfixes are just strange postfixes, syntactically
speaking.  Semantically they may do strange things such as behave
more like macros than operators, of course.  Certainly .() is highly
magical that way, and maybe subscripts too.

Larry
  

Magical how?

I take it that the macro-like behavior is in how the circumscribed text 
is parsed, and once that has been collected, it behaves just like a 
function call to a function named postcircumfix:<( )> etc.?


And if I create a function named postcircumfix:<[ ]> (or one of the 
others), I get the _same_ magic as normally applied to subscripts?  If 
it's a matter of defining the argument as @@ (for subscripts) or Capture 
(for function-call syntax), that's not magic. 


--John

Easy question: what is a "list comprehension" ?

[John M. Dlugosz]

What is a "list comprehension"?  I've seen that term bantered around here.

--John

STD.pm

[John M. Dlugosz]

I'm trying to fathom STD.pm.

Maybe someone can help me trace through this one?  

How is
$obj!privA = 1;
parsed?

Reading expect_term, it trys , then  sees the "$" and commits 
to the decision, reads "obj" as a , then checks for a ".", but 
doesn't have similar logic for "!".  

So it's parsed as
   $obj  !  privA


--John

Re: postfix and postcircumfix

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

I only mean that you can't simply rewrite

$foo.($bar)

as

$foo.postcircumfix:<( )>.($bar)

and think you've gotten anywhere, since you'd then have to rewrite it
again:

$foo.postcircumfix:<( )>.postcircumfix:<( )>.($bar)
$foo.postcircumfix:<( )>.postcircumfix:<( )>.postcircumfix:<( )>.($bar)
...

Something has to recognize it as a special form.

  
You lost me.  Why does it apply operator(), er, postcircumfix:<( )> 
multiple times on successive return results?




Well, it's possible the subscript itself isn't the magical part there.
At minimum, the semilist rule probably needs to recognize @@ and ** at the
top level (or @@ and ** need to recognize that they're at the top
level of a context that wants them to interpolate multiple dimensions
rather than just one).

It's also possible that even this amount of syntactic magic is evil,
but I'd like [1;**;3] to know it has an arbitrary number of dimensions,
while [1;$two;3] should know that it has exactly three dimensions even
if $two happens to contain ** or @@.
  
Your previous description of handing * in array subscripting explained 
that it was done at run-time.  From that earlier discussion, nothing in 
the parsing of the text between the brackets interacts with the declared 
properties of the array.


So, in slice context 1;$two;3 will contain 3 lists.  Even without slice 
context, a scalar variable like $two never interpolates but adds a 
single value to the list (so it is writ).  So when postcircumfix:<[ ]> 
looks at its argument at runtime, it would see [ [1], [**], [3] ], 
assuming I'm writing that correctly.  What $two happens to contain 
should not matter, or you've lot a lot more revising to do.



It's also possible I'm just nuts, and slice context should be a purely
run-time activity.

  
That doesn't mean that the standard postcircumfix<[ ]> should be defined 
to handle what it sees as ** inside one of its arguments.  Perhaps it 
should use the cardinality of its argument (a list of lists) as an 
indication of what it should do, and then if it finds something in one 
of those sublists that is not a list of indexes, it is an error.


That means if you wanted to compose the number of dimensions at 
run-time, you would have to explicitly use a construct that did the 
proper amount of flattening, e.g. [1; @@ $two; 3].


--John

What I'm Working On

[John M. Dlugosz]

I'm taking a stab at turning the S\d\d documents into a formal standard.
Going through S02, each factoid gets filed away in a developing 
outline.  I'm using a single ODT file to make it easy to manipulate the 
outline (currently mostly stubs). 

Here is an early effort to flesh out imprecise specification, and 
identify all the needed details.  I'm not worried about disagreement, 
since it is easier to edit than to compose.  But identifying and listing 
such details that need to be addressed will be my contribution, and 
serve as a straw-man for others to pick at.


Here is a sample:




--John

Re: Protected data member access considered harmful

[John M. Dlugosz]

Thom Boyer thom-at-boyers.org |Perl 6| wrote:
I believe Mr. Stroustrup's deprecation of 'protected' access applies 
only to data data members, not function members:


  Fortunately, you don't have to use protected data in C++; 'private'
  is the default in classes and is usually the better choice.  Note
  that none of these objections are significant for protected member
  *functions*.  I still consider 'protected' a fine way of specifying
  operations for use in derived classes.

  -- Bjarne Stroustrup
 _The_Design_and_Evolution_of_C++_
 Section 13.9 [Protected Members]

So I understand Perl 6 will have no protected access for data members 
(though trusted access can be used to provide a similar back door).


But does Perl 6 have protected access for methods?
=thom

I like the idea of using an interface (Role) to specify which methods 
are allowed to be accessed, for which purposes.  Add to that a way to 
write type comprehensions; i.e. "All types T such that..." and you can 
say "This abstract interface, beyond the default public interface, is 
available to types which have this type as a base class."


A less general means would be to allow trust to be transitive when 
granted as such. 


Perhaps:

   class C 
  does R1

  does R2
  is Base
  {
  does R3 :trusts(D :transitive);
  does R4 :trusts(D|E);
  is Base2 :private;   # allows virtual overrides but no "isa" 
static type

  does R5 :trusts($?CLASS, :transitive);  # like C++ "protected"
 
  method ...

  }

I think that syntax would work under the current situation, at least 
when used inside the class block.


--John

Re: What I'm Working On

[John M. Dlugosz]

TSa Thomas.Sandlass-at-


This hinges on the details how binding works. If it is pure
name lookup then you can bind only variables of equal type.
But $Larry has the idea of $x1 and $x2 being different views
of the same underlying item. E.g.

That's not at all the same kind of thing as briefly described under what 
static typing is all about and what binding means.  It looks like this 
feature would be more like a "tie" where multiple different variables 
write back to the same original. 

I'm not convinced that needs to be in the core language.  It can be done 
by programming appropriate container types, such as an aliased "item".


Can you give a pointer to where this was discussed?

--John




   $x2 = "   2.010  ";
   my Num $x3 := $x2;
   say "x1 = ($1);  x2 = ($2);  x3 = ($x3)";

prints "x1 = (  2.010  );  x2 = (2);  x3 = (2.01)". That is
the chars of the original string are preserved in the Int|Str
view but lost in the Num or Int view. The latter is also
flooring away the fractional part. Some of the consequences
are that

   $x1 ne $x2
   $x1 != $x2
   $x1 == $x3

but of course

   $x1 =:= $x2 =:= $x3

but note that after

   $x1 = 42;

we now have

   $x1 eq $x2
   $x1 == $x2
   $x1 == $x3

The Int constraint of $x2 means of course that $x2 = 'xx' is
an error, but $x1 = 'xx' is legal and *indistinguishable*
from $x1 = 0 for $x2.

   my Int $x3 := $x1 :defer; # OK, fetches checked at run-time
   my Int|Str $y3 := y1 :defer; # OK, stores checked at run-time
   my Int $x4 := $x1 :coerce; # fails at run time because actual
  # container type still wrong
   my Int $x5 := $y2 :coerce; # type check agrees at run time.
   # (The :coerce and :defer adverbs to := is proposed)

With the view paradigm these adverbs are obsolete I guess.


Regards, TSa.

failure notice

[John M. Dlugosz]

I've been working hard on re-organizing the S\d\d docs and other lore into a 
technical
specification with an outline suitable for the contents.

But lately I've done some "original work" on what strong typing means and the 
detailed
semantics of having types.

So, please take a look at section 10.4 in my document, which is my brainstorm 
on the
Failure type.

Because failure is always an option, how do you preserve strong typing as the 
promise of a
specific interface?  The S02 docs state that it is transformed into the correct 
type, in a
sentence or two.  I expanded that and fleshed it out, and dealt with another 
issue I ran
into, that of incompletely-specified types.

Please take a look.  I posted it at
http://www.dlugosz.com/files/specdoc.odt
or
http://www.dlugosz.com/files/specdoc.pdf

--John

Nomenclature Question - BEGIN etc.

[John M. Dlugosz]

Consider the words that may be used to introduce a block for a special 
purpose, like


BEGIN
END
INIT
CATCH
etc.

What do you call those?  They are not even "special named blocks" 
because that is not the block name (that already means something).


--John

Re: Nomenclature Question - BEGIN etc.

[John M. Dlugosz]

Mark J. Reed markjreed-at-mail.com |Perl 6| wrote:

Now you've lost me.  I was pretty sure that was the block name.  AIUI,
you can give arbitrary names to any block, and these names function
the same way (i.e. can be used in flow control statements), but they
also happen to control when the block is actually evaluated.

  

I might have misremembered, but i thought labels were followed by a
colon in Perl 6.  A quick scan of the docs... "

It is illegal for a provisional subroutine call to be followed by a
colon postfix, since such a colon is allowed only on an indirect object,
or a method call in dot form.  (It is also allowed on a label when a
statement is expected.) ...
foo:#   label   -- must be label at statement 
boundary.
   -- ILLEGAL otherwise
foo: bar:   #   two labels in a row, okay

My specdoc (was Failure Notice)

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

Just so you don't think this is warnocked, I'm looking at it, and
thinking about it.
Thanks.  I thought perhaps everyone filtered it out since it had a bad 
subject line.





By and large it seems to be going the right
direction, though I've naturally got a number of quibbles.
Probably each quibble needs to be a separate thread though, since
many of them will probably breed discussion.

On a larger question, I'm wondering if it's time to slush/freeze
the Synopses as historical documents and put all spec effort into
the new form (presumably as a wiki that knows how to serialize into
a document).  I don't think we have the bandwidth to maintain multiple
standard documents.  Well, okay, *I* don't have the bandwidth...

You might need to teach some of us how to write in Standardese,
however.  :)

If we did set up a wiki, we could have some of the specific language
lawyering discussions attached to the specchunk in question, which
seems like a good idea to save wear and tear on our email clients,
and to prevent recurring FAQs.

We'll probably need to exercise a modicum of control over who gets
to revise the spec.  We also probably need to have a discussion of
whether the current section outline is optimal, and if not, whether
it needs fixing now or can be simply renegotiated via wiki.

Larry

  
I was contemplating that a Wiki or other hypertext format might 
alleviate the issue of "outlining" since it would not have to have a 
unique outline, but can refer to definitions and other concepts as it 
goes, and have multiple organizing pages of links.
I'm having no problem re-arranging the outline as things suggest 
themselves, just by dragging.  I agree that a hyperdocument would render 
that moot.


Right now, since I have a "productive period" of full-time effort, I'd 
like to keep pouring stuff in myself.  And work on standard language and 
terminology by posting threads like the current one on BEGIN etc.


I'm really pulling on three straws at the same time:

1) copy every fact from the Synopses documents to the new outline.
2) flesh out things that are not explained well, have conflicts, etc.
3) state things in formal language.

The synopses combine tutorial and specification.  The spec doc should be 
specification, without "explanation" to a certain extent.  For the 
casual reader, this renders it unfathomable.  So I think explanation and 
discussion of a feature can be linked in as non-normative sections.


As a hyperdocument, there are several kinds of pages (or content on one 
physical page):

- the formal spec itself
- explanation to give an approximate understanding of what the spec 
will say

- rationale on why things were done a certain way
- commentary and feedback of any other content
- implementation notes for specific implementations

These can be clearly differentiated by style, so explanation and formal 
spec could be mixed on a page much as "literate programming" mixes code 
and comments.


Maybe we need to start identifying a documentation system that does what 
we need.


I think I can teach "standardeze" by example once I get some worked in 
there.  I never really thought about it; it just grows on you.  It's 
more like programming than essaying, is how it feels.  Vocabulary is 
important: use the correct term for the concept, watch your "will", 
"shall", etc. as that is the "programming" of the actual specification.


--John

Re: Nomenclature Question - BEGIN etc.

[John M. Dlugosz]

I've consolidated all the discussion into one reply:


>> The perldocs call them "Five specially named code blocks", The Camel 
names them individually (e.g. BEGIN block). How about phase blocks? They 
control in what phase of compilation/runtime the code runs in.



>> I don't know, "phase" sounds too specific to me.  Does the catching of an 
exception really bring us into a new phase of execution?  What about the LAST time through a 
loop?  etc.



An exception is certainly a phase-change.  Last time through a loop?  
Well, context anyway, if not phase, unless phase means "stage" in this 
instance.  Hmm, I'm starting to talk like Larry.  Bad John.



>>  Well, lessee. The Common Lisp spec calls them "situations" in the 
definition of (eval-when)...


Good pointer, not just for the name candidate, but to look at another 
formal spec to help clear up details.  If they've already been thought 
out, steal it.


>> It looks like they already have a name in S04: Closure traits

>> >> I don't know, it seems like any value might happen to both be a 
closure and have traits, which aren't necessarily these particular ones...


My feeling exactly.

>> >> As I read it, the original question was about the actual keyword 
- e.g. the word "BEGIN" - as distinct from the block it's attached to.  
Though I agree we need a general term for the latter, the name "event 
block" seems to imply that "BEGIN" et al are events, which might be ok 
or might cause confusion with more thoroughly event-driven programming 
models.


>> >> >> Hmm, maybe "control event blocks" and "control events", then...


>> How about Control Closure then?

>> syntactically speaking, 
http://svn.pugscode.org/pugs/src/perl6/STD.pm groups them in 
, just like 'if' and 'for'.  semantically speaking, i 
don't have a clever or unique name for them, other than what larry has 
already come up with.


>> It's a really good question ... But I pretty certain we should be 
using the term "block" here instead,  ... people are already used to 
saying "BEGIN block" and such.
And "traits" is also problematic; it says what they are, but not really 
what they do.
... So I think perhaps the best term for them might be something more 
like "event blocks", blocks that are called if and when a particular 
event happens. That's a more user-oriented definition.




OK, so people already want to say "The BEGIN block".  So the set of them 
are "The XXX blocks" where XXX is the collective name for those keywords.

Beware of these words as they already convey meaning or connotation:
  event  trait  ... ?

Perhaps the concept of "phase"/"stage" needs to be described in detail 
as well, in and of itself.  Then the same term can be used.


In C++ there are "phases of translation" (or is it "stages"?).  We 
already refer to compile-time vs run-time, sometimes CHECK time etc.  so 
we need a name for that semantic category.  Cue the thesaurus...


"episode" makes my short list.  An incident in the course of a series of 
events... an incident within a narrative usually fully developed and 
either integrated within the main story or digressing from it.  An 
intermediate or digressive passage.  A portion of a narrative that 
relates an event or a series of connected events and forms a coherent 
story in itself.  A passage between statements of a main subject or 
theme, as in a rondo or fugue.
Those all have allegories with the work of the Perl implementation.  
CATCH relates an event and forms a coherent story in itself.  BEGIN, 
CHECK, INIT etc may be portions of the overall series of events, or 
chapters if you will.  But a block that is written among the lines of 
the main code but put elsewhere for execution is "a passage between 
statements of a main subject."


"exigency" is interesting, but hang on to that for exception handling 
and continuations.


--John

"episodes" of execution

[John M. Dlugosz]

See my latest, in section 4.2, for a first cut on "episodes".  I took a first 
stab at formalizing all phases of translation and execution, and documented 
what was known about the episodes I knew about, especially those corresponding 
to keywords that introduce an "episodic block" (as a generalization of "BEGIN 
block", etc.  That also makes the term "non-episodic block" for a normal 
statement a perfect legaleeze example)

Just this section: 
http://www.dlugosz.com/files/2.pdf

and the full files (specdoc.pdf and .odt) have also been updated.

--John

Re: failure notice

[John M. Dlugosz]

It will always be too early, and too late.  There will always be
reasons not to do it till next year, and reasons you're hosed because
it wasn't done years ago.  Now is all we've got at the moment...

Larry

  


That's how C++ was.  The call to ANSI was hot on the heels of a 
statement saying it was not time to standardize yet!


But the ANSI/ISO committee actually because a language design, not a 
standardization/documentation effort at all.  Very unusual in that it 
invented most of what it set down.  It also took 10 years.


--John

syntax question on parameter lists

[John M. Dlugosz]

S06 shows how to define named-only parameters, "marked with a prefix :".  But 
no example shows anything more than a bare parameter name.  No type is ever 
given!

Looking through my copy of STD.pm, I'm baffled, as it seems not to take types 
in parameter lists at all.

So, is it
  method bytes ( Encoding :$encoding ) returns Int

or 

  method bytes ( : Encoding $encoding ) returns Int

?

I'm guessing that the latter would be confused with use of : after the 
invocant, and it follows that

  method bytes (Encoding :encoding($override_encoding)) returns Int

would work.

default parameters in methods

[John M. Dlugosz]

It is not specified in the Synopses as I recall, but I believe that this is 
useful enough that it must be made to work:

   method bytes (Encoding :$encoding = .encoding)
   returns Int

or even

   method bytes (Encoding :$encoding = self!encoding)
   returns Int

That is, a named-only parameter, which may be used as an optional adverb or 
extra parameter to affect details of the function, should default to a pre-set 
value inside the instance.

If this is not allowed, the beginning of the method would always have to check 
for defaults.  That should be automatic.  And it documents the situation nicely 
in the signature, without further explanation that "if the parameter is not 
supplied..."

This means that the default arguments run inside the context of the method 
call, and can do anything that you would expect from their lexical position.

--John

Re: default parameters in methods

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:


All default expressions to any parameter are defined to run in the
context that assumes any parameters to their left are already bound,
so you may safely depend on self already being set.

  


OK, so there is no technical reason why it can't work that way.

But, self the keyword is not $self the parameter (it only works "in" 
methods), and there are issues of trust.  So I need to describe it properly.


--John

Symbolic references and OUTER

[John M. Dlugosz]

OUTER::<$varname> (S06, "Out-of-scope names")
$OUTER::varname (S02, "Names")

specifies the $varname declared in the lexical scope surrounding the current 
lexical scope (i.e. the scope in which the current block was defined).


sub outersub ()
 {
 my $a;
 my $b;
 my $closure = sub {
say $a;  # OK, that's what closures do.
say $OUTER::a;  # same thing
say $OUTER::("b");  # symbolic reference
}
 my &Pascalishsub := sub ($cl)
  {
  $cl();  # CALL 2
  }
 $closure();  # CALL 1
 Pascalishsub($closure);  # prelude to CALL 2
 return $closure;  # prelude to CALL 3
 }

my $cl = outersub;
$cl();  # CALL 3


What happens?  The OUTER scope no longer exists at CALL 3.  Does a symbolic 
reference to OUTER require that the entire scope be retained, just in case?  If 
"OUTER" itself (or OUTER::OUTER::...) is symbolic, it would need to remember 
everything always, just in case.

Yet in CALL 1, the use of OUTER makes sense, and is a normal use.  This 
situation should be allowed, or you'll have a hard time describing exactly when 
OUTER may be used symbolically, since the simple description now is that all 
blocks are closures, but most can be optomized down.

Now look at CALL 2.  The situation is similar in that the outer scope still 
exists, but it is much harder for OUTER to figure out where to look.  Does this 
work?  If not, again, its hard to explain just when it should or shouldn't, 
because cases that do are just automatic degenerate forms of "every block is a 
closure".

--John

What is the "self pragma"?

[John M. Dlugosz]

In S06, "A method's invocant always has the alias self. Other styles of self 
can be declared with the self pragma."

What is the self pragma, and what are other styles of self, prey tell?

--John

quick ones on subs

[John M. Dlugosz]

In S06, a wrong word:

"Alternately, optional fields may be marked by supplying a default value. "
should be parameters, not fields.

Now here is my question:
Params are bound in declaration order, not call order, and may refer to 
previous parameters.  But what if a multi makes use of your intentional 
mechanism of having value constraints, namely the use of named subtypes.  You 
don't know if the parameter is suitable for the subtype until its value is 
known.  And the multis have their named parameters in opposite orders, or 
similar names with different contexts.  It's not supposed to process the 
argument list until after it decides with function to call.  But you also want 
a mechanism to distinguish alternatives based on values.  What gives?

--John

slurpy scalar parameter?

[John M. Dlugosz]

What is the difference between:

 sub head(*$head, [EMAIL PROTECTED])

and

 sub head($head?, [EMAIL PROTECTED])

?

The example calls it with
 head( 1,2,3,4 );

I'm thinking that there are differences that are not apparent in this example.

--John

Question (mistake?) in S06 "Multidimensional argument list binding"

[John M. Dlugosz]

The section contrasts 
sub foo (*@@slice) { ... }
sub foo (\$slice) { ... }

but he latter is never explained anywhere.  Did you mean to use | instead of \ 
in that section?

If not, what am I missing?

Re: quick ones on subs

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

What gives (in the sense of breaking) is the notion that you can do
multiple dispatch on randomly ordered arguments.  That's the main
reason we invented proto multis, so that the compiler can rearrange
supposedly randomly ordered arguments into positional slots so that
you can to multiple dispatch on them.  Other than that, we make no
promises about supporting multiple dispatch on named args other than by
excluding candidates that can't bind at all.

Larry

  


OK, I got it.

Now what about "excluding"?  Will it execute the code in the constraint 
check for a subtype to see if it _might_ bind? 

Help understanding syntax in S06 "Unpacking tree node parameters"

[John M. Dlugosz]

multi traverse ( NAry $top ( :kids [$eldest, [EMAIL PROTECTED] ) ) {

The inner signature is

   :( :kids [$eldest, [EMAIL PROTECTED] )

This starts out like a named-only parameter, 
   :xx  or  :xx($yy)
but then there is a space and an array.
   :xx @yy

I don't follow that.

Clarify "Design by Contract"

[John M. Dlugosz]

PRE/POST on methods:

"
When applied to a method, the semantics provide support for the "Design by 
Contract" style of OO programming: a precondition of a particular method is met 
if all the PRE blocks associated with that method return true. Otherwise, the 
precondition is met if all of the parent classes' preconditions are met (which 
may include the preconditions of their parent classes if they fail, and so on 
recursively.)

In contrast, a method's postcondition is met if all the method's POST blocks 
return true and all its parents' postconditions are also met recursively.
"

If the PRE blocks on the method don't all return true, it appeals to the 
preconditions on the base class of the class defining the method?  I don't get 
it.  Why would a class-level precondition override a method-level precondition? 
 Why bother defining them on the method, if they are ignored if they are false 
anyway?

--John

Q on function returning

[John M. Dlugosz]

In S06, it is explained how the parameter list to 'return' is preserved as a 
Capture.

So, what is the role of the inner and outer return types that are declared on 
the function?

'returns' vs 'of'

[John M. Dlugosz]

I don't like the assignments of 'returns' and 'of'.  I think it is easily 
confused.  I've written

foo (Int $x)
returns Int

in examples and nobody noticed.  As formal documentation, that scans right as 
the outer perceived return value type.  But no, it's supposed to be

foo (Int $x)
of Int

instead.  The returns keyword affects the implementation of the function, not 
the external contract.  

Yet, if returns is missing it uses the of value by default, but if the of is 
missing it does not give static type checking to the caller, rather than using 
the same as the returns.

Will other programmers make the same mistake?  I think it's going to be a 
problem.  It's like thinking you used strict but did not, and the compiler 
wasn't telling you things it should have.

--John

Idea: infir types of constants

[John M. Dlugosz]

Just surfing, I noticed something about the "D" programming language:

"
The types of constants need not be specified explicitly as the compiler 
infers their types  from 
the right-hand sides of assignments.


const fact_7 = Factorial!(7);
"




Now in C++, templates can be used to make function return types go along 
with their argument types, for generic arguments.


In Perl 6, I think you would have to arrange to write the return type 
later rather than sooner to do this:


  sub foo (::T $a, T $b)
  is of T

and writing it the other way around would violate the one-pass parsing.

So, how would you write the constant above in Perl 6, without knowing 
specifically what foo returned?  I'm thinking of a situation where you 
have foo as a method of a generic class, or otherwise depends on a 
generic type parameter already.  But, it could be an expression not just 
a function call, and depend on the generic types present in outer scopes 
in a less-than-simple way.


  my Type $x = $a ⊗ $b;

With C++, I would have to hope that the template writer thought to give 
the return type of that function a snappy name, rather than just 
referring to it as an inline conglomeration that involves the generic types.


The compiler knows what that type is.  How do I refer to it?  Can I say, 
"declare $x to be the type of the right-hand-side", rather than making 
me name it and checking that I got it right, or leaving it off and not 
having compile-time checking and optimization for subsequent use of $x ?


Here's an idea:  a pseudo-type of the form ::?RHSTYPE.

I could even capture it for subsequent use, like with generic type 
parameters:


  my ::?RHSTYPE ::ProdType $x = $a ⊗ $b;
  my ProdType $y = $x;

--John

A TEMP block?

[John M. Dlugosz]

S06 "Temporization", along with 'temp' variables, defines a TEMP block.

Do we really need such a thing?  It appears to be a LEAVE block with another 
level of indirection.  Hmm, that is, the body of the TEMP block executes at its 
normal place at run-time, unlike the episodic blocks it resembles; the return 
value is appended to the LEAVE trait.

It seems difficult to generate a closure at run time (as opposed to just 
cloning one specified at compile time), so I wonder why you would need to do 
that.

It also makes me think about traits on cloned closures or specific instances of 
routines.  But again, I don't think we really need to have individual instances 
of routines have their own traits distinct from the Routine object itself, 
since you can accomplish that using variables subject to cloning within the 
closure in the trait (e.g. the LEAVE trait).

In short, can we drop 
  TEMP {{ $next = $curr }}
?

Re: Idea: infir types of constants

[John M. Dlugosz]

I'm thinking that if strong typing is enabled, mixing untyped and typed 
things will cause warnings or errors that need not be there. 

I'm thinking that 'constant' is more special than other variables, and 
that the formal description of strong typing and static types should say 
that the compiler =will= implicitly get the type for $pi rather than 
making it Any.


Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote:

Doesn't perl do this when you don't specify a type?

constant $pi = sub_that_calcs_pi();

Since static types are optional, I don't see the point in explicitly
speccing type inference. That's only stating that type information is
determined at compile time, which seems like an optimization to me that
doesn't need to be in perl 6.0.0. Of course any implementer is welcome
to do perform that optimization where possible ;-)

Moritz


  

Re: Clarify "Design by Contract"

[John M. Dlugosz]

Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote:


This is described in depth in "Object oriented software construction" by
Bertrand Meyer.

  
OK, reading about it in Wiki, I see what it's supposed to do. 


PRE - derived classes may weaken but not strengthen.

So if it fails, but the preconditions of the same method on the base 
class pass, that means you wrote the precondition wrong.  Rather than 
ignoring that, shouldn't it be an error?


--John

Help understanding syntax in S06 "Pairs as lvalues"

[John M. Dlugosz]

:(:who($name), :why($reason)) := (why => $because, who => "me");

What do the symbols $name and $reason refer to?  Are they names already in 
scope?

"Alternately, the my declarator can also force treatment of its argument as a 
signature."

That would be

my (:who($name), :why($reason)) := (why => $because, who => "me");

which declares $name and $reason, and poises them for aliasing to named return 
values.  Signatures normally are used as the beginning of functions and 
introduce local variables.

--John

the nature of 'temp'

[John M. Dlugosz]

Does 'temp' operate on the value or on the container?  

The text starts, "The temp macro temporarily replaces the value of an existing 
variable..." and the description seems consistent with that.

   temp $*foo = 'foo';

The restore feature is generated by calling VAR($*foo).TEMP, and the method 
Scalar.TEMP can call its own STORE method.

But then there is the example

   temp &bar := sub {...};

That is, it uses binding rather than assignment, which applies to the container 
itself.  

How can the container, which is Routine, know about the caller's &bar symbol?  
That is, &bar.TEMP, might be defined in Routine to be

   method TEMP ($self:)
{
...
return sub { $self := $originalvalue }
}

it can rebind the $self argument which it closed over, but that will not affect 
the original caller's bar variable.  The aliasing of parameters to arguments is 
done by pointing to the same container.

Does anybody disagree with me?  That just doesn't compute.

Now what we really want here is to temporarily replace the meaning of the 
function call.  Routine already has the ability to be changed in-place, which 
is what .wrap does.  So we should simply allow .STORE to use the same ability, 
and then ordinary assignment, not binding, works.

   temp &bar = sub {...};  # use = not :=

The use of assignment calls the container's STORE, or whatever it will be named 
on Callable containers (there is no precedent in Perl 5's tie interface).  The 
use of temp will call Routine.TEMP for a closure, and it can work exactly like 
it does in a scalar: use its own STORE method to put back the saved value.

This change (just the one line of example) affects S06 under "Temporization".

--John

context vs context

[John M. Dlugosz]

The term "context" is used for two different purposes.  I don't like that.

The context can refer to "list context", "item context" etc.

The context can also refer to the dynamic calling chain, which are 
Context objects navigated by the context function.

Re: cross operator and empty list

[John M. Dlugosz]

Doug McNutt douglist-at-macnauchtan.com |Perl 6| wrote:

At 09:58 -0700 4/14/08, Larry Wall wrote:
  

By the way, you don't need to put parens around the arguments to X. It takes a 
list on either side.  We made it tall so that it would stand out visually 
anyway:

   $a,$b,$c X $x,$y,$z



How long before some engineer or 3D graphic artist gets really frustrated when 
he doesn't get what he expects?

($a,$b,$c) X ($x,$y,$z) ---> ($b*$z - $c*$y, $c*$x - $a*$z, $a*$y - $b*$x)

use classic_vectors; # perhaps.


  
I think the ability to use mathematical vectors should be in a library.  
Perhaps more than one, with different aims.


So I'm more interested in making sure the core language supports writing 
such a library, that works with existing types and operators more 
seamlessly then in other languages, than about the actual semantics of a 
mathematical vector.

Re: Idea: infir types of constants

[John M. Dlugosz]

To me the foo looks like a template sub and I wonder how it is
instanciated with different types. Since type parameters are
provided with [] it should be foo[Int], foo[Str] and the like.
I wonder further if that could also be written foo of Str like
with Array of Int etc.

  my foo of Int &intfoo;

  my Int $x := intfoo(3,2); # type correct

Also I wonder if Perl 6 can support all foo[::T] with a single
generic body where other languages have to generate different
code for each ::T. The type inferencer could also find out a
lot of constraints for ::T from the body. E.g.

   sub foo (::T $a, T $b --> T)
   {
   if $a != 0 && $b != 0   # ::T does Compare[Num]
   {
  return $a * $b;  # ::T does Arithmetic
   }
   ...
   }


Regards, TSa.


Having a generic type in sub foo will serve the same effect as templates 
in C++.  I think it literally means having one body, without strong 
typing, that has static type checking added to it.


The implementation could indeed decided to instantiate different bodies 
depending on the type, rather than doing it the slow way on each use of 
the object.


But, &sub is a single Routine object, unlike a multi which are different 
subs that can be referred to individually.  If the implementation 
chooses to specialize the body, it would be "inside" the single &foo 
entry point.  Code that calls foo still needs to call the single entry 
point rather than optimizing to the real body, in case &foo gets wrapped 
at run-time.


Note that an implementation can =always= generate specific code and then 
run it, rather than looking up untyped access as it goes.  If you have


  sub bar ($a)

and call a lot of methods on $a, perhaps in a loop with millions of 
iterations, the implementation might specialize the block once when it 
knows the actual type of the object in $a.  Lets hear it for read-only 
variables--they can be as useful as declared types, for optimizing!  If 
you run the optimizer at run-time, that is.


I don't think the inferencer can tell that ::T does Compare.  It could 
find any implementation of the operator that can be called with that 
type, without it being part of a known interface.
It has to build up an interface on the fly based on what is done in the 
function, and then populate it upon entry.  For things that are not 
called as method-call syntax, it will have trouble even doing that 
unless it knows the types of the other arguments too.


--John

Re: Idea: infer types of constants

[John M. Dlugosz]

Mark J. Reed markjreed-at-mail.com |Perl 6| wrote:

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;



  
So the idea of marking the use of implicit type would be better than 
making it automatic in some cases and not in others.  Logically, that is 
just a symbol like ::?TYPERHS but with more syntactic sugar, such as a 
special symbol:


 my ☂ $approx_pi = 3.14;

Where the umbrella is meant to convey the protective nature.  For those 
who don't have umbrella keys on their keyboards, you might consider the 
useless "window" buttons near the spacebar, or invest in one of these 
(http://piengineering.com/xkeys/xkstick.php). 

More seriously, reusing existing symbols and concepts, a generic type is 
introduced using ::T, in a signature.  The stuff after 'my' is actually 
a signature, so if


  sub foo (::T $a)

actually works (⦃and it might not -- still need to hear from Larry about 
leaving off the other type, you might have to write   sub foo (Any ::T $a) ⦄

Then the declaration

  my ::T $x = whatever;

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

  my Any ::T $x = whatever;

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


--John

static types, checking, conversions

[John M. Dlugosz]

I posted my thoughts as a sort of white paper here:

http://www.dlugosz.com/files/static-type.pdf

This needs to be fleshed out.  Decisions need to be made.  Anyone want to 
discuss it with me?

--John

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

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?

Chained Comparisons ?

[John M. Dlugosz]

I know how comparisons are chained in Perl 6.  There is a very short section on 
it in S03.

So, are the operators infix:{'<'} etc. written in the normal way to take two 
arguments?  Then the language transforms A op B op C into A op B AND B op C on 
an innate level.  Does that apply to any user-defined operator with those 
names?  If I want to make my own chained operator, perhaps the curvy ≼, 
≽, etc. or make my operator ≧ a synonym for >=, how would I tell 
the compiler that they belong to the same set of chained operators?

Or, are the operators written in a tricky way, to return an object that 
encapsulates the original right argument and the proper boolean result, and has 
forms to take this object as well?  IOW, no built-in support.

--John

Re: static types, checking, conversions

[John M. Dlugosz]

Thom Boyer thom-at-boyers.org |Perl 6| wrote:

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

The links under ECMAscript 4, like "Read the tutorial on evolutionary 
programming in ES4 
"
In http://www.ecmascript.org/.  This paper shows how to add types to an 
untyped program as it grows.


--John

Returning Arrays?

[John M. Dlugosz]

How do you declare a function that returns an array?  Something like

   sub foo (blah) is Array of X { ... }

seems right, but it has two problems.  First is a real problem, and is a 
mistake seen a lot in C# and the .NET framework.  A concrete type is 
used when it should be an interface.  What if the function wants to use 
a List or Seq or some bizzare tied thing of its own?  Defining it as



   sub foo (blah) is Positional of X { ... }

is not as snappy, and I don't think it will catch on.  (I'm still 
wondering whether Lists and Seq's are Positional anyway, merely lazy 
about it)


So that brings me to the second problem.  For parameters, it's no 
problem because people just use the @ sigil and don't think about 
containers.  So how do I do that with the return value?  I don't name 
the return value, so there is no place to put the sigil.


  sub foo (blah) is X @*

perhaps?   I seem to recall seeing sigils in a signature without names, 
but now I can't remember where.


--John

Re: static types, checking, conversions

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:



I found two dissertations and a couple of papers about typing
JavaScript. The quintessential is that optional typing is
defined as having *no* impact on the dynamic behavior of the
program. In that respect type annotations are like comments.
I doubt that this is the case with Perl 6, or is it?


Regards, TSa.



In Perl 6, I'm trying to identify where type annotations affect behavior 
and when they don't.  I think that's important since it separates the 
must-do analysis from optional optimization, and conversely describes 
what the optimizer can't do even if it thinks it could.


As a degenerate case, not being allowed to assign or bind something is 
certainly an impact on behavior.


If MMD is based on actual dynamic types, then static types don't affect 
the result, other than to prevent the program from loading the wrong 
thing into a variable that then gets used as a parameter. 


Also, look at:
 
  my Dog $spot .= new("Fido");


the static type Dog does affect the subsequent use of .new.  Even if you 
explain that in terms of the protoobject, the point is that saying Dog 
=does= something, it's not just a comment like a (current) Javascript 
naming convention.


--John

Re: Returning Arrays?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

John M. Dlugosz wrote:

How do you declare a function that returns an array?  Something like

   sub foo (blah) is Array of X { ... }



I meant "of", not "is".



In general the of keyword instanciates parametric types just like
the direct indexing of typenames with []. The only unspecced thing
is the variance of ::Foo[::Bar] with respect to ::Bar.


Variance?





So that brings me to the second problem.  For parameters, it's no 
problem because people just use the @ sigil and don't think about 
containers.  So how do I do that with the return value?  I don't name 
the return value, so there is no place to put the sigil.


  sub foo (blah) is X @*


Should be 'sub foo( --> X *@)' or 'our X *@ sub foo()'. In case that
this doesn't parse 'our :(X *@) sub foo()' should.


No, *@ is the slurpy array parameter.  I was thinking of

  (*,*,$x) = @array;  # skips first two elements

to suppose that @* might mean "no name" if the syntax would not allow 
for bare @ there without an identifier.

Re: Returning Arrays?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

John M. Dlugosz wrote:

I seem to recall seeing sigils in a signature without names,
but now I can't remember where.


E.g. in S06 und section "The want function".

Regards, TSa.
Somewhere else, I think it discussed unnamed parameters to functions, 
not just signature matching.

Re: Chained Comparisons ?

[John M. Dlugosz]

Patrick R. Michaud pmichaud-at-pobox.com |Perl 6| wrote:

It applies to any operator that has 'chain' associativity --
see S06, "Subroutine traits".

  
If I want to make my own chained operator, perhaps the 
curvy ≼, ≽, etc. or make my operator ≧ 
a synonym for >=, how would I tell the compiler that they 
belong to the same set of chained operators?



sub infix:«≽» ($a, $b) is equiv(&infix:«>=») { ... }

Or, if you want to create your own chained precedence level
separate from the existing relational ops, 


sub infix:«≽» ($a, $b) is assoc is looser(...)  { ... }

Pm

  


Your answer is the opposite of Brandon's. 

Re: Chained Comparisons ?

[John M. Dlugosz]

Larry Wall larry-at-wall.org |Perl 6| wrote:

Well, that's more or less how Icon does it, but we're not going to expose
anything like that to the user.  If we assume that comparisons take two
immutable objects, we can leave it to the compiler to compute the actual
value once, and then feed it to both sides of the implicit AND.  The
user just writes an ordinary binary comparison that returns a boolean.

For several years now I've been treating any use of "but" as a code
smell, and changing the design so it isn't necessary.  It's been a
rather useful construct that way, like "eval" and "BEGIN". :)

  

Thanks for the clarification, Larry.
 * hidden from the user (no funny return values, no funny way to write 
the function)

 * argument only evaluated once
Any strong feeling about order-of-evaluation issues?

I assume this extends to any user-written infix:{'<'} since we're not 
supposed to reuse existing operators for different purposes, but only to 
extend the domain of the same meaning.


So how about making a new operator or set of operators that will have 
the same behavior?  I don't like compiler magic that is not available 
for reuse .


Is "chained" associativity specific to this (functions return Bool and 
are ANDed pairwise), or can it be used for other things like ganging 
$a+$b+$c+$d to a single +(*$L,*$R,Vector [EMAIL PROTECTED]) function that doesn't 
keep re-allocating and copying memory but does it all in one shot?


--John

Generic Parameter Proposal

[John M. Dlugosz]

First, consider the stated examples for Generic type parameters, from the 
passage which defines the terminology in S02:

sub max (Num ::X @array) {
push @array, X.new();
}

sub compare (Any ::T $x, T $y) {
return $x eqv $y;
}

There are only two paragraphs and these two examples, so many questions are 
"begged".  I propose to answer many of these with this treatment, and hold it 
up for peer review and acceptance.  I also want to propose a new feature change.

Question 1 - can the Any be left off?  That is, ::X as an undeclared type name 
used as the only type, syntactically correct?

Question 2 - is $x constrained to ::T or does that just note what it was 
originally? (in cases where $x is not read only.  In this example that is moot.)

The syntax to define the value type for variables provides for multiple types 
simply listed one after the other, which are taken to mean "and".

Dog Fish $x;

This means that $x must have both Dog and Fish interfaces.  A better example 
might be

Document Storable Positional $doc;

where the code makes use of several different fairly abstract interfaces and 
doesn't care what kind of concrete class it gets.

So, we might want to capture that concrete type to, and write

Document Storable Positional ::DocType $doc;

Now the fact that this is a generic type notwithstanding, it is just another 
type in the list.  It just happens to be the same type that is the actual type 
$doc was initialized with.  But, it implies that yes, $doc is constrained to 
that type from then on.  The generic type just customizes the list at run-time, 
but it is still a list of juxaposed types, so they are ANDed together.

Mammel Elephant $dumbo;

might be redundant if Elephant .does Mammel.  But that's beside the point.  
Likewise that DocType (after binding) subsumes all the others in the list.

Now we have a list of juxaposed type names, that are ANDed together.  The 
generic type is the one that wasn't defined (as a type) before.  It needs the 
:: so it doesn't flag as an undefined symbol, but the others could have the 
sigil if you wanted to be explicit:

::Document ::Storable ::Positional ::DocType $doc;

Whether or not the sigil was present is lost on the semantic meaning, once it 
gets past the parser.  The only reason we had it on ::DocType or ::T was 
because it was not defined.

The only real difference between the generic type and the others is that one 
was not previously known.  Really, it is just a list of type names.

So,

::T $x;

Should be just fine.  The parser is not depending on another type already seen 
before that.  It is a list of one type, and after it figures that out, it later 
notices that it is not defined yet.

That answers the two questions, based only on other things in the Synopses.

Now for a proposal, and the observation of an issue.

The only thing that makes a generic type parameter generic is that it was 
previous undefined as a type.  So, what if you have code that's working just 
fine, and then some other change puts a symbol T into the lexical scope, 
perhaps as a global import?  Boom!  The code changes meaning drastically.

Contrast that to the normal meaning of declaring a variable, in which case it 
hides anything with the same name in the outer scopes.  Introducing a global 
one does not change the code that uses lexical variables.  Except for generics. 
 That is inconsistant and wrong for the same reason that it would be wrong for 
all other kinds of symbols.

To address this, I propose using a positive way to declare generic parameters 
rather than having them implicit based on not previously existing.  I propose 
the triple colon, :::, for this purpose:

:::T $x;

I beleive this does not conflict with anything, and it is in the same spirit as 
@@ and ;;.

--John

Desk check this code please

[John M. Dlugosz]

Is this code syntactically and conceptually correct?

 method postfix:<++> (-->::?CLASS)
 is export
  {
  my ::?CLASS $temp = self;
  self =. successor;
  return $temp;
  }
 
 method prefix:<++> (-->::?CLASS)
 is export
 is rw
  {
  self =.successor;
  return self;
  }

In particular, are pre/postfix functions defined as methods inside a class (or 
role, as the case may be)?  I'm guessing that 

 ++$x

will first see that prefix:<++> is a member of that class, and do method 
dispatch on it.

So, does making it "export" mean anything?

Operator or not, if methods are "export", do they need to be multi, or are they 
not multi if dispatched via method but become multi if dispatched as a sub?

--John

Does STD.pm handle this?

[John M. Dlugosz]

 sub GetType (-->Type) { ... }
 my ::RunTimeType := GetType;

This is clearly permitted by the prose, that " ::x may be bound to any object 
that does the Abstraction role, such as a typename, package, module, class, 
role, grammar, or any other protoobject with .HOW hooks."

But the syntax might think that is the value type and complain that no variable 
followed.  Can someone make sure the grammar handles this, so we can bug Larry 
if it doesn't?

Also, is this the normal way of making typedefs?

   my ::Newname := OldTypeName;

(or constant instead of my?)
or is there some other syntax specific to the task?

Re: Chained Comparisons ?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


Why the complicated sig? Note that the left sequential definition
enforces that ($a + $b) + $c dispatches to a version of + with the
return type of the lhs addition. That is you need lots of overloaded
versions of listfix +. Nonetheless I would like to define + and * to
be listfix and commutative, that is independent of order. Note that
this is orthogonal to the definition of evaluation order.


Regards, TSa.


Because the function is specific for adding a bunch of Vectors, and 
needs at least two.

Re: Returning Arrays?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

John M. Dlugosz wrote:

Variance?


Yeah, the standard set of co-, contra-, in- and bivariance ;)

Assume A <: B being subtypes. Then how should Foo[A]
and Foo[B] relate?

   Foo[A] <: Foo[B]   # covariance
   Foo[B] <: Foo[A]   # contravariance

Invariance means there's no relation at all. And Bivariance
means both!

Regards, TSa.
The multi-dictionary search didn't show this usage of covariance and 
contravariance.  But the series of articles on Type Theory in JOT uses 
it to mean "in the same direction" and "in the opposite direction" but 
doesn't define it as absolute subtyping directions.  How is it being 
used in this mailing list?


I've thought about the issue, and it depends.  The type parameters to 
the class might be annotated to indicate whether it is treated like a 
contained value type, is ignored, or what.  But there are too many cases 
and the relationships are complex.  Instead, it needs to look at the 
resulting public methods that involve the type parameters.  It considers 
one a subtype of the other if they meet the requirements for method 
substitutability. 


--John

Re: Does STD.pm handle this?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


I guess not. But

   ::Newname ::= OldTypeName;

should work. The type system is a runtime overlay to
the value system. This is reflected in the source by
putting types and values into different syntactic slots.
You cannot mix these!


But Newname is not declared yet!



I unify class and code conceptually and Perl 6 might
unify them actually. That is I think invoking a sub
essentially means:

   sub foo ($x) {...}

   $x = &foo.new(3);
I don't understand your point.  Are you thinking of .callwith or 
postcircumfix<( )> methods on the Code object?





   class foo ($x) {...}  # constructor syntax?

   $y = ::foo.new(3);# perhaps also: ::foo(3)

   $z = foo 3; # ambiguous or &foo?

If you wanted more than one constructor you'd need to prefix
it with multi.

That doesn't look like Perl 6 at all.  The parens after class foo is not 
part of the grammar.  I think what you are showing on the second line 
would be a definition for method new inside of class foo.  I get you're 
trying to explain how subs are like classes, but I'm not following.



BTW, I wonder why S12 is wasting {} for parent class construction:

class Dog is Animal {...}
my $pet = Dog.new( :name, Animal{ :blood, :legs(4) } );

Wouldn't parens be sufficient? Looks like Type{} now means protoobject
construction and Type() means concrete object construction. And Type[]
means type construction. So what exactly can one do with a protoobject?
And what is a protoinvocation of a sub? When is it evaluated?
Finally I wonder why we didn't give a meaning to Type<>? Does that
look too much like C++, C# or Java templates?


Regards, TSa.


Type as a list operator is type conversion.  The parens are just 
grouping, as in any list operator.  Type would mean Type{'blah'} 
from the usual correspondence of <> indexing to hash indexing without 
quotes.  Likewise you also have the frenchquote form which is the same 
with interpolation.  So that doesn't mean anything in the situation, but 
<> are "taken" in a sense.


--John

Re: Generic Parameter Proposal

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


Which is no problem if ::T defines it in the lexical scope. Any
outer definition is hidden. I guess re-using ::T in the same scope
again for capturing a new type is an error. Just like redeclaring
a value variable. BTW is
You appear to be saying that any use of Type with the sigil ::Type, in a 
signature where a type is expected, makes it generic and declares it 
hiding any outer value.


Reading S02 again, I see that is explained.
"C<::> can serve as its own sigil indicating intentional use of a 
not-yet-declared package name."


But the synopses uses ::Type to empasize that it is a Type, e.g. "$spot 
is initialized with ::Dog".


In one case it is used for a Signature.

  my ::MySig ::= :(Int, Num, Complex, Status)



And here it is used to indicate "type" so as not to run into reserved 
syntax:


Foo::<::Bar><::Baz> # same as Foo::Bar::Baz

And in S03:

Type names

   Num
   ::Some::Package


Class-qualified method call

   $obj.::Class::meth

In S06:

   is ::Foo[...]   # definitely a parameterized typename

In S10:

Since there are no barewords in Perl 6, package names must be predeclared,
or use the sigil-like C<::PackageName> syntax.  The C<::> prefix does not



imply top-levelness as it does in Perl 5.  (Use C<::*> for that.)




   $obj.Class::meth# same thing, assuming Class is predeclared


Finally, in S12:

In an rvalue context the C<::> prefix is a no-op, but in a declarational 
context, it binds a new type name within its declared scope.

===

So, I agree with your reading.  But I don't like it.  


--John

use of ::?CLASS

[John M. Dlugosz]

OK, what is the proper use of ::?CLASS ?  Say in a role you want to take an 
argument of the same class as the final class, or explicitly declare $self.  
S12 gives an example:

 method doit (::?CLASS $self: $a, $b, $c) { ... }

but this CONTRADICTS the idea that using the :: sigil in a declaration declares 
a generic type.  And you can't spell ?CLASS without the sigil because you never 
have a twigil without a sigil and ?CLASS is not a legal identifier.

The example of

my @candidates := $object.WALK(:name, :breadth, :omit($?CLASS));

doesn't shed any light.  The meaning of $?CLASS is never explained.  Just a 
cryptic line in S02 "what class am I in (as variable)".  Is the same Type 
object accessible as the value of the item with the $ sigil?  Why is this 
necessary?  I wonder if it has something to do with problems using the :: sigil 
that I'm musing with.

--John

Generics, Take 2

[John M. Dlugosz]

The current intent in the Synopses is that using the :: sigil in a 
declaration makes it a generic type parameter and declares that name there.


As a minimal fix to make that work, refine it to say that use of :: as a 
sigil in a declaration on a name that contains only a single identifier 
(no :: scope parts, no twigils, no funny symbols as names) declares a 
generic type parameter.


  sub (::Type $x) # declares generic type parameter as actual type 
of $x argument
  sub (::Type $)   # ditto, but don't care what the value is.  Value 
passed though.

  sub (::Type)   # the parameter is a type object.
  sub ($x, $y --> ::+RetType)  # Not a generic, but the current value 
of the context variable

  sub (::?CLASS $self, $x, $y)  # Not a generic, but special ? variable
  sub ($x, ::Foo::Bar $y)  # Not a generic, but current meaning of 
::Foo::Bar
  sub ($x, ::Bar $y)  # Generic, defines new Bar and ignores any 
current meaning


That would fix the problems with cases where you must use the sigil.  
But I still think the idea smells bad: that the sigil normally means a 
symbol of a particular type, can be omitted when that kind of symbol is 
expected, but leaving it on is "normal" and explicit but omitting it is 
a shortcut; except now the sigil means something different if you don't 
omit it but only in some places.


I still want to find a positive syntax for declaring generic types that 
harmonizes better.  Many ways suggest themselves, but the hard part is 
coming up with something succinct. 

Larry, you never said what you thought of my idea of simply using more 
colons.  That seems to have precedent in the language as it stands.  
Type is probably the most precedent-harmonizing, but :::Type seems 
sufficient.


Using more words is not succinct.  Using symbol prefixes hard because 
the grammar is already so crowded, unless you want to use a non-ASCII 
symbol like ⍈.


But suffixes, there is lots of room available.  We already know that it 
has a :: sigil and a single identifier.  Perhaps  ::Type! connotes 
"declare me here", and goes well with the ? suffix of optional parameters.


And I close with this example of generics and signature extraction, 
because Perl 6 generics needs to be at least as powerful as C++ templates:


   sub (Positional ::Container[of => ::ValType] $x)

makes both Container and ValType available in the scope of the 
function's block, and ensures that whatever is passed also supports 
Positional. 

The only thing is, I had to make the parameter $x not @x.  How can I 
name the container type as a generic, rather than the value type?


--John

Context and return types question

[John M. Dlugosz]

If a function returns different things if called in list context or item 
context, how do you define the "of" type (outer return type) to make the 
function strongly typed?

Re: use of ::?CLASS

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


Sorry, I see no contradiction. Method doit *is* a parametric type.
That is you need a type argument to make a code type. And then
you need args to make an invocation. Now the question is who provides
the type argument and when. An explicit instanciation would read

   doit[Int] 3: 3,2,1;

but the compiler might also infer this. Note that this has the
surprising effect of inserting doit into the HOW of the runtime
invocant. Question is how long this persists and what errors can
occur when the attempt is made. This is what I call a free method
and the Perl 6 grammar might actually forbid method definitions
outside of class bodies.
I did not see anything about "free methods" or the passing of type 
arguments in that manner to functions, in the synopses.





The usual circumstance of instanciating doit is in class composition

   role R
   {
  method doit (::?CLASS $self: $a, $b, $c) { ... }
   }

   class A does R
   {
  # this is generated by the compiler
  method doit (A $self: $a, $b, $c) {...}
   }


I do see that the use in a role is like a generic.

But you would use the sigil every time, e.g.

   method doit (::?CLASS $self: ::?CLASS $other --> ::?CLASS)

that is not three separate generics with conflicting names, but the same 
thing.  With generics you can only use the sigil on the first use.






That is all methods in a role are parametric on ::?CLASS just
as all methods in a class are parametric on ::?SELF

   class B is A;

instanciates a new type &doit:(B $self: $a, $b, $c). This nicely


But doit is not a type.  I think you were talking something like that 
earlier and I didn't follow.

Re: Does STD.pm handle this?

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:



   sub foo ($x) {...}

   $x = &foo.new(3);
I don't understand your point.  Are you thinking of .callwith or 
postcircumfix<( )> methods on the Code object?


No, I think of foo not as a Code object but as a class that
does Code. Invoking foo means instanciating the Code class.
That is the above stores an uninvoked invocation of foo in $x.
Obviously you can invoke it as $x() later to get out what
foo(3) would. I think you can continue this with




No, &foo is an =instance= of class Routine (or something further derived 
from it), and Routine does Code.



Your example of making an uninvoked call is contradicted by the 
Synopses.  It is explained under "currying".


--John

Re: Context and return types question

[John M. Dlugosz]

If a function returns different things if called in list context or
item context, how do you define the "of" type (outer return type) to
make the function strongly typed?


How about sub foo (--> Seq^Item) {...}?



Interesting idea, but that doesn't tell the compiler that the return is 
keyed to the context.  The compiler should know what return type to 
expect, if only I could explain it.


I don't see how Seq^Item as a type is any different than Seq|Item.  It 
can only hold one at a time anyway.

Re: Context and return types question

[John M. Dlugosz]

Great.  So the flip side is, what do I return from a function so that it 
gives a single value if called simply, but provides optional named 
returns that are there if you catch them?  As a capture with one 
positional and one named argument?


And how do you declare =that= return type ("of" type) to be strongly typed?

--John

Larry Wall larry-at-wall.org |Perl 6| wrote:

On Fri, Apr 18, 2008 at 05:34:25AM -0500, John M. Dlugosz wrote:
  
If a function returns different things if called in list context or item 
context, how do you define the "of" type (outer return type) to make the 
function strongly typed?



You can't.  An "of" type forces the function into a single context
(unless we allow polymorphic return types as TSa mentions).

In general, we're trying to get away from want-based context dependency
and instead attempting to encourage lazy semantic constructs such
as Captures that can behave with a wide dynamic range when actually
bound later.

For instance, Arrays now behave such that, if you use one in numeric
context, you get the number of elements, so unlike in Perl 5, you need
not decide at return time whether the array is in item or list context.
You just return the array, and it will act much like it does in Perl 5
if you use it in a numeric or boolean context.  Since the default
return type is Capture, it doesn't matter if you declare the "of"
type as Array or not, since the Capture doesn't force either item or
list context on the Array either.  It should behave much the same in
either case, except that if you declare the "of" type as Array, you
give the compiler/optimizer/type inferencer more information to work
with at compile time.

Larry

  

Re: S12 delegation ("handles" trait)

[John M. Dlugosz]

Dave Whipp dave-at-whipp.name |Perl 6| wrote:

>
> Since the method name (but nothing else) is known at class
> construction time, the following .wag method is autogenerated for you:
>
>method wag (|$args) { $!tail.wag(|$args) }

...


Another thing that might be nice (maybe not a perl 6.0.0 feature, but 
something that it shouldn't be too difficult to add later) would be a 
way to tell the delegation to pass "self" as an extra arg to the 
delegate method.




The |$args does include the $self as the first argument.  The syntax 
tail.wag(|$args) will start with the implied tail as the first argument, 
then interpolate the rest of the args including its first one.


Unless the receiver is in a different slot in the Capture, but the 
binding rules don't explain that, only give a hint that you can use 
Capture in scalar context to get it.  If that's the case, then the one 
on the right overrides, and you will find the method in tail's class 
called with the original object as self, which just doesn't make sense.


So, I concur that the description of delegation still needs work, and is 
open for ideas on how to make it work right.  (Unless Larry knows in his 
head and just didn't explain it fully)


--John

method hiding (or not) in derived classes

[John M. Dlugosz]

Perl 6 has a concept of a "candidate list".  The candidate list are those that 
could handle the call, typically inherited methods and multi variations.  

It seems that multi variations, at least with respect to the semicolon 
parameters, compare the actual type and drop out of the list if any don't match.

What about ordinary methods (and ordinary parameters of multis)?  Does the 
candidate list hold every method name that matches, or does it do simpler 
parameter matching based on number of arguments, required named arguments, etc.?

If that is the case, then a derived method might not hide a base class method 
if the parameter list is seriously incompatible.  More interestingly, 
left-to-right ordering of multiply-inherited base classes will be checked for 
applicability rather than  arbitrarily taking the leftmost.

--John

Critisizms on postcircumfix:<( )>

[John M. Dlugosz]

I think the idea of "The expected semantics of &.() is that of a type 
coercion..." confuses the notion of function call and conversion.  If anything 
other than a Code object has one, it is acting as a functor, or function-like 
object.  The meaning of Dog(args) is seemingly a class method anyway, not a 
normal instance method.  It was elsewhere said that the type name as a listop 
indicates conversion.  I think that should be taken to mean that the compiler 
uses whatever form of conversion function is available.  I think $obj(args) 
should mean whatever I want it to mean, like any other function.  An (untyped) 
variable $obj can call &.() with the same syntax it does with an object of type 
Code, no problem.

We already use the method .new to mean "create one of these using these 
arguments".  Sometimes that =is= logically a conversion.  In C++ that is 
assumed by default.  So why make a different function with different syntax?

I propose that any method that is logically a "conversion" can be marked with a 
property to say so, and the implementation will draw upon those when asked to 
perform a conversion.

 our C multi method ^new (D $oldguy) is conversion { ... }

(er, the default inherited .new doesn't prevent me from making a multi new in 
my class, right?)

Now I can say  $c = C.new($d);  and if I ever say $c = C $d; or my C $c = $d;  
it will know that this is the function to call.

--John

progress report

[John M. Dlugosz]

I've identified a few more issues while refactoring the text across all 
the synopses, but I'm just noting everything in my document.  Not enough 
discussion going on to post them all.


My main creative effort is in studying type systems, and musing over 
what it would be like to have Perl 6's type system to be F-bounds 
specified subtyping.  According to Anthony Simons, no one has ever 
completely implemented it before.  I think Perl is a language that 
=could= do it, with its mixture of helpful typing and lax non-typing.  
Can't get a strict subtype defined properly?  Forget about it and just 
use Any.


--John

Class names are virtual

[John M. Dlugosz]

Larry, you've wanted to have class names used within a class be 
virtual.  With various degrees of conviction across the synopses, you've 
wanted classes defined within a class to be overridable, or all classes 
referenced by a class to be overridable, speculating on whether this is 
do-able.


I've worked out all the details, included a specification on pages 66-69 
of my document.  The excerpt is at 
, and the 
whole document at specdoc.odt and .pdf.


You'll be happy to know that not only is it do-able (once you know what 
is and is not affected), but it will play a role in making the type 
system F-bounds quantified.


I hope you have a few minutes to look it over.

--John

Re: progress report

[John M. Dlugosz]

whiteringmoon-at-gmail.com |Perl 6| wrote:

I stumbled onto this group as I was looking for language statisics and
I tried understanding what I am looking at.
What is Perl?
I don't mean to sound stupid in asking this.   But could you explain
what it is that I am looking at here?

WR


  


See 

Re: method hiding (or not) in derived classes

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


"Candidate set" would be a better term. It is a subset of all long names
of a multi in a lexical scope.

List, not set, because it is ordered.  nextsame/nextwith/etc. are 
described as invoking the next candidate on the list.  Therefore, there 
is a list.






What about ordinary methods (and ordinary parameters of multis)?
Does the candidate list hold every method name that matches, or does
it do simpler parameter matching based on number of arguments,
required named arguments, etc.?


There is hopefully a complete specification what constitutes
applicability. There can hardly be differing simpler versions.
In other words there is only one subtype relation that is used
whenever a binding takes place.


I have no idea what you said.





If that is the case, then a derived method might not hide a base
class method if the parameter list is seriously incompatible.


That is a natural and welcome consequence of type based dispatch.
Classes are for implementation sharing, not for transitive typing.


I'm talking about non-multi's here.



 More
interestingly, left-to-right ordering of multiply-inherited base
classes will be checked for applicability rather than  arbitrarily
taking the leftmost.


Indeed, I would hope that order of inheritance doesn't matter.

Sounds more role-like, now that you mention it.





Regards, TSa.

Re: use of ::?CLASS

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


You are right and I didn't address this, sorry. Actually the
only solution I see is dropping the ::? twigil altogether and
specify that CLASS is lexically declared by the compiler.
Otherwise we have to make a special case exception out of
::? variables.

All twigiled variables.  No longer special case: it only applies to 
non-qualified names with no twigil.






But doit is not a type.  I think you were talking something like that 
earlier and I didn't follow.


It is an arrow type, like foo: Int --> Int and bar: Int --> Int.
These are structurally identical. The fun thing is that the Perl 6
type system is supposed to be nominal. Thus foo and bar are different
types. But contradictory to that you can use foo and bar wherever
an Int --> Int is expected. I love this self contradiction of Perl ;)
Well, and you can't neither use foo nor bar to denote the arrow type.


doit =has= a signature.  Yes, I expect functions will be typechecked 
when you try and assign one to a variable that declares a function 
type.  But the function is a value of that type, just like 5 is a value 
of type Int, not itself a type.


--John

Re: Context and return types question

[John M. Dlugosz]

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


I guess with strong you mean as lossless as possible?

I think the type is just :( $: :named$ ) if you want to extract the 
invocant with a $ prefix. Otherwise it would be :( $, :named$ ) and you
extract the item positionally with prefix @ or .[]. 

I don't want to have to "extract" it.  I want to be able to say

 $x = foo

and get the single value return from foo, and only dress it up if I want 
the optional secondary returns


 my ($x, :$named) = foo;   # or something like that





Note that Captures
are immutable and therefore nicely covariant. Except of course that
containers are captured as containers and can be mutated. But Larry
revealed that single assignment semantics are aspired and mutability
is a historic artifact or so.


Regards, TSa.


Sorry, you lost me again.