Re: Guillemets: innies or outies?

[Damian Conway]

Thomas A. Boyer wrote:


Damian, somewhere in the conversation on hyper-ops you switched over from this syntax:
  my @sum = @a «+» @b;
to this syntax:
  my @sum = @a »+« @b;


> Would you care to share your thoughts on why you've gone with 
inward-pointing guillemets?

Because that's what Larry decided last time this thread arose.
Convex guillemets will be used for word lists:

	use strict «vars subs conversions»;

	for «Doh Ray Me Far So La Tee» -> $word {
	print "$word, %desc{$word}\n";
	}

This is a far more naturally parenthetical usage of guillemets than vector ops 
would be.

And I strongly prefer the concave guillemets for vectorizing, because they 
highlight the operation, pointing it out in a distinctly "lookie-here" manner.


Damian
	

Re: Guillemets: innies or outies?

[Thomas A. Boyer]

> And, please, let's spawn no threads talking about how parentheses in font Foo 
> on platform Bar look like they point outwards. Ulk.

Er... I meant to say "inwards". Else that sentence makes NO sense.

Double Ulk.

=thom
"You live and learn. Or you don't live long." --Lazarus Long

Guillemets: innies or outies?

[Thomas A. Boyer]

Damian Conway wrote:
> Correct. Although presumably this:
> 
>  my @d = @x »but« Foo;

Damian, somewhere in the conversation on hyper-ops you switched over from this syntax:
  my @sum = @a «+» @b;
to this syntax:
  my @sum = @a »+« @b;

(Since those two statements use non-ASCII characters, let's just say that on my screen 
those two statements look a lot like:
  my @sum = @a <<+>> @b;
and
  my @sum = @a >>+<< @b;
respectively, but the doubled angle brackets are single characters [guillemets].)

I saw one post from someone who said that the French use the outward-pointing 
convention for quoting, and the Germans use the inward-pointing convention. I never 
saw anything else along these lines, but you've used the outward-pointing convention 
since then.

I like the outward-pointing convention better (why *else* would I be whinging? :-) 
because parentheses and brackets are both used with the outward-pointing convention. 
Would you care to share your thoughts on why you've gone with inward-pointing 
guillemets?

And, please, let's spawn no threads talking about how parentheses in font Foo on 
platform Bar look like they point outwards. Ulk.
=thom

Re: L2R/R2L syntax

[martin]

On Sat, 25 Jan 2003, Damian Conway wrote:
> As far as I know Larry is not planning to remove the functional
> forms of C, C, etc.
>
> Those forms may, it's true, become mere wrappers for the OO forms.
> But I confidently expect they will still be available.

Hmmm, so that means that they should be overloadable on a per-arrayish-class
basis, no?

Then what happens to

  @A = map { ! $_ } @B, @C;

when @B and @C are different classes?

Does that transmogrify into

  @A = ( @B.map { ! $_ }, @C.map { ! $_ } )

or into

  @A = [ @B, @C ] .map { ! $_ }

?

-Martin

Re: Spare brackets :-)

[Damian Conway]

This may sound like a silly idea


It's been suggested previously.



Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?


Yes. We rejected the idea.



In particular, it would seem that

  %foo[$key]

would be just as easy for the compiler to grok as

  %foo{$key}


Sure. But then is this:

	$ref[$key]

an array or hash look-up???

Damian

Re: More Array Behaviors

[Damian Conway]

Dave Whipp wrote:


OK, I've assimilated all that (though it still feels wrong). I think you are
saying that of the following, the 4th is an error.

  my @d = @x but Foo; # error: no values involved in this assignment


Correct. Although presumably this:

my @d = @x »but« Foo;

is okay.



I think that the thing that confused is that C Vs C distinction was
introduced as compile-time vs run-time. It seems that this distinction is
not relevant.


Let's say it's an approximation to the true.



Lets see if I apply this to objects. Objects are variables 

Yes.



(they contain attributes).


Yes.



All access to objects is via (scalar) references: 

Yes.



these references, being values, can have C properties. 

Yes.



When a method is invoked on an object, that method has an invocant, which 
> enables the method to see the C properties on that reference.

