Re: Angle quotes and pointy brackets

[Smylers]

Juerd writes:

> For oneliners, I think I'd appreciate using -o for that. The module
> itself can be Perl::OneLiner. Things the module could do:
> 
> * disable the default strict

The C<-e> flag indicating the one-liner disables C anyway.

Smylers

Name needed for Test.pm compatibility module

[Michael G Schwern]

I'm writing a module to emulate the functionality of Test.pm but with
a Test::Builder backend so you can use TB-based modules with older tests.  

I'm trying to come up with a name.  The current working title is Test::Legacy.
Test::Compat and Test::Classic have also been suggested.

Thoughts?


-- 
Michael G Schwern[EMAIL PROTECTED]  http://www.pobox.com/~schwern/
It's Ecstacy time!

Re: Angle quotes and pointy brackets

[Alexey Trofimenko]

On Fri, 26 Nov 2004 09:33:49 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: I notice that in Perl6 thoose funny  and  could be much more common
: than  other paired brackets. And some people likes how they look, but
: nobody likes the fact that there's no (and won't!) be a consistent way  
to > : type them  in different applications, wether it's hard or easy.
...
: We also have another ascii pair, < and > . maybe they could be better  
: than  and  ?:) i'm not that farseeing, but isn't problem of :  
distinguishing < as a bracket and < as an comparison operator no harder
: than  distinguishing << as bracket and as part of heredoc?..
It would get very confusing visually, even if the computer could sort it  
out:

@a >= @b
@a >=< @b
But there are some things that would be completely ambiguous:
%hash
%hash
I not meant to replace it everywhere. But problem still exists.
I know about only four uses of  and Â. Tell me if there's more?
1) hyperoperators;
  @a = @b Â*Â @c @aÂ.method
  @a = @b >>*<< @c   @a>>.method
  (and, of course, mentioned in the past supercool 7-chars >>=:=<<  
operator!)
  hm.. IMO, hyperoperations are fat enough to be fat even in code. I  
wonder only if whitespace allowed there:
  @a = @b >> * << @c @a  >>.method

2) qw//-like construct;
  @array = Âfoo bar bazÂ
  @array = <>
  @array = qw
once again, there's nothing wrong. Although, using just   
would confuse Perl6 no more than  and  confuses Perl5.  
"want an operator/want a term" rule applies here.

3) pair(adverb) value quoting;
   myfunc :fooÂbar :barÂbazÂ
   myfunc :arrayÂvalue1 value2 value3Â
   myfunc :foo<> :bar<>   # this certainly suck
   myfunc :foo("bar") :bar("baz")   # I'm going to use that if it works(?).
   # still this suck less:
   myfunc :array<< value1 value2 value3 >>
   # ..than:
   myfunc :array("value1", "value2", "value3")
but replacement of << >> with plain < > here is a no-problem:
   myfunc :foo :bar :array
after you type :foo only three times, you'll acquire internal alarm  
on constructs like

  myfunc :foo :bar<10;
which are rather obfuscating already.
IMHO, mandatory whitespace between :bar and <10 here won't make anybody  
sick.
I wonder how many people would like to write it
  myfunc:foo:bar<10;

4) hash subscripting;
that's a real pain.
rather cute
   $varÂkey1ÂÂkey2Â[3]Âkey3Â
suddenly becomes an ugly monster:
   $var<><>[3]<>
of course we could write:
   $var{'key1'}{'key2'}[3]{'key3'}
and I would prefer this one to previous variant..
but it adds noise too. and it prevent us to logicaly recognize 'key1' and  
'key2' not as strings but as something more like struct elements, like we  
got used in perl5

When I look at this
   $var[3]
then I think that it's a *very* cute, nice, and clean syntax... I really  
like it!
(and I would sacrifice something for that to happen, if I would be Larry  
:) )
but there's a problem for people and parser too. < is a comparison  
*operator* and hash subscript is *operator* too, and there's no way to  
distinguish them at all. "Term rule" won't help here.

+< and +> for comparison is plain sickness, of course. But we have some  
whitespace rules already. One of them is that subscripts shouldn't have  
whitespace to the left of them. We could add one more - to always PUT  
whitespace before < comparison. so

  $a
