This week on Perl 6, week ending 2003-04-27

Apr 27, 2003 by Piers Cawley

Welcome back to (I hope) a normal length summary of Perl 6 shenanigans after last week’s bumper double length installment. (Thankfully traffic has been much lighter this week; I’m not sure I could cope with writing another epic.)

Perl6-internals was quiet again this week, but traffic does appear to be picking up a little.

IMC and Variable Number of Arguments

Following on from questions on this subject last week, Klaas-Jan Stol asked for some clarification of Parrot calling conventions as documented in Parrot Design Document (PDD) 03. In a subsequent post he noted that it seems strange that the current perl6 implementation (such as it is) doesn’t follow the Parrot calling conventions. Sean O’Rourke shuffled his feet slightly and admitted that he’d chosen that method because ``It was easiest”, though he’d later rationalized that to ``It doesn’t matter for internal calls”. Dan Sugalski pointed out that it was only a temporary aberration. Unless I missed something, nobody actually answered Klaas-Jan’s initial questions.

http://groups.google.com/groups

Short-lived memory allocation

Last week, in a discussion of the Garbage Collection (GC) system, Dan mentioned that Parrot GC would walk the system stack in order to build the Root Set (the list of memory ‘nodes’ that are initially known to be alive) which makes life a good deal easier for anyone allocating memory because they don’t have to worry about explicitly attaching their shiny new buffer to the root set. Of course, it doesn’t lessen the pain of whoever writes the GC system because, as Benjamin Goldberg pointed out, any system stack walking system is inherently unportable.

Benjamin was concerned that there may be systems where, not only could you not use the same stack walking code as was used everywhere else, but it would be impossible to walk the system stack at all. Dan admitted that there ‘used to be’ such systems, but asserted that, for Parrot’s purposes ``Either we get access to the C auto variable chain, or we can’t run there.” Kurt Stephens pointed at some deeply scary sounding (and gloriously non-portable) system stack walking methods which involve co opting the C stack pointer and collecting garbage from unlikely places…

If you’re not sure what is meant by ‘Walking the system stack’ then you’re not alone. Tim Howell asked for clarification and received it from Matt Fowles and Brent Dax.

http://groups.google.com/groups

http://groups.google.com/groups

PMC Documentation

Alberto Simões continued on his mission to document Parrot’s various PMC classes. This week he offered up some Perlstring documentation

http://groups.google.com/groups

The Native Call Interface (NCI) system.

Michael Collins has been playing around with calling C from Parrot and found the NCI system rather cumbersome. He wondered if the whole thing couldn’t simply be implemented with a callcfunc opcode and showed a simple implementation of what he was driving at. Dan replied to this, explaining that he’d considered it but that it turns out not to be the Right Thing, and gave his reasons to do with encapsulation (when you call a PMC’s method you shouldn’t have to know whether it’s written in C, PASM or Befunge) and issues with dynamic generation of stub functions. Michael wasn’t entirely convinced by Dan’s argument.

On the subject of NCI, Clinton A Pierce wondered if it is supposed to be Win32 capable and, if it was, what he needed to do to get it working as his first attempt had failed. Currently on the horns of Warnock’s Dilemma.

http://groups.google.com/groups

http://groups.google.com/groups

use for p6c

Joseph F. Ryan resent his patch to implement use in Parrot’s Perl 6 implementation, this time as a straight CVS diff on Steve Fink’s request.

http://groups.google.com/groups

Building on Win32

Matthia Barbon continued his sterling work on getting Parrot to play well with Win32, offering a couple of patches. Steve Fink applied them both.

http://groups.google.com/groups

http://groups.google.com/groups

External Data Interfaces draft PDD

Matthia Barbon redrafted Brent Dax’s External Data Interfaces PDD based on the discussion of the original document. This elicited a few comments and I presume we can expect another, clarified draft at some point.

http://groups.google.com/groups

PPC JIT questions

Peter Montagner has started to work on the Just In Time (JIT) system for the PowerPC architecture (a chap can get tired of making sure that every initialism is expanded at least once in a document you know. Still, it’s been a few summaries since I last did anything like this) and had a couple of questions about its architecture and what he was allowed to do in PPC assembly. Dan answered, Peter asked for clarification; the usual give and take.