Yes.



If an object wants to have properties that apply to all references 
> (to a given instance), then that property must be defined as an attribute

of the object. 

Yes. At least, for the new "opaque" objects. Because there's no way to ascribe
the necessary C property to them.

Of course, old-style blessed objects *can* have C properties, if they're
created with them:

	method new ($class: $name, $rank, $snum) {
	my %self is Proper('teed') =
		( name=> $name, rank=>$rank, snum=>$snum );
	return $class.bless(%self);
	}


> An instance, itself, doesn't have postIt style properties.

Not sure what you mean by "postIt style". In my view, *all* properties are 
"PostIt style"...to the extent that they are stuck loosely on the variable or 
value to which they're ascribed.

Damian

Re: More Array Behaviors

[Austin Hastings]

--- Dave Whipp <[EMAIL PROTECTED]> wrote:
> "Damian Conway" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> >Anything that "holds" anything is a variable, not a value.
> > [...]
> > I'm saying that only scalar *values* can have C properties.
> > And yes, that includes Array references, but not arrays.
> >
> > > My mental image is of variables
> > > that provide access to values: variables are compile-time, and
> lexically
> > > scoped: values are run-time, and (can be) dynamically scoped.
> >
> > Not quite. Variables are containers, values are the data they
> contain.
> > Compile-time/run-time and scoping are orthogonal to that.
> 
> OK, I've assimilated all that (though it still feels wrong). I think
> you are
> saying that of the following, the 4th is an error.
> 
>   my @a is Foo = @x;
>   my $b = [@x] but Foo;
>   my $c = @x but Foo; # ArrayRef automagically created
>   my @d = @x but Foo; # error: no values involved in this assignment
>   my @e is Foo := @x;
> 
> I think that the thing that confused is that C Vs C
> distinction was
> introduced as compile-time vs run-time. It seems that this
> distinction is
> not relevant.
> 
> Lets see if I apply this to objects. Objects are variables (they
> contain
> attributes). All access to objects is via (scalar) references: these
> references, being values, can have C properties. When a method
> is
> invoked on an object, that method has an invocant, which enables the
> method
> to see the C properties on that reference. If an object wants to
> have
> properties that apply to all references (to a given instance), then
> that
> property must be defined as an attribute of the object. An instance,
> itself,
> doesn't have postIt style properties.

I'll ask, since I don't know: What's the access syntax for these
things?

my $i is wooly;

How do I test for wooliness?   if ($i.wooly) { print "Booly!"; }

my $i = 6 but wooly;

How do I test for wooliness?   if ($i.wooly) { print "Booly!"; }

class Mammoth {
  member Boolean wooly;
};

my Mammoth $i;

if ($i.wooly) { print "Booly!!"; }

Is this right?


I ask this because I can easily see wanting a class behavior that
attaches value properties, such as "but true". This might almost become
a standard idiom, as:

my HideousDatabaseConnection $hdc = new HideousDatabaseConnection(...);

die "Hideous Death"
  unless $hdc;


Where the ctor would ensure that but true/but false was set. 

(Welcome to 1977. K&R, anyone?)

=Austin



=Austin

Spare brackets :-)

[martin]

This may sound like a silly idea but ...

Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?

In particular, it would seem that

  %foo[$key]

would be just as easy for the compiler to grok as

  %foo{$key}

but would mean that we could stop worrying about the precedence of
postfix/infix "{", and things like

  if %test { $count++ }

would not require whitespace before the "{" to be disambiguated.

I don't have a complete solution as anonymous array and hash construction would
still need different syntaces, but has anyone else thought about this?

- Martin

Re: More Array Behaviors

[Austin Hastings]