Personally I'm not lazy to put spaces because of my little Forth  
experience.
but I don't want to be lynched by mad horde of programmers in white robes,  
who will discover that
  while $a<$b {...}
  for qw {...}

and even
  foo()
*sigh.. I'll write my own grammar:) I only afraid that it would take a  
half of all my remaining lifetime (because of addiction)

But I'll return to topic.
I've seen proposal by Juerd, somewhere it this thread, to use `` for  
autoquoting subscripting.

but proposed
  %hash`foo`bar`$foo`0`$bar=0
not going to work
delimiters should have corresponding closing character, so it should be  
something like

  %hash`foo``bar`{$foo}[0]{$bar}=0
or it would be *much* worse for parser than <>.
actually, (countrary to [] and {} which could have arbitrary complex  
nested expressions in it) "autoquoting" subscript shouldn't neccessarily  
be a paired string. Any character could be used for it without any  
ambiguity. Even perl4 style ' or even "
 Same with :pairs

 %hash"key""anotherkey"[1]=0
 %hash'key''anotherkey'[1]=0
 :key"value"
 :key'value'
ah, using " here would cause difficulties to interpolation of "hello,  
$world"
so what about ' or ` (or whatever you could imagine)?

P.S. I also considered "shorcuts" like
   $var<>[1]  # but that not going to remove MUCH of  
linenoise.
or
   $var.[1].  # yikes, but still better than <<>><<>>
...

Re: Perl 6 Summary for 2004-11-22 through 2004-11-29

[Rosser Schwarz]

while you weren't looking, Matt Fowles wrote:

>Lexicals, Continuations, Register Allocation, and ascii art
> This thread (and the ones that preceded it) have made me wish that gmail
> and google groups had a fixed width font option. Sadly, this summary
> will probably not get me it, as it did not get me p6c either

If you're using Firefox, add:

div.msg div.mb {
font-family: monospace !important;
font-size: 10px !important; /* or whatever font size you'd prefer */
}

to your /chrome/userContent.css and you'll get it in
gmail at least.

Some View Source-ing in Google Groups suggests they're just wrapping
their article bodies in PRE tags there.

/rls

Re: Angle quotes and pointy brackets

[Brent 'Dax' Royal-Gordon]

Juerd <[EMAIL PROTECTED]> wrote:
> > but talking about oneliners and short shell-like scripts, where `` is
> > pretty useful.. hm.. things good for oneliners are rarely as good for
> > larger programs, and vice versa. Of course, Perl5 proves opposite, but
> > Perl6 tends to be a little more verbose, and even in Perl5 we use quite
> > different "toolbox" and style for mentioned above. Why not to make an
> > average sized module of various "shortcut" grammars, with a very short
> > name ("x", f.e.), with defaults to export :all, so we could just do
> >   perl -Mx -e 'print `echo this is a perl5qx`'
>
> For oneliners, I think I'd appreciate using -o for that. The module
> itself can be Perl::OneLiner.

module e {
module *::Main {
# Or whatever we'd need to do to switch to the top-level Main
close $*CODE;# if there is such a thing
no strict;
no warnings;
my macro circumfix:<<` `>> (String $cmd)
is parsed(/ <[^`\\]>* [ \\ . <[^`\\]>*: ] * /) {
{ run :capture $cmd }
}
use File::Copy qw(mv cp);
...
# I do hope we get something better than #line.
eval "#line 1 '-me'\n" ~ @ARGS.shift;
}
}

perl -me 'say "This is my one-liner!"'

One-liners with no specific support in the core--and it's different
from Perl 5, so we can detect old one-liners.  How's that for
orthagonal?

--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker

"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)

Perl 6 Summary for 2004-11-22 through 2004-11-29

[Matt Fowles]

Perl 6 Summary for 2004-11-22 through 2004-11-29
All~

