Re: Perl 6 Summary for 2005-04-12 through 2005-04-19
On Tue, 19 Apr 2005, Matt Fowles wrote:
Python on Parrot
^^
Kevin Tew wondered what the state of pyrate was. Sam Ruby provided a
general explanation.
(I'm not on all of the lists, so this may have come out before and I just
ignore it, but...) this is a pun, isn't it?!?
Michele
--
sub printpages
{
return;
}
This sub is the best code you have written so far.
- A. Sinan Unur in clpmisc, Re: Free source guestbook - unfinished
Re: alarm() and later()
Gaal Yahas [EMAIL PROTECTED] wrote: Two things popped up while implementing a demo version of alarm() today. 1. In perl5 and in most underlying libraries, alarm() has 1 second granularity 2. ..., in which you can pass an optional closure to alarm() I can't say anything about the actual Perl6 syntax, but Parrot provides sub-second resolution as well as alarm callbacks and of course multiple timers. leo
Re: How do I... tie hashes/arrays?
Larry Wall [EMAIL PROTECTED] wrote:
On Tue, Apr 19, 2005 at 02:02:41PM +, Ingo Blechschmidt wrote:
: # Possibility #2
: multi sub *postcircumfix:'[', ']'(TiedArray $self, $index) {
: # Body as above
: }
None of those are quite right, because you have to be prepared to deal
not only with slices, but with multiple dimensions of slices.
Then again the question arises, if all the possible indexed access isn't
clearer written as multi subs:
multi sub *postcircumfix:[ ](TiedArray $self, int $index) {...}
multi sub *postcircumfix:[ ](TiedArray $self, Int $index) {...}
multi sub *postcircumfix:[ ](TiedArray $self, Slice $index) {...}
multi sub *postcircumfix:[ ](TiedArray $self, MyDims $index) {...}
or with FETCH and STORE as distinct variants too, and r/w ...
That's the philosophy, anyway. It may yet turn out that proxying
completely fouls up the optimizer in this case. Sometimes a
cut-and-paste has the benefit of being concrete enough for the
optimizer to understand, whereas the abstraction is too, er, abstract.
Yep.
... However, that being
said, there's enough flexibility in the FETCH/STORE proxy that you
could defactor the identification code out to the various handlers
and get the same benefit.
Well, isn't the defactorized code just a bunch of multi subs?
Larry
leo
apo/A06.pod: spelling error(s)?
In
macro circumfix:(*...*) () is parsed(/.*?/ { }
is the second enclosing part of the parsed parentheses omitted
by intention? If not, I'd volunteer to provide a patch.
Steven
Re: apo/A06.pod: spelling error(s)?
Steven Philip Schubiger writes:
In
macro circumfix:(*...*) () is parsed(/.*?/ { }
is the second enclosing part of the parsed parentheses omitted
by intention? If not, I'd volunteer to provide a patch.
Fixed. Thanks.
Luke
Calling junctions of closures
Hi,
Assuming this is allowed, what will the .() calls below return?
Does the result depend on the calling context?
use junctions; # still required?
my @subs = ( sub { return 1 } ,
sub { return 2 } );
# call the closures in the junction
any(@subs).();
all(@subs).();
one(@subs).();
none(@subs).();
one(any(@subs),sub { ... }).();
I'd guess the rule is call 'em all and return a similarly
structured junction. How far off the mark am I?
On Fri, 2005-02-11 at 10:46 +1100, Damian Conway wrote:
Subject: Re: Fwd: Junctive puzzles.
Junctions have an associated boolean predicate that's preserved across
operations on the junction. Junctions also implicitly distribute across
operations, and rejunctify the results.
Brad
PS. Pugs 6.2.0 currently gets confused:
pugs: cannot cast from VJunc
any(SubRoutine(anon),SubRoutine(anon)) to AST.VCode
--
The occurrence of mysteries is alway by word of mouth. -- Hagakure
Re: Calling junctions of closures
Brad Bowman wrote:
Assuming this is allowed, what will the .() calls below return?
Does the result depend on the calling context?
...
one(any(@subs),sub { ... }).();
Starting to argument from the statement that junctions are values
the above plays in the league of 3.() which might not have observeable
side effects other then busying the compiler for a while. Actually
it could be optimised away :)
I'd guess the rule is call 'em all and return a similarly
structured junction. How far off the mark am I?
Unless you ask a question nothing is called. So at least you need
something like if one(...) {...}. Then the call order is undefined
and might stop after the first success. Knowing about the constness
of the return values of the subs referred to from the junction, and
knowing that none of their values is false, these cases might be
optimized towards the front when this stops the influx of further
interrogation by the if. The reverse might apply for interrogation
by unless---but that's up to the oracle :)
--
TSa (Thomas Sandlaß)
{ = } autocomposition
In Pugs's t/pugsbugs/map_function_return_values.t, iblech added this test:
%ret = map { $_ = uc $_ }, split , $text;
This fails because it is parsed, undef the {=} autocomposition rule, into:
# Fails because arg1 is not Code
%ret = map(hash($_ = uc $_), split(, $text));
Instead of the intended:
# Works correctly
%ret = map(sub ($_) { $_ = uc $_ }, split(, $text));
Is this a known issue?
Thanks,
/Autrijus/
pgpB0h0cY8Ev9.pgp
Description: PGP signature
embedding languages in Perl 6
Hi,
I'm just wondering, if the following would be possible with Perl 6 or not?
XML
$a=elemselemContent #1/elemelemContent #2/elem/elems;
say $a.elems[0].elem[1].content; # Content #1
for ($a.elems) { say $_.content; }
or XPath like syntax on a structure?
SQL
$a=select * from table;
for(select * from table where id5) {
say $_.id ~ ' - ' $_.value;
}
The ideas coming from Comega, the next version of CSharp(?). Here's an
intro about it:
http://www.xml.com/pub/a/2005/01/12/comega.html?page=2
Or just search for comega with you favourite search engine.
The first one, creating native XML support for a language is not new,
E4X (EcmaScript for XML) is about the same:
http://www.ecma-international.org/publications/standards/Ecma-357.htm
I think both about macros, and it seem's it will be possible extend Perl
6 with them. But what do you think about extending Perl 6 (or Perl 6.1)
with native XML handling, like it's native regular expression / rule
handling?
Bye,
Andras
Re: { = } autocomposition
Hi,
Autrijus Tang wrote:
%ret = map { $_ = uc $_ }, split , $text;
[...]
I suppose my test is wrong.
When I clicked on reply a moment ago, I wanted to propose to change the
hash/code disambiguation rule, so that {...} is always parsed as Code
if the body contains $_ or $^
But as this change would break the following code, I think we should
leave it as it now.
my @AoH = map {
my $hashref = { $^a = ... };
do_something_with $hashref;
$hashref;
};
--Ingo
--
Linux, the choice of a GNU | Mr. Cole's Axiom: The sum of the
generation on a dual AMD | intelligence on the planet is a constant;
Athlon!| the population is growing.
Re: { = } autocomposition
On Wed, Apr 20, 2005 at 05:08:53PM +0200, Ingo Blechschmidt wrote:
: Hi,
:
: Autrijus Tang wrote:
: %ret = map { $_ = uc $_ }, split , $text;
: [...]
:
: I suppose my test is wrong.
:
: When I clicked on reply a moment ago, I wanted to propose to change the
: hash/code disambiguation rule, so that {...} is always parsed as Code
: if the body contains $_ or $^
:
: But as this change would break the following code, I think we should
: leave it as it now.
: my @AoH = map {
: my $hashref = { $^a = ... };
: do_something_with $hashref;
: $hashref;
: };
Hmm, what we have said in the past is that the proper way to disambiguate
that is to require an explicit return if you mean the closure, but that
doesn't actually work unless there's an explicit sub. I suppose the
rightest answer at this point is:
%ret = map { ($_ = uc $_) }, split , $text;
since the = is no longer the top-level operator, but the parens are, if
you believe in parens as an operator and not just a grouper. Or
%ret = map { $_ = uc $_; }, split , $text;
should presumably also work. That may look like an arbitrary amount
of lookahead, but I tried to define the hash/closure rule in terms of
a semantic analysis rule rather than a syntax rule, such that it's
always parsed as a closure, but at some point in semantic analysis
you can look at the AST and see that the top-level operator is =,
and throw an implicit new Hash: do on the front of the closure,
or whatever operator it is that evaluates a closure for its pairs
and builds a hash from it.
I'd really like to save the overloading of {...} if we can DWTM in most
cases and at least produce decent errors in the other cases. We can
certainly produce a decent Maybe you meant... diagnostic on the
map thingy, even if it defaults counterintuitively in that case.
Larry
Re: { = } autocomposition
On Wed, Apr 20, 2005 at 08:51:24AM -0700, Larry Wall wrote:
That may look like an arbitrary amount of lookahead, but I tried to
define the hash/closure rule in terms of a semantic analysis rule
rather than a syntax rule, such that it's always parsed as a closure,
but at some point in semantic analysis you can look at the AST and see
that the top-level operator is =, and throw an implicit new Hash:
do on the front of the closure, or whatever operator it is that
evaluates a closure for its pairs and builds a hash from it.
Currently in Pugs, the analysis is done when the parser is done parsing a
block, i.e. when there is a Exp already formed:
-- Try to analyze Exp if the block is bare and without formal
-- arguments; extractHash merely looks at the toplevel OP, to
-- see if it matches (pair | =) or (, [(pair | =), ...])
retBlock SubBlock Nothing exp
| Just hashExp - extractHash exp = return \\{} [hashExp]
%ret = map { ($_ = uc $_) }, split , $text;
%ret = map { $_ = uc $_; }, split , $text;
Sadly, both the grouping parens and the trailing semicolon are currently
ignored as semantically insignificant.
I think the latter suggestions works better, as we already make the
distinction between semicolon-separated Stmts (which contains multiple
Exps), and a simple Exp.
Adding a special form Parens that takes one Exp and simply returns
it is possible, but unless it serves to disambiguate other cases,
that approach seems more heavy-handed to me.
Thanks,
/Autrijus/
pgpSrBabV4fWE.pgp
Description: PGP signature
Re: embedding languages in Perl 6
On Wed, Apr 20, 2005 at 05:08:51PM +0200, BÁRTHÁZI András wrote:
: Hi,
:
: I'm just wondering, if the following would be possible with Perl 6 or not?
:
: XML
:
: $a=elemselemContent #1/elemelemContent #2/elem/elems;
:
: say $a.elems[0].elem[1].content; # Content #1
:
: for ($a.elems) { say $_.content; }
:
: or XPath like syntax on a structure?
That's somewhat ambiguous with our current qw// notoation.
: SQL
:
: $a=select * from table;
: for(select * from table where id5) {
: say $_.id ~ ' - ' $_.value;
: }
That one would be pretty easy to do with a select macro, if you could
figure out how to terminate the SQL parse.
: The ideas coming from Comega, the next version of CSharp(?). Here's an
: intro about it:
:
: http://www.xml.com/pub/a/2005/01/12/comega.html?page=2
:
: Or just search for comega with you favourite search engine.
:
: The first one, creating native XML support for a language is not new,
: E4X (EcmaScript for XML) is about the same:
:
: http://www.ecma-international.org/publications/standards/Ecma-357.htm
:
: I think both about macros, and it seem's it will be possible extend Perl
: 6 with them. But what do you think about extending Perl 6 (or Perl 6.1)
: with native XML handling, like it's native regular expression / rule
: handling?
We should avoid installing fads or domain-specific sublanguages into
Standard Perl 6, but it's easy enough to change the language with a
single use or macro. I see that doing select is trivial and doesn't
impact anything in Standard Perl 6, since Perl 5's select() is likely
going away anyway.
It's a little harder to sneak foo.../foo into the language since
we have foo to mean qw/foo/ as a term. Perhaps this is indicating
that we should reserve a character for introducing user-defined terms.
I suppose the logical candidate for that is ` these days, since pretty
much everything else in ASCII land is taken. So you could write
a macro on ` that treats the next thing as a self-terminating construct.
(That is, no terminating ` is required, though the default `...` could
still parse to mean q:x/.../, I suppose. You'd lose that if you redefine
term:` to something else, but no big loss, unlike foo.) Anyway,
you'd get things like:
$a=`elemselemContent #1/elemelemContent #2/elem/elems;
$a=`select * from table`;
I've gone ahead and terminated the sql variant like a quote construct
just to clarify the end of it, since SQL is not so obviously self-terminating
as XML is.
You could not, of course, have both of those unless you did lookahead
to see if the next thing was or select. Hmm, maybe that should be
standard behavior for user-defined ` extensions. If the actual
macros were term:`\ and term:`select, then any unrecognized
`...` could still default to qx//. Of course, then you'd have to be
careful about things like:
$meow = `/dev/tty cat`;
We've also proposed reserving ` for introducing units, but that would
be where an operator is expected, not a term, so it doesn't conflict
with term usages unless you also want to use those terms as subscripts.
In other words, Juerd could overload postfix:` to do %hash`foo if he
still wants to do that, but then he couldn't also use ` to mark units.
Larry
Re: { = } autocomposition
On Thu, Apr 21, 2005 at 12:09:18AM +0800, Autrijus Tang wrote: : Adding a special form Parens that takes one Exp and simply returns : it is possible, but unless it serves to disambiguate other cases, : that approach seems more heavy-handed to me. As someone who is currently trying to write a perfect p5-to-p5 [sic] translator, you have to somehow remember the parens (and whitespace (and comments (and constant-folded subtrees))) to have a complete AST representation of the original text. Or maybe it should be called a CST instead of an AST in that case... Though remembering doesn't have to be the default. But I'd like to point out that adding such annotations to the AST after you've optimized parts of the tree away is much more difficult than reserving a spot for them in the first place. I speak from sad experience... :-) Larry
Re: { = } autocomposition
On Wed, Apr 20, 2005 at 09:38:28AM -0700, Larry Wall wrote: As someone who is currently trying to write a perfect p5-to-p5 [sic] translator, you have to somehow remember the parens (and whitespace (and comments (and constant-folded subtrees))) to have a complete AST representation of the original text. Or maybe it should be called a CST instead of an AST in that case... I see. Do you think preserving the /span/ (i.e. the character offset ranges) of each AST element is enough to do that? That effectively means each node points to a substring inside the original source string. That way, p6-to-p6 translators in the future can, at worst, trigger a reparse under the appropriate subrules level, and obtain the information we optimized away. Thanks, /Autrijus/ pgpMrB9z2eohX.pgp Description: PGP signature
Re: embedding languages in Perl 6
Hi,
: I'm just wondering, if the following would be possible with Perl 6 or not?
:
: XML
:
: $a=elemselemContent #1/elemelemContent #2/elem/elems;
:
: say $a.elems[0].elem[1].content; # Content #1
:
: for ($a.elems) { say $_.content; }
:
: or XPath like syntax on a structure?
That's somewhat ambiguous with our current qw// notoation.
Yes, I've realized it. One of the reason of my mail was this.
: SQL
:
: $a=select * from table;
: for(select * from table where id5) {
: say $_.id ~ ' - ' $_.value;
: }
That one would be pretty easy to do with a select macro, if you could
figure out how to terminate the SQL parse.
It ends, when a non opened ')', a ';' or a '}' is coming. Of course,
that's not all cases, but it seems to be not so hard to find the all
possible cases.
: The ideas coming from Comega, the next version of CSharp(?). Here's an
: intro about it:
:
: http://www.xml.com/pub/a/2005/01/12/comega.html?page=2
:
: Or just search for comega with you favourite search engine.
:
: The first one, creating native XML support for a language is not new,
: E4X (EcmaScript for XML) is about the same:
:
: http://www.ecma-international.org/publications/standards/Ecma-357.htm
:
: I think both about macros, and it seem's it will be possible extend Perl
: 6 with them. But what do you think about extending Perl 6 (or Perl 6.1)
: with native XML handling, like it's native regular expression / rule
: handling?
Let me note, that E4X is not just about declaring, but processing, too.
We should avoid installing fads or domain-specific sublanguages into
Standard Perl 6, but it's easy enough to change the language with a
single use or macro. I see that doing select is trivial and doesn't
impact anything in Standard Perl 6, since Perl 5's select() is likely
going away anyway.
I'm not sure, if XML is more domain specific than regexp or not. I think
it's somewhere related to text processing as much as regexpes.
It's a little harder to sneak foo.../foo into the language since
we have foo to mean qw/foo/ as a term. Perhaps this is indicating
that we should reserve a character for introducing user-defined terms.
I suppose the logical candidate for that is ` these days, since pretty
much everything else in ASCII land is taken. So you could write
a macro on ` that treats the next thing as a self-terminating construct.
(That is, no terminating ` is required, though the default `...` could
still parse to mean q:x/.../, I suppose. You'd lose that if you redefine
term:` to something else, but no big loss, unlike foo.) Anyway,
you'd get things like:
$a=`elemselemContent #1/elemelemContent #2/elem/elems;
I don't like it. I've learned at Perl 5 and in other languages, that `
need a closing `.
It would be nicer to say:
$a=xmlelemselemContent #1/elemelemContent #2/elem/elems;
But native xml parsing is better, I think. :)
$a=`select * from table`;
It looks better, but I think ` isn't needed for it. Anyway, I agree,
that SQL is a more domain specific language, that it should come from a
module - at least you have to give for initialization somewhere the
server address, the user and the password (or other connection
parameters), so it's better to do it at with a setup sub.
Anyway, it's possible to write:
$a=sqlselect * from table;
I've gone ahead and terminated the sql variant like a quote construct
just to clarify the end of it, since SQL is not so obviously self-terminating
as XML is.
If MS Comega and E4X can do it, I think Perl 6 could do it easily, too. ;)
You could not, of course, have both of those unless you did lookahead
to see if the next thing was or select. Hmm, maybe that should be
standard behavior for user-defined ` extensions. If the actual
I agree, except the notation.
Bye,
Andras
Closure/block/sub multiplier /// Win32 module for Perl6
Ok, I have 2 questions. 1. I know there is the xx operator for repeating strings. I also know you can use XX for repeating either closures, blocks, or subs; though I'm not sure which. Assuming you could use XX on a sub, how would you gather the results into an array? @names = get_next(...) XX 5; Would this even be possible, or is it now? 2. Is anyone working on making a Win32 module for Perl6 yet, or porting over the p5 one? If not, I may be willing to make one, along with some help from friends. If I do, does anyone have any pointers or suggestions for me when I begin the adventure? Specifically, how it should be organized, among other things. Thanks :), Matt Creenan -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Closure/block/sub multiplier /// Win32 module for Perl6
Matt skribis 2005-04-20 13:00 (-0400):
1. I know there is the xx operator for repeating strings. I also know you
can use XX for repeating either closures, blocks, or subs; though I'm not
sure which. Assuming you could use XX on a sub, how would you gather the
results into an array?
@names = get_next(...) XX 5;
I'm not sure the XX thing will happen, but if it does, it'd be most
useful if it wouldn't treat a sub call differently.
In other words,
@random = { rand } XX 5;
would return 5 different random values, while
@random = { rand }() XX 5;
would do exactly the same as
@random = rand xx 5;
And your
@names = get_next(...) XX 5; # Why the , by the way?
I think should be
@names = { get_next(...) } XX 5;
or, if get_next doesn't take arguments,
@names = get_next XX 5;
Note that if the ... should change each of the 5 times, then this should
be done using map:
1..5 == map { get_next($_) } == @names;
or of course
@names = map { get_next($_) }, 1..5;
The XX was proposed mainly because the 1..5 part of map often does not
make sense as a range, and in those cases you just abuse it for
repetition.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: alarm() and later()
On Wed, Apr 20, 2005 at 08:20:04AM +0200, Leopold Toetsch wrote:
: I can't say anything about the actual Perl6 syntax, but Parrot provides
: sub-second resolution as well as alarm callbacks and of course multiple
: timers.
We will certainly be pushing all the time interfaces of Perl 6 toward
using floating-point time values. The only question is whether alarm()
is the right name for one of the interfaces, and whether we even need an
interface whose *default* behavior is to send a signal, ugh. We should
probably be encouraging timed callbacks instead. We could even force
people to define their own alarm if they want one. Assuming we
rehuffmanize kill to sendsignal or some such, we have:
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.cue(:delay($secs));
}
Though I suppose people really mostly just want something like
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.delay($secs);
}
The actual verb/adverb names are negotiable, but they need to handle
relative vs absolute times intuitively. Different words have different
connotations in that regard. delay is definitely relative, while
after tends toward absolute, though can be used relatively too.
at is definitely absolute time, but maybe too overloaded with
positional meanings. later is unfortunately completely ambiguous.
By the way, I was tempted to make it sendsig, but then I started
wondering what it would mean to send a sigil or a signature...
In any event (no pun intended), I've always wondered how it is you
can kill a process with a SIGCONT. As long as we're fixing everything
else, maybe we can fix Unix too. :-)
Larry
Re: Closure/block/sub multiplier /// Win32 module for Perl6
Juerd skribis 2005-04-20 19:09 (+0200): I'm not sure the XX thing will happen, but if it does, it'd be most useful if it wouldn't treat a sub call differently. I forgot rationale. It shouldn't treat a sub call differently, so that a called sub can in a useful manner return a closure, which is then executed several times. The same annoying special syntax can be found in perl 5's goto, that can't go to a returned subref using goto sub_that_returns_a_subref();. Which brings me to the following questions: Does goto LABEL still exist in Perl 6? Must LABEL be quoted/a normal string? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: { = } autocomposition
On Thu, Apr 21, 2005 at 12:50:56AM +0800, Autrijus Tang wrote: : I see. Do you think preserving the /span/ (i.e. the character offset ranges) : of each AST element is enough to do that? That effectively means each : node points to a substring inside the original source string. Yes, though making a copy isn't bad if it's not the default behavior. It mostly just needs a spot. : That way, p6-to-p6 translators in the future can, at worst, trigger a : reparse under the appropriate subrules level, and obtain the information : we optimized away. Except that you've probably thrown away the definition of appropriate by then as well. :-) p5-to-p5 actually intercepts the op_free() calls and has a place for all the optimized trees. But that's not the default behavior. By default it only costs one empty madprops pointer per op node. (MAD stands for miscellaneous attribute decorations.) Only if we set the madskills option do we generate a linked list of madprops. Then you don't have to worry about the overhead in the general case, and you also don't have to worry about your two parses getting out of sync in the specific case. You just have to know in advance when you want to remember the details, which I think is not too much of a constraint. If you don't want to worry about this in the Haskell version of the compiler, that's okay, as long as we think about it more when we bootstrap the Perl 6 version. Certainly if you're remembering parens in some optional data structure, you can't depend on it for ordinary disambiguation. Larry
Re: { = } autocomposition
On Wed, Apr 20, 2005 at 10:21:32AM -0700, Larry Wall wrote: : Except that you've probably thrown away the definition of appropriate : by then as well. :-) Well, maybe not, since you presumably need to keep track of the current parser for eval. Larry
Re: embedding languages in Perl 6
On Wed, Apr 20, 2005 at 06:57:00PM +0200, BÁRTHÁZI András wrote: : It ends, when a non opened ')', a ';' or a '}' is coming. Of course, : that's not all cases, but it seems to be not so hard to find the all : possible cases. The question is what will be clear to the reader of the code. : We should avoid installing fads or domain-specific sublanguages into : Standard Perl 6, but it's easy enough to change the language with a : single use or macro. I see that doing select is trivial and doesn't : impact anything in Standard Perl 6, since Perl 5's select() is likely : going away anyway. : : I'm not sure, if XML is more domain specific than regexp or not. I think : it's somewhere related to text processing as much as regexpes. I was classifying XML as fad. :-) : $a=`elemselemContent #1/elemelemContent #2/elem/elems; : : I don't like it. I've learned at Perl 5 and in other languages, that ` : need a closing `. I think that would be relatively easy to unlearn. : It would be nicer to say: : : $a=xmlelemselemContent #1/elemelemContent #2/elem/elems; : : But native xml parsing is better, I think. :) Sure, just not in Standard Perl 6, which lasts no longer than down to the first use. : $a=`select * from table`; : : It looks better, but I think ` isn't needed for it. Anyway, I agree, : that SQL is a more domain specific language, that it should come from a : module - at least you have to give for initialization somewhere the : server address, the user and the password (or other connection : parameters), so it's better to do it at with a setup sub. : : Anyway, it's possible to write: : : $a=sqlselect * from table; I think something like that is a lot more readable than the dangling sql syntax. : I've gone ahead and terminated the sql variant like a quote construct : just to clarify the end of it, since SQL is not so obviously : self-terminating : as XML is. : : If MS Comega and E4X can do it, I think Perl 6 could do it easily, too. ;) It can do it easily. Just not by default. :-) : You could not, of course, have both of those unless you did lookahead : to see if the next thing was or select. Hmm, maybe that should be : standard behavior for user-defined ` extensions. If the actual : : I agree, except the notation. Details, details... Now where did I put my spare bikeshed... :-) Larry
Fwd: Re: embedding languages in Perl 6
I sent this to BÁRTHÁZI only instead of BÁRTHÁZI and the list as well. So
here's a forward of what I sent and he replied to.
--- Forwarded message ---
From: Matt [EMAIL PROTECTED]
To: BÁRTHÁZI András [EMAIL PROTECTED]
Cc:
Subject: Re: embedding languages in Perl 6
Date: Wed, 20 Apr 2005 13:12:43 -0400
On Wed, 20 Apr 2005 12:57:00 -0400, BÁRTHÁZI András [EMAIL PROTECTED]
wrote:
It would be nicer to say:
$a=xmlelemselemContent #1/elemelemContent #2/elem/elems;
But native xml parsing is better, I think. :)
Anyway, it's possible to write:
$a=sqlselect * from table;
If not already possible, it would be neat to be able to define your own
quote blocks. Such as being able to define how to parse the below lines:
$result = q:sql/SELECT * FROM table/;
for q:sql/SELECT * FROM table WHERE id=$id/ {
say $_.id ~ ' - ' ~ $_.value;
}
Or someone could write a module for P6SQL ? (Pardon me for not remembering
exactly how HEREDOCs work in P6)
p6sql_query SQLPROC
$result = SELECT * FROM table
FOREACH ROW IN $result AS $field
SAY $field.id - $field.value
END FOREACH
SQLPROC
Or maybe I'm getting a bit too crazy.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: { = } autocomposition
On Wed, Apr 20, 2005 at 10:21:32AM -0700, Larry Wall wrote: On Thu, Apr 21, 2005 at 12:50:56AM +0800, Autrijus Tang wrote: : I see. Do you think preserving the /span/ (i.e. the character offset ranges) : of each AST element is enough to do that? That effectively means each : node points to a substring inside the original source string. Yes, though making a copy isn't bad if it's not the default behavior. It mostly just needs a spot. Okay. I'll make it happen then. Is this something we want to make available at the runtime language level, in addition to the compiler error/warnings level? p5-to-p5 actually intercepts the op_free() calls and has a place for all the optimized trees. But that's not the default behavior. By default it only costs one empty madprops pointer per op node. (MAD stands for miscellaneous attribute decorations.) Only if we set the madskills option do we generate a linked list of madprops. Wow, nice trick. Mad props to you. :) Then you don't have to worry about the overhead in the general case, and you also don't have to worry about your two parses getting out of sync in the specific case. You just have to know in advance when you want to remember the details, which I think is not too much of a constraint. As you noted in the followup mail, I think the compiler needs to remember the active subrule and source code range anyway, so that performance penalty is already there. If you don't want to worry about this in the Haskell version of the compiler, that's okay, as long as we think about it more when we bootstrap the Perl 6 version. I do intend to bootstrap the Perl 6 version by simply compiling the Pugs source code from Haskell into Perl6 AST, then decompile it back into Perl 6 code. :-) That is, unless someone crazy enough comes around and recoded everything in Perl 6 by hand... Thanks, /Autrijus/ pgpSLpfMhGbK8.pgp Description: PGP signature
Re: Fwd: Re: embedding languages in Perl 6
On Wed, Apr 20, 2005 at 01:51:11PM -0400, Matt wrote:
: If not already possible, it would be neat to be able to define your own
: quote blocks. Such as being able to define how to parse the below lines:
:
: $result = q:sql/SELECT * FROM table/;
:
: for q:sql/SELECT * FROM table WHERE id=$id/ {
: say $_.id ~ ' - ' ~ $_.value;
: }
That's certainly doable, for some value of certainly. But see below.
: Or someone could write a module for P6SQL ? (Pardon me for not remembering
: exactly how HEREDOCs work in P6)
:
: p6sql_query SQLPROC
:
: $result = SELECT * FROM table
: FOREACH ROW IN $result AS $field
: SAY $field.id - $field.value
: END FOREACH
:
: SQLPROC
:
: Or maybe I'm getting a bit too crazy.
Heredocs are variants on q:toSQLPROC these days, but if you're going
to be mixing Perl and SQL syntax, it's probably better to dispense
with the heredoc and just have a language variant so that you can
parse it at compile time. A heredoc would tend to delay your parse
till run-time, and you'd still have to mix up your parsers somehow.
I don't offhand see a good reason for delaying your parse till run
time, and I can see good reasons for wanting to make your SQL visible
to some optimizer or other at compile time. (You can certainly parse
at compile time and delay various bindings till run time, so that's not
what is at issue here.)
Larry
Re: Fwd: Re: embedding languages in Perl 6
Matt skribis 2005-04-20 13:51 (-0400):
If not already possible, it would be neat to be able to define your own
quote blocks. Such as being able to define how to parse the below lines:
It is possible to create your own sql// if you want it.
for q:sql/SELECT * FROM table WHERE id=$id/ {
say $_.id ~ ' - ' ~ $_.value;
}
What is the benefit of this syntax over having a simple function that
takes one argument, interpolating variables from CALLER::?
for sql 'SELECT * FROM table WHERE id=$id' { ... }
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, Apr 20, 2005 at 07:17:14PM +0200, Juerd wrote:
: Juerd skribis 2005-04-20 19:09 (+0200):
: I'm not sure the XX thing will happen, but if it does, it'd be most
: useful if it wouldn't treat a sub call differently.
:
: I forgot rationale.
:
: It shouldn't treat a sub call differently, so that a called sub can in a
: useful manner return a closure, which is then executed several times.
: The same annoying special syntax can be found in perl 5's goto, that
: can't go to a returned subref using goto sub_that_returns_a_subref();.
Doesn't this work in Perl 5?
goto {sub_that_returns_a_subref()};
If not, I'd say it's a bug.
: Which brings me to the following questions:
:
: Does goto LABEL still exist in Perl 6?
:
: Must LABEL be quoted/a normal string?
Hmm, well we do still have bare labels for loop control, so I'd
probably still put goto LABEL into the same category. Overloading
goto in Perl 5 for stack frame replacement was probably a mistake.
These days that should probably be handled with sub.tailcall(@_) or
some such anyway so that we can confuse it with ordinary tailcall
optimizations. In fact, that might just be what ordinary tailcall
optimization compiles down to.
Larry
Re: alarm() and later()
On Wed, Apr 20, 2005 at 10:11:35AM -0700, Larry Wall wrote:
We will certainly be pushing all the time interfaces of Perl 6 toward
using floating-point time values. The only question is whether alarm()
is the right name for one of the interfaces, and whether we even need an
interface whose *default* behavior is to send a signal, ugh. We should
probably be encouraging timed callbacks instead. We could even force
people to define their own alarm if they want one. Assuming we
rehuffmanize kill to sendsignal or some such, we have:
(FWIW, this is called signalProcess in Haskell.)
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.cue(:delay($secs));
}
Though I suppose people really mostly just want something like
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.delay($secs);
}
The actual verb/adverb names are negotiable, but they need to handle
relative vs absolute times intuitively. Different words have different
connotations in that regard. delay is definitely relative, while
after tends toward absolute, though can be used relatively too.
at is definitely absolute time, but maybe too overloaded with
positional meanings. later is unfortunately completely ambiguous.
We also want repeat events; I can think of two ways to do it. Either
require everything to be explicit with adverbs, or have the closure's
return value determine whether to keep calling back or to quit. GLib
does the latter, and there's a cleanliness in how the closure itself can
control when to stop, but the former means you can schedule arbitrary
code without changing it.
Is there anybody from the perl-loop gang around here? I'm sure they've
thought about these things a lot.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Fwd: Re: embedding languages in Perl 6
Hi,
What is the benefit of this syntax over having a simple function that
takes one argument, interpolating variables from CALLER::?
for sql 'SELECT * FROM table WHERE id=$id' { ... }
The difference is between compile time parsing and runtime parsing. This
expression can be transformed to a prepare statement plus a call, which
is not just faster, but more safer, if $id contains aposthropes or other
characters.
Maybe other abstraction would be possible, too.
What about this (I'm not really sure, if it's ok):
INSERT INTO table (col1, col2) VALUES %row;
And it will be:
INSERT INTO table (col1, col2) VALUES (?,?)
and
%row.col1, %row.col2 will be insert as values.
Bye,
Andras
Re: Fwd: Re: embedding languages in Perl 6
On Wed, 20 Apr 2005 14:13:42 -0400, Larry Wall [EMAIL PROTECTED] wrote:
Heredocs are variants on q:toSQLPROC these days, but if you're going
to be mixing Perl and SQL syntax, it's probably better to dispense
with the heredoc and just have a language variant so that you can
parse it at compile time. A heredoc would tend to delay your parse
till run-time, and you'd still have to mix up your parsers somehow.
I don't offhand see a good reason for delaying your parse till run
time, and I can see good reasons for wanting to make your SQL visible
to some optimizer or other at compile time. (You can certainly parse
at compile time and delay various bindings till run time, so that's not
what is at issue here.)
Larry
Good point.
On Wed, 20 Apr 2005 14:14:47 -0400, Juerd [EMAIL PROTECTED] wrote:
What is the benefit of this syntax over having a simple function that
takes one argument, interpolating variables from CALLER::?
for sql 'SELECT * FROM table WHERE id=$id' { ... }
Juerd
You know, you are right. That would work. I just didn't put enough
thought into it, or else I would have realized that the specialized quote
serves no special purpose over a simple function.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Closure/block/sub multiplier /// Win32 module for Perl6
Larry Wall skribis 2005-04-20 11:25 (-0700):
: It shouldn't treat a sub call differently, so that a called sub can in a
: useful manner return a closure, which is then executed several times.
: The same annoying special syntax can be found in perl 5's goto, that
: can't go to a returned subref using goto sub_that_returns_a_subref();.
Doesn't this work in Perl 5?
goto {sub_that_returns_a_subref()};
If not, I'd say it's a bug.
Hm, it does. But it's not something I thought of when I needed it.
But it's one of those cases that have case-specific special syntax, and
I think it's best to avoid that.
The same thing goes for all those places where a variable is expected
that begins with $, like foreach. You can't easily use an lvalue sub.
The workaround is like your goto workaround:
for ${\thatsub()} (1..10) { ... }
Although admittedly, I only encountered this when playing with a
non-readonly undef ;) (This is something I can recommend to anyone:
redefining true, false and undef leads to very spectacular code, where
anything's possible, and defined(undef) can be a true that stringifies
as false.)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: { = } autocomposition
At 10:38 PM +0800 4/20/05, Autrijus Tang wrote:
In Pugs's t/pugsbugs/map_function_return_values.t, iblech added this test:
%ret = map { $_ = uc $_ }, split , $text;
This fails because it is parsed, undef the {=} autocomposition rule, into:
# Fails because arg1 is not Code
%ret = map(hash($_ = uc $_), split(, $text));
Instead of the intended:
# Works correctly
%ret = map(sub ($_) { $_ = uc $_ }, split(, $text));
Is this a known issue?
A clear way to disambiguate a block from a hash-ref when using
map/grep/sort etc is to use a colon before the leading brace for a
block rather than a space, like this:
map:{ $_ = uc $_ }
I read that in the synopsis documents a month back, though I'm having
a bit of trouble finding the reference now. Maybe it has something
to do with adverbs? But I do explicitly remember it being used to
disambiguate.
In any event, I used that form exclusively with my Perl 6 ports to date.
So in that case, the test is wrong.
-- Darren Duncan
Re: { = } autocomposition
At 8:43 PM +0200 4/20/05, Juerd wrote:
Darren Duncan skribis 2005-04-20 11:40 (-0700):
A clear way to disambiguate a block from a hash-ref when using
map/grep/sort etc is to use a colon before the leading brace for a
block rather than a space, like this:
map:{ $_ = uc $_ }
I think the best disambiguators for hash/sub interpretation are hash
and sub, even though sub is a little longer than a colon.
Juerd
In this case, I seem to recall reading that the problem was with the
space, and the colon replaces the space.
The problem is that, with 'sort' for example, the block is optional,
and I think it is like an adverb.
For example, this leaves it out:
@bar = sort @foo;
In this case, it is kept:
@bar = sort:{ $a = $b } @foo;
In both cases, @foo is the argument, and not the block. If you do
'sub' or etc, that would make this look like a code argument, which
it isn't.
If you did this:
@bar = sort { ... } @foo;
Then the {} would look like a first argument which is a hash ref.
The general principle of using the ':' was meant to work with any
kind of list operator usage, to say how it does its thing, not with
what.
-- Darren Duncan
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, Apr 20, 2005 at 07:17:14PM +0200, Juerd wrote:
: Must LABEL be quoted/a normal string?
Forgot to answer the more general question. Presuming we still have
next LABEL;
last LABEL;
redo LABEL;
goto LABEL;
how do we parse something like this
goto join , L, { rand 10 } XX rand 10;
without doing inconsistent autoquoting or confusticating the current
subroutine namespace with the label space? I think the answer is
that those control keywords always autoquote the next identifier,
and if you want to do something run-timeish, you have to say
goto(join , L, { rand 10 } XX rand 10);
or, slightly more problematically,
(join , L, { rand 10 } XX rand 10).goto;
(slightly more problematic insofar as .goto is presumably not a
built-in method on Str, so you're relying on failover to MMD.)
Anyway, with these rules, goto LABEL and friends can just automatically
quote the next identifier if there is one, and not worry about it
otherwise, just as = only autoquotes its left side if it's an identifier.
Or did we open that up to general names like Foo::bar? I don't recall.
Hmm. What would it mean to goto a class?
And if we write
Foo::Bar = 1,
Str = 2,
do we care that class names are getting string typed in the pairs'
keys, if you can use a string as a class name anywhere? Or maybe
we don't care the other direction, insofar as, if the = autoquoter
ignores predefined class names and types them as classes, but classes
always stringify to their own name anyway, so it doesn't matter. Hmm.
That's probably better, since with the first approach we'd have to make
sure that Str supports class methods somehow, if only by failover to MMD.
It would be kind of nice if autoquoting policy were similar between =
and goto, but maybe that's a foolish consistency. We've never allowed
:: in labels before, whereas I can see lots of uses for class names
on the left side of pairs.
I think I'm arguing myself out of autoquoting :: names. So in
Foo::Bar = 1,
Str = 2,
I think it should autoquote Str only, and then if you really mean
the class there instead of the autoquoted string, you should say
::Str = 2,
instead. And now we don't have a problem with consistency. Autoquoted
labels are limited to bare identifiers also.
Larry
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, Apr 20, 2005 at 08:39:43PM +0200, Juerd wrote:
: The same thing goes for all those places where a variable is expected
: that begins with $, like foreach. You can't easily use an lvalue sub.
: The workaround is like your goto workaround:
:
: for ${\thatsub()} (1..10) { ... }
Yes, and that's one reason we intentionally broke most of those forced
sigil syntaxes for Perl 6. You can say push($foo,$bar) in Perl 6 too.
: Although admittedly, I only encountered this when playing with a
: non-readonly undef ;) (This is something I can recommend to anyone:
: redefining true, false and undef leads to very spectacular code, where
: anything's possible, and defined(undef) can be a true that stringifies
: as false.)
Perl 6 culture might feebly try to discourage the redefinition of truth.
Larry
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, Apr 20, 2005 at 12:00:22PM -0700, Larry Wall wrote: : Although admittedly, I only encountered this when playing with a : non-readonly undef ;) (This is something I can recommend to anyone: : redefining true, false and undef leads to very spectacular code, where : anything's possible, and defined(undef) can be a true that stringifies : as false.) Perl 6 culture might feebly try to discourage the redefinition of truth. Hmm, and here I was thinking that the culture was rapidly evolving towards There Is More Than One Way To Define It. :-) Pm
Re: alarm() and later()
On Wed, Apr 20, 2005 at 09:29:17PM +0300, Gaal Yahas wrote: : (FWIW, this is called signalProcess in Haskell.) Also in the FWIW department, I mislike mixed-case identifiers for anything in the core. That sort of things screams user-defined to me. To a lesser extent, I also tend to avoid underscores in the core unless I'm trying to be obnoxious: DONT_EVER_USE_THIS_FEATURE(1). : We also want repeat events; I can think of two ways to do it. Either : require everything to be explicit with adverbs, or have the closure's : return value determine whether to keep calling back or to quit. GLib : does the latter, and there's a cleanliness in how the closure itself can : control when to stop, but the former means you can schedule arbitrary : code without changing it. I think the conceptual default for callbacks should be single call, with the return value reserved for returning actual data to whatever context calls it. It's easy enough to have a special call that says something like call_me_again(). Er, callmeagain()... :-) You also have the ability to schedule repeated calls externally to the closure, presumably. In general, I think that's even cleaner than usurping the return value. I'm presuming we also give the closure some way to get at its scheduler handle so it can remove itself from repeats, or otherwise give it some kind of dont_call_me_again(). Er... All that being said, it doesn't actually make a lot of sense to return user data to the scheduler. Unless, that is, the scheduler is also managing some kind of pipeline and will feed that return value to some other code. But then, timed generators are nice for lots of simulation applications. (But then you start getting into discrete event simulations where you want to simulate the flow of time as well, where delay() isn't really a real delay, but just waits till virtual time gets far enough. Well, that's enough brain strain for now.) Larry
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, Apr 20, 2005 at 02:15:20PM -0500, Patrick R. Michaud wrote: : On Wed, Apr 20, 2005 at 12:00:22PM -0700, Larry Wall wrote: : : Although admittedly, I only encountered this when playing with a : : non-readonly undef ;) (This is something I can recommend to anyone: : : redefining true, false and undef leads to very spectacular code, where : : anything's possible, and defined(undef) can be a true that stringifies : : as false.) : : Perl 6 culture might feebly try to discourage the redefinition of truth. : : Hmm, and here I was thinking that the culture was rapidly evolving : towards There Is More Than One Way To Define It. :-) As long as it's still spelled TMTOWTDI. Or I suppose we could always recontextualize the meaning of is instead. There is prior art... Larry
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, 2005-04-20 at 15:15, Patrick R. Michaud wrote:
On Wed, Apr 20, 2005 at 12:00:22PM -0700, Larry Wall wrote:
Perl 6 culture might feebly try to discourage the redefinition of truth.
Hmm, and here I was thinking that the culture was rapidly evolving
towards There Is More Than One Way To Define It. :-)
I would suggest that it's been more of,
perl -nle 'push @{$x{uc substr($_,0,1)}}, $_;END{p(TMTOWTDI,\%x)}sub p {my
$a=shift;my $h=shift; my $w=shift;$w=[] unless $w;my $letter =
substr($a,0,1);$a=substr($a,1);foreach my $word (@{$h-{$letter}}){ if ($a)
{p($a,$h,[EMAIL PROTECTED],$word])} else {print join , @$w, $word} }}'
/usr/share/dict/words
But, what do I know? ;-)
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: How do I... tie hashes/arrays?
On Wed, Apr 20, 2005 at 08:39:02AM +0200, Leopold Toetsch wrote:
: Larry Wall [EMAIL PROTECTED] wrote:
: On Tue, Apr 19, 2005 at 02:02:41PM +, Ingo Blechschmidt wrote:
:
: : # Possibility #2
: : multi sub *postcircumfix:'[', ']'(TiedArray $self, $index) {
: : # Body as above
: : }
:
: None of those are quite right, because you have to be prepared to deal
: not only with slices, but with multiple dimensions of slices.
:
: Then again the question arises, if all the possible indexed access isn't
: clearer written as multi subs:
:
: multi sub *postcircumfix:[ ](TiedArray $self, int $index) {...}
: multi sub *postcircumfix:[ ](TiedArray $self, Int $index) {...}
: multi sub *postcircumfix:[ ](TiedArray $self, Slice $index) {...}
: multi sub *postcircumfix:[ ](TiedArray $self, MyDims $index) {...}
:
: or with FETCH and STORE as distinct variants too, and r/w ...
Depends on whether the user is actually expecting equal MMD there,
or tie-breaking between multi methods within the particular class.
My gut-level feeling is that they expect the latter.
: ... However, that being
: said, there's enough flexibility in the FETCH/STORE proxy that you
: could defactor the identification code out to the various handlers
: and get the same benefit.
:
: Well, isn't the defactorized code just a bunch of multi subs?
I don't think of it that way. Considering the code is bound to a
particular proxy object before it is ever called, it seems to fall
even more into the category of multi method rather than multi sub.
This is one of the big flying leaps that Perl 6 is trying to take.
We've had lots of MMD implementations in the world, but Perl 6 is
attempting to make that orthogonal to all the other scoping mechanisms,
including lexical scopes and class scopes. If there's prior art,
I'm not aware of it. I suppose the non-brain-burning view of it is
that any extra lexical or class scope dimension just turns into an
extra absolute constraint on which subset of the global subs of that
short name can be called.
Larry
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, Apr 20, 2005 at 03:35:13PM -0400, Aaron Sherman wrote:
: On Wed, 2005-04-20 at 15:15, Patrick R. Michaud wrote:
: On Wed, Apr 20, 2005 at 12:00:22PM -0700, Larry Wall wrote:
:
: Perl 6 culture might feebly try to discourage the redefinition of truth.
:
: Hmm, and here I was thinking that the culture was rapidly evolving
: towards There Is More Than One Way To Define It. :-)
:
: I would suggest that it's been more of,
:
: perl -nle 'push @{$x{uc substr($_,0,1)}}, $_;END{p(TMTOWTDI,\%x)}sub p {my
$a=shift;my $h=shift; my $w=shift;$w=[] unless $w;my $letter =
substr($a,0,1);$a=substr($a,1);foreach my $word (@{$h-{$letter}}){ if ($a)
{p($a,$h,[EMAIL PROTECTED],$word])} else {print join , @$w, $word} }}'
/usr/share/dict/words
:
: But, what do I know? ;-)
Dude, nowadays we're trying to make Perl 6 more Unicode aware, not
less; /usr/share/dict/words is so, like, monocultural, and stuff.
Larry
Re: Closure/block/sub multiplier /// Win32 module for Perl6
Larry Wall skribis 2005-04-20 11:54 (-0700):
goto(join , L, { rand 10 } XX rand 10);
By the way -- Does this mean the XX operator is official now?
And what about X? It'd let you write the same thing without the join:
goto(L ~ { rand 10 } X rand 10)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
$?OS globals, etc.
Hi,
I've not been keeping very up to date in recent times of how this stuff
is working. I've been noticing the use of these variables within pugs
and have a slight suggestion.
Currently there is rather limited abstraction with these items (as far
as I am aware) and while they are usable and comparatively similar to
the perl5 ways of doing things, I see a benefit in changing how these
work. I would like to suggest changing the $?OS, etc variables to being
attributes of a class which always have a singleton object within the
outer-most scope of a process. ie:
class GLOBAL {
has $.PID;
has $.OS;
has $.UID;
... # etc
}
I believe though, that keeping things the way people expect is also
important, so keeping $?OS, etc. about is still important. To accomodate
this I suggest exporting these variables from the GLOBAL class as Proxy
objects which in turn use the accessors on the GLOBAL singleton object.
Why would this be useful? Why should anyone care? Well, a real world
example would be if I wished to find out through a large codebase to
locate all the areas within the codebase that are calling $?OS. To do
this, I would simply override the $.OS accessor in the GLOBAL class to
provide logging.
Although I'm not entirely sure how this would fit into the usage of
compile-time vs. run-time, I would believe that this abstracted approach
would be beneficial wherever it was used. Hopefully that made sense
thanks,
--
-Scott McWhirter- | -kungfuftr-
Quick question: parens vs subroutine parameter
So, following up on the Parens handling, are these two equivalent? # Assuming is has the parameter signature (Str, Str, Str) is((1,2), (3,4), hey); is([1,2], [3,4], hey); What happens if is is of type (Any, Any, Str)? Thanks, /Autrijus/ pgp0OW38SoE0X.pgp Description: PGP signature
Re: Quick question: parens vs subroutine parameter
Autrijus Tang skribis 2005-04-21 4:19 (+0800): So, following up on the Parens handling, are these two equivalent? # Assuming is has the parameter signature (Str, Str, Str) is((1,2), (3,4), hey); is([1,2], [3,4], hey); I think so. What happens if is is of type (Any, Any, Str)? Same thing, as the inner comma is still in scalar context. However, with list context, I expect things to flatten, so with a signature of [EMAIL PROTECTED], it puts 5 elements in @_. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, Apr 20, 2005 at 09:45:08PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-20 11:54 (-0700):
: goto(join , L, { rand 10 } XX rand 10);
:
: By the way -- Does this mean the XX operator is official now?
No. I just threw that in to see if anyone was awake.
: And what about X? It'd let you write the same thing without the join:
:
: goto(L ~ { rand 10 } X rand 10)
But that doesn't mean I've ruled it out yet either. But it seems
like there should be a way to get the same effect with x and xx with
some option or context sensetivity. I just haven't thought about
enough yet.
Larry
Re: Quick question: parens vs subroutine parameter
On Wed, Apr 20, 2005 at 10:23:14PM +0200, Juerd wrote: : Autrijus Tang skribis 2005-04-21 4:19 (+0800): : So, following up on the Parens handling, are these two equivalent? : # Assuming is has the parameter signature (Str, Str, Str) : is((1,2), (3,4), hey); : is([1,2], [3,4], hey); : : I think so. : : What happens if is is of type (Any, Any, Str)? : : Same thing, as the inner comma is still in scalar context. : : However, with list context, I expect things to flatten, so with a : signature of [EMAIL PROTECTED], it puts 5 elements in @_. That's all correct. Larry
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, 20 Apr 2005 13:00:01 -0400, Matt [EMAIL PROTECTED] wrote: 2. Is anyone working on making a Win32 module for Perl6 yet, or porting over the p5 one? If not, I may be willing to make one, along with some help from friends. If I do, does anyone have any pointers or suggestions for me when I begin the adventure? Specifically, how it should be organized, among other things. To expand on this... How will you be able to access shared libraries with native code, such as DLLs on windows? Is there a way to do this proposed for Perl6 yet? If so, is it possible in PUGS? Thanks.
Re: $?OS globals, etc.
On Wed, Apr 20, 2005 at 08:45:02PM +0100, Scott McWhirter wrote:
: Hi,
:
: I've not been keeping very up to date in recent times of how this stuff
: is working. I've been noticing the use of these variables within pugs
: and have a slight suggestion.
:
: Currently there is rather limited abstraction with these items (as far
: as I am aware) and while they are usable and comparatively similar to
: the perl5 ways of doing things, I see a benefit in changing how these
: work.
There has been some discussion of this in the past. Certainly the
mechanisms are there do whatever aliasing/wrapping/delegation needs doing.
: I would like to suggest changing the $?OS, etc variables to being
: attributes of a class which always have a singleton object within the
: outer-most scope of a process. ie:
:
: class GLOBAL {
:has $.PID;
:has $.OS;
:has $.UID;
:... # etc
: }
:
: I believe though, that keeping things the way people expect is also
: important, so keeping $?OS, etc. about is still important. To accomodate
: this I suggest exporting these variables from the GLOBAL class as Proxy
: objects which in turn use the accessors on the GLOBAL singleton object.
Well, there are several global namespaces already, so you'll have to
differentiate more than that. We already distinguish $?FOO (compile-time
global) from ?*FOO (run-time global), plus $=FOO is the pod namespace.
There may be others, and that doesn't count splitting things out by
things that are global to the thread/process/OStype/OSinstance/whatever.
Lumping these into one GLOBAL object is to make most of the same mistake
under a different name.
: Why would this be useful? Why should anyone care? Well, a real world
: example would be if I wished to find out through a large codebase to
: locate all the areas within the codebase that are calling $?OS. To do
: this, I would simply override the $.OS accessor in the GLOBAL class to
: provide logging.
:
: Although I'm not entirely sure how this would fit into the usage of
: compile-time vs. run-time, I would believe that this abstracted approach
: would be beneficial wherever it was used. Hopefully that made sense
It's a good idea. We just haven't finished designing that part of it.
Anyone who wants to help with that part of the design is welcome to
participate--it's not the crown jewels, and as you say the important
ones end up getting aliased into global namespace anyway. We're taking
the same approach with redesigning the function call space (aka S29).
Larry
Re: Closure/block/sub multiplier /// Win32 module for Perl6
On Wed, Apr 20, 2005 at 04:50:38PM -0400, Matt Creenan wrote: : To expand on this... : : How will you be able to access shared libraries with native code, such as : DLLs on windows? Is there a way to do this proposed for Perl6 yet? Already implemented in Parrot under the name NCI. : If so, is it possible in PUGS? Anything is *possible* in PUGS. :-) Larry
Re: $?OS globals, etc.
On Wed, Apr 20, 2005 at 08:45:02PM +0100, Scott McWhirter wrote: : Why would this be useful? Why should anyone care? Well, a real world : example would be if I wished to find out through a large codebase to : locate all the areas within the codebase that are calling $?OS. To do : this, I would simply override the $.OS accessor in the GLOBAL class to : provide logging. Oh, I was also going to point out that a simple .wrap is probably what you want there, rather than screwing around with overrides that depend on clobbering the class or on type changes getting propagated to existing variables. Of course, a .wrap could be construed as clobbering the class, but if you don't want to change the underlying functionality, it's a lot cleaner than replacing the method in question. Larry
[PATCH] Re: apo/A06.pod: spelling error(s)?
On 20 Apr, Luke Palmer wrote:
: Steven Philip Schubiger writes:
: In
: macro circumfix:(*...*) () is parsed(/.*?/ { }
:
: is the second enclosing part of the parsed parentheses omitted
: by intention? If not, I'd volunteer to provide a patch.
:
: Fixed. Thanks.
:
: Luke
You missed some.
Steven
--- perl6/doc/trunk/design/apo/A06.pod Wed Apr 20 20:03:19 2005
+++ perl6/doc/trunk/design/apo/A06.pod Wed Apr 20 20:05:32 2005
@@ -3004,12 +3004,12 @@
interpolated with a special C ... marker, which is considered part
of the name:
-macro circumfix:(*...*) () is parsed(/.*?/ { }
+macro circumfix:(*...*) () is parsed(/.*?/) { }
[Update: That's now solved by use of existing slice syntax:
-macro circumfix:(* *) () is parsed(/.*?/ { }
-macro circumfix:{'(*', '*)'} () is parsed(/.*?/ { }
+macro circumfix:(* *) () is parsed(/.*?/) { }
+macro circumfix:{'(*', '*)'} () is parsed(/.*?/) { }
That's so convenient that we'll discard the special rule about
splitting symmetrically in favor of requiring a two element slice.]
Inline code (was: Closure/block/sub multiplier)
On Wed, Apr 20, 2005 at 04:50:38PM -0400, Matt Creenan wrote:
To expand on this...
How will you be able to access shared libraries with native code, such as
DLLs on windows? Is there a way to do this proposed for Perl6 yet? If
so, is it possible in PUGS?
It is possible in Pugs's Haskell backend by using the experimental,
unspecced (and will probably be changed) eval_haskell() primitive
to natively call Win32 DLLs.
Alternatively, you can write modules using the experimental,
unspecced (and will probably be changed) syntax:
module SHA1-0.0.1;
inline Haskell = '
import qualified SHA1
sha1 :: String - String
sha1 = SHA1.sha1
';
Inline::C support is also trivial, by translating the C signatures
into Haskell FFI calls, and adding them to Pugs.External.C.
In Pugs's IMC backend, I expect the same syntax to still hold; I have
started investigating interop with Parrot/Tcl, and it does seem
feasible.
Bringing the topic back to perl6-language, I'd like to inquire
how eval and inlining other languages works. Here's some thoughts:
eval('printf(Hello!)', :languageC);
eval(:C('printf(Hello!)'));
inline C = '...';
inline C = =foo.c;
If there is some consensus on this, I'd like to change Pugs's
existing `eval_perl5()` and `inline` syntax to agree with it.
Thanks,
/Autrijus/
pgpcJeRR2TD26.pgp
Description: PGP signature
Re: Inline code (was: Closure/block/sub multiplier)
On Thu, Apr 21, 2005 at 05:31:05AM +0800, Autrijus Tang wrote:
: Bringing the topic back to perl6-language, I'd like to inquire
: how eval and inlining other languages works. Here's some thoughts:
:
: eval('printf(Hello!)', :languageC);
: eval(:C('printf(Hello!)'));
:
: inline C = '...';
: inline C = =foo.c;
:
: If there is some consensus on this, I'd like to change Pugs's
: existing `eval_perl5()` and `inline` syntax to agree with it.
I think eval($str) is just syntactic sugar for
$?MYGRAMMAR.top($str).compile.run
or some such. We could just leave eval meaning that, and let people
define their own shortcuts for other languages. If someone is going
to do one eval in a different language, they're often going to
a lot of them, so a syntax like:
eval('printf(Hello!)', :languageC);
is going to be too heavyweight for that anyway, and people will write
sub eval_C ($proggie) { CGrammar.top($proggie).compile.link.run.dump.gdb }
or whatever. :-)
The other part we might want to replace is the .top, since .top is
probably going to create a new lexical scope, whereas .statement or
some such will presumably execute the new statement in the current
scope, so we have some way of writing an interactive eval loop that
doesn't throw away declarations.
Larry
Re: Inline code (was: Closure/block/sub multiplier)
Autrijus Tang skribis 2005-04-21 5:31 (+0800):
Bringing the topic back to perl6-language, I'd like to inquire
how eval and inlining other languages works. Here's some thoughts:
eval('printf(Hello!)', :languageC);
Is that comma needed?
eval(:C('printf(Hello!)'));
Strange use of a pair - feels to me like you can provide alternatives:
eval(
C= 'printf(Hello!)',
Ruby = 'print Hello!',
sh = 'echo Hello\!'
);
inline C = '...';
inline C = =foo.c;
Syntactic sugar that was nice for Perl 5, but is probably better to be
left alone.
eval(Str $code, +$lang) has my preference, syntax-wise, but that can
perhaps only work with Parroty languages, of which I think C isn't
one.
Sometimes you want to add a word in between terms for documentation. For
this reason, I've always wanted the arguments for index to be the other
way around, so I could think index $needle, (in) $haystack.
It'd be fun to have a different spelling for comma (here I assume that
leading comma is ignored and that because of the special new leading
keyword, non-slurpy can come after slurpy), for example:
multi eval ($code, using ?$lang) { eval($code, :lang($lang)) }
eval 'printf(Hello!)' using C;
multi index (of $needle, in $haystack, +$offset) { index(...) }
my $pos = index of , in Hello, world!;
multi join ([EMAIL PROTECTED], on $separator) { ... }
my $joined = join @fields on :;
The same thing can almost be done with pairs, but these words don't make
good identifier names.
Can something like this be done without resorting to macros with hard to
construct regexes?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Quick question: parens vs subroutine parameter
Autrijus asked me to summarize here what I said on IRC #perl6, and ask Larry for another that's all correct. I've rephrased everything as facts/assumptions. Array context, as provided by a signature of Array $foo, is still a form of scalar context, even though Array.isa(List). Array is a class here. Classes when used for context expect objects. Objects are references. Array implies ref. The main contexts, void, scalar and list, have nothing to do with types. Scalar context can expect a certain type of value, for example, an Array or a Dog. List context can also expect a certain type of values for its elements. Somewhere during our conversation, I suggested renaming scalar and list context to singular and plural context, to avoid all the confusion. Void context still exists and is not a form of singular or plural context. Perhaps this should be called nullar context, although void context works equally well for me and is not confusing because we have no Void type. When we really want a scalar (the thing itself), we call that Any context or Scalar context, both forms of singular context (formerly called scalar context). What exactly is the difference between Scalar and Any? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: alarm() and later()
GY == Gaal Yahas [EMAIL PROTECTED] writes:
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.cue(:delay($secs));
}
Though I suppose people really mostly just want something like
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.delay($secs);
}
The actual verb/adverb names are negotiable, but they need to handle
relative vs absolute times intuitively. Different words have different
connotations in that regard. delay is definitely relative, while
after tends toward absolute, though can be used relatively too.
at is definitely absolute time, but maybe too overloaded with
positional meanings. later is unfortunately completely ambiguous.
GY We also want repeat events; I can think of two ways to do it. Either
GY require everything to be explicit with adverbs, or have the closure's
GY return value determine whether to keep calling back or to quit. GLib
GY does the latter, and there's a cleanliness in how the closure itself can
GY control when to stop, but the former means you can schedule arbitrary
GY code without changing it.
GY Is there anybody from the perl-loop gang around here? I'm sure they've
GY thought about these things a lot.
i do a fair amount of event loop stuff in perl and have worked on
various apis for it. i have a few rfc's which try to tie in timers and
signals and async io with perl6's i/o functions (none of which are
defined yet).
the good news is that parrot will be providing a clean core event loop
mechanism using native kernel threads and event queues.
what a proper event loop program needs is an event loop run core or
module. it would block on reading the event queue and dispatch events
(via callbacks) as they get read in.
also you need to let go of flow control to an event loop. otherwise you
will be running 100% cpu until you block hard and the event loop can't
run again. the problem is that if you use callbacks and no threads, you
must have an event loop take over. parrot will not offer this directly
but it will be easy to create one on top of the event queue it
provides.
most uses of simple alarms now are sleep timers and breaking out of
blocking calls with die. anything more complex (even 2 timers at one
time) need a proper event loop and proper control over creating and
handling them.
signal handling can be a subset of the event loop (which is good, as
that means they can get delivered synchronously and not be a worry like
they used to be in p5 without event loops).
so the biggest difference with larry's api is that you need to specify a
callback (method or code ref or either?) in the call that sets up a
timer. and you need several options so it should be a key/value api with
good defaults. here are some of the useful options (see Event.pm for
where this is mostly from).
the problem with signal alarm is that it doesn't have any way to handle
the extra options without major pain.
callbackcode ref, closure, method (and object in diff
arg) or Signal::ALARM.
this could have a default like ::timer_handler
delay MINIMUM delay before timer gets triggered
at absolute time. converted internally to delay
intervalrepeat interval. if this is set and delay isn't,
the first delay will be this interval. this gets
you a simple repeating trigger.
hardthis is useful boolean but can be tricky to explain. a
hard timer doesn't count the time used in the
callback. its intervals are hard (i.e. always 5
seconds). a soft timer counts the interval from
when the callback returns. so it is 5 seconds
plus callback time as the interval.
object callback to this object (forces the callback to
be method name).
Event.pm has a single callback arg, either a sub name or code ref or a
anon array with a method and object.
so the api could be as simple as this (p5ish style):
sub timer_handler {
say 'my time has come!'
}
set_timer_handler( interval = 5.0 ) ;
main_event_loop() ;
note the use of the default callback sub name.
a more complex one:
method timer_method {
say 'my time has come!'
}
set_timer_handler( callback = timer_method, object = $obj, interval = 5.0 ) ;
main_event_loop() ;
also the set_timer func returns a handle to manage the timer. then you
can reset it (reset the timer to 0 for this interval. useful for i/o
activity monitoring), disable/enable it and shut it down. so i would say
the returned thing should be an event object with those (and other)
methods. this implies a core Event class to handle this common stuff.
and integrating with other event loops (GUI ones in particular) is
handled by creating Event::EventLoopofChoice wrapper
Re: Quick question: parens vs subroutine parameter
On Wed, Apr 20, 2005 at 11:28:23PM +0200, Juerd wrote: : Autrijus asked me to summarize here what I said on IRC #perl6, and ask : Larry for another that's all correct. : : I've rephrased everything as facts/assumptions. : : Array context, as provided by a signature of Array $foo, is still : a form of scalar context, even though Array.isa(List). I don't think Array.isa(List). I think List.isa(Array of Generator), and Array.maybehasa(List) stored under it's .specs property for generating more values of the Array if you run off the end of the existing elements. : Array is a class here. Yes. : Classes when used for context expect objects. If by context you mean variable declaration, then yes. : Objects are references. Objects are blessed referents, just as in Perl 5. It's just that most such referents are an opaque type now. I think what you're trying to say here is that Real Objects are never value types, which is true. Objects are always accessed through references, as in Perl 5. : Array implies ref. Yes, though people don't have to realize that when they say @foo[$bar]. : The main contexts, void, scalar and list, have nothing to do with : types. That's a slight overstatement, but mostly true. : Scalar context can expect a certain type of value, for example, an : Array or a Dog. Yes. : List context can also expect a certain type of values for its : elements. Right. : Somewhere during our conversation, I suggested renaming scalar and list : context to singular and plural context, to avoid all the confusion. I often talk about them in those terms, but I'd hate to have to type singular instead of scalar or plural instead of list all the time. : Void context still exists and is not a form of singular or plural : context. Perhaps this should be called nullar context, although void : context works equally well for me and is not confusing because we have : no Void type. So let's get just rid of Scalar and List types. : When we really want a scalar (the thing itself), we call that Any : context or Scalar context, both forms of singular context (formerly : called scalar context). : : What exactly is the difference between Scalar and Any? Isn't any, that I can tell. So maybe we settle on Any for the type and scalar() for the function/concept. It'd be nice if we could unify those somehow, but any() is taken. Maybe Item/item(). Likewise, there's really no such thing as a List. The basic list types are actually Eager and Lazy, and an Array conveniently contains one of each. Larry
Re: [PATCH] Re: apo/A06.pod: spelling error(s)?
On Wed, Apr 20, 2005 at 08:13:20PM +0200, Steven Philip Schubiger wrote:
On 20 Apr, Luke Palmer wrote:
: Steven Philip Schubiger writes:
: In
: macro circumfix:(*...*) () is parsed(/.*?/ { }
:
: is the second enclosing part of the parsed parentheses omitted
: by intention? If not, I'd volunteer to provide a patch.
:
: Fixed. Thanks.
:
: Luke
You missed some.
Fixed some. Thanks!
Pm
Re: Inline code (was: Closure/block/sub multiplier)
Juerd writes:
It'd be fun to have a different spelling for comma (here I assume that
leading comma is ignored and that because of the special new leading
keyword, non-slurpy can come after slurpy), for example:
multi eval ($code, using ?$lang) { eval($code, :lang($lang)) }
eval 'printf(Hello!)' using C;
multi index (of $needle, in $haystack, +$offset) { index(...) }
my $pos = index of , in Hello, world!;
multi join ([EMAIL PROTECTED], on $separator) { ... }
my $joined = join @fields on :;
The same thing can almost be done with pairs, but these words don't make
good identifier names.
I believe this was an RFC at some point. And this probably can't be
done without hard-to-construct regexes, but we'll leave that
construction to the module author so it only need be done once. I don't
actually expect that it would be *that* hard to do.
Luke