--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Note that converting to and from C in numeric contexts is much
> less troublesome in Perl 6, because the C operator makes it
> trivial to
> catch bad cases and handle them appropriately:
> 
>   @a[$str//0] // silently convert to zero
>   @a[$str//die]   // silently convert to exception

Good point. When it's this simple to avoid the warning, the warning
should stay on by default.

> 
> >> What about @a[NaN]?  Just another warning probably.
> 
> Actually, I would expect it to throw an exception. Using something
> that is
> explicitly and deliberately *not* a number [*], in a context that
> expects a 
> number, almost certainly points to a serious problem in the code.

It's a sink. A data sink if we allow it, and a time sink if we discuss
it.

Given that NaN is, in fact, a "numerish" value (IOW: The context in
which NaN is meaningful is a numeric one) you could argue for allowing
storing into @a[NaN]. But you can't make a meaningful argument about
fetching from it.

Since NaN == NaN is false, how could you possibly retrieve any value
you earlier stored?

So it's either illegal, or legal but write-only.

=Austin

Re: More Array Behaviors

[Dave Whipp]

"Damian Conway" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>Anything that "holds" anything is a variable, not a value.
> [...]
> I'm saying that only scalar *values* can have C properties.
> And yes, that includes Array references, but not arrays.
>
> > My mental image is of variables
> > that provide access to values: variables are compile-time, and lexically
> > scoped: values are run-time, and (can be) dynamically scoped.
>
> Not quite. Variables are containers, values are the data they contain.
> Compile-time/run-time and scoping are orthogonal to that.

OK, I've assimilated all that (though it still feels wrong). I think you are
saying that of the following, the 4th is an error.

  my @a is Foo = @x;
  my $b = [@x] but Foo;
  my $c = @x but Foo; # ArrayRef automagically created
  my @d = @x but Foo; # error: no values involved in this assignment
  my @e is Foo := @x;

I think that the thing that confused is that C Vs C distinction was
introduced as compile-time vs run-time. It seems that this distinction is
not relevant.

Lets see if I apply this to objects. Objects are variables (they contain
attributes). All access to objects is via (scalar) references: these
references, being values, can have C properties. When a method is
invoked on an object, that method has an invocant, which enables the method
to see the C properties on that reference. If an object wants to have
properties that apply to all references (to a given instance), then that
property must be defined as an attribute of the object. An instance, itself,
doesn't have postIt style properties.

Dave.

Re: More Array Behaviors

[Damian Conway]

Michael Lazzaro wrote:


1) Edge cases in array indexing:

 @a[ undef ]   # undef, or 1?
 @a['foo'] # undef, or 1?


These should generate warnings, at least.
I don't know whether undef or 1 is more correct.


It's certainly a legitimate question.  (I'm not sure that @a[undef] == 
@a[0] is the correct behavior, going forward.  It certainly can be 
error-prone.)

We need an expert decision here, please.

I'd expect that C converts to zero (with an evitable warning).

I would expect that non-numeric strings like 'foo' convert to C
and thence on to zero (again with an evitable warning).

Unless C is in effect, of course.

Note that converting to and from C in numeric contexts is much
less troublesome in Perl 6, because the C operator makes it trivial to
catch bad cases and handle them appropriately:

	@a[$str//0]	// silently convert to zero
	@a[$str//die]	// silently convert to exception




What about @a[NaN]?  Just another warning probably.


Actually, I would expect it to throw an exception. Using something that is
explicitly and deliberately *not* a number [*], in a context that expects a 
number, almost certainly points to a serious problem in the code.

Damian


[*] ...as opposed to 'foo', which is merely implicitly and accidentally not a 
number ;-)

Re: More Array Behaviors

[John Williams]

On Mon, 27 Jan 2003, Michael Lazzaro wrote:

> Some requests for verification, plus additional questions.  If anyone
> has any arguments/clarifications/questions on these, please discuss so
> I can document.
>
> 1) Edge cases in array indexing:
>
>  @a[ undef ]   # undef, or 1?
>  @a['foo'] # undef, or 1?

These should generate warnings, at least.

I don't know whether undef or 1 is more correct.

Perl5 chooses 1, but it's smart enough to distiguish between $a["1e0"]
(returns 2) and $a["1e"] (returns 1 and a non-numeric warning), so it's
definitely choosing to return $a[0] for non-numeric indexes.
(0+"1e" is 1, not 0)

> Is [undef] the same as [0] in Perl6?  Is there any index value you can
> give that will cause an exception?

What about @a[NaN]?  Just another warning probably.

~ John Williams

Re: More Array Behaviors

[Michael Lazzaro]