Rather than try to do something witty about the strange music I am
listening to, or the stuffed animals who are assisting me. I will start
this summary off with an entirely self-serving request. A while
ago I saw the quote "Computer Science is merely the post-Turing Decline
of Formal Systems Theory." without an attribution. I have tried to find
an attribution for it, but have been unable to find one. If any of you
know it, that information would be appreciated. With that out of
the way, I bring you

  Perl 6 Language
   Deep Operators
Last week, Matthew Walton wondered about Deep Operators and if they
would work as he expected. As I tentatively predicted, the answer came
back and was "yes". Then the thread got side tracked with context and
Perl vs perl vs PERL concerns.



   gather to separate bins
Dave Whipp wanted to know if he could use gather/take with multiple
bins. Michele Dondi suggested using adverbs for it. Rod Adams pointed
out that as gather is inherently lazy the two binned approach could
cause strange results (like churning for a while filling one bin trying
to get an element for the other). Of course, not being able to do it
would mean possibly having to compute an expensive generate function
more than necessary, unless it is memoized...



   « in here-docs
Thomas Seiler has decided to test my copy-paste-fu by starting a discuss
on characters that don't appear on my keyboard. His question was if «END
could start a here-doc. The answer appears to be no.

 -- here-doc

   « != <<
The above thread led to a discussion of the various quoting operators,
and the differences between «» and <<>>. This led to much discussion on
the finer points of qw, qx, and qq (among others). Juerd suggested
scrapping qx and qw in favor of qq:x and qq:w, which Larry liked. Rod
Adams suggested scrapping 

   unifying namespaces
Alexey Trofimenko wondered about unifying the $, @, and % namespaces.
Larry told him that this ship sailed long ago and that it was not
changing.



   Lexing/Parsing Perl6 without executing code
Adam Kennedy wants to be able to syntax color (and possible perform
basic programatic manipulations of perl6 code). Anyone who has used a
good IDE like Visual Studio, Eclipse, or IntelliJ probably understands
where he is coming from. He does not, however, want to execute arbitrary
code in the process of doing this. Much discussion ensued, but it does
not look like he will be able to do this. Quite the tragedy, but perl is
simply too dynamic to be docilly lexed like static languages.



  Perl6 Compiler
   Nice Work
Nick Glencross has the honor of the only message on p6c this week. But
his sentiment is shared by all. Nice work, Patrick.



  Parrot Internals
   Parrot_compreg.sig
Bernhard Schmalhofer noticed that Parrot_compreg had a different
signature then documented, so he submitted a patch to fix it. Leo
applied it.



   opcode numbering
Leo added a TODO ticker for opcode numbering.



   tests pass, but create core files
I reported that on my machine all of the tests claim to pass, but core
files appear in the parrot directory. Dan confirmed my suspicion that
this was a real problem. I tried to supply helpful information like
backtrace, but Warnock applies.

 -- initial message

 -- squeeky wheel gets the kick?

   pcc cleanup
Leo removed the recently deprecated P0, P1, P2 usage. Relatively few
tests break as a result.



   Namespace-sub invocation
Luke Palmer wanted to know if there was syntax for calling subs from a
particular namespace. Leo provided the answer, call it as a method on
the namespace PMC.



   Reserved Words Annoy
Luke Palmer wondered if he could define a .sub "new" to get around
reserved word problems. Leo added the support, but warned him not to use
"spaces or such".



   Lexicals, Continuations, Register Allocation, and ascii art