http://groups.google.com/groups

A question about encoding

Speed junkie Luke Palmer (Hmm… that may not mean quite what I want it to mean) is working on the next iteration of string_str_search, which, apparently isn’t fast enough (it’s still slower than Perl 5). He had a few questions about encodings. Benjamin Goldberg offered answers and an entire function. Luke was impressed, but he still muttered about how much faster single byte searching could be (he’s written a singlebyte/singlebyte search routine that goes slightly more than 2.5 times faster than Perl 5 apparently).

Later, Luke posted a new implementation of string_str_search which used his screamingly fast algorithm for single byte searching and a ‘stupid, slow algorithm’ for multibyte searches. Steve Fink applied the patch and asked for a unified diff next time as they are easier to read.

http://groups.google.com/groups

http://groups.google.com/groups

Leo Tötsch’s iterator proposal

Remember Leo Tötsch’s iterator proposal that received so little feedback a few weeks back? Steve Fink finally commented.

http://groups.google.com/groups

uniq.pasm and Parrot IO

About a month ago, Jürgen Bömmels was doing some work on the moving Parrot’s IO operators to use Parrot’s own PIO asynchronous IO system, which broke Leon Brocard’s uniq.pasm. Jürgen estimated that he might have it working ‘next weekend’. This week Leon asked if any progress had been made yet.

http://groups.google.com/groups

Meanwhile, over in perl6-language

The Type discussions continued. (Though I note, with some satisfaction that most of the discussions died down after I posted the summary. Maybe I got it right. Or not.)

Types

Michael Lazzaro’s excellent summary of what we knew about Types served as the seed for this particular discussion, which was essentially a continuation by other title of the thread that started last week. Discussion centred on ways of specifying what sorts of type coercions should be automatic and which disallowed. Paul Hodges suggested use strict allow => { Int => Str, Foo => Bar } as a possibility, which doesn’t quite work where you want to allow a type to convert to more than one possible target type, but it does look like a reasonable start.

There was also discussion of autocoercion to different types via a ‘path’ of coercions which looks to like it has enormous potential for complexity based nuisance. Michael Lazzaro reckoned that a lot of the chaining problems would go away if you drew a distinction between a ‘lossless’ coercion to a string and a serialization of something to a string for the purposes of debugging or whatever. (Coercing *from* a string to almost any other type but a numeric one seems to be the hard problem…)

Damian offered some thoughts about user defined coercions when he pointed out that a coercion is really an interaction between two classes and should therefore be implemented using a multimethod. He argued that things like Coercions were a strong argument for allowing return type to be incorporated into the multidispatch resolution mechanism. Others agreed that this would be a good thing, and we await a decision from Larry.

http://groups.google.com/groups – Seed

http://groups.google.com/groups – This week’s ‘root’

http://groups.google.com/groups

Change in ‘if’ syntax

The Subject of the thread still thinks the discussion is about a change in the syntax of if, but it’s actually about a change in how a block is recognized, which has knock on effects on on the syntax of various control structures, of which if is just one example. Various people balked (again) at the fact that the new rules for detecting a block mean that code like %foo {bar} no longer means ``find the value associated with ‘bar’ in the hash %foo” but instead evaluates to a hash variable followed by a block, and probably a syntax error soon afterwards. Michael Lazzaro and Damian showed workarounds for this (%foo .{bar} and %foo{ bar} respectively) and Arcadi Shehter reminded everyone of the space eating _ that seems to have been completely forgotten since the last time this issue arose.

http://groups.google.com/groups

anon-sub()’s execute in a for??

Paul Hodges took a crack at implementing for as a subroutine and came up with something that didn’t look too insane. Luke Palmer added a refinement allowing for n at a time looping. However, for reasons that I can’t quite put my finger on, I’m not quite sure that either method has got the sub signature quite right, and I’m not entirely sure how you would express for’s signature as a Perl 6 signature anyway. Answers on a mailing list please.

http://groups.google.com/groups

* vs **

Paul Hodges wondered about the * and ** flattening operators. He wondered if they were actually distinct operators or if the double variant was simply the result of applying * to the results of *@whatever. According to Larry, the two are distinct, the only difference between them is one of timing. I’m not sure I understood the distinction to be honest and I don’t think I’m alone in this. Austin Hastings asked for an illustrative example, but we didn’t see any before the end of the week.