On Monday, January 27, 2003, at 01:15  PM, Dave Whipp wrote:

"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message

   ... if such capabilities exist, what are their real names?  Can
anyone think of any that are absolute must-haves?  Are any of the 
above
must-haves?

I think that the only must-have is the ability to add these things 
later.
The size constraints are probably C properties, as is C. 
The
exception behavior probably deserves to remain an C property. 
There are
so many possibilities that we can't expect to have them as built-ins. 
And I
don't really see any compelling reason for any of the suggestions as a
builtin. Examples of other properties include:

(modulo Damian's correction that it's C, not C, in this case.)

Um, as an aside, I think perhaps I need a(nother, (better)) 
clarification on which things properties are to be used for, and what 
class inheritance is to be used for.  What's the underlying philosophy 
here?  When should something be a property, vs. a normal behavior of a 
class?

I would think that 'properties' should be reserved for things that can 
be applied to all variables, regardless of type, but some of these 
example 'behaviors' are very specific to Array -- to a particular 
assumed implementation of an Array, in fact.  I would figure those 
would more likely be attributes of the implementing class.

What's the (stylistic) rules?

MikeL

Re: More Array Behaviors

[Michael Lazzaro]

On Monday, January 27, 2003, at 11:46  AM, John Williams wrote:

On Mon, 27 Jan 2003, Michael Lazzaro wrote:

1) Edge cases in array indexing:

 @a[ undef ]   # undef, or 1?
 @a['foo'] # undef, or 1?


These should generate warnings, at least.
I don't know whether undef or 1 is more correct.


It's certainly a legitimate question.  (I'm not sure that @a[undef] == 
@a[0] is the correct behavior, going forward.  It certainly can be 
error-prone.)

We need an expert decision here, please.

Perl5 chooses 1, but it's smart enough to distiguish between $a["1e0"]
(returns 2) and $a["1e"] (returns 1 and a non-numeric warning), so it's
definitely choosing to return $a[0] for non-numeric indexes.
(0+"1e" is 1, not 0)



What about @a[NaN]?  Just another warning probably.


Probably.  After all, 'foo' in a numeric context should probably be... 
um... NaN.  Or did we ever decide on that one, after discussing it into 
the ground?

MikeL

Re: More Array Behaviors

[Damian Conway]

This confuses me: I thought an array *is* a value.


Nope. Arrays are variables.



Sure, its a value that holds other values: 

Anything that "holds" anything is a variable, not a value.