This thread (and the ones that preceded it) have made me wish that gmail
and google groups had a fixed width font option. Sadly, this summary
will probably not get me it, as it did not get me p6c either :-( Ah
well. The problems associated with lexicals and continuations churned.
There was a plea for guidance from Dan. Hopefully he will guide us
shortly.

 -- one thread about it

 - and another (with plea)

   old Parrot question
Bloves had a question about assemble.pl in t

Re: Too many opcodes

[Dan Sugalski]

At 9:20 AM +0100 11/24/04, Leopold Toetsch wrote:
Too many opcodes
Bluntly, no. Not too many opcodes.
This has been an ongoing issue. I'm well aware that you want to to 
trim down the opcode count for ages and replace a lot of them with 
functions with a lightweight calling convention. Well, we already 
*have* that. We call them (wait for it) *opcodes*. That's one of the 
really big points of all this. You're micro-optimizing things, and 
you're not going the right way with it.

Yes, I'm well aware that the computed goto and switch cores are big, 
and problematic. The answer isn't to reduce the op count. The 
answer's to make the cores manageable, which doesn't require tossing 
ops out. It requires being somewhat careful with what ops we put *in*.

It's perfectly fine for a good chunk of the ops to not be in the main 
switch or cgoto loop, and have to be dispatched as indirect 
functions, the same as any opcode function from a loadable opcode 
library is. (Hell, some of these can go into a loadable opcode 
library if we want, to make sure the infrastructure works, including 
the packfile metadata that indicates which loadable op libraries need 
to be loaded) I'm also fine with making some of the ops phantom 
opcodes, ones that the assembler quietly rewrites. That's fine too, 
and something I'd like to get in.

So, short answer: Ops aren't going away.
Longer answer: We need to add in the following facilities:
 1) Op functions tagged (either in their definitions for all 
permutations, or in the ops numbering metadata file for individual 
functions) as to whether they're in the core loop or not. Ones that 
aren't hit the switch's default: case (and the cgoto core's 
equivalent, and the JIT's perfectly capable of handling this too) and 
get dispatched indirectly.

 2) The assembler and PIR compiler need to be taught appropriate 
transforms, which then *could* allow for "add N2, I3, N3" to be 
turned into "add N2, N3, I3" if we decide that in commutative IxN ops 
it's OK to make them NxI and so on. (Comparisons too, up to a point 
-- we can't do this with PMCs)

 3) The loadable opcode library stuff needs to be double-checked to 
make sure it works right, so we can create loadable libraries and 
actually load them in

 4) The metadata in packfiiles to indicate which loadable opcode 
libraries are in force for code in each segment needs to be 
double-checked to make sure it works right

 5) The ops file to C converter needs to have a knockout list so we 
can note which combinations aren't supported (and believe me, I fully 
plan on trimming hard, but only *after* we're functionally complete) 
or, if we'd rather, it can respect the ops numbering list and just 
not generate ops not on it.

Once this is done the only difference between 'real' opcodes and 
fixed-arg low-level functions is which are in the switch/cgoto/jit 
cores and which aren't, something that should be transparent to the 
bytecode and tunable as we need to. Which is as it should be.

The list of opcode functions is going to grow a lot, and there's 
really no reason that it shouldn't. With proper infrastructure there 
just isn't any need for there to be a difference between opcode 
functions and library functions.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: [CVS ci] opcode cleanup 1 - minus 177 opcodes

[Dan Sugalski]

At 8:29 AM +0100 11/28/04, Leopold Toetsch wrote:
Thomas Seiler <[EMAIL PROTECTED]> wrote:
 Dan Sugalski wrote:
 At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
 See also subject "Too many opcodes".
  >> [...]
  >>
 Could you undo this please? Now is not the time to be trimming ops out.
When is the time? After another 1000 opcodes are in, which all ought to
be functions?
Yes. Y'know, when we start doing the optimization based on a fully 
designed and implemented engine. Anything before that's premature. 
(Shall I go dig up a half dozen or more archive references with you 
chiding me for premature optimizations?)

 > OTOH, it won't hurt anyone and it is already in.
That's my point.
Then your point's wrong. This patch broke a lot of my code.
You keep wanting to chop things out of the core. Stop. That's not 
your call -- it's mine, and it will be made, but not now.

Put these back.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: [CVS ci] opcode cleanup 1 - minus 177 opcodes

[Michael Walter]

There is also such thing as premature "pessimization". I'm not in the
position to judge whether it is appropriate in this case, though.

Back-to-reading-mode-ly yours,
Michael