http://groups.google.com/groups

P6Objects: Hint’s allegations and things unsaid

Austin Hastings’ response to last week’s mammoth Types discussion was a mammoth document of his own on what is currently known about Perl 6’s Object Orientation features which was the result of trawling back through about two years of perl6-language postings. And jolly good it is too. It triggered a modest amount of discussion, but my theory is that everyone was too impressed to say much. I know I was.

http://groups.google.com/groups

Storing program state for restarting

Ed Peschko wondered if it would be possible to serialize the state of a running program so that it could pick up where it left off after it died at the point of expiry. Dave Storrs suggested that, if one could just serialize the current continuation, the problem would become trivial (I’m not entirely sure he’s right about that though; the current continuation seems to me to be in slightly the wrong place) and asked how one could do such a thing. The answer appears to be ‘to the best of current research’s knowledge, you can’t generally do that, but we’re working on it…’.

http://groups.google.com/groups

C-struct style data reads

Paul Hodges doesn’t like pack. What he wants to be able to do is something akin to C’s:

    struct {
        int   someInt;
        float someFloat;
        char  strData[42];
        float otherFloat;
        char  moreStr[123]
    } buf;
    fread(buf, sizeof buf, 1, fp);
    printf("%.0f %s", buf.someFloat, buf.moreStr);

instead of unpacking a string with unpack "ifa43fa123" <$file> or whatever. This led to some discussion of appropriate syntax and the like, but it was generally felt that, even if something like this wasn’t in the core, it wouldn’t be too hard to implement it.

http://groups.google.com/groups

Return types vs. Generic Programming

Michael Lazzaro wants the moon on a stick. In particular he wants to be able to declare:

   class Object { method CLONE returns MAGIC_TYPE {...} }

where MAGIC_TYPE is some magical token that means not having to declare

   class Whatever { method CLONE returns Whatever { .NEXT::CLONE } }
   class Whoever  { method CLONE returns Whoever  { .NEXT::CLONE } }

Quite what’s wrong with

   class Object { method CLONE returns Object {...} }

is a mystery to me. Luke Palmer wants more than that. The insanity continued for several messages.

Do you get the feeling that I’m not a fan of this particular proposal? I confess I’m finding it very hard to summarize it any more than the above without exclamations of shock and dismay. So I’ll stop now. Read the thread if you’re interested.

http://groups.google.com/groups

Type Conversion Matrix

Michael Lazzaro posted a matrix of some of the known built in types and of the possibilities of conversion between them, noting that what was shown were the conversions that it was possible to make automatic, not necessarily those which should be automatic. For some reason this led to a discussion of boolean types. Nope, I don’t know why either.

Another subthread discussed which conversions were lossy and whether or not to make them automatic in the case of going from, say ‘Int’ to ‘int’. (Int being a Perl Integer which could be undef and have properties and traits, and ‘int’ being, essentially, at least 32 bits of signed integer).

Michael posted a second take on the matrix with more information and with an additional ‘Scalar’ type added to it.

http://groups.google.com/groups

http://groups.google.com/groups

Fun with Junctions

Austin Hastings got faintly confused by the difference between ‘all’ and ‘any’ junctions. The rule of thumb appears to be ‘if you want to use a junction to represent a set, use an ``any” junction.’

http://groups.google.com/groups

Fun with multi-dimensional arrays

Dave Whipp pointed everyone at a discussion of Perl 6 on Perlmonks, where people were implementing J H Conway’s Game of Life in Perl. Dave had a some questions about tools for iterating over multidimensional arrays, suggesting some syntax as he went, then pulling it all together in a rather neat recalculation engine for the game of life.

Things got scary pretty quickly after that; at one point Dave even did a local redefinition of infix:= which certainly had me worried. Some clever stuff going on there and no mistake.

http://groups.google.com/groups

http://www.perlmonks.org/index.pl?node_id=253366

Acknowledgements, Announcements and Apologies

That about wraps it up for this week.

If you’ve appreciated this summary, please consider one or more of the following options:

Tags

perl-6
perl-6-internals-parrot

Feedback

Something wrong with this article? Help us out by opening an issue or pull request on GitHub