Are you saying that only scalars have C properties
(i.e. an ArrayRef can, but an array can't)? 

I'm saying that only scalar *values* can have C properties.
And yes, that includes Array references, but not arrays.



My mental image is of variables
that provide access to values: variables are compile-time, and lexically
scoped: values are run-time, and (can be) dynamically scoped.


Not quite. Variables are containers, values are the data they contain.
Compile-time/run-time and scoping are orthogonal to that.

Damian

Re: More Array Behaviors

[Dave Whipp]

"Damian Conway" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Dave Whipp suggested:
>
> > The size constraints are probably C properties, as is C.
The
> > exception behavior probably deserves to remain an C property.
>
> Nope. They're all C properties. C properties only apply to
*values*.
> Variable such as Arrays always take C properties.

This confuses me: I thought an array *is* a value. Sure, its a value that
holds other values: but an array is a run-time construct, which is not
(necessarily) lexically scoped, and which changes over time. Am I missing
something? Are you distinguishing between value-semantics and
reference-semantics? Are you saying that only scalars have C properties
(i.e. an ArrayRef can, but an array can't)? My mental image is of variables
that provide access to values: variables are compile-time, and lexically
scoped: values are run-time, and (can be) dynamically scoped.

Dave.
--
mailto:[EMAIL PROTECTED]; http://dave.whipp.name

Re: More Array Behaviors

[Damian Conway]

Dave Whipp suggested:


The size constraints are probably C properties, as is C. The
exception behavior probably deserves to remain an C property.


Nope. They're all C properties. C properties only apply to *values*.
Variable such as Arrays always take C properties.

Damian

Re: More Array Behaviors

[Dave Whipp]

"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...

>... if such capabilities exist, what are their real names?  Can
> anyone think of any that are absolute must-haves?  Are any of the above
> must-haves?

I think that the only must-have is the ability to add these things later.
The size constraints are probably C properties, as is C. The
exception behavior probably deserves to remain an C property. There are
so many possibilities that we can't expect to have them as built-ins. And I
don't really see any compelling reason for any of the suggestions as a
builtin. Examples of other properties include:

but sparse #  sparse arrays
but lower_bound=>N   # orthogonal to base_index
is interpolated(algorithm=>Linear) # permit fractional indexes on this
variable.

> (Note that the obvious added complexity caused by so many options can
> probably be optimized away for the default array implementation.)

Any that are defined as C properties are trivially optimized, because
they don't affect the stored value.

Re: More Array Behaviors

[Austin Hastings]

--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 27, 2003 at 11:00:17AM -0800, Michael Lazzaro wrote:
> 
> > resize => (1024),  # internal blocksize (in indexes)
> ># by which array expands?
> > resize => { $_ * 2 },  # or via closure, based on current
> size?
> 
> I think you're making too many assumptions about the internal
> implementations
> of arrays here.
> At least, I'm hoping that the innards will be flexible enough to let
> me
> do different things, such as request sparse arrays by default
> 
> > locked => 1,   # read-only, can't store new values
> 
> There was a discussion on p5p about "restricted hashes", and what one
> might
> want. Even for arrays I can think of at least 2 levels.
> 
> 1: everything locked - no new elements, existing elements treated as
> read only
> 2: size locked - you can't extend (or shrink) the array, but you can
>add/remove elements
> 

How bizarre. When you said you could think of two levels, I immediately
thought of two levels, but mine and yours aren't the same. I thought of
"totally read-only" and "content-locked" -- expanding/contracting is
okay, but no updates. (Think of implementing a stack, say.)

Maybe this is my C background coming out. The difference between 

const int * ptr; /* Variable pointer to unchanging elements. */

and 

const int const * ptr; /* Unchanging pointer to unchanging elements */

versus

int const * ptr;   /* Unchanging pointer to variable elements */

Anyway, I guess "locked" means different things to different folks.
Probably this shouldn't be core -- it should be easy enough to code up
a standard set of permutations. 

(OTOH, it's not unreasonable to talk about a standard set of methods
for this stuff, so that all those post-facto implementations speak the
same language.

Far better to have

LockedArray, LockedString, LockedNumeric, LockedBarnDoor, LockedMouth

than to have

FrozenArray, StaticString, ConstNumeric, LockedBarnDoor, SealedLips

(Unless this is one of those gobhoblins... ?)



=Austin


> If array indexes have a concept of exists distinct from defined, then
> several
> more graduations appear.
> 
> Nicholas Clark

Re: More Array Behaviors

[Leopold Toetsch]

Michael Lazzaro wrote:

I have some answers from current low level implementation.


2) As hinted above, is there a (platform-dependent) maximum addressable 
array index, or do we promise to correctly handle all integers, even if 
BigInt?  (This might come into play for lazy/sparse arrays.  Maybe.)


 new P0, .PerlArray
 set I0, 1
 shl I0, I0, 31
 dec I0
 dec I0
 set P0[I0], I0
 set I1, P0[I0]
 print I1
 print "\n"
 end

Current max index is 2^31-2 (for 32bitters). SIZE/RSS of above running 
is 1152 (list.c can do sparse arrays). IMHO for bigger arrays use a 64 
bit processor, and you can't fill them anyway ;-)


4) Optional array behavior.  In addition to default values, it may be 
possible to expose other details of array behavior, such that the user 
has some flexibility in the implementation of a given array.  Examples:

my @a is Array(
min_size => 50,# minimum reported size of this array


Just set @a[49]



resize => (1024),  # internal blocksize (in indexes)



items per chunk, yes.



   # by which array expands?
resize => { $_ * 2 },  # or via closure, based on current size?



Small arrays start extending by doubling chunk sizes, big arrays start 
with maximum chunk sizes and don't grow chunks anymore. Closures or such 
are for sure overkill and will slow it down.


exception => 1,# whether out-of-bounds addressing



This is default for Array.pm (PerlArray does auto resize).



MikeL



leo

Re: More Array Behaviors

[Nicholas Clark]

On Mon, Jan 27, 2003 at 11:00:17AM -0800, Michael Lazzaro wrote:

> resize => (1024),  # internal blocksize (in indexes)
># by which array expands?
> resize => { $_ * 2 },  # or via closure, based on current size?

I think you're making too many assumptions about the internal implementations
of arrays here.
At least, I'm hoping that the innards will be flexible enough to let me
do different things, such as request sparse arrays by default

> locked => 1,   # read-only, can't store new values

There was a discussion on p5p about "restricted hashes", and what one might
want. Even for arrays I can think of at least 2 levels.

1: everything locked - no new elements, existing elements treated as read only
2: size locked - you can't extend (or shrink) the array, but you can
   add/remove elements

If array indexes have a concept of exists distinct from defined, then several
more graduations appear.

Nicholas Clark

More Array Behaviors

[Michael Lazzaro]

Some requests for verification, plus additional questions.  If anyone 
has any arguments/clarifications/questions on these, please discuss so 
I can document.


1) Edge cases in array indexing:

my int @a = (1,2,3);

@a[0] # 1
@a[1] # 2
@a[2] # 3
@a[3] # undef
@a[2**128]# undef (but not exception???)
@a[Inf]   # undef (but not exception)
@a[ undef ]   # undef, or 1?
@a['foo'] # undef, or 1?

@a[-1]# 3
@a[-2]# 2
@a[-3]# 1
@a[-4]# undef
@a[-Inf]  # undef (but not exception)

Is [undef] the same as [0] in Perl6?  Is there any index value you can 
give that will cause an exception?


2) As hinted above, is there a (platform-dependent) maximum addressable 
array index, or do we promise to correctly handle all integers, even if 
BigInt?  (This might come into play for lazy/sparse arrays.  Maybe.)