On Mon, 29 Nov 2004 20:25:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:29 AM +0100 11/28/04, Leopold Toetsch wrote:
> >Thomas Seiler <[EMAIL PROTECTED]> wrote:
> >>  Dan Sugalski wrote:
> >>>  At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
> >>>
>   See also subject "Too many opcodes".
> 
> >>   >> [...]
> >>   >>
> >>>  Could you undo this please? Now is not the time to be trimming ops out.
> >
> >When is the time? After another 1000 opcodes are in, which all ought to
> >be functions?
> 
> Yes. Y'know, when we start doing the optimization based on a fully
> designed and implemented engine. Anything before that's premature.
> (Shall I go dig up a half dozen or more archive references with you
> chiding me for premature optimizations?)
> 
> >  > OTOH, it won't hurt anyone and it is already in.
> >
> >That's my point.
> 
> Then your point's wrong. This patch broke a lot of my code.
> 
> You keep wanting to chop things out of the core. Stop. That's not
> your call -- it's mine, and it will be made, but not now.
> 
> Put these back.
> 
> 
> --
> Dan
> 
> --it's like this---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk
>

Re: deprecated transcendental ops with I arguments

[Dan Sugalski]

At 3:02 PM +0100 11/25/04, Leopold Toetsch wrote:
Transcendental (and some other) ops that have a FLOATVAL out 
argument and INTVAL source argument(s) are deprecated.
No, dammit, they are *not* deprecated.
Like the other numeric ops, this isn't your call. Leave them in.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Objects, classes, metaclasses, and other things that go bump in the night

[Dan Sugalski]

Right, so with at least a basic rework of the string stuff in, it's 
time to turn our attention to objects and all the stuff that goes 
with them.

I'd originally thought that the bits we'd put in place would be 
sufficient to do everyone's object system (well, all the languages 
that we explicitly care about at least) but, well... that turns out 
not to be the case.

Here's a quick recap on the architecture bits that already exist.
Each PMC can:
   *) Return a PMC which represents that PMC's class
   *) Look up and return a PMC representing a named method
   *) Look up and return a named property for the PMC
I think that we can accommodate most everyone's needs with this, 
assuming we set up some protocols and give a really big kick to the 
code in objects.c.

The rest of this should be prefaced with the caveat that I'm finding 
that the more I'm learning about how all the different languages do 
objects the less I actually know what's going on, so this all might 
be wrong, or at least really sub-optimal.

Anyway, with the vtable slots as they stand, we can make a method 
call on an object. There's a single op for this -- it calls the 
object's find_method function and then invokes the resulting PMC. The 
object is in complete control over what invokable PMC gets returned, 
and the invoked PMC has full control over what it actually does.

Python has this interesting concept where properties and methods are 
sort of mixed -- that is if you do:

a = foo.some_thing
a will be either the property some_thing or the method object you'd 
get if you invoked some_thing on foo, bound up such that you can 
later do:

