Re: String concatentation operator
Dan Sugalski wrote: The expensive part is the shared data. All the structures in an interpreter are too large to act on atomically without any sort of synchronization, so everything shared between interpreters needs to have a mutex associated with it. Mutex operations are generally cheap, but if you do enough of them they add up. Why do we need to use preemptive threads? If Parrot is a VM, then surely the threading can be implemented at its level, or even higher. If it is the VM that implements the threading, then its data structures don't need to be locked. The main problem with that approach is that the multithreading would not be able to preempt C-level callouts: but that could be solved by spawning a true thread only when code makes calls out of the parrot VM. Dave.
Re: Literals, take 2
On Wed, 2002-11-13 at 13:26, Angel Faus wrote:
>
> There are many ways to specify literal numeric values in perl, but
> they default to base 10 for input and output. Once the number has
Surely, Perl 6 will allow changing the radix on a more global scale.
use radix(16); # or something of the ilk
in which case, the default (ie, non-prefixed) radix will be some
property, which itself defaults to base 10.
In any case, you should present the radix prefix semantics globally,
and then indicate when and where you can imply the radix.
That will alleviate confusion on some of the fringe cases - or perhaps
the confusion is only mine. :-)
> been read by perl it becomes just a magnitude. That is it loses all
> trace of the way it was originally represented and is just a number.
> This code for instance prints the literal value 14.
>
> my $x = 14; # stores the integer 14 in $x
> print $x;
>
> You can represent the literal value in any other base, using the
> C syntax.
>
> For example:
>
> my $i = 2:101110;# binary
> my $j = 3:1210112; # tertiary
> my $k = 8:1270; # octal
>
> Printing these would give 46, 1310, and 696 respectively. When the
> base is greater than 10, there is a need to represent digits that are
> greater than 9.
>
> You can do this in two ways:
>
> =over
>
> =item *
>
> Alphabetic characters: Following the standard convention, perl will
> interpret the A letter as the digit 10, the B letter as digit 11, and
> so on.
>
> my $l = 16:1E3A7; # hexadecimal
>
> =item *
>
> Separating by dots: You can also write each digit in its decimal
> representation, and separate digits using the C<.> character.
>
> my $m = 256:255.255.255.0;# 256-base
>
> =back
>
> For example, the integer 30 can be written in hexadecimal base in two
> equivalent ways:
Do these ways have names?
>
> my $x = 16:1D
> my $x = 16:1.14
>
> These two representations are incompatible, so writing something like
> C<16:D.13> will generate a compile-time error.
>
> Also note that a compile-time error will be generated if you specify a
> "digit" that is larger than your radix can support. For instance,
>
> my $x = 3:23; # error
How does one specify a single digit in the... that second one there.
The extended notation.
my $x = 16:12; # 10:18
my $x = 16:12.; # 10:12 ?
Also, given an implied radix, can one use the second extended notation?
my $x = 4.5;# Same as 45 in base 10
use radix(16);
my $x = 14.8.10; # Same as 0x0d8a;
If so, what about the two digit ambiguity?
>
> Finally, you can create negative integers by prepending the C<->
> character.
To what? To the digits? To the radix?
>
> For example:
>
> my $x = 18;
> my $y = -18;
my $x = 10:18;
my $y = -10:18;
my $z = 10:-18;
On one hand, you've negated a base 10 number. OTOH, you've got a base
10 negative number. I can think in both directions, but I'm afraid
some folks may be confused with the first, whereas the second is clear
and just as messy.
>
> Perl allows the underline character, C<_>, to be placed as a separator
> between the digits of any literal number. You can use this to break
> up long numbers into more readable forms. There aren't any rules to
> it; you can use it however you like:
>
> 123_456_000.000 (floating point)
> 2:0110_1000 (binary)
> 16:FF_88_EE (hexidecimal)
>
> =section ** Floating-Point Numbers
>
> You can use the decimal representation of the number and the standard
> exponental notation.
>
> my $x = -2.542;
> my $x = 7.823e12;
Not wanting implementation to drive the language, but the parsing of
integer and numerical values may all be built upon above. Going back
to above, is radix parsing core to numerical parsing? (IOW, is a radix
prefix possible *everywhere* an integer is wanted, or is radix notation
its own beastie which then wants an integer type? [Much of the same
argument as above with negative numbers.])
my $x = 7.832e16:D; # error?
>
> Perl lets you operate integer numbers with floating-point numbers, so
> the following operation is correct:
>
> print 3.5 + 2; # prints 5.5
>
> You can use the C<_> separator too in Floating-Point numbers:
>
> my $x = 1312512.25; # floating-poing number
> my $x = 1_312_512.25; # the same
1_234.345_123
1_345.678_123e1_345;
>
> =section ** Pseudo-numbers
>
> The terms C<+Inf> and C<-Inf> represent positive and negative
> infinity; you may sometimes use these to create infinite lists.
>
> The value C ("Not a Number") may be returned by some functions
> or operations to represent that the result of a calculation (for
> example, division by zero) cannot be represented by a numeric value.
>
> =section * Literal strings
>
> Duble quotes or single quotes may be used around literal strings:
>
> print "Hello, world";
> print 'Hello, world';
>
> However, only double quotes "interpolate" variables and special
> character
[CVS ci] JIT/i386: 370% faster mops_p.pasm
JIT has big improvement in integer related programs but did lack to
improve real world i.e. PMC using apps.
I wanted to test, how much we can gain, by doing vtable calls directly
in JIT and did optimize 4 ops (dec_p, inc_p, if_p_ic, unless_p_ic)
(which happen to be used in mops_p.pasm's MOPS loop) - and the result
really is impressiv: 3,7 times faster execution.
The generated code replaces the call to Parrot_jit_{normal,cpfp}_op by
code that calls the vtable function directly, thus saving one funtion
call plus recalculating the address of parrot registers.
By defining macros to the standard functions, the code should be
compatible with different architectures, though I couldn't test this.
Have fun,
leo
[CVS ci] GC related string fixes
The biggest problem currently seems to be string_to_cstring. Some time ago, I made a change, that the returned cstr has the BUFFER_immobile_FLAG set, which should be the Right Thing(tm), *but* - though immobile strings don't move - the memory_pool, where these strings live, get freed at the end of compact_pool. So the best proabably would be, to allocate system memory for such strings. leo
Re: [perl #18445] [PATCH] Fix packfile initialization
Simon Glover (via RT) wrote: # New Ticket Created by Simon Glover # Please include the string: [perl #18445] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18445 > Applied, thanks leo
C#/Parrot Status
I've been working on some other stuff lately, so this is the first opportunity I've had to catch up on Parrot. I'm interested in the current status of the following within Parrot: - object/class support - fixed-sized integers and/or conversion opcodes - embedding of binary extension sections "Not Done Yet" is an acceptable answer. :-) Cheers, Rhys.
Re: C#/Parrot Status
Rhys Weatherley wrote: I've been working on some other stuff lately, so this is the first opportunity I've had to catch up on Parrot. I'm interested in the current status of the following within Parrot: - object/class support - fixed-sized integers and/or conversion opcodes - embedding of binary extension sections "Not Done Yet" is an acceptable answer. :-) and the correct answer too. IMHO a start would be to do fixed-sized integers + conversion ops. Please have a look at include/parrot/datatypes.h. I hope that there are all types you'll need. Can you specify, what opcodes you would need? Cheers, Rhys. leo
Re: Continuations
Damian Conway wrote:
my $iter = fibses();
for < <$iter> > {...}
(Careful with those single angles, Eugene!)
Operator << isn't legal when the grammar is expecting an
expression, right? The < must begin the circumfix <> operator.
Is the grammar being weakened so that yacc can handle it? The
rule engine is still talked about, but sometimes I get the
feeling that people don't want to depend on it.
That < <$iter> > syntax reminds me too much of C++.
- Ken
Re: String concatentation operator
On Mon, Nov 18, 2002 at 08:22:45AM +1100, Damian Conway wrote: > Luke Palmer asked: > > > Of course, there will be a pragma or something to instruct it to > > operate serially, yes? > > I doubt it. Unless there's a pragma to instruct threads to operate > serially. > > In any case, I'm not sure what such a pragma would buy you. The > ordering of evaluation would still be inherently unordered. If parrot had cheap threading within the same perl interpreter, then it might buy you something. Without the pragma, there is no reason why parrot should not use multiple threads (on a SMP machine) to evaluate the parts of a junction in parallel, so you'd have to have your perl level code capable of being re-entrant. With the pragma, you could at least specify that you want one thing to finish before the next starts, even though there is still no fixed order in which they take place. But I'm not sure if parrot is going to give the perl interpreter cheap threading. (Does the async IO mean that one parrot interpreter could internally co-operatively thread perl in some cases?) Nicholas Clark
Re: C#/Parrot Status
If memory serves me right, Leopold Toetsch wrote: > Please have a look at include/parrot/datatypes.h. I hope that there are > all types you'll need. It seems so ... but I'm not really certain about Float data types ... > Can you specify, what opcodes you would need? Hmm... I guess I can only quote the ECMA spec here ... conv.i1 Convert to int8, pushing int32 on stack conv.i2 Convert to int16, pushing int32 on stack conv.i4 Convert to int32, pushing int32 on stack conv.i8 Convert to int64, pushing int64 on stack conv.r4 Convert to float32, pushing F on stack conv.r8 Convert to float64, pushing F on stack conv.u1 Convert to unsigned int8, pushing int32 on stack conv.u2 Convert to unsigned int16, pushing int32 on stack conv.u4 Convert to unsigned int32, pushing int32 on stack conv.u8 Convert to unsigned int64, pushing int64 on stack conv.i Convert to native int, pushing native int on stack conv.u Convert to native unsigned int, pushing native int on stack Thanks to the polymorphic nature of the opcodes the "from" entry is in another table in ECMA But I guess conversions of lower integer data types to I registers and back would be a starting point ? Gopal -- The difference between insanity and genius is measured by success
Re: Literals, take 2
-- On 17 Nov 2002 11:09:53 -050 Bryan C. Warnock wrote: >On Wed, 2002-11-13 at 13:26, Angel Faus wrote: >> >> There are many ways to specify literal numeric values in perl, but >> they default to base 10 for input and output. Once the number has > >Surely, Perl 6 will allow changing the radix on a more global scale. Of course it will! But just about anything acn be changed with a grammer munge. Theoretically Perl 5 could add radix notation with a source filter. But we don't have to document that. I think that we should avoid refering to pragmas and modules as much as possible in the core documentation. That's a departure from Perl 5. Here's my case: * Were writing the spec. While that doesn't give us licence to be dense and unreadable, we should leave common case information (like documenting the radix pragma) for the tutorials. * Perl 6 will likely not have a standard set of modules and pragmas. As that is the case, we can't assume modules and pragmas in the docs. * Perl 6 can do just about any wild and crazy thing with a grammer munge. Instead of documenting pragmas like radix piecemeal, we should be beating the concept that a use declaration means all bets are off into everybody's heads (beating in a pleasant metaphorical sense. of course). When a use is seen that modules documentation should be grabbed, not the core docs. -Erik > >use radix(16); # or something of the ilk > >in which case, the default (ie, non-prefixed) radix will be some >property, which itself defaults to base 10. > >In any case, you should present the radix prefix semantics globally, >and then indicate when and where you can imply the radix. > >That will alleviate confusion on some of the fringe cases - or perhaps >the confusion is only mine. :-) > > >> been read by perl it becomes just a magnitude. That is it loses all >> trace of the way it was originally represented and is just a number. >> This code for instance prints the literal value 14. >> >> my $x = 14; # stores the integer 14 in $x >> print $x; >> >> You can represent the literal value in any other base, using the >> C syntax. >> >> For example: >> >> my $i = 2:101110;# binary >> my $j = 3:1210112; # tertiary >> my $k = 8:1270; # octal >> >> Printing these would give 46, 1310, and 696 respectively. When the >> base is greater than 10, there is a need to represent digits that are >> greater than 9. >> >> You can do this in two ways: >> >> =over >> >> =item * >> >> Alphabetic characters: Following the standard convention, perl will >> interpret the A letter as the digit 10, the B letter as digit 11, and >> so on. >> >> my $l = 16:1E3A7; # hexadecimal >> >> =item * >> >> Separating by dots: You can also write each digit in its decimal >> representation, and separate digits using the C<.> character. >> >> my $m = 256:255.255.255.0;# 256-base >> >> =back >> >> For example, the integer 30 can be written in hexadecimal base in two >> equivalent ways: > >Do these ways have names? > >> >> my $x = 16:1D >> my $x = 16:1.14 >> >> These two representations are incompatible, so writing something like >> C<16:D.13> will generate a compile-time error. >> >> Also note that a compile-time error will be generated if you specify a >> "digit" that is larger than your radix can support. For instance, >> >> my $x = 3:23; # error > >How does one specify a single digit in the... that second one there. >The extended notation. > >my $x = 16:12; # 10:18 >my $x = 16:12.; # 10:12 ? > >Also, given an implied radix, can one use the second extended notation? > >my $x = 4.5;# Same as 45 in base 10 > >use radix(16); >my $x = 14.8.10; # Same as 0x0d8a; > >If so, what about the two digit ambiguity? > >> >> Finally, you can create negative integers by prepending the C<-> >> character. > >To what? To the digits? To the radix? > >> >> For example: >> >> my $x = 18; >> my $y = -18; > >my $x = 10:18; >my $y = -10:18; >my $z = 10:-18; > >On one hand, you've negated a base 10 number. OTOH, you've got a base >10 negative number. I can think in both directions, but I'm afraid >some folks may be confused with the first, whereas the second is clear >and just as messy. > > >> >> Perl allows the underline character, C<_>, to be placed as a separator >> between the digits of any literal number. You can use this to break >> up long numbers into more readable forms. There aren't any rules to >> it; you can use it however you like: >> >> 123_456_000.000 (floating point) >> 2:0110_1000 (binary) >> 16:FF_88_EE (hexidecimal) >> >> =section ** Floating-Point Numbers >> >> You can use the decimal representation of the number and the standard >> exponental notation. >> >> my $x = -2.542; >> my $x = 7.823e12; > >Not wanting implementation to drive the language, but the parsing of >integer and numerical values may all be built upon above. Going
Re: Numeric Literals (Summary)
On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote: > Hmm, interesting. Just as an aside, this gives me an idea: would it be > feasible to allow the base to be specified as an expression instead of > a constant? (I'm pretty sure it would be useful.) For example: > > 4294967296:1.2.3.4 # working with a really big base, hard to grok > 2**32:1.2.3.4 # ah, much better > > 24*60*60:10 # one day in seconds, easy representation And the advantage of that over 24*60*60*10 would be ? > Or how about run-time evaluated versions? > > # Set a timer to run for either a day or an hour, depending > $timer = 60*60*($use_days ? 24 : 1):10 Then it is no longer a literal is it. Are we not just getting too carried away with all this base of literals. I also think -documentation is the wrong place to discuss this. Graham.
RE: Numeric Literals (Summary)
Graham Barr wrote: > On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote: > > Or how about run-time evaluated versions? > > > > # Set a timer to run for either a day or an hour, depending > > $timer = 60*60*($use_days ? 24 : 1):10 > > Then it is no longer a literal is it. True. But this might: $foo = [60*60*($use_days ? 24 : 1):10]; Larry said that could be the equivalent of: $foo = scalar(list(60*60*($use_days ? 24 : 1):10)); I've tried asking if lists are literals or not... but I've been Warnock'd. > I also think -documentation is the wrong place to > discuss this. Yes. There seems to be a bit language design going on under the subtext of documentation. We are here to ask questions that provoke Larry to disambiguate. Not come up with our own answers. If I can borrow a bit of time from my non-existant pool, I'll try to summarize the syntax issues... But aren't the 1*10:9, -2:1 or 2:-1, 0:0, 1:0, 37:aA, etc. issues exactly the type of questions we're supposed to be steering back to perl6-language? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: String concatentation operator
At 9:10 PM -0800 11/17/02, Dave Whipp wrote: Dan Sugalski wrote: The expensive part is the shared data. All the structures in an interpreter are too large to act on atomically without any sort of synchronization, so everything shared between interpreters needs to have a mutex associated with it. Mutex operations are generally cheap, but if you do enough of them they add up. Why do we need to use preemptive threads? If Parrot is a VM, then surely the threading can be implemented at its level, or even higher. If it is the VM that implements the threading, then its data structures don't need to be locked. The main problem with that approach is that the multithreading would not be able to preempt C-level callouts: but that could be solved by spawning a true thread only when code makes calls out of the parrot VM. Parrot's not just a VM--if we did our own threads that'd slow down JIT-generated code universally, or forbid the use of the JIT when running with threads, both of which are no good, not to mention all the fun we'd have recreating all the threading mistakes of the past. Plus we wouldn't be able to use multiple processors on systems that have them. It's not easy to do right, and there's no real benefit to be had in doing it at all, so we're not. System threads are the way to go for us. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String concatentation operator
At 2:57 PM + 11/18/02, Nicholas Clark wrote: But I'm not sure if parrot is going to give the perl interpreter cheap threading. (Does the async IO mean that one parrot interpreter could internally co-operatively thread perl in some cases?) Oh, it could do it preemptively. And parrot can (and, I think, will) provide inexpensive threading, but only in cases where there's minimal mutable data sharing. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continuations elified
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> The semantics of C would simply be that if it is given an
> iterator object (rather than a list or array), then it calls
> that object's iterator once per loop.
By extension, if it is NOT given an iterator object, will it appear to
create one?
That is, can I say
for (@squares)
{
...
if $special.instructions eq 'Advance three spaces'
{
$_.next.next.next;
}
...
}
or some other suchlike thing that will enable me to consistently
perform iterator-like things within a loop, regardless of origin?
(Oh please! Let there be one, and for love of humanity, let it be
called "bork". Pleasepleaseplease!!! It's a shorthand form of "bind or
kontinue", really it is. :-) :-) :-))
> but I think that's...err...differently right.
The verb form is "euph" ? Or "euphemise"?
> Otherwise I can't see how one call call an iterator directly in a
> for loop:
>
> for {...}
Which suggests that fibs is a coroutine, since otherwise its return
value is weird. But
while { ... }
suggests instead behavior rather like while (!eof()), although the
diamond is strange.
So in general, diamonded-function-call implies coroutine/continuation?
> But I could certainly live with it not having that, in which case
> the preceding example would have to be:
>
> my $iter = fibs();
> for <$iter> {...}
That's not horrible, but it does even more damage to expression
folding.
> and, if your coroutine itself repeatedly yields a iterator
> then you need:
>
> my $iter = fibses();
> for < <$iter> > {...}
>
> (Careful with those single angles, Eugene!)
To disagree, vile Aussie! To be looking at perl5's adornmentless
diamond:
perlopentut sez:
POT> When you process the ARGV filehandle using ,
POT> Perl actually does an implicit open on each file in @ARGV.
POT> Thus a program called like this:
POT>$ myprogram file1 file2 file3
POT> Can have all its files opened and processed one at a time
POT> using a construct no more complex than:
POT>while (<>) {
POT># do something with $_
POT>}
This *ought* to work the same in p6.
Since you can modify @ARGV in a pure string context, what's the real
behavior?
If I say: while (<>) {print;} I'm asking for file-scan behavior.
If I say: for (@ARGV) { print; } I'm asking for array-scan behavior.
If I say: for (<@ARGV>) { print; } I'm asking for trouble?
Proposal:
@ARGV is a string array, but <> is topicized in :: (or whatever the
default execution context is called) to iterate over @_MAGIC_ARGV,
which is := @ARGV but of a different class whose iterate behavior
performs an open "<$_" in the background, and iterates serially over
each entry in @ARGV once EOF occurs.
my CoolFileType @MY_ARGV := @ARGV; # Same data, different interface.
for (<@MY_ARGV>) {
print;
}
This is kind of neat, but there needs to be a solid, readable
typecasting mechanism to facilitate the multiple flavors of iteration
-- to convert from one iterator format to another, for example.
> > They elegantify stuff.
>
> If you're going to talk Merkin, talk it propericiously:
>
> "They elegantificatorize stuff"
We Merkuns don't add, we shorten. That's "elify", to wit:
"Z'at elify the code?"
"Elify - no."
Reduction of length, combined with conservation of ambiguity. Win win
win.
=Austin
__
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com
Re: Numeric Literals (Summary)
On Mon, Nov 18, 2002 at 10:47:17AM -0600, Garrett Goebel wrote: > I've tried asking if lists are literals or not... but I've been Warnock'd. I have comments to make on several things posted recently. I'm waiting for my boss to ask our legal department if I can contribute. There may be others doing the same thing. > > I also think -documentation is the wrong place to > > discuss this. > > Yes. There seems to be a bit language design going on under the subtext of > documentation. We are here to ask questions that provoke Larry to > disambiguate. Not come up with our own answers. I think that they are. There are some things here that we know the answer to they've been discussed already and someone remembers what was decided. There are also some things that we don't know the answer to because they haven't been discussed at all. > If I can borrow a bit of time from my non-existant pool, I'll try to > summarize the syntax issues... But aren't the 1*10:9, -2:1 or 2:-1, 0:0, > 1:0, 37:aA, etc. issues exactly the type of questions we're supposed to be > steering back to perl6-language? I think you're right about the need to collate the stuff nobody's mentioned yet into a set of coherent questions to ask. andrew -- Aries: (March 21 - April 19) Someday, you'll look back on all of this and laugh very, very bitterly. msg24323/pgp0.pgp Description: PGP signature
Re: Numeric Literals (Summary)
On Mon, Nov 18, 2002 at 03:14:52PM +, Graham Barr wrote: > On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote: > > 24*60*60:10 # one day in seconds, easy representation > > And the advantage of that over 24*60*60*10 would be ? Well, for one thing, my version means 1 day and yours means 10 days. > Are we not just getting too carried away with all this base > of literals. Perhaps. I don't feel strongly enough about it to argue it if people don't like the idea. > I also think -documentation is the wrong place to discuss this. In all seriousness, where would you suggest it should be discussed? I thought part of the purpose of this list was to define all the corner cases...surely, whether or not the radix can be an expression is a corner case. --Dks
RE: Glossary?
From: Dave Storrs [mailto:[EMAIL PROTECTED]] > On Thu, Nov 14, 2002 at 02:29:38PM -0600, Garrett Goebel wrote: > > It is interesting that no one has yet taken the time to > > start defining the terms we're using. > > Good point. I volunteered to be keeper of the glossary a while ago, > but I never actively started creating one. That said, let's make this > the first entry. Comments and constructive criticisms welcomed from > all comers. I'd prefer to see glossary entries similar the newspaper article format: o catchy title o one paragraph summary o detail Or to restate it in POD: =pod =head1 TERM B =head1 SYNOPSIS A literal is a represention of a fixed value. =head1 DEFINITION blah blah blah =head1 SEE ALSO L, L, L, L, L, L, =cut > > Term: literal > > Definition: A literal is a way of writing a particular > fixed value. [...] While I enjoy detail, anecdotes, etymology, related concepts, etc. That said, I'd like to see glossary entries written with an extreme economy of words. For example, to nitpick your first sentence. I'd rewrite it as: A literal is a representation of a fixed value. 1) "represent" encompasses write, type, sign, say, etc... 2) "particular" is superfluous I'd also try to limit the entry to the word being defined; refering related topics to their own entries. In this case, I'd put the discussion of literal arrays and array of literals into their own entries, and link to them from the "literal" and "array" entries. > Examples of literals: 7, 3.1415926535897932384, 'Fourscore and seven', > 0xDEADBEEF, b10100011, 'z'. > > Examples of non-literals: $foo, @bar, %baz, jaz() How about however the symbolic constant: my $foo is constant => 1; Do we draw the distinction between a symbolic constant and a literal constant? And what is the difference between a literal, literal constant, and literal value? I'm asking because I really don't know. Are they all short-hand for literal constant value? > NOTES: > > (*) There was a long thread a little while ago on how arrays would be > written. I believe the final decision was that [] was the array > composer, but I'm not sure. Can someone confirm or deny this for me? > (I'll go dig through the archives after I send this, but if someone > knows offhand, it would save time.) No, [] is the explicit list composer Apoc 2, RFC 175: > > explicit list composer: > > [1,2,3] whereas Apoc 2, RFC 009: > > @foo = (1,2,3); > > will supply an unbounded list context to the right side, but > > (@foo, @bar) = (@bar, @foo) > > will supply a context to the right side that requests two > scalar values that are array references. and Apoc 2, RFC 009: > That is, all variables may be thought of as references, not > just scalars. And in that case, subscripts always dereference > the reference implicit in the array or hash named on the left. > > This has two major implications, however. It means that Perl > programmers must learn to write @foo[1] where they used to > write $foo[1]. Which leaves me wondering how do we compose an anonymous array? > First, when I originally started writing these entries, they were > substantially shorter. As I look at them now, I wonder if I haven't > written something that is too long for a glossary entry, and would > better be used for main documentation (or bird cage liner, if you are > unkind)--what do you all think? I agree. I don't mind a lengthy detailed definition and historical or etymological notes... But someone should be able to look at a glossary entry and get the jist of the term as quickly as possible. Which is why I suggested a SYNOPSIS followed by a lengthier DESCRIPTION. > Second, what format should this document be kept in? I know that POD > is the standard, but I feel that POD by itself is a poor fit for a > glossary, since a glossary needs very little presentation but a lot of > structure (for example, you want to group the definition with the > term, and you might want to include attributes--is this a beginner, > intermediate, advanced, or gurus-only concept? Does this term refer > to a core language concept, or is it used primarily in a module? > Which module? And so on). POD provides enough structure: TERM, SYNOPSIS, DEFINITION, SEE ALSO. And we can certainly provide attributes if needed. > Does anyone strongly object if I keep it in a mixture of XML and POD > (that is, XML containing POD)? If so, what should I keep it in? If > not, does anyone have suggestions on what attributes we should have? POD. TERM, SYNOPSIS|SUMMARY, DESCRIPTION|DEFINITION, SEE ALSO -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Numeric Literals (Summary)
On Monday, November 18, 2002, at 07:14 AM, Graham Barr wrote: Are we not just getting too carried away with all this base of literals. I also think -documentation is the wrong place to discuss this. Yep. I'll try and come up with a summary today or tomorrow that marks all the *known* behaviors, and marks all the unknown behaviors or proposed additions. If we want any of the proposed additions, we'll have to ask for judgments on them. Gimme till tomorrow to summarize the radix/literal stuff so we can regroup and ask questions. In the meantime, we're still trying to figure out the best way(s) to specify "this number should always be printed in hex format" or "when converting from a string, always treat the string as being in octal format". (formatted in/out from strings). Several proposals, but I think we could use a bit more discussion on what people want... MikeL
Numeric Literals (Summary 2)
--- Numeric Literals --- decimal notation: 123 # int 123 0123 # int 123 123.0 # num 123.0 -123 # int -123 0_1.2_3 # ok _01.23 # wrong 01.23_ # wrong 01_._23 # wrong 1__2# wrong exponential notation: -1.23e4 # num -1.23E4 # num (identical) 1.23_e_4# wrong bin/oct/hex notation: 0b0110 # bin 0c0123 # oct 0x00ff # hex 0x00fF # hex, == 0x00ff 0x00FF # hex, == 0x00ff -0xff # ok -0x00ff # ok 0xf_f # ok 0x_ff # ok explicit radix: (radix 2-32) 20:1gj # base 20 20:1GJ # base 20 (identical) 20:1.G.J # base 20 (identical) 20:1_G_J # base 20 (identical) 20:1.16.19 # base 20 (identical) 20:1_16_19 # NOT identical; == 20:11619 20:1.1_6.19 # WRONG: dotted form may not have underlines -20:1GJ # base 20 (negative) -20:1.16.19 # base 20 (negative) 62:zZ # base 62 (?) 62:z.Z # base 62 (identical?) 62:z_Z # base 62 (identical?) 62:Zz # base 62 (not identical?) (radix 33-RADIX_MAX) 256:0.253.254.255 # base 256 256:0_253_254_255 # base 256 Other issues w/ literals: - radix <= 32, alpha digits may be upper or lowercase - underlines may appear ONLY between digits - dotted form may therefore not have underlines - radix < 2 throws error - negative sign goes before radix, e.g. -20:1GJ, in order to match usage in cases like -0x00ff. - need to specify RADIX_MAX - can't have runtime radix, e.g. 2**8:10, because : binds tighter. can't say (2**8):10, because not a literal anymore, and ':' is used for adverbial in many locations (ambiguous). - need to verify that 0b1, 0c1, 0x1 are still allowed in addition to explicit radix (but seems appropriate to leave them in, given their frequency.) MikeL
Design Team Issues: Numeric Types
Here are some issues we need the design team to decide.
(A) How shall C-like primitive types be specified, e.g. for binding
to/from C library routines, etc?
Option 1: specify as property
my numeric $a is ctype("unsigned long int"); # standard C type
my numeric $b is ctype("my_int32"); # user-defined
my numeric $c is ctype("long double");
my int $a is range(1000..1255) is unchecked; # auto-infer 8bit
Option 2: specify as type
my u_long $a;# standard C type
my long_double $c;
Option 3: ???
(See p6d discussion, "Numeric Types")
(B) Need to know the root of the numeric types
Option 1:
numeric (mostly abstract base class)
- num
- int
Option 2:
num (floating point 'num' is the base class)
- int
Option 3: ???
(C) If C-like primitives are builtin, need to know what their type
names/aliases will be, and need to verify whether _ALL_ will have
promoted counterparts, e.g. numeric -> Numeric, u_long -> U_Long, etc.
# (TEMPORARY) need final list of numeric types & any aliased names,
# assuming we don't want to support *all* of these names (tho we could)
# the base numeric type
numeric
# signed integers
int
int8 char
int16short short_int
int32long long_int
int64quad long_longlong_long_int
# unsigned integers
bit
uint u_int
uint8u_int8 u_charbyte
uint16 u_int16u_short u_short_int
uint32 u_int32u_longu_long_int
uint64 u_int64u_quadu_long_longu_long_long_int
# floating point numbers
num (== double)
float
double
long_double
MikeL
Re: Literals, take 2
On Thu, Nov 14, 2002 at 07:40:38PM +0100, Angel Faus wrote: : I would preferer to limit the usage of "letter notation" to just base : 11-36, and have n:F = n:f for every n. : : It is simpler, and we can always use de "dot notation" for bigger : bases. I'm thinking at the moment that I'd like to go back to the Ada notation and use # for the radix, and rather that using dots, use colons. So an IP address would actually look like 256#192:168:1:1 (But only on a big-endian machine! Use v-strings instead!) The dot stays the radix point, and there's no conflict with 10#3.14159 and such. It's still not possible to write an IPv6 address, but those ought to be strings anyway, not numbers. They may need some specific syntactic relief. Maybe we need x-strings as well as v-strings. I don't think there's much conflict between # for radix and # for comments, by the way. I also think the radix is limited to a literal integer. -10#42 is just -(10#42). Larry
Re: Numeric Literals (Summary 2)
On Monday, November 18, 2002, at 10:57 AM, Michael Lazzaro wrote: Eek, that one was short-lived! No problem: if Larry decides on Ada syntax, the following changes happen: s/:/#/ (for explicit radix) s/./:/ (for dotted -- er, coloned -- form) - floating point becomes allowed in explicit radix (and 0b,0c,0x) Everything else stays the same. Other issues w/ literals: - radix <= 32, alpha digits may be upper or lowercase - underlines may appear ONLY between digits - dotted form may therefore not have underlines - radix < 2 throws error - negative sign goes before radix, e.g. -20:1GJ, in order to match usage in cases like -0x00ff. - need to specify RADIX_MAX - can't have runtime radix, e.g. 2**8:10, because : binds tighter. can't say (2**8):10, because not a literal anymore, and ':' is used for adverbial in many locations (ambiguous). - need to verify that 0b1, 0c1, 0x1 are still allowed in addition to explicit radix (but seems appropriate to leave them in, given their frequency.) MikeL
RE: [perl #18170] [PATCH] very complete lexical scope implementation
> -Original Message- > From: kj [mailto:[EMAIL PROTECTED]] > > I'm getting mixed results building from this morning's CVS -- on > Linux/x86 I only get the t/op.lexicals.t failures, but on Darwin/PPC I'm > also getting failures in t/pmc/scratchpad.t. Would your patch have > anything to do with the latter? I'm still learning the internals, and > haven't quite figured that out yet. With a fresh checkout I am getting no errors in Linux/x86, however I don't have access to a Darwin/PPC box. Would you mind getting the latest from CVS and try again on Darwin/PPC? As much detail as you can send me about any failures would be appreciated. Thanks. -- Jonathan Sillito
Re: C#/Parrot Status
Gopal V said: > If memory serves me right, Leopold Toetsch wrote: > > > Please have a look at include/parrot/datatypes.h. I hope that there are > > all types you'll need. > > It seems so ... but I'm not really certain about Float data types ... > > > Can you specify, what opcodes you would need? > > Hmm... I guess I can only quote the ECMA spec here ... > conv.i1 Convert to int8, pushing int32 on stack > conv.i2 Convert to int16, pushing int32 on stack > conv.i4 Convert to int32, pushing int32 on stack > conv.i8 Convert to int64, pushing int64 on stack > conv.r4 Convert to float32, pushing F on stack > conv.r8 Convert to float64, pushing F on stack > conv.u1 Convert to unsigned int8, pushing int32 on stack > conv.u2 Convert to unsigned int16, pushing int32 on stack > conv.u4 Convert to unsigned int32, pushing int32 on stack > conv.u8 Convert to unsigned int64, pushing int64 on stack > conv.i Convert to native int, pushing native int on stack > conv.u Convert to native unsigned int, pushing native int on stack This might be a stupid question, but are this datatypes going to be PMCs? > Gopal -- Alin
RE: Numeric Literals (Summary 2)
Michael Lazzaro wrote: > > decimal notation: > 123 # int 123 > 0123 # int 123 [...] > 0c0123 # oct [...] > - need to verify that 0b1, 0c1, 0x1 are still allowed Found a problem: perl -e "print 0123" gives: 83 perl -e "print 0c0123" gives: Bareword found where operator expected at -e line 1, near "0c123" (Missing operator before c0123?) syntax error at -e line 1, next token ??? Execution of -e aborted due to compilation errors. In perl5, octel is signified by the leading zero. There is no 0c0123 notation. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Literals, take 2
On Mon, Nov 18, 2002 at 10:59:07AM -0800, Larry Wall wrote:
> On Thu, Nov 14, 2002 at 07:40:38PM +0100, Angel Faus wrote:
> : I would preferer to limit the usage of "letter notation" to just base
> : 11-36, and have n:F = n:f for every n.
> :
> : It is simpler, and we can always use de "dot notation" for bigger
> : bases.
>
> I'm thinking at the moment that I'd like to go back to the Ada notation
> and use # for the radix, and rather that using dots, use colons. So
> an IP address would actually look like
>
> 256#192:168:1:1
>
> (But only on a big-endian machine! Use v-strings instead!)
Why only on big-endian ? This is a just a number. To use it
as an IP address you would need to pack it with pack("N",256#192:168:1:1)
which should work on any endian machine. Or am I missing something
Graham.
Re: Numeric Literals (Summary 2)
On Monday, November 18, 2002, at 11:37 AM, Garrett Goebel wrote: In perl5, octel is signified by the leading zero. There is no 0c0123 notation. Right, but on p6l we had been talking about eliminating the assumed octalness of 0123, therefore requiring us to come up with an alternate syntax, e.g. 0c0123. Because assuming octalness on leading zero is a back-@$$ed affront to humanity that leads to things like: 0123 != '0123' MikeL
RE: Numeric Literals (Summary 2)
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]] > On Monday, November 18, 2002, at 11:37 AM, Garrett Goebel wrote: > > In perl5, octal is signified by the leading zero. There is no 0c0123 > > notation. > > Right, but on p6l we had been talking about eliminating the assumed > octalness of 0123, therefore requiring us to come up with an > alternate syntax, e.g. 0c0123. Because assuming octalness on > leading zero is a back-@$$ed affront to humanity that leads to > things like: > > 0123 != '0123' I don't know... it probably looks fine to most C and Perl programmers. And I still find it very confusing that you wrote: > - need to verify that 0b1, 0c1, 0x1 are still allowed When 0c1 has never been allowed in any exist perl implementation. Though I'd have to say it looks like a good replacement for the leading-zero. I went back through those posts, and I found where you suggested 0c0123... but I can't find a post from Larry confirming it. It would helpful if there were more citations of the A&E's, and even perhaps links to the mailing list posts where Larry definitively comes down on one side or another. In the same vein, it'd be nice if syntax developed on the documentation list to flush out ambiguities or propose syntax workarounds were marked as such. When reading some of the summaries, I've found myself wondering what parts come from the A&E's, which have Larry & Damian since reversed or altered, and which are suggestions from the documentation team... -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Design Team Issues: Numeric Types
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
> (A) How shall C-like primitive types be specified, e.g. for binding
> to/from C library routines, etc?
>
>Option 1: specify as property
>
> my numeric $a is ctype("unsigned long int"); # standard C type
> my numeric $b is ctype("my_int32"); # user-defined
> my numeric $c is ctype("long double");
>
> my int $a is range(1000..1255) is unchecked; # auto-infer 8bit
Just to clarify: I think of the latter (C) for efficient
packing into arrays (e.g. a 5-bit range can be packed efficiently,
even though there is no 5-bit c-type): binding to C routines is
probably best done explicity.
The C property would enable performance
optimizations. Checked-ranges probably catch a few more
bugs, though.
Dave.
Re: Unifying invocant and topic naming syntax
On Mon, Nov 18, 2002 at 08:05:47AM +1100, Damian Conway wrote:
: I still think my original:
:
: sub bar(; $foo = $topic) is given($topic) {...}
:
: is the appropriate compromise.
Won't fly. Referring to something lexical before it's declared is
a no-no. I think we need some other way of indicating the outer topic
if we're gonna use it as a default, and I think we do want that.
Perhaps it's a good time for a real keyword for use in defaults:
sub bar(; $foo = topic) {...}
That would let us work it nicely for arrays too:
sub bar(*@args = [topic]) {...}
Without the [], people might get confused about what to do with a $_
containing an array reference. But maybe that means it should really
be a magical variable so we can distinguish
sub bar(*@args = $) {...} # default to [$_]
sub bar(*@args = @$) {...} # default to @$_
What might be is an interesting, er, topic.
Larry
Re: Unifying invocant and topic naming syntax
Larry Wall wrote:
On Mon, Nov 18, 2002 at 08:05:47AM +1100, Damian Conway wrote:
: I still think my original:
:
: sub bar(; $foo = $topic) is given($topic) {...}
:
: is the appropriate compromise.
Won't fly. Referring to something lexical before it's declared is
a no-no.
I would maintain that that depends on the associativity of C. ;-)
But you mean in a strict left-to-right parsing sense.
I think we need some other way of indicating the outer topic
if we're gonna use it as a default, and I think we do want that.
I think so too.
Perhaps it's a good time for a real keyword for use in defaults:
sub bar(; $foo = topic) {...}
That would have to be:
sub bar(; $foo = topic) is given($whatever) {...}
wouldn't it? Otherwise the topic is C.
Anyway, I think a C keyword is NQR.
For a start, it introduces a (rather too) subtle difference between:
sub bar($foo = topic) is given($whatever) {...}
and:
sub bar($foo is topic) is given($whatever) {...}
not to mention the pain in continually needing to explain why this is okay:
sub bar($foo is topic = topic) is given($whatever) {...}
but this is not:
sub bar($foo = topic is topic) is given($whatever) {...}
Hm. Given that the topic is in some sense a property of the lexical
scope of the subroutine body, this might be a possibility:
sub bar($foo is MY.topic) is given($whatever) {...}
But I think there's a better solution. See below.
That would let us work it nicely for arrays too:
sub bar(*@args = [topic]) {...}
Without the [], people might get confused about what to do with a $_
containing an array reference. But maybe that means it should really
be a magical variable
Yep.
so we can distinguish
sub bar(*@args = $) {...} # default to [$_]
sub bar(*@args = @$) {...} # default to @$_
What might be is an interesting, er, topic.
I would argue it ought to be just $_, which is, after all,
the One True Topic. And conveniently lexically predeclared in all scopes.
I would also argue that it ought not be called anything else.
Surely don't want two specially named variables for the topic?
Damian
Re: Continuations
Ken Fox wrote:
Damian Conway wrote:
my $iter = fibses();
for < <$iter> > {...}
(Careful with those single angles, Eugene!)
Operator << isn't legal when the grammar is expecting an
expression, right?
Right.
The < must begin the circumfix <> operator.
Or the circumfix <<...>> operator. Which is the problem here.
Is the grammar being weakened so that yacc can handle it?
Heaven forbid! ;-)
> The rule engine is still talked about, but sometimes I get the
feeling that people don't want to depend on it.
That's not the issue.
That < <$iter> > syntax reminds me too much of C++.
Yes. But since iterating an iterator to get another iterator that
is immediately iterated will (I sincerely hope!) be a very rare
requirement, I doubt it will be anything like the serious inconvenience
it is in C++.
Damian
Re: Continuations elified
Austin Hastings asked:
By extension, if it is NOT given an iterator object, will it appear to
create one?
Yep.
That is, can I say
for (@squares)
{
...
if $special.instructions eq 'Advance three spaces'
{
$_.next.next.next;
}
...
}
or some other suchlike thing that will enable me to consistently
perform iterator-like things within a loop, regardless of origin?
If, by C<$_.next.next.next;> you mean "skip the next three elements
of @squares", then no. $_ isn't an alias to the implicit iterator
over @squares; it's an alias for the element of @squares currently
being iterated.
You want (in my formulation):
my $dance = Iterator.new(@squares);
for $dance {
...
if $special.instructions eq 'Advance three spaces' {
$dance.next.next.next;
}
...
}
(Oh please! Let there be one, and for love of humanity, let it be
called "bork". Pleasepleaseplease!!! It's a shorthand form of "bind or
kontinue", really it is. :-) :-) :-))
"Brain on raw krack" more like it ;-)
So in general, diamonded-function-call implies coroutine/continuation?
That's the problem. I can't see how that works syntactically.
To disagree, vile Aussie! To be looking at perl5's adornmentless
diamond:
>
If I say: while (<>) {print;} I'm asking for file-scan behavior.
Yes. Special case.
If I say: for (@ARGV) { print; } I'm asking for array-scan behavior.
Yes.
If I say: for (<@ARGV>) { print; } I'm asking for trouble?
Under my proposal, you're saying:
* Grab next element of @ARGV
* Iterate that element.
*Unless* the elements of @ARGV in Perl 6 are actually special Iterator-ish,
filehandle-ish objects that happen to also stringify to the command-line
strings. Hm.
Proposal:
Seemed very complex to me.
That's "elify", to wit:
"Z'at elify the code?"
"Elify - no."
Damian
Re: String concatentation operator
Damian Conway wrote: BTW, in thinking about it further, I realize that Dan is going to have to tackle this issue anyway. There's fundamentally no difference in the exigencies of: $junction = $x | $y | $z; foo($junction);# Call foo($x), foo($y), and foo($z) # in parallel and collect the results # in a disjunction Looking at that code, I'm wondering how you pass a junction. Suppose I want to pass a junction to a subroutine instead of calling the sub with each value of the junction... how would I do that? m:att d:iephouse and $junction = &f | &g | &h; $junction($x); # Call f($x), g($x), and h($x) # in parallel and collect the results # in a disjunction Damian
Re: String concatentation operator
matt diephouse wrote:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
# in parallel and collect the results
# in a disjunction
Looking at that code, I'm wondering how you pass a junction. Suppose I
want to pass a junction to a subroutine instead of calling the sub with
each value of the junction... how would I do that?
Tell the sub that it's expecting an undistributed junction as its argument:
sub foo($param is junction) {...}
Damian
Re: String concatentation operator
At 9:05 AM +1100 11/19/02, Damian Conway wrote:
matt diephouse wrote:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
# in parallel and collect the results
# in a disjunction
Looking at that code, I'm wondering how you pass a junction.
Suppose I want to pass a junction to a subroutine instead of
calling the sub with each value of the junction... how would I do
that?
Tell the sub that it's expecting an undistributed junction as its argument:
Hrm. What happens if the junction is then used as an iterator?
$junction = File::Open("foo") | File::Open("bar);
for (<$junction>) {
...
}
Which could get interesting if inside the for loop the code creates
more junctions and iterates over them. (Potentially ad infinitum)
And here I thought Quantum INTERCAL was a joke... :)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: C#/Parrot Status
Gopal V wrote: If memory serves me right, Leopold Toetsch wrote: ^^^... Your mailer should know ;-) Hmm... I guess I can only quote the ECMA spec here ... conv.i1 Convert to int8, pushing int32 on stack truncate to [-128..127]? And why the push? What is the behaviour on overflow? conv.i8 Convert to int64, pushing int64 on stack Datatypes bigger then INTVAL would need a PMC as storage. Gopal leo
Re: C#/Parrot Status
Iacob Alin wrote: This might be a stupid question, but are this datatypes going to be PMCs? Only types bigger then our current native types: INTVAL typically 32 bit long on 32 bit machines FLOTVAL typically double Alin leo
Re: C#/Parrot Status
On Mon, 18 Nov 2002, Iacob Alin wrote: > > Hmm... I guess I can only quote the ECMA spec here ... > > conv.i1 Convert to int8, pushing int32 on stack > > conv.i2 Convert to int16, pushing int32 on stack [etc.] > This might be a stupid question, but are this datatypes going to be PMCs? It's a very good question, actually. The answer is probably something like "ones that can be easily emulated with native types will probably not need to be PMCs; the others probably will." Two examples: 1. If your INTVAL is only 32 bits, then handling 64-bit ints will probably have to be done with a PMC. 2. If your short, int, and long are all 64 bits, then handling the int16 and int32 types might have to be done with PMCs (depending on the precise requirements for those types, which I don't know.) -- Andy Dougherty [EMAIL PROTECTED]
Re: C#/Parrot Status
Leopold Toetsch wrote: > > If memory serves me right, Leopold Toetsch wrote: > >^^^... > > Your mailer should know ;-) That's his mailer talking. It always does that. :-) > > Hmm... I guess I can only quote the ECMA spec here ... > > conv.i1 Convert to int8, pushing int32 on stack > > truncate to [-128..127]? And why the push? Gopal was listing the IL opcodes, which are stack based. They pop a value, convert, and then push a new value. The stack cannot hold int8 values directly, so "conv.i1" truncates, sign-extends back to int32, and then pushes that. In Parrot syntax, it would probably be: conv.int8 dstreg, srcreg conv.uint32 dstreg, srcreg (etc) > What is the behaviour on overflow? IL has two sets of conversion opcodes. One which truncates, ignoring overflow. And the other which raises an exception on overflow. It also has two sets of arithmetic operators (add, sub, mul) that handle the "no overflow" and "overflow" cases. (Overflow handling isn't needed for div, because it cannot overflow). Overflow handling would be nice, but we can work around it in the same way we worked around it for JVM (with a helper library). Support for unsigned types is more important. The list of types in "datatypes.h" looks good. The one exception was "signed and unsigned integers the same size as a pointer". e.g. the C "intptr_t" type. Perhaps INTVAL already handles that? Cheers, Rhys.
Re: C#/Parrot Status
If memory serves me right, Leopold Toetsch wrote: > > > Hmm... I guess I can only quote the ECMA spec here ... > > conv.i1 Convert to int8, pushing int32 on stack > > > truncate to [-128..127]? And why the push? IL is a fully stack language ... pop int32, trunc, push int8 ... Yes, truncate is the required operation . I guess sign-extension is also present for up conversion ... > What is the behaviour on overflow? *.ovf suffixed instructions like (conv.i1.ovf) exist seperately .. but that could be remedied by an explicit check ? ... > Datatypes bigger then INTVAL would need a PMC as storage. Ok. Otherwise this would complicate register handling ? (jvm allocates 2 adjacent local variables for a long and double .. *yow*) Gopal -- The difference between insanity and genius is measured by success
Re: Continuations elified
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings asked:
> > That is, can I say
> >
> > for (@squares)
> > {
> > ...
> > if $special.instructions eq 'Advance three spaces'
> > {
> > $_.next.next.next;
> > }
> > ...
> > }
> >
> > or some other suchlike thing that will enable me to consistently
> > perform iterator-like things within a loop, regardless of origin?
>
> If, by C<$_.next.next.next;> you mean "skip the next three elements
> of @squares", then no. $_ isn't an alias to the implicit iterator
> over @squares; it's an alias for the element of @squares currently
> being iterated.
>
> You want (in my formulation):
>
> my $dance = Iterator.new(@squares);
> for $dance {
> ...
> if $special.instructions eq 'Advance three spaces' {
>$dance.next.next.next;
> }
> ...
> }
How'zat, again? What is the means for extracting the actual VALUE of
$dance? And why is that different for $_-as-iterator?
IOW:
my Iterator $dance = ...;
for <$dance> {
print $_; # should this print the current dance, -> $_ by default?
print $dance;
# Should the above be ".value()"
# or ".next()"
# or ".toString()" ?
print <$dance>; # Obviously "get next value and advance" a la p5
}
Also, in your formulation:
> my $dance = Iterator.new(@squares);
> for $dance {
What happens when iterators require magic state info? It seems more
appropriate to define a CLASS.iterator method, which overloads a
simplistic default. ("fail" in scalar cases, iterative for Array and
Hash)
> > (Oh please! Let there be one, and for love of humanity, let it be
> > called "bork". Pleasepleaseplease!!! It's a shorthand form of "bind
> or
> > kontinue", really it is. :-) :-) :-))
>
> "Brain on raw krack" more like it ;-)
Whatever! As long as I get to say:
for my <@Swedish> -> $chef {
$chef.bork.bork.bork;
}
Perlmuppets, anyone?
> > So in general, diamonded-function-call implies
> coroutine/continuation?
>
> That's the problem. I can't see how that works syntactically.
I was thinking in terms of "reading", not "parsing" -- that is, "when a
coder reads diamonded-function-call, the reflex will be 'this is a
continuation'" -- valuable clues.
> > To disagree, vile Aussie! To be looking at perl5's adornmentless
> > diamond:
> >
> > If I say: while (<>) {print;} I'm asking for file-scan behavior.
>
> Yes. Special case.
But a special case of WHAT?
> > If I say: for (<@ARGV>) { print; } I'm asking for trouble?
>
> Under my proposal, you're saying:
>
> * Grab next element of @ARGV
> * Iterate that element.
That's the problem. Why would the second point "* Iterate that element"
happen? We've already GOT a flattener. If I want recursive iteration I
can say:
for (<*@ARGV>) { print; }
or maybe
for (*<@ARGV>) { print; }
I can't be sure.
> *Unless* the elements of @ARGV in Perl 6 are actually special
> Iterator-ish,
> filehandle-ish objects that happen to also stringify to the
> command-line
> strings. Hm.
I thought of that one first, but discarded it.
> > Proposal:
>
> Seemed very complex to me.
It's because I discarded the "@ARGV is magic that stringifies" option.
In other words, let @ARGV be normal, first and foremost. Then apply
magic to it.
That way, I can argue for being able to apply the SAME magic to
something else, rather than trying to fight with having to reimplement
the @ARGV magic class.
my @file_names = ( list of strings );
my FileIterator @argv_alike := @file_names;
while (<@argv_alike>) {
...
}
Now the question is, how do I get it into $_/@_/whatever_, so that I
can use <> instead of <@argv_alike>? (I avoid simply slapping it into
@_ because I vaguely recall something about the inevitable demise of
@_-as-arglist etc. But that was before the weekend, when there were
more brain cells.)
>
Warning: File iterator used in void context. Possible loss of data.
=Austin
__
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com
RE: Unifying invocant and topic naming syntax
Damian Conway:
# Larry Wall wrote:
# > On Mon, Nov 18, 2002 at 08:05:47AM +1100, Damian Conway wrote:
# > : I still think my original:
# > :
# > : sub bar(; $foo = $topic) is given($topic) {...}
# > :
# > : is the appropriate compromise.
# >
# > Won't fly. Referring to something lexical before it's
# declared is a
# > no-no.
# > sub bar(*@args = $) {...} # default to [$_]
# > sub bar(*@args = @$) {...} # default to @$_
# >
# > What might be is an interesting, er, topic.
#
# I would argue it ought to be just $_, which is, after all,
# the One True Topic. And conveniently lexically predeclared in
# all scopes.
I prefer $CALLER::_ ("CALLER:: - access caller's lexical variables, then
globals"). I'd expect that you could use the same thing for other
variables, e.g. $CALLER::some_lexical. Of course, the can of worms that
opens is horrifying to consider (and no longer has the benefit of the
ugly caller.MY). :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: String concatentation operator
Damian Conway wrote:
matt diephouse wrote:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
# in parallel and collect the results
# in a disjunction
Looking at that code, I'm wondering how you pass a junction. Suppose
I want to pass a junction to a subroutine instead of calling the sub
with each value of the junction... how would I do that?
Tell the sub that it's expecting an undistributed junction as its
argument:
sub foo($param is junction) {...}
Damian
Doesn't that go against perl's dynamic philosophy? That requires me to
type my methods where I may not want to. Let's say I have a sub that
logs errors:
sub log_error($fh, $error) { # filehandle and error msg
$error_num++; # global
print $fh: "$error_num: $error\n";
}
my $file = open "error.log";
log_error $file, "This message is phony";
However, during my debugging, I realize that I need two error logs
(Don't ask me why, I just do). Instead of changing the one line to
my $file = open "error.log" & "../some/other.log"; # I hope this is
legal
I also need to change the subroutine now, because the error count will
be off, even though my change is temporary. It reduces the ability to
write subs that accept anything and DWIM. The question is when/how do
you choose whether to pass a junction or evaluate all of them. I think
that the solution would be best left out of the sub's signature though.
Of course this has to stop somewhere; you eventually have to pick a state.
m:att d:iephouse
Re: String concatentation operator
Dan Sugalski wrote:
Hrm. What happens if the junction is then used as an iterator?
$junction = File::Open("foo") | File::Open("bar);
for (<$junction>) {
...
}
In Larry's formulation that's just the same as:
while $_ := $junction.next { ... }
which, when called on a junction, Cs each state in parallel and
returns a junction of the returned values. In other words, in each iteration
$_ will have a disjunction of the next lines from files foo and bar.
Which could get interesting if inside the for loop the code creates more
junctions and iterates over them. (Potentially ad infinitum)
The C loop is still single-threaded, only the values it's iterating
are multiplexed.
And here I thought Quantum INTERCAL was a joke... :)
Junctions Aren't Quantum.
Damian
Re: Unifying invocant and topic naming syntax
Larry:
> > sub bar(; $foo = ) {...}
Damian:
> topic [would be] C.
I assumed implied an 'is given'.
I don't see why it couldn't.
Damian:
> Hm. Given that the topic is in some sense
> a property of the lexical scope of the subroutine
> body, this might be a possibility:
>
> sub bar($foo is MY.topic) is given($whatever) {...}
Isn't this confusing dynamic and lexical scopes?
Perhaps:
sub bar (;$foo = YOUR.topic) { ... }
sub bar (;$foo = CALLERS.topic) { ... }
> > sub bar(*@args = $) {...} # default to [$_]
> >
> > What might be is an interesting, er, topic.
>
Damian:
> I would argue it ought to be just $_
You seem to be saying one could write:
sub bar (;$foo = $_) { ... }
Btw, can one write any/all of these and
have DWIMery:
sub bar (;$_) { ... }
bar ( _ => 1 );
sub bar (;$_ = $_) { ... }
As other's have suggested, a mumble of
$CALLERS::_ makes sense:
sub bar (;$foo = $CALLERS::_) { ... }
but I can see the point of a different
syntax dedicated to just the upscope topic
to avoid encouraging wider use of $CALLERS.
Hmmm.
--
ralph
Re: Literals, take 2
On Mon, 2002-11-18 at 10:08, Erik Steven Harrison wrote: > > -- > > On 17 Nov 2002 11:09:53 -050 > Bryan C. Warnock wrote: > >On Wed, 2002-11-13 at 13:26, Angel Faus wrote: > >> > >> There are many ways to specify literal numeric values in perl, but > >> they default to base 10 for input and output. Once the number has > > > >Surely, Perl 6 will allow changing the radix on a more global scale. > > Of course it will! But just about anything acn be changed with a grammer munge. >Theoretically Perl 5 could add radix notation with a source filter. But we don't have >to document that. > > I think that we should avoid refering to pragmas and modules as much as possible in >the core documentation. That's a departure from Perl 5. Here's my case: > Is it expected that the base grammar should always be base 10, or that the base grammar should always have a default radix? Given the amount of introspection normally found in perl, I expect the latter, regardless of the implementation - ie, a pragma, or a property, or a magic variable. The point was to *not* state in the documentation that an implicit radix defaults to base 10, but to a default radix (which, by default, happens to be 10). It's not important to document how that default can be changed, but it *is* important to capture the precise semantics of the language-to-be, for both the users and the core coders. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Numeric Literals (Summary 2)
On Monday, November 18, 2002, at 12:48 PM, Garrett Goebel wrote:
I went back through those posts, and I found where you suggested
0c0123... but I can't find a post from Larry confirming it.
It's not confirmed, just wild speculation. If we're reasonably sure we
don't have any gaping errors in the summary, we can ask the design team
to pass judgement upon it and make a final decision. They may indeed
decide 0123 needs to stay octal.
In the same vein, it'd be nice if syntax developed on the
documentation list to flush out ambiguities or propose syntax
workarounds were marked as such. When reading some of the summaries,
I've found myself wondering what parts come from the A&E's, which have
Larry & Damian since reversed or altered, and which are suggestions
from the documentation team...
Yeah, I agree. One of the problems is that most of the things we need
to talk about most are the things that have been described the least,
so we by definition have to suggest a lot as we go, and it's difficult
to figure out where the merely "implied" stuff from the A&Es ends and
the "revised" or "suggested" stuff begins. :-/ Not sure there's any
easy solution, since it's almost impossible to find previous references
to some stuff. ("Oh, that was talked about in Zurich!", or "you know,
that thread from last April") ;-P
Once we give the document(s) to them, they'll give us feedback, and
after an iteration or two we'll have a section they can mark as
"approved". _THEN_ it will be FINAL, as in people should code to it.
Mostly. We hope. :-)
MikeL
Re: Design Team Issues: Numeric Types
On Monday, November 18, 2002, at 01:33 PM, Dave Whipp wrote: my int $a is range(1000..1255) is unchecked; # auto-infer 8bit Just to clarify: I think of the latter (C) for efficient packing into arrays (e.g. a 5-bit range can be packed efficiently, even though there is no 5-bit c-type): binding to C routines is probably best done explicity. The C property would enable performance optimizations. Checked-ranges probably catch a few more bugs, though. Yeah, I threw that one in because it demonstrated a similar case of using properties to represent "hints" that could be optimized at a very primitive level, not because the last example itself necessarily represents an explicit C type. Sorry for the ambiguity there... MikeL
Re: String concatentation operator
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Mon, 18 Nov 2002 18:59:58 -0500
> From: matt diephouse <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Damian Conway wrote:
>
>> matt diephouse wrote:
> >
> >>> $junction = $x | $y | $z;
> >>> foo($junction);# Call foo($x), foo($y), and foo($z)
> >>># in parallel and collect the results
> >>># in a disjunction
> >>
> >>
> >>
> >> Looking at that code, I'm wondering how you pass a junction. Suppose
> >> I want to pass a junction to a subroutine instead of calling the sub
> >> with each value of the junction... how would I do that?
> >
> >
> > Tell the sub that it's expecting an undistributed junction as its
> > argument:
> >
> > sub foo($param is junction) {...}
> >
> > Damian
>
> Doesn't that go against perl's dynamic philosophy? That requires me to
> type my methods where I may not want to. Let's say I have a sub that
> logs errors:
>
> sub log_error($fh, $error) { # filehandle and error msg
> $error_num++; # global
> print $fh: "$error_num: $error\n";
> }
>
> my $file = open "error.log";
> log_error $file, "This message is phony";
>
> However, during my debugging, I realize that I need two error logs
> (Don't ask me why, I just do). Instead of changing the one line to
>
> my $file = open "error.log" & "../some/other.log"; # I hope this is
> legal
>
> I also need to change the subroutine now, because the error count will
> be off, even though my change is temporary. It reduces the ability to
> write subs that accept anything and DWIM. The question is when/how do
> you choose whether to pass a junction or evaluate all of them. I think
> that the solution would be best left out of the sub's signature though.
> Of course this has to stop somewhere; you eventually have to pick a state.
It's either that or have your functions, which were perfectly logical
suddenly be subject to junction logic. That is, if $x == 2 and $x
== 3 both being true, when your code relies on them not both firing.
I think it's a very good decision to make sure that functions know
they might be getting junctions and making it explicit.
Luke
> m:att d:iephouse
>
>
Re: Continuations elified
On Tue, Nov 19, 2002 at 08:53:17AM +1100, Damian Conway wrote:
: my $dance = Iterator.new(@squares);
: for $dance {
Scalar variables have to stay scalar in list context, so $dance cannot
suddenly start behaving like a list. Something must tell the scalar
to behave like a list, and I don't think I want C to do that.
A C should just take an ordinary list.
So you can do it any of these ways:
for <$dance> {
for $dance.each {
for each $dance: {
^ note colon
Then there's this approach to auto-iteration:
my @dance := Iterator.new(@squares);
for @dance {
Larry
Re: Continuations elified
Larry wrote:
So you can do it any of these ways:
for <$dance> {
for $dance.each {
for each $dance: {
^ note colon
Then there's this approach to auto-iteration:
my @dance := Iterator.new(@squares);
for @dance {
Okay, so now I need to make sense of the semantics of <...> and
C and coroutines and their combined use.
Is the following correct?
==
The presence of a C automatically makes a subroutine a coroutine:
sub fibs {
my ($a, $b) = (0, 1);
loop {
yield $b;
($a, $b) = ($b, $a+$b);
}
}
Calling such a coroutine returns an Iterator object with (at least)
the following methods:
next() # resumes coroutine body until next C
next(PARAM_LIST) # resumes coroutine body until next C,
# rebinding params to the args passed to C.
# PARAM_LIST is the same as the parameter list
# of the coroutine that created the Iterator
each() # returns a lazy array, each element of which
# is computed on demand by the appropriate
# number of resumptions of the coroutine body
In a scalar context:
<$fh> # Calls $fh.readline (or maybe that's $fh.next???>
<$iter> # Calls $iter.next
fibs() # Returns iterator object
# Returns iterator object and calls that
#object's C method (see note below)
In a list context:
<$fh> # Calls $fh.each
<$iter> # Calls $iter.each
fibs() # Returns iterator object
# Returns iterator object and calls object's C
So then:
for <$fh> {...}# Build and then iterate a lazy array (the elements
# of which call back to the filehandle's input
# retrieval coroutine)
for <$iter> {...} # Build and then iterate a lazy array (the elements
# of which call back to the iterator's coroutine)
for fibs() {...} # Loop once, setting $_ to the iterator object
# that was returned by C
for {...} # Build and then iterate a lazy array (the elements
# of which call back to the coroutine of the
# iterator returned by C
==
Note: this all hangs together *very* nicely, except when someone writes:
loop {
my $nextfib = ;
...
}
In which case $nextfib is perennially 1, since every call to C
returns a new Iterator object.
The solution is very simple, of course:
my $nextfib = ;
but we might want to contemplate issuing a warning when someone calls
an argumentless coroutine within a scalar context <...>.
Damian
Re: Unifying invocant and topic naming syntax
On Tue, Nov 19, 2002 at 07:45:25AM +1100, Damian Conway wrote:
: >What might be is an interesting, er, topic.
:
: I would argue it ought to be just $_, which is, after all,
: the One True Topic. And conveniently lexically predeclared in all scopes.
:
: I would also argue that it ought not be called anything else.
: Surely don't want two specially named variables for the topic?
I actually had an entire ramble on that subject that I deleted from
my previous message before I wrote what I wrote. But the gist of
it was similar, in that $_ is of indeterminate meaning in a signature
anyway, so why not force it to mean what we want it to mean? The
long and the short of it was that
my sub foo ($_ := $arg = $_)
is how you might set $arg to be both the "topic" and the "given".
In the common case, that comes down to
my sub foo ($_ = $_)
to just propagate the outer $_ inward. But it still has the problem that
it looks like a declaration of $_ followed by a use of $_ that *isn't* that
declaration. So I was thinking it'd be better to use something different to
represent the outer topic, like:
my sub foo ($_ = $^)
my sub foo ($_ = $+)
my sub foo ($_ = $|)
my sub foo ($_ = $=)
my sub foo ($_ = $:)
my sub foo ($_ = $?)
my sub foo ($_ = $$)
my sub foo ($_ = $@)
or some such. That's what I meant by . I kinda like $= at the
moment, presuming it's coming available from formats. Or maybe $?.
Possibly we have something more evil than that, such as the notion that
$? is a double sigil that pulls a name out of the dynamic context's
lexical scope. Then we could write $?_ for the outer $_, $?foo for the
outer $foo, @+_ for the outer @_, $?! for the outer $!, etc. That would
make it
my sub foo ($arg is topic = $?_)
I suppose it could be argued that defaulting the outer topic should also
set the inner topic by default, so you could write
my sub foo ($arg = $?_) {
when 1 { ... }
...
}
I'm trying to remember why it was that we didn't always make the first
argument of any sub the topic by default. I think it had to do with
the assumption that a bare block should not work with a copy of $_ from
the outside. But if the signature for a bare block is ($_ = $?_), and
if the = there is really a binding operator, then the inner $_ is just
an alias for the outer one, and it doesn't really matter in that case.
I'm not sure whether we should allow $?_ in a sub body, however.
for @sortparms {
&closure := { $?_
j ?? $^a <=> $^b
:: $^b <=> $^a
};
sort &closure, @list;
}
In this case, $?_ would be synonymous with $OUTER::_, since the block is
called in the same lexical context. But that wouldn't necessarily always
be the case. We can assume the outer dynamic scope also has a $_ in its
lexical scope, but assuming there's a $?foo out there is more problematic.
But maybe that's one way to explicitly export symbols:
module Foo;
&?foo := &my_foo;
That assumes we can tell the the outer scope is being compiled
currently. It would have the same restrictions as mucking around
with caller.MY, basically.
But don't worry, I still think normal export should be via properties
on the declaration of sub my_foo.
Larry
Re: Continuations
Damian Conway wrote:
Ken Fox wrote:
The < must begin the circumfix <> operator.
Or the circumfix <<...>> operator. Which is the problem here.
This is like playing poker with God. Assuming you can get over
the little hurdles of Free Will and Omniscience, there's still
the problem of Him pulling cards out of thin air.
What does the circumfix <<...>> operator do? [1]
Here docs are re-syntaxed and the << introducer was stolen
for the <<...>> operator? [2]
Yes. But since iterating an iterator to get another iterator that
is immediately iterated will (I sincerely hope!) be a very rare
requirement, I doubt it will be anything like the serious inconvenience
it is in C++.
True. I suppose even multi-dimensional data structures will
rarely be iterated over with a simple:
for < <$array> > {
}
Most people will probably want more control:
for <$array> {
for <$_> {
}
}
Anyways, I was wondering about the general principle of using
C++ style hacks to make yacc happy. I should have known better
coming from the author of "C++ Resyntaxed". Did the immodest
proposal fix < <> > syntax? ;)
- Ken
[1] I can't google for <<. Anybody know if Google can add perl6
operators to their word lists? Seriously!
[2] Hmm. Will the uproar on here docs beat string concatenation?
Re: Continuations
Ken Fox lamented: Or the circumfix <<...>> operator. Which is the problem here. This is like playing poker with God. I hear God prefers dice. What does the circumfix <<...>> operator do? It's the ASCII synonym for the «...» operator, which is a synonym for the qw/.../ operator. Here docs are re-syntaxed and the << introducer was stolen for the <<...>> operator? Nope. Heredocs still start with <<. Anyways, I was wondering about the general principle of using C++ style hacks to make yacc happy. I should have known better coming from the author of "C++ Resyntaxed". Did the immodest proposal fix < <> > syntax? ;) But of course! In SPECS, type parameters live in unambiguously nestable (and yacc parsable) <[...]> delimiters. Damian
Re: Continuations
Damian Conway wrote: It's [<<...>>>] the ASCII synonym for the «...» operator, which is a synonym for the qw/.../ operator. Nope. Heredocs still start with <<. Hey! Where'd *that* card come from? ;) Seriously, that's a good trick. How does it work? What do these examples do? print <<"a" "b" "c">>; print <<"a" "b" "c">>; a Is it illegal now to use quotes in qw()? - Ken
Compiler version solves Darwin/PPC test failures (was Re: [perl #18170] [PATCH] very complete lexical scope implementation)
Hello Jonathan, I just dropped my shell resources back down (datasize 6144k, stacksize 512k) and the tests pass for the version compiled with the gcc-3.1-based compiler. Looks like we found our culprit, at least for Darwin 5.5. I wonder which version of the compiler is on glastig? Having a look at that might well have 'er showing green on the tinderbox reports. Cheers, ~kj
Re: [perl #18170] [PATCH] very complete lexical scope implementation
Hello again, I tried upping the datasize to 80 meg and stacksize to 8 meg in my shell, and compiled with gcc3: Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs Thread model: posix Apple Computer, Inc. GCC version 1041, based on gcc version 3.1 20020105 (experimental) Parrot built cleanly and passed all of the tests, and here's the test log: perl t/harness --gc-debug --running-make-test t/src/basic.ok t/src/exit..ok t/src/intlist...ok t/src/list..ok t/src/manifest..ok t/src/sprintf...ok t/op/basic..ok t/op/bitwiseok t/op/comp...ok t/op/debuginfo..ok t/op/gc.ok t/op/globalsok t/op/hacks..ok t/op/ifunless...ok t/op/info...ok t/op/integerok t/op/interp.ok t/op/lexicals...ok t/op/macro..ok 1/15 skipped: Await exceptions t/op/number.ok t/op/rx.ok 1/23 skipped: various reasons t/op/stacks.ok 1/35 skipped: various reasons t/op/string.ok t/op/time...ok t/op/trans..ok t/op/types..ok t/pmc/array.ok t/pmc/boolean...ok t/pmc/intlist...ok t/pmc/multiarrayok t/pmc/perlarray.ok t/pmc/perlhash..ok t/pmc/perlint...ok 1/4 skipped: various reasons t/pmc/perlstringok 1/8 skipped: various reasons t/pmc/pmc...ok 2/79 skipped: various reasons t/pmc/scratchpadok t/pmc/sub...ok All tests successful, 7 subtests skipped. Files=37, Tests=506, 1330 wallclock secs (506.26 cusr + 106.24 csys = 612.50 CPU) Cheers, ~kj
Re: Compiler version solves Darwin/PPC test failures (was Re: [perl #18170] [PATCH] very complete lexical scope implementation)
At 4:47 PM -0800 11/18/02, kj wrote: Hello Jonathan, I just dropped my shell resources back down (datasize 6144k, stacksize 512k) and the tests pass for the version compiled with the gcc-3.1-based compiler. Looks like we found our culprit, at least for Darwin 5.5. I wonder which version of the compiler is on glastig? Having a look at that might well have 'er showing green on the tinderbox reports. [glastig:~] dan% gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs Thread model: posix Apple Computer, Inc. GCC version 1151, based on gcc version 3.1 20020420 (prerelease) It's going to stay that way as well--it's the compiler install from the DevTools CD that came with Jaguar. It's the stock compiler, and we need to work with that. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric Literals (Summary 2)
I've updated the literals tests to fully account for the radix notation; and I've also updated the tests to use the new radix#(number):(number) notation. Let me know if anyone finds any errors. Find them at: http://jryan.perlmonk.org/images/literals.tar.gz Michael Lazzaro wrote: --- Numeric Literals --- decimal notation: 123 # int 123 0123 # int 123 123.0 # num 123.0 -123 # int -123 0_1.2_3 # ok _01.23 # wrong 01.23_ # wrong 01_._23 # wrong 1__2# wrong exponential notation: -1.23e4 # num -1.23E4 # num (identical) 1.23_e_4# wrong bin/oct/hex notation: 0b0110 # bin 0c0123 # oct 0x00ff # hex 0x00fF # hex, == 0x00ff 0x00FF # hex, == 0x00ff -0xff # ok -0x00ff # ok 0xf_f # ok 0x_ff # ok explicit radix: (radix 2-32) 20:1gj # base 20 20:1GJ # base 20 (identical) 20:1.G.J # base 20 (identical) 20:1_G_J # base 20 (identical) 20:1.16.19 # base 20 (identical) 20:1_16_19 # NOT identical; == 20:11619 20:1.1_6.19 # WRONG: dotted form may not have underlines -20:1GJ # base 20 (negative) -20:1.16.19 # base 20 (negative) 62:zZ # base 62 (?) 62:z.Z # base 62 (identical?) 62:z_Z # base 62 (identical?) 62:Zz # base 62 (not identical?) (radix 33-RADIX_MAX) 256:0.253.254.255 # base 256 256:0_253_254_255 # base 256 MikeL
Re: String concatentation operator
On Monday, November 18, 2002, at 05:47 PM, Luke Palmer wrote: It's either that or have your functions, which were perfectly logical suddenly be subject to junction logic. That is, if $x == 2 and $x == 3 both being true, when your code relies on them not both firing. I think it's a very good decision to make sure that functions know they might be getting junctions and making it explicit. My god, I just realized that junctions are going to *completely* do away with the complaints of JAPH fans that Perl 6 will be too verbose, too hard to make obscure... Oh well, price of power, I guess. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Continuations
Seriously, that's a good trick. How does it work? What do these examples do? print <<"a" "b" "c">>; Squawks about finding the string "b" immediately after the heredoc introducer. print <<"a" "b" "c">>; Likewise. Is it illegal now to use quotes in qw()? Nope. Only as the very first character of a <<...>>. So any of these are still fine: print << "a" "b" "c" >>; print <<\"a" "b" "c">>; print «\"a" "b" "c"»; print qw/"a" "b" "c"/; Damian
Re: Continuations elified
On Monday, November 18, 2002, at 06:51 PM, Damian Conway wrote:
for <$fh> {...}# Build and then iterate a lazy array (the elements
# of which call back to the filehandle's input
# retrieval coroutine)
for <$iter> {...} # Build and then iterate a lazy array (the elements
# of which call back to the iterator's coroutine)
for fibs() {...} # Loop once, setting $_ to the iterator object
# that was returned by C
for {...} # Build and then iterate a lazy array (the elements
# of which call back to the coroutine of the
# iterator returned by C
How will while behave?
while <$fh> {...}# Iterate until $fh.readline returns EOF?
while <$iter> {...} # Iterate until $iter.each returns false?
while fibs() {...} # Infinite loop -- fibs() returns an
# iterator every time?
while {...} # I'm afraid to ask!
Best,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: String concatentation operator
matt diephouse wrote:
sub foo($param is junction) {...}
Doesn't that go against perl's dynamic philosophy?
???
That requires me to type my methods where I may not want to.
> Let's say I have a sub that logs errors:
sub log_error($fh, $error) { # filehandle and error msg
$error_num++; # global
print $fh: "$error_num: $error\n";
}
my $file = open "error.log";
log_error $file, "This message is phony";
However, during my debugging, I realize that I need two error logs
(Don't ask me why, I just do). Instead of changing the one line to
my $file = open "error.log" & "../some/other.log"; # I hope this is legal
Under my junctive semantics it is. It simply calls C twice, with
the two states, and returns a conjunction of the resulting filehandles.
Though you probably really want a *dis*junction there.
I also need to change the subroutine now, because the error count will
be off, even though my change is temporary. It reduces the ability to
write subs that accept anything and DWIM.
So how does C know to parallelize, rather than just pass in the
junction?
You can't have it both ways. Either the default is to parallelize at
the point a junction is passed to a subroutine, and you have to mark
subroutines that preserve their junctive arguments; or the default is
that junctions pass into subroutines, and you have to mark subroutines
that parallelize when given a junction.
I've thought about it at considerable length, and played around with
the Q::S module. I concluded that passing junctions into subroutines
by default is a Very Bad Idea. The reason, as Luke has already pointed
out, is that junctive logic is different from scalar logic. So most
subroutines won't be able to "accept anything and DWIM" anyway.
Damian
Re: Continuations elified
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> X-Sent: 19 Nov 2002 02:51:54 GMT
> Date: Tue, 19 Nov 2002 13:51:56 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
> X-Accept-Language: en, en-us
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Larry wrote:
>
> > So you can do it any of these ways:
> >
> > for <$dance> {
> >
> > for $dance.each {
> >
> > for each $dance: {
> >^ note colon
> >
> > Then there's this approach to auto-iteration:
> >
> > my @dance := Iterator.new(@squares);
> > for @dance {
>
> Okay, so now I need to make sense of the semantics of <...> and
> C and coroutines and their combined use.
>
> Is the following correct?
>
> ==
[snip]
> ==
I like this I better than what you explained before. Most of my
problems with two iterators to the same thing in the same scope are
gone, as well as the confusions I had about C.
Luke
Re: Continuations elified
David Wheeler asked:
How will while behave?
C evaluates its first argument in scalar context, so:
while <$fh> {...}# Iterate until $fh.readline returns EOF?
More or less. Technically: call <$fh.next> and execute the loop body if that method
returns true. Whether it still has the automatic binding to $_ and the implicit
definedness check is yet to be decided.
while <$iter> {...} # Iterate until $iter.each returns false?
Yes.
while fibs() {...} # Infinite loop -- fibs() returns an
# iterator every time?
I suspect so.
while {...} # I'm afraid to ask!
Usually an infinite loop. C returns a new iterator every time,
which <...> then calls C on.
Damian
Re: Continuations elified
On Monday, November 18, 2002, at 08:05 PM, Damian Conway wrote:
while <$fh> {...}# Iterate until $fh.readline returns EOF?
More or less. Technically: call <$fh.next> and execute the loop body
if that method
returns true. Whether it still has the automatic binding to $_ and the
implicit
definedness check is yet to be decided.
That's a scalar context? I assumed it was list context from your
previous post:
In a list context:
<$fh> # Calls $fh.each
At any rate, I hope that it's bound to $_ -- nice conversion from Perl
5's behavior, that.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Continuations
> Date: Tue, 19 Nov 2002 14:29:46 +1100 > From: Damian Conway <[EMAIL PROTECTED]> > > Ken Fox lamented: > > >> Or the circumfix <<...>> operator. Which is the problem here. > > > > This is like playing poker with God. > > I hear God prefers dice. > > > > What does the circumfix <<...>> operator do? > > It's the ASCII synonym for the «...» operator, which is a > synonym for the qw/.../ operator. I did not have Unicode working during the dreaded operator thread. What was the final syntax for vector ops? @a ≪+≫ @b @a ≫+≪ @b Something else? If the former, how does one disambiguate a qw with a unary vector op? Luke
Re: Continuations elified
David Wheeler asked:
while <$fh> {...}# Iterate until $fh.readline returns EOF?
That's a scalar context?
Sure. C always evaluates its condition in a scalar context.
Damian
Re: Continuations
Luke Palmer asked: What was the final syntax for vector ops? @a ≪+≫ @b @a ≫+≪ @b The latter (this week, at least ;-). Damian
Re: Continuations
* Damian Conway ([EMAIL PROTECTED]) [19 Nov 2002 15:19]: > Luke Palmer asked: > > What was the final syntax for vector ops? > > > >@a ???+??? @b > >@a ???+??? @b > The latter (this week, at least ;-). Y'know, for those of us who still haven't set up Unicode, they look remarkably similar =) cheers, -- Iain.
Re: Continuations elified
On Monday, November 18, 2002, at 08:17 PM, Damian Conway wrote: Sure. C always evaluates its condition in a scalar context. Oh, duh. Thanks. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: String concatentation operator
"Damian Conway" <[EMAIL PROTECTED]> wrote > >my $file = open "error.log" & "../some/other.log"; # I hope this is legal > > Under my junctive semantics it is. It simply calls C twice, with > the two states, and returns a conjunction of the resulting filehandles. > Though you probably really want a *dis*junction there. The thing that's worrying me is: what happens when one of them throws an exception? Can I catch half of the junction? Do the two threads ever join? Does the exception get deferred until after all the threads have completed? If both throw an exception: what happens then? Dave.
Re: Unifying invocant and topic naming syntax
Larry wrote:
The long and the short of it was that
my sub foo ($_ := $arg = $_)
is how you might set $arg to be both the "topic" and the "given".
Wow. I'm surprised by how much I don't like that syntax! ;-)
I mean, two entirely different meanings for $_ in the space of one parameter
definition? And both := and = in one parameter definition?
I'd *so* much prefer to have to write:
my sub foo ($arg is topic = $CALLER::_)
(see below).
In the common case, that comes down to
my sub foo ($_ = $_)
to just propagate the outer $_ inward.
That only works when $_ can somehow be shoe-horned into the parameter list.
Whereas:
my sub foo is given($_)
works for *any* parameter list.
So I was thinking it'd be better to use something different to
represent the outer topic, like:
my sub foo ($_ = $^)
my sub foo ($_ = $+)
my sub foo ($_ = $|)
my sub foo ($_ = $=)
my sub foo ($_ = $:)
my sub foo ($_ = $?)
my sub foo ($_ = $$)
my sub foo ($_ = $@)
or some such. That's what I meant by . I kinda like $= at the
moment, presuming it's coming available from formats. Or maybe $?.
$= as an alias for the caller's $_, I could certainly live with.
It's mnemonically *much* better than $?. And it gets rid of the need
for a separate C property on the subroutine, since the sub
can just refer to $= if it needs to.
And no, formats aren't going to need $=.
Possibly we have something more evil than that, such as the notion that
$? is a double sigil that pulls a name out of the dynamic context's
lexical scope. Then we could write $?_ for the outer $_, $?foo for the
outer $foo, @+_ for the outer @_,
Typo on that last one (I hope!)
$?! for the outer $!, etc. That would
make it
my sub foo ($arg is topic = $?_)
The only problems I have with this are:
1. Do we really want to allow every lexical to be accessible anywhere
in its dynamic scope? This has many of the same drawbacks as C.
$_ is probably a special case (which argues for $= rather than
a general mechanism).
2. If we *do* want to provide that mechanism, do we really want to make
it that easy/subtle/short/missable? If we're going to do this,
I think $CALLER::_, $CALLER::foo, @CALLER::_, $CALLER::! might be
better. At least they're ugly, and scream for special attention. ;-)
I suppose it could be argued that defaulting the outer topic should also
set the inner topic by default, so you could write
my sub foo ($arg = $?_) {
when 1 { ... }
...
}
Yeah, I wouldn't have a problem with that
(except for $?_ not being $CALLER::_ ;-)
Though I think:
my sub foo($arg = $=) {...}
would be even better.
Damian
Re: String concatentation operator
Dave Whipp wrote: Under my junctive semantics it is. It simply calls C twice, with the two states, and returns a conjunction of the resulting filehandles. Though you probably really want a *dis*junction there. The thing that's worrying me is: what happens when one of them throws an exception? Then the exception propagates back to the calling context and the result junction is never created. > Can I catch half of the junction? You mean: can you catch the exception generated by half a junction. Yes. Do the two threads ever join? Yes. At the point of recombining the values of the parallel calls. Does the exception get deferred until after all the threads have completed? I would doubt it. If both throw an exception: what happens then? You just get one or the other, in no defined order. (No, I'm *not* going to scare Dan by suggesting that $! ends up with a junction of the two exceptions. ;-) Damian
Re: Continuations
Iain 'Spoon' Truskett wrote: @a ???+??? @b @a ???+??? @b Y'know, for those of us who still haven't set up Unicode, they look remarkably similar =) "Think Of It As Evolution In Action" ;-) Damian
Re: Continuations
On Monday, November 18, 2002, at 08:19 PM, Damian Conway wrote: (B (B>> What was the final syntax for vector ops? (B>> @a $B"c(B+$B"d(B @b (B>> @a $B"d(B+$B"c(B @b (B> (B> The latter (this week, at least ;-). (B (BThis reminds me: I though of another set of bracing characters that I (Bdon't recall anyone ever mentioning before, and that might be useful in (Bsome context where such a thing is needed. (B (B C< \op/ > or C< /op\ > (B (BI realize that there could be issues with patterns, but the first (Bexample ought to avoid that, I would think. If someone *has* thought of (Bthese characters as complementary braces (why wouldn't someone have?), (Bwell, just forget about it. (B (BDavid (B (B-- (BDavid Wheeler AIM: dwTheory ([EMAIL PROTECTED] ICQ: 15726394 (Bhttp://david.wheeler.net/ Yahoo!: dew7e (BJabber: [EMAIL PROTECTED]
Re: String concatentation operator
At 3:45 PM +1100 11/19/02, Damian Conway wrote: Dave Whipp wrote: Does the exception get deferred until after all the threads have completed? I would doubt it. We're definitely going to need to nail the semantics down. Would one thread throwing an exception require all the threads being aborted, for example? If both throw an exception: what happens then? You just get one or the other, in no defined order. (No, I'm *not* going to scare Dan by suggesting that $! ends up with a junction of the two exceptions. ;-) Don't worry about me. I'm still trying to shake that whole quantum thing... :-P -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Unifying invocant and topic naming syntax
> > my sub foo ($_ = $_) > > > > to just propagate the outer $_ inward. > > That only works when $_ can somehow be > shoe-horned into the parameter list. > Whereas: > >my sub foo is given($_) > > works for *any* parameter list. Other than the placeholder situation, I don't understand when one could do the 'is given($_)' and not do the ($_ = $_). > > Possibly we have something more evil than > > that, such as the notion that $? is a double > > sigil that pulls a name out of the dynamic > > context's lexical scope. > > 1. Do we really want to allow every lexical to >be accessible anywhere in its dynamic scope? It is intriguing. One only needs to know the def of a sub one is calling. One does not have to worry about subs that get called by the sub one is calling. Imo one should know the def of a sub one calls. In this case one needs to know the pertinent arg /names/, not just their position, but that is already somewhat the case for optional args. When writing in the, er, medium (as against small or large), one could develop a variable name vocabulary, rather as one does with globals, but without its dangers: A (horrible, but hopefully illustrative) example: my $filename = 'foobar'; my $buf; open; read; write; delete; I'm imagining a potential sweetspot between globals and lexicals. An extension of the power of "it", which is just a way to talk more succinctly when you can get away with assumptions about nearby nouns. No? > 2. If we *do* want to provide that mechanism, >do we really want to make it that easy/subtle If the sweetspot I theorize above exists, then I think my answer is 'yes' to easy. But, no matter what, NO to subtle. It would be important that people know that any given arg is, er, given, or one just ends up with something that is halfway to the usual global problem. I'm thinking the syntax should be, in order of priority, LOUD, short, pleasing. I'm also thinking it would be nice to be able to say that the called sub's lexical shares its name as well as value (copy or bound) with the calling sub's lexical, without having to say the name twice. Further, that this would be a good pick as the norm, with the syntax optimized for that, so that it may be more cumbersome when you want the formal and actual arg names to be different. Perhaps we need some Unicode? ;> -- ralph
Re: String concatentation operator
Dan Sugalski wrote: We're definitely going to need to nail the semantics down. Would one thread throwing an exception require all the threads being aborted, for example? I would imagine so. You can't reasonably build a junction out of values that weren't successfully created. If you write: $var = die(); you get an exception thrown. Why should it be any different if the rvalue was trying to assume other non-exceptional values as well: $var = foo() | bar() | die(); The whole point of junctions is "No Visible Parallelism": all the parallelism occurs inside the junction constructor. At the end of construction your single thread gets back a single scalar. And if the construction of that single scalar involved an exception, your single thread should get that exception. As for short-circuiting: why not? Junctions are inherently unordered, so there's no guarantee which state of the junction is processed first (whether they're being processed in parallel or series). Damian
Re: Unifying invocant and topic naming syntax
ralph wrote:
Other than the placeholder situation, I
don't understand when one could do the
'is given($_)' and not do the ($_ = $_).
Any time that the caller's topic isn't supposed to be
explicitly passed as an argument, but is still used within
the subroutine.
For example, the Class::Contract module provides a subroutine
like this:
# Perl 5 code
sub check(\%;$) {
my $state = !$#_ ? 0 : $_[1] ? 0 : 1;
my $forclass = $_;
defined $forclass or croak;
$_[0]->{$forclass} =
bless { prev=>$no_opt{$forclass}, forclass=>$forclass},
'Class::Contract::FormerState';
$no_opt{$forclass} = $state;
}
It is passed a hash (that is used to store objects it generates) and a scalar
that indicates whether checking is to be enabled or disabled. It uses the
callers $_ (which is specifically *not* passed as an argument) to determine
what class to turn checking on or off for. That (slightly odd) interface
allows users of the module to write very tidy code:
check %cache, $on_or_off
for qw/Class1 Class2 Class3/;
C needs the callers $_, but doesn't (want to) have it passed as an
argument. So a ($_ = $_) argument won't work.
And, yes, I could make it an optional argument, but them I have no way of
preserving my chosen interface. Or porting that code cleanly.
Besides all that, ($_ = $_) where $_ means something different from $_
is Just Plain Wrong. ;-)
Damian
Re: Suggested fix for ticket #16941 (imcc autogen files with wrong timestamps)
On Nov-15, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >I replied to ticket #16941 a while back but I don't think I had RT
> >actually send any mail to anybody. Anyone have an opinion on the patch
> >I put in it? (I'm trying to clean out some local changes so I can
> >apply other people's patches more easily.)
> >
> >Thanks.
>
> I don't like it very much, to run make regen_all while developing, but
> anyway, I always can hack my local Makefile.
I don't understand. The patch never runs anything unnecessarily; it
just replaces make's timestamp-based dependency check with a
checksum-based check. So it unconditionally runs the runyacc script,
but that script only runs yacc/bison if it needs to. As long as you
don't change imcc.y, yacc will never run.
Or am I misunderstanding your objection?
Checksum-based dependency analysis has been used successfully in other
projects. For example, I think that Cons defaults to using it
exclusively.
Note that the patch would require a few changes: it should be used for
running lex as well as yacc, and the 'runyacc' script should be
renamed to something more neutral
('regenerate-if-outdated-something-that-generates-C-code').
> So, if we don't have an option, that after CVS checkin the generated
> files are touched automatically it would be better to apply #16941.
I'm not sure, but I don't think CVS is guaranteed to obey checkin
order on checkout. I think it just checks out in directory order.
As for #16941, which completely removes the dependencies and instead
requires the user to manually do a 'make regen_all': I could live with
it, but I'd rather not. I've spent too much of my life tracking down
mysterious failures that caused by me forgetting to regenerate
something or other. And I'm not growing a lot of new brain cells these
days, so I'd prefer an automated solution.
Another alternative would be to have Configure.pl update the
timestamps in the correct order, but my initial attempt to implement
something like that felt much too hackish -- or, at least, too hackish
considering that it's only a partial solution; I don't always rerun
Configure.pl after every update, so I'm likely to mess it up anyway.
Parrot 0.0.9 status
The basic status is that lots of people, many of them coincidentally named Leopold Toetsch, have been fixing zillions of things and implementing a number of new features. Nearly everything needed for 0.0.9 has happened, and a lot else besides. I personally have been busy with my day job, shipping one unit and making a release for the software that goes on it -- in that order, with a week between. Release when ready, ship when needed. I'll be on vacation next week, which means I'll have much more time to spend on Parrot, but much less connectivity. There are still a couple of things needed for this release: 1. The tinderbox is a solid sheet of orange flame. No release until it's all green. The current problems appear to be: legitimate bugs that don't show up on my platform, known PPC problems in varargs code, and an incorrect tar file being used by all the TD-* machines. 2. Warnings. Still too many for comfort. I'll probably get a chance to look at some of these on a different platform soon, but I don't have access to anything very interesting. 3. The previously mentioned varargs/sprintf* PPC problem. On the bright side, these are the major pieces that have been completed out of my original 0.0.9 list: * JIT trace/restart (Leo) * Patch backlog (it fits on a screen now!) * Bytecode format (well, we're a little further along, anyway) And we have some fairly major new features: * lexicals (J Sillito) * stabs support for JIT (Leo) * memory leak cleanups (Leo)