3) Array default values.  It has been mentioned repeatedly that it 
would be nice to be able to specify what the value an array cell will 
contain, if it has not been previously stored to.  What's the preferred 
syntax?  One example:

   my @a is Array( default => 'foo' ); # (a) by value?

   my @a is Array( default => { $_ ** 2 } );   # (b) via closure???

Note that if (b) is possible, I don't know how you'd _store_ a closure 
as the default value of an array, if you're into that sort of thing.


4) Optional array behavior.  In addition to default values, it may be 
possible to expose other details of array behavior, such that the user 
has some flexibility in the implementation of a given array.  Examples:

my @a is Array(
min_size => 50,# minimum reported size of this array
max_size => 100,   # maximum reported size of this array

resize => (1024),  # internal blocksize (in indexes)
   # by which array expands?
resize => { $_ * 2 },  # or via closure, based on current size?

exception => 1,# whether out-of-bounds addressing
   # causes an exception to be thrown
exception_neg => 1,# (for negative indexes only?)
exception_pos => 1,# (for positive indexes only?)

locked => 1,   # read-only, can't store new values

start_index => 0,  # starting index, if not zero
);

  ... if such capabilities exist, what are their real names?  Can 
anyone think of any that are absolute must-haves?  Are any of the above 
must-haves?

(Note that the obvious added complexity caused by so many options can 
probably be optimized away for the default array implementation.)

MikeL

This week's Perl 6 Summary

[Piers Cawley]

The Perl 6 Summary for the week ending 20030126
Welcome to the first Perl 6 summary of the new 'Copious Free Time
enabled' era, which should mean that these summaries will get mailed out
on Monday evening from now on.

We start, as usual, with perl6-internals

  The eval patch
Leopold Tötsch continued to work on making "eval" and its associated
operators work and asked for some opinions about a problem he was having
with jumps between code segments. Jason Gloudon played sounding board
and the two of them found a way forward.



  The Parrot crashes
Dan announced that Parrot was crashing big time under (at least) OS X,
throwing segfaults in the NCI mark routine. Other people contributed
reports of what was happening on their platform and Leo Tötsch tried to
track down the error, working on the assumption that it was something to
do with his eval patch as that was the last patch that had gone in.