a()
and it's the same as if you'd done foo.some_thing(). I think. Pretty 
sure, at least, though I'm not sure of the order. Anyway, for this 
the core functionality is fine, though it assumes that the python 
compiler will emit a "fetch prop/test/fetch method/bind method" 
sequence for the a=foo.bar statement. I think I'm OK with that, 
though I'm more than willing to take arguments to the contrary. 
("It's not easy" isn't a good argument -- we're down at the machine 
level. Nothing's easy. "It breaks because of X and therefore has to 
be a fundamental thing to guarantee it works" is a good argument)

This assumes we have binding functionality that takes some parameters 
and produces an invokable PMC that uses those, and any other 
provided, parameters later on. Given that Perl 6 is doing 
higher-order functions (or curried functions, or whatever) where 
there's going to be a fair amount of binding going on I'm OK with 
core support for this, where core may be "we have a bind PMC type 
with some methods on it" or something like that. Dunno, we can work 
that out later.

PMCs also implement 'is', 'does', and 'can'. These are three vtable 
methods that allow code to query a PMC to see if it it 'is' an 
instance of a named class, if it 'does' a particular interface, and 
whether it 'can' invoke the named method. PMCs are supposed to answer 
truthfully, however no assumptions are made as to how the pmc 
actually is, does, or can do something. It's perfectly acceptable for 
a PMC that has an AUTOLOAD (or its non-perl equivalent) function to 
answer true to any can query, and how an interface is implemented in 
a PMC's parent classes (if indeed it even has any parent classes) is 
also generally irrelevant, so long as the answers are either correct 
or egregiously wrong.

Anyway, so much for the 'outside world' view of objects as black box 
things that have properties and methods. That part's easy, and I 
think we're fine there.

The tricky part is all the bits that back the objects. Or, rather, 
arranging so that everyone can reasonably have their own custom 
backing bits while still allowing mix-n-match inheritance between the 
bits, and providing enough information to do things properly, or to 
cleanly fail. We're not going to *require* that classes of different 
sorts be able to inherit from one another, just require that if they 
do allow that then they behave properly.

Almost everything we do here is going to be with method calls. 
There's very little that I can see that requires any faster access 
than that, so as long as we have a proper protocol that everyone can 
conform to, we should be OK.

The one big exception to the "we use methods" thing is with composite 
objects. The only sane way I can think of to handle cross-system 
inheritance is through delegation and composition -- that is, if you 
have class A which inherits from Foo and A_Class, each of which is 
from a unique object system (like, say, CLOS, perl 5's 'object 
system', and new-style python classes), there's no way a single class 
system can reasonably express the differing semantics, so the only 
sane thing to do is have a composite object. The 'main' object is 
class A's (however that class instantiates objects) and hanging off 
it are two sub-objects, one for Foo and one for A_Class. These 
sub-objects will have a flag set ma

Re: Angle quotes and pointy brackets

[Alexey Trofimenko]

Matthew Walton wrote:
James Mastros wrote:
Larry Wall wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: ah, I forget, how could I do qx'echo $VAR' in Perl6? something like   
: qx:noparse 'echo $VAR' ?

I think we need two more adverbs that add the special features of qx  
and qw,
so that you could write that:

q:x/echo $VAR/
where ordinary qx/$cmd/ is short for
qq:x/$cmd/
  I think I'd like that much better if we consider execution and  
word-splitting to be the primary operations, and interpolation and  
noninterpolation the adverbial modifiers then the other way around,  
making that qx:q/echo $VAR/ or qx:qq/$cmd/.
especially because adverbs are meant to say "how to do" rather than "what  
to do", aren't they?

 OTOH, I expect backticks to be rare enough that I wouldn't mind writing
 use Spawn 'spawn';
spawn :capture :wait ($cmd);
spawn :capture :wait ('echo $VAR');

Although I'm masochistic enough that I don't mind the idea of always  
having to do execution with qx//, qx:q// or qx:qq// (running with other  
suggestions, I'd guess that would be non-interpolating execution, then  
the same again more explicitly, then interpolating execution) but I do  
like the idea of spawn.
hm.. qx:q//  qx:qq//
...compare with:
 qx q//  qx qq//
so there's no need in adverbs. But we have no need in qx either. Why to  
introduce (or REintroduce) something if we have something similar already?

 $captured = system :capture q/cmd../;
or maybe even:
 (code=>$code, out=>$captured, err=>$err) = system qq/cmd/;
or maybe even(!)
 $captured = slurp qq/$cmd |/;
Kind of removes the idea of pulling in the output of other programs as a  
fundamental part of the language though, for that it's nice to have an  
executing, capturing quote. Perhaps an adverb to qx that makes it behave  
like system() - I don't think it'd be a good idea to provide one that  
makes it behave like exec(), although perhaps other people do.
 I haven't that long unix background, and spawning processes is a very  
*fat* operation for me.. maybe after year or two I'll change my point of  
view, but for now I would be pretty happy with a 'slurp' variant. IMHO,  
spawning processes has nothing to do with other quoters, and perl already  
went far away from shells.

but talking about oneliners and short shell-like scripts, where `` is  
pretty useful.. hm.. things good for oneliners are rarely as good for  
larger programs, and vice versa. Of course, Perl5 proves opposite, but  
Perl6 tends to be a little more verbose, and even in Perl5 we use quite  
different "toolbox" and style for mentioned above. Why not to make an  
average sized module of various "shortcut" grammars, with a very short  
name ("x", f.e.), with defaults to export :all, so we could just do
  perl -Mx -e 'print `echo this is a perl5qx`'

even if `` would be taken for something more useful in Perl6,
and still be able to import only something useful for our larger program  
with
 use x qw/:perl5qx/;

Re: Backticks (was: Angle quotes and pointy brackets)

[Luke Palmer]

Juerd writes:
> Luke Palmer skribis 2004-11-29 16:10 (-0700):
> > 
> > http://groups.google.com/groups?selm=20040420175551.GA16162%40wall.org&rnum=1clarify
> >  
> > It says that backticks won't be used at all in Perl 6.  That's (the) one
> > key of the keyboard that we're leaving to user-definition.
> 
> It says that, but after saying "Leaving aside the use of C<``> as a term
> ...". And that use of backticks is what this subthread appears to be
> about. As I interpret it, backsticks for qx, unless elsewhere declared
> gone, are still there.

Sorry, I misread.

Luke

[perl #32676] testj hangs on string_102

[via RT]

# New Ticket Created by  Luke Palmer 
# Please include the string:  [perl #32676]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32676 >


make testj hangs on string_102.pasm.  Here's the gdb backtrace. 

% gdb parrot
GNU gdb Red Hat Linux (6.0post-0.20040223.19rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db 
library "/lib/tls/libthread_db.so.1".

   
(gdb) run -j t/op/string_102.pasm
Starting program: /home/fibonaci/devel/parrot/parrot -j t/op/string_102.pasm
Error while mapping shared library sections:
: Success.
Error while reading shared library symbols:
: No such file or directory.
[Thread debugging using libthread_db enabled]
[New Thread -150292160 (LWP 10828)]
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
[New Thread -159155280 (LWP 10831)]
[New Thread -169645136 (LWP 10832)]

   
Program received signal SIGINT, Interrupt.
[Switching to Thread -150292160 (LWP 10828)]
0x00880d34 in _int_malloc () from /lib/tls/libc.so.6
(gdb) bt
#0  0x00880d34 in _int_malloc () from /lib/tls/libc.so.6
#1  0x00881bbd in _int_memalign () from /lib/tls/libc.so.6
#2  0x00880467 in memalign () from /lib/tls/libc.so.6
#3  0x008826a6 in posix_memalign () from /lib/tls/libc.so.6
#4  0x080ab600 in mem_realloc_executable (old=0x9f13000, newsize=4720) at 
memexec.c:47
#5  0x080ad3d2 in build_asm (interpreter=0x9d21008, pc=0x9f1b1c0, 
code_start=0x9f1b1c0, code_end=0x9f1b56c, objfile=0x0)
at src/jit.c:1402
#6  0x08160068 in init_jit (interpreter=0x9d21008, pc=0x9f1b1c0) at 
src/interpreter.c:461
#7  0x08160124 in runops_jit (interpreter=0x9d21008, pc=0x9f1b1c0) at 
src/interpreter.c:528
#8  0x08160495 in runops_int (interpreter=0x9d21008, offset=0) at 
src/interpreter.c:744
#9  0x081612d2 in runops (interpreter=0x9d21008, offs=0) at src/inter_run.c:81
#10 0x080d6308 in Parrot_runcode (interpreter=0x9d21008, argc=1, 
argv=0xfef6856c) at src/embed.c:762
#11 0x080d614f in Parrot_runcode (interpreter=0x9d21008, argc=1, 
argv=0xfef6856c) at src/embed.c:694
#12 0x0809b4fb in main (argc=1, argv=0xfef6856c) at imcc/main.c:581

% uname -a
Linux jabberwock 2.6.5-1.358custom #2 Mon Aug 16 05:15:44 MDT 2004 i686 athlon 
i386 GNU/Linux

% cat myconfig
Summary of my parrot 0.1.1 configuration:
  configdate='Mon Nov 29 03:39:43 2004'
  Platform:
osname=linux, archname=i386-linux-thread-multi
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=/usr/bin/perl
  Compiler:
cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS 
-DDEBUGGING  -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-I/usr/include/gdbm',
  Linker and Libraries:
ld='gcc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp'
  Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
  Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8

Re: Lexing requires execution (was Re: Will _anything_ be able to

[Adam Kennedy]

It's quite a disappointment in some ways, but we've lived with it in 
Perl 5, and I'm sure we can live with it in Perl 6.

And I still think Perl 6 will have fewer cases in which it's completely 
impossible for not-Perl to parse it. Unfortunately, fewer still implies 
some, and some is still a problem.
Frankly, as the only person who has managed to get together a "guessing 
lexer" that is sufficiently accurate to be something other than useless, 
I see nothing in Perl 6 that makes it any easier than Perl 5. In fact, 
my reason for starting this thread in the first place is because I was 
increasingly getting the feeling there would be MORE problems.

The "prototype and operator/operand content" problem is still there. PPI 
works around it with quite a bit of hackery (look ahead, look behind, 
look ahead again, and shake it all about. Do the hokey pokie etc etc)

For the relevant code, look for '47' in
http://search.cpan.org/src/ADAMK/PPI-0.831/lib/PPI/Token/Whitespace.pm
This can still be easily tricked if you are trying to (see Randal's 
examples again), but usually gets most "real world" code right.

Then again, I avoid the whole problem of attaching params to sub calls 
by not doing it at all. The closest I can get is to list a set of tokens 
within a statement.

Perl 6 has the same problems, and then also adds a higher likelyhood of 
encountering custom grammars than in Perl 5, where source filters are 
considered largely bad form.

The fundamentals would appear to be the same.
As a side note, I may have used "parse" erroneously. What PPI attempts 
to do is to be a tokenizer and a lexer, without understanding its 
function as code.

So perhaps a "syntax lexer" is a closer term. The ability to read in and 
work with code based purely on syntax, without needing to know what it 
means.

Adam

Re: continuation enhanced arcs

[Jeff Clites]

On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
I just thought of a heuristic that might help with register
preservation:
A variable/register should be preserved over a function call if either 
of the
following is true:

1. The variable is referred to again (lexically) after the function has
   returned.
2. The variable is used as the argument of a function call within the
   current compilation unit.
That doesn't solve it, though you'd think it would. Here's the 
counter-example:

x = 1
foo()
print x
y = 2
return y
You'd think that x and y could use the same memory location (register, 
variable--whatever), since ostensibly their lifetimes don't overlap. 
But continuation re-invocation can cause foo() to return multiple 
times, and each time it should print "1", but it won't if x and y use 
the same "slot" (it would print "2" each time after the first). In 
truth, their lifetimes do overlap, due to the hidden (potential) loops 
created by continuations.