Later in the week Dan realised that part of the problem with OS X was a
problem with imclexer.c, an autogenerated file being generated with bad
code. Leo reckoned it was a problem with something having been multiply
defined, which had since been fixed.

Still later in the week, Steve Fink offered some analysis on the NCI
mark routine and a patch which attempted to fix the problems he saw with
it. Leo reckoned that the patch wasn't quite right, but the analysis was
good and used that to fix the problem and discovered in the process that
the parrot build process's dependency analysis wasn't quite up to the
mark. (I don't think there's a fix for that yet, but at least we know
the problem exists...)







  Compiling to Parrot
K Stol is looking for a final project for his Bachelor's degree and
would like to implement some language targeting Parrot and asked for
suggestions. Simon Wistow suggested PHP or Lua, Leon Brocard suggested
Java (though Gopal V wasn't sure that was such a good idea just yet).
Dan suggested that, just because someone else was already working on a
TCL compiler it didn't mean it wasn't worth trying anyway, but
apparently it would have been unlikely to get approval as a Bachelor's
project. There was some further discussion of Lua and whether there
would be any real point in implementing it and the thread died down
before Mr Stol told anyone what he'd decided to do, which was rather a
shame I thought.



  Extending the packfile format
Some months ago, Jürgen Bömmels offered a patch to extend the Parrot
packfile format whilst retaining backward compatibility. This week,
after a little modification, Leo Tötsch applied it. James Mastros
wondered if it didn't make sense (at least before parrot 1.0) to ignore
backward compatibility issues and just make it right. Leo and Dan
agreed, but Leo pointed out that, at least until the switch from
assemble.pl to IMCC was complete, maintaining backward compatibility was
the right thing. (So, if you're currently using assemble.pl to assemble
your language, consider moving it to IMCC sooner rather than later).



  The long running Objects thread
Discussions continued. A good deal of time this week was spent
discussing the overrideablility (there's got to be better word than
that...) of OO method dispatch for different languages (and at a
language level too I hope -- I like flexibility). Python for instance
seems to require that every step in the process be subject to override.
Dan pointed out that dispatch would end up being implemented as vtable
methods on per language Object PMCs so that messages from one language's
objects to another's would use the target language's dispatch rules.
Which seems rather cute (in a good way).

 -- Christopher Armstrong talks
about Python

 -- Dan on how it works.

  Intersegment branching
Leo Tötsch added a new opcode for intersegment branches, called
"branch_cs" which was his implementation of the fix that he and Jason
Gloudon had discussed while talking about problems with "eval". Dan
didn't think Parrot needed this and that we could just use a plain jump.
Leo pointed out that there were several places where this didn't quite
work, especially in the presence of JIT optimization. Dan didn't think
that didn't mean it wouldn't work, but reckoned that the cases Leo
pointed out were reasons he wanted to see intersegment jumps mediated by
subroutine calls. Leo followed up to this with an example. I c

Re: A proposal for separable verbs.

[Piers Cawley]

Austin Hastings <[EMAIL PROTECTED]> writes:

> --- "Joseph F. Ryan" <[EMAIL PROTECTED]> wrote:
>> If the final design stays the way it is now, there really won't be
>> a "lexer".  Instead, a perl6 grammar parses the data, and builds up
>> a huge match-object as it, well, matches.  This match object is then
>> munged into the optree.
>> 
>
> With this in mind, I'll say it again:
>
> Let's support separable verbs. 
>
> Here's how:
>
> # Note my arbitrary selection of _ as separation indicator. Feel free
> to replace this with something more appropriate:
>
> sub if($test, &block) 
>   _ elsif ($test, &block) is optional is floating is multi
>   _ elsunless ($test, &block) is optional is floating is multi
>   _ else (&block) is optional is fixed
> {
>   while (!$args[0].test) shift;
>   &args[0].block();
> }

Mmm... Smalltalk style message specifiers here we come...

 method Bool::ifTrue (&trueBlock) _ ifFalse (&falseBlock);

 ($a == $b).ifTrue { do_this() }
ifFalse { do_that() }

I really like this idea or something like it.

-- 
Piers