The problem isn't preservation across calls per se, it's the implicit 
loops. Continuations are basically gumming up tons of potential 
optimizations.

JEff

Re: EcmaScript

[Bernhard Schmalhofer]

Herbert Snorrason wrote:
On Sat, 27 Nov 2004 22:48:42 +0100, liorean <[EMAIL PROTECTED]> wrote:
CLR, JVM and C/C++ implementations exists. As parrot is supposed to be
better for dynamic languages, I guess EcmaScript 3.0 would fit right
in with parrot.



I'd love to contribute. Could one write an initial compiler in
JavaScript, compile from SEE or SpiderMonkey and then run the compiler
on that implementation?
What the compiler would do is to transform JS code into PIR ... you
most likely could do that in any language, so another JS
implementation wouldn't be impossible.
Hi,
I got started on a ECMAScript-Project, but I haven't really gotten very 
far and haven't looked at it since August.

The basis for 'js2pir.js' is narcissus, 
http://lxr.mozilla.org/mozilla/source/js/narcissus/, which is a 
JavaScript interpreter written in JavaScript.
'narcissus' runs on SpiderMonkey, and the plan was of course to 
eventually do the bootstrapping.

I have put the sources on 
http://www.schmalhofer.info/schmalhofer/bernhard/projects/oxpecker/. 
There are propably a couple of files missing, as I had to recover from 
an unfortunate 'make distclean'.
The status is that "Hello World", but not much else, was running in August.

In case that a real ECMAScript-project gets started, I'd be happy to 
contribute.

CU, Bernhard
--
**
Dipl.-Physiker Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: [EMAIL PROTECTED]
Website: www.biomax.com
**