Re: How to push a hash on an array without flattening it to Pairs?
* Elizabeth Mattijsen <l...@dijkmat.nl> [2015-09-26 13:20]:
> The flattening will not be done if more than one argument is specified:
>
> $ 6 'my %h = a => 42, b => 666; my @a = %h,%h; dd @a'
> Array @a = [{:a(42), :b(666)}, {:a(42), :b(666)}]
>
>
> This is the same behaviour as with for:
>
> $ 6 'my %h = a => 42, b => 666; dd $_ for %h'
> :a(42)
> :b(666)
>
> $ 6 'my %h = a => 42, b => 666; dd $_ for %h,%h'
> Hash %h = {:a(42), :b(666)}
> Hash %h = {:a(42), :b(666)}
>
>
> It’s the same rule throughout :-)
Yes, but adding a trailing comma to convert a lone item to an element in
a one-element list, causing the flattening to apply to the list instead
of the item, thus avoiding the flattening of that item as a side effect
of sorts… is just way too meta for my taste, at least for everyday parts
of the language.
> There is: you just need to itemize the hash, e.g. by prefixing it with $
>
> $ 6 'my %h = a => 42, b => 666; my @a = $%h; dd @a'
> Array @a = [{:a(42), :b(666)},]
>
> This is the one argument rule at work.
Aha! Much better. Explicit. “Don’t subject %h to flattening.”
No need to combine two other unrelated rules to bend around invoking the
undesired rule; just directly saying not to invoke it.
Now of course I must ask – is there an opposite also? I.e. when writing
a list, is there a way I can say “do flatten this item?” Or put in other
words, what goes in place of XXX in the following to make it real?
$ 6 'my %h = a => 42, b => 666; dd $_ for %h,XXX'
Hash %h = {:a(42), :b(666)}
:a(42)
:b(666)
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: How to push a hash on an array without flattening it to Pairs?
* Moritz Lenz <mor...@faui2k3.org> [2015-09-26 09:40]:
> A trailing comma helps:
>
> my %h = a => 1, b => 2;
> my @a = %h, ;
> say @a.perl;# [{:a(1), :b(2)},]
I think I understand why, but wow, that’s not reasonable. Is there
really no better way to avoid the flattening? Even Perl 5 is nicer
in that situation…
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]
* Parrot Raiser 1parr...@gmail.com [2014-12-07 22:40]: The practical distinction, surely, is that the output of a compiler is usually kept around, to be run one or more times, whereas the an interpreter always works with the original human-readable source. Yes, surely that’s it. We all consider Python a compiler, after all. :-) Go on, tweak your definition to pin it down. :-) * Gerard ONeill oobl...@usa.net [2014-12-08 15:10]: How about an interpreter interprets input directly into action (even if there is some optimization going on), while a compiler converts instructions from one set to another set to be interpreted later. That’s just an unnecessarily concrete rephrasing of the definitions I mentioned. Which would make perl both at the perl source level, Perl never interprets raw perl code without first parsing it into an optree. and an interpreter at the bytecode level. Well yeah, bytecode always implies an interpreter. Thinking of execution as interpretation, this allows for the transmeta concept, where the CPU was just an interpreter / just in time compiler that interpreted x86 instructions. Although modern CISC CPU's have a step where the input to the chip was still converted to microcode which was actually what was run. So a compilation step, and an interpreting step. Execution takes a program as input and produces the program’s output as output. So it’s interpretation. By definition. Sometimes there are dedicated hard-wired circuits that do it, and sometimes there are other layers of abstraction around the hard-wired circuitry. The layers can be in hardware, and even then at different degrees of abstraction (FPGA vs microcode, say), or in software, and really what is software and what is hardware depends merely on your perspective. There are plenty of coprocessors that internally run code which is opaque from the outside; is that software or hardware? That’s what I meant by fuzzy ideas. You don’t get anywhere trying to nail this pudding to the wall. You only get somewhere if you accept that which is which is relative to your point of view and that the difference is defined in terms of the output: compilers transform programs to other programs and interpreters transform a program into its output. That’s it. E.g. if you have something perl running a Perl program then you have the CPU interpreting a program (perl) that itself interprets another program (the optree), which in turn was compiled from the user Perl program earlier on. Once you stop trying to artificially force everything into a single absolute distinction, the entire debate about which is which vanishes. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]
* Moritz Lenz mor...@faui2k3.org [2014-12-06 20:05]: First of all, the lines between interpreters and compilers a bit blurry. People think of Perl 5 as an interpreter, but actually it compilers to bytecode, which is then run by a runloop. So it has a compiler and an interpreter stage. This is sort of a tangent, but it was a clarifying insight that resolved a point of vagueness for me, so I’d like to just talk about that for a moment if you’ll indulge me. Namely, that line is actually very clear in a theoretical sense, if you judge these types of program by their outputs: Interpreter: A program that receives a program as input and produces the output of that program as output Compiler: A program that receives a program as input and produces another equivalent (in some sense) program as output Now some compilers emit programs that can be run directly by the CPU of the same computer that is running them, without an extra interpreter. This is what people with fuzzy ideas of the terms usually refer to when they speak of a compiler. But the output doesn’t have to be a program of this kind. The blurriness in practice comes from the fact that essentially all programming languages in use by humans are very impractical to use for direct interpretation. And so almost every interpreter ever written is actually coupled to a compiler that first transforms the user source program into some other form which is more convenient to interpret. Even the BASICs on those famous old home computers of the past are combined compiler-interpreters in this sense. Basically just parsing an input program up front as a whole essentially meets the definition of a compiler – even if a rather weak version of it. I think that means shells are typically true interpreters, and that they are more or less the only real examples of such. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Converting a Perl 5 pseudo-continuation to Perl 6
* Aristotle Pagaltzis pagalt...@gmx.de [2009-01-02 23:00]:
That way, you get this combination:
sub pid_file_handler ( $filename ) {
# ... top half ...
yield;
# ... bottom half ...
}
sub init_server {
# ...
my $write_pid = pid_file_handler( $optionspid_file );
become_daemon();
$write_pid();
# ...
}
It turns out that is exactly how generators work in
Javascript 1.7:
https://developer.mozilla.org/en/New_in_JavaScript_1.7
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Converting a Perl 5 pseudo-continuation to Perl 6
* Geoffrey Broadwell ge...@broadwell.org [2009-01-01 21:40]:
In the below Perl 5 code, I refactored to pull the two halves of the PID
file handling out of init_server(), but to do so, I had to return a sub
from pid_file_handler() that acted as a continuation. The syntax is a
bit ugly, though. Is there a cleaner way to this in Perl 6?
##
sub init_server {
my %options = @_;
# ...
# Do top (pre-daemonize) portion of PID file handling.
my $handler = pid_file_handler($options{pid_file});
# Detach from parent session and get to clean state.
become_daemon();
# Do bottom (post-daemonize) portion of PID file handling.
$handler-();
# ...
}
sub pid_file_handler {
# Do top half (pre-daemonize) PID file handling ...
my $filename = shift;
my $basename = lc $BRAND;
my $PID_FILE = $filename || $PID_FILE_DIR/$basename.pid;
my $pid_file = open_pid_file($PID_FILE);
# ... and return a continuation on the bottom half (post-daemonize).
return sub {
$MASTER_PID = $$;
print $pid_file $$;
close $pid_file;
};
}
##
When I asked this question on #perl6, pmurias suggested using
gather/take syntax, but that didn't feel right to me either --
it's contrived in a similar way to using a one-off closure.
Contrived how? I always found implicit continuations distasteful
in the same way that `each` and the boolean flip-flop are bad in
Perl 5: because they tie program state to a location in the code.
When there is state, it should be passed around explicitly. So I
think the return-a-closure solution is actually ideal.
F.ex. it keeps you entirely clear of the troublesome question of
when a subsequent call should restart the sub from the beginning
or resume it – should that happen when identical arguments are
passed? Or when no arguments are passed? Are there any rules
about the proximity of the calls in the code? Or does the
coroutine state effectively become global state (like with `each`
and `pos` in Perl 5)?
When you have an explicit entity representing the continuation,
all of these questions resolve themselves in at once: all calls
to the original routine create a new continuation, and all calls
via the state object are resumptions. There is no ambiguity or
subtlety to think about.
So from the perspective of the caller, I consider the “one-off”
closure ideal: the first call yields an object that can be used
to resume the call.
However, I agree that having to use an extra block inside the
routine and return it explicity is suboptimal. It would be nice
if there was a `yield` keyword that not only threw a resumable
exception, but also closed over the exception object in a
function that, when called, resumes the original function.
That way, you get this combination:
sub pid_file_handler ( $filename ) {
# ... top half ...
yield;
# ... bottom half ...
}
sub init_server {
# ...
my $write_pid = pid_file_handler( $optionspid_file );
become_daemon();
$write_pid();
# ...
}
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Guido’ s library porting considerations
Hi all, this sounds sensible: * http://www.artima.com/weblogs/viewpost.jsp?thread=227041: I implore you (especially if you’re maintaining a library that’s used by others) not to make incompatible changes to your API. If you *have* to make API changes, do them *before* you port to 3.0 – release a version with the new API for Python 2.5, or 2.6 if you must. (Or do it later, *after* you’ve released a port to 3.0 without adding new features.) Why? Think of your users. Suppose Ima Lumberjack has implemented a web 2.0 app for managing his sawmill. Ima is a happy user of your most excellent web 2.0 framework. Now Ima wants to upgrade his app to Py3k. He waits until you have ported your framework to Py3k. He does everything by the books, runs his source code through the 2to3 tool, and starts testing. Imagine his despair when the tests fail: how is he going to tell whether the breakage is due to your API changes or due to his own code not being Py3k-ready? On the other hand, if port your web 2.0 framework to Py3k *without* making API changes, Ima’s task is much more focused: the bugs he is left with after running 2to3 are definitely in his own code, which (presumably :-) he knows how to debug and fix. And the Don’t Break CPAN line: The same recommendation applies even more strongly if your library is a dependency for other libraries – due to the fan-out the pain caused to others multiplies. Sounds quite well reasoned to me. Is this something that makes sense to encourage for 5-to-6 migrations of Perl code as well? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Regexp: s/at($pos)/$str/ should replace or add?
* gabriele renzi [EMAIL PROTECTED] [2007-04-14 22:20]: sorry about the dumb question but I'm not sure I understand the at($pos) assertion. If I write something like my $s=hello s/at(1)/a/ I expected it to give me hallo whereas it give ms haello. Does it mean that basically the assertion is a character/string property instead of the character/string itself? No, it is a zero-width assertion. `at(1)` means the position “between” the 0th and 1th character of the string. Also, what is the correct way to replace the i-th character in a Str ? `substr`. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: xx operator
I have the following code:
class MyStupidString {
method repeatit(Str $string, Int $repeat) {
say $string xx $repeat;
my $add = $string xx $repeat;
say $add;
}
};
my $obj = MyStupidString.new;
$obj.repeatit(---,10);
Interestingly, it says:
pugs test2.p6
--
--- --- --- --- --- --- --- --- --- ---
What am I misunderstanding here?
The `xx` operator. That's list-repeat, not string-repeat.
In Perl 5 terms, the code you wrote is:
sub repeatit {
my ( $string, $repeat ) = @_;
my @res = ( $string ) x $repeat;
print @res;
my $add = @res;
print $add;
}
which should make it obvious what is going on.
--
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
Re: the CGI.pm in Perl 6
* Juerd [EMAIL PROTECTED] [2006-09-20 22:25]:
I think it's time we moved away from the param method, and
started using a hash.
I don’t know about that. The `param` method has the nice property
that it allows you to pretend everything’s a single value or to
use multi-valued params, at your own discretion, at any time,
with no change of syntax.
my $foo = $q-param( 'foo' );
my @bar = $q-param( 'bar' );
If you tried to do this with a hash, you’d get
my $foo = $q-param-{ 'foo' }[0];
# my ( $foo ) = @{ $q-param-{ 'foo' } };
my @bar = @{ $q-param-{ 'bar' } };
You could try making the type of the value depend on arity and be
either a scalar or an arrayref, but then you get V*E*R*Y U*G*L*Y
client code that needs to constantly check whether it’s dealing
with one or the other.
Does Perl 6 offer any help in making access to a HoL look like
the first example? If not, then no, let’s please stick with the
`param` protocol.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: the CGI.pm in Perl 6
* Randal L. Schwartz merlyn@stonehenge.com [2006-09-19 21:25]: The form-generation stuff needs tight coupling with the getting (and setting) of the incoming param values. You couldn't just use two random modules for that... they'd have to specifically know about each other and work together. Err, no. They just need a known protocol, and the semantics of CGI.pm’s `param` method have spread pretty widely and are now used by many other modules as well. In general, you can pass instances from any of these modules to anything that expects something that speaks that protocol and they work just fine. F.ex., you can pass CGI::Simple objects into HTML::Template for variable prepopuluation and it Just Works because they talk to each other using the CGI.pm `param` protocol. Form handling clearly requires no coupling. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: more on perl5 modules
* Richard Hainsworth [EMAIL PROTECTED] [2006-09-18 15:20]: I copied your neat program into a file, called it gtk2test.p6 and got pugs gtk2_test.p6 *** unexpected : expecting term postfix, operator, ; or end of input at gtk2_test.p6 line 2, column 56 Note my translation was purely based on what I picked up, and completely untested. Debug as needed to fix it. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: more on perl5 modules
* Richard Hainsworth [EMAIL PROTECTED] [2006-09-17 18:05]:
The .can workaround doesnt seem to work for more complex
modules.
Err, the .can workaround is a way to get past missing sub
exports. Methods are never exported. Why are you using the
workaround for sub exports on methods.
Here is a working perl5 program that puts up a message with two
buttons.
use strict;
use Gtk2 -init;
use Gtk2::Ex::Dialogs(destroy_with_parent=-1, modal=-1, no_separator = 0);
my $window = Gtk2::Window-new('toplevel');
Gtk2::Ex::Dialogs-set_parent_window( $window );
my $r = Gtk2::Ex::Dialogs::Question-ask( Is Perl only hackers glue?);
if ($r) {print yes\n;} else {print no\n;};
Should be simply:
use perl5:Gtk2 '-init';
use perl5:Gtk2::Ex::Dialogs :destroy_with_parent( -1 ) :modal( -1 )
:!no_separator;
my $window = Gtk2::Window.new( 'toplevel' );
Gtk2::Ex::Dialogs.set_parent_window( $window );
my $r = Gtk2::Ex::Dialogs::Question.ask( Is Perl only hackers glue? );
say $r ?? 'yes' !! 'no';
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: perl6 and a multi-interpreted-language example
* William Herrera [EMAIL PROTECTED] [2006-09-17 21:50]:
perl 5 (9 lines, 353 bytes)
use FreezeThaw qw(cmpStr);
my @a1_9 = (1 .. 9);
my @numbers = sort {rand(10) $a} @a1_9;
for (my $steps = 0; cmpStr([EMAIL PROTECTED], [EMAIL PROTECTED]); ++$steps) {
print join( , @numbers), \nReverse how many? ;
my $flipcount = STDIN;
@numbers[0..$flipcount - 1] = reverse(@numbers[0..($flipcount-1)]);
}
print Done! That took you $steps steps.\n;
To be fair, Perl 5 can be a good deal nicer. 10 lines, 316 bytes,
and much less punctuation:
use List::Util 'shuffle';
my @numbers = shuffle my @goal = ( 1 .. 9 );
my $num_steps;
while ( @numbers ne @goal ) {
print @numbers\nReverse how many? ;
my @slice = 0 .. STDIN - 1;
@numbers[ @slice ] = reverse @numbers[ @slice ];
++$num_steps;
}
print Done! That took you $num_steps steps.\n;
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
* Yuval Kogman [EMAIL PROTECTED] [2006-09-12 12:05]: There are *so* many ways to do session handling that lugging them all into CGI.pm will just make a mess. Agreed, but maybe this is a case where it would make sense to do something like what Perl 6 does for OO vs Perl 5, ie provide one good default set of options that people can use without thinking too much about it when they first get started? F.ex., I could imagine that CGI.pm6 would provide a framework for plugging in session implementations somehow (insert your wisdom from the Catalyst design here f.ex.), and then comes with an easy to set up default session store that would be configured in the course of Perl 6 installation. This way, it would work the way PHP works: when the sysadmin installs it, it is automatically fully set up to provide sessions somehow, and only the people who really need performance or special features need to think harder about it. (Which they can, because the whole thing is still pluggable.) I think we stand to gain a lot from adopting the PHP/Python “batteries included” attitude (cf. Elaine’s Law). (I note that Catalyst is not holding up so well there… although it has made great strides, in all fairness.) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: the CGI.pm in Perl 6
* Trey Harris [EMAIL PROTECTED] [2006-09-10 23:50]: But the HTML methods are used everywhere. And the more novitiate the programmer, the more likely they are to be using them spaghetti-like throughtout their code. If they discover that every time they see a Cstart_form it's going to entail new coding, they're going to rapidly get discouraged about porting to Perl 6. I see that argument. So build a lean, well-designed CGI module, but also offer a CGI5 module that aggregates the CGI stuff along with HTML::Gen and whatnot into a CGI.pm5-compatible API melange for easy porting. No need to drag old mistakes along for all eternity just for the sake of their familiarity. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Stubborn coworkers
* Jeff Stampes [EMAIL PROTECTED] [2006-08-29 17:00]: Since I came to programming after the days of Forth and Lisp being prominent languages, I can't dispute nor concur with her statement. How would you respond? By telling her that the comparison is flawed? Neither Lisp nor Forth have anything you could straight-facedly call a syntax. Perl 6 is a polar opposite. YOU FORTH LOVE IF HONK THEN, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Announcing the Perl 6 and Parrot wiki workspaces
* Juerd [EMAIL PROTECTED] [2006-08-28 16:35]: In other words: it's pretty unusably slow with over 15 seconds, sometimes even 45 seconds per page. I get the same. Andy said it was his home box. Guess his connectivity’s not that great, which makes me wonder why Conrad thought it was a good place to point to. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Announcing the Perl 6 and Parrot wiki workspaces
* Andy Lester [EMAIL PROTECTED] [2006-08-28 21:05]: Try it again. That’s better. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Conditionally included list elements
* Juerd [EMAIL PROTECTED] [2006-06-18 14:10]:
pugs my @foo = 1, 2, 3, { 4 if 0 }.(), 5; say @foo.perl
[1, 2, 3, 5]
bool::true
pugs my @foo = 1, 2, 3, { 4 if 1 }.(), 5; say @foo.perl
[1, 2, 3, 4, 5]
bool::true
That’s “conceptually noisy” though… I don’t know if I’d end up
picking
$foo, $bar, { $baz if $wibble }.(), $quux
over
$foo, $bar, ( $wibble ?? $baz !! () ), $quux
With more complex “movable parts,” there would be even less
difference between the two than here.
Does Perl 6 have `do BLOCK` like Perl 5? That would make it
$foo, $bar, do { $baz if $wibble }, $quux
which I find more acceptable.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Conditionally included list elements
Hi Stuart,
* Stuart Cook [EMAIL PROTECTED] [2006-06-18 15:05]:
On 6/18/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
Is there a construct in Perl 6 to express this more
immediately? Something along the lines of the following would
seem ideal:
$foo, $bar, ( $baz if $wibble ), $quux
How about this:
pugs sub infix:pv($x, $cond) { $cond ?? ($x,) !! () }; say 1, 2, (3 pv
1), 4
1234
bool::true
Good point! I like.
However, what are the evaluation semantics here? Neither the
ternary nor the `if`-based solutions evaluate the expression they
return if the condition turns out to be false. Wouldn’t your
solution evaluate it unconditionally?
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Conditionally included list elements
* Larry Wall [EMAIL PROTECTED] [2006-06-18 19:05]:
On Sun, Jun 18, 2006 at 05:18:52PM +0200, A. Pagaltzis wrote:
: Maybe TheLarry can enlighten us… :-)
We already have the operator you want. It's spelled Cxx?. :-)
Nice. :-) How’s it used? S03 doesn’t list it.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Conditionally included list elements
* Larry Wall [EMAIL PROTECTED] [2006-06-18 19:40]:
On Sun, Jun 18, 2006 at 07:27:57PM +0200, A. Pagaltzis wrote:
* Larry Wall [EMAIL PROTECTED] [2006-06-18 19:05]:
We already have the operator you want. It's spelled Cxx?.
:-)
Nice. :-) How’s it used? S03 doesn’t list it.
Nope. Doesn't list the C**- or C||! operators either. :-)
(Hint: it doesn't matter if you put a space between the Cxx
and the C?.)
Ahh. So you’re telling me that Perl 5 has the same operator, but
it spells it Cx!!. Clever!
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
OT: wiki engine architecture (was: $1,000 prize for Perl 6 Wiki written in Perl 6)
* Thomas Wittek [EMAIL PROTECTED] [2006-06-07 15:05]: I guess that the architecture/design for such a flexible piece of software will be relatively complex. All I can think of is “YAGNI”. Defining a syntax in a configuration file doesn’t strike me as a particularly smart move. You will either end up with a pretty rigid parser that caters to a class of only superficially different syntaxes, in which case diversity equals drawback because you have to cope with documents written in incompatible (though similar) syntaxes for no real gain (because all the syntaxes are similar in expressiveness). Or you will end up writing a parser interpreter whose “configuration” is really a more or less turing complete language. I’ve seen this sort of thing play out all too many times. And I’m pretty sick of little languages by now. (Hey, wasn’t that why Larry began writing Perl in the first place?) Let’s use Perl 6 Grammars to define syntaxes. We are just about to get this mindblowingly awesome tool for parsing; why insist on tieing our feet together and having to hop around like that? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
OT: my wiki syntax is better than yours (was: $1,000 prize for Perl 6 Wiki written in Perl 6)
* Juerd [EMAIL PROTECTED] [2006-06-06 17:50]: side-by-side layouts (extremely useful for showcasing differences between Perl 5 and Perl 6) Good point. * Markdown does not have tables. But it lets you embed verbatim HTML as an escape hatch for constructs that it does not model, and although it will normally not format the content of block-level HTML tags, you can ask it to do so anyway by adding a `markdown=1` attribute to a particular tag. There have also been several long discussions about tables and definition lists on the Markdown mailing list, too (some started by Gruber himself). Table and DL syntax will eventually be added. * Textile does not have paragraphs in table cells. Textile does not support nesting constructs (like code blocks within list items or the like) at all. * Kwiki does not have paragraphs in table cells. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
* Thomas Wittek [EMAIL PROTECTED] [2006-06-03 22:30]: Interestingly it is very similar to Markdown although I never heard about it before :) Hmm, it doesn’t look similar at all to me? Not even superficially similar, but most importantly, it looks line-based. Markdown is block-based. If you want another example of block-based, take a look at the new-style PhpWiki markup. These let you do things like put a code block inside a blockquote within a list item, or heck, even things as simple as multi-paragraph list items. Mediawiki markup, like many other wiki syntaxes, can’t express that. Yours doesn’t look like it can either. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: 3 Good Reasons...
* Michael Mathews [EMAIL PROTECTED] [2006-05-26 12:45]: In the end it was decided to rewrite that chunk in Perl. I can tell you, there definitely was cursing in the office that day, and I doubt anyone there would see it as a plus to have the ability to mix languages more easily. I just wouldn't put it that way if I were trying to sell Perl6 to a business manager. Using libraries from other languages and writing code in multiple languages are very different things. You will not be able to argue with a straight face that being able to do the former is a downside. Currently, “other languages” translates to C, so the utility of this is limited; being able to bridge to more languages would be a great boon. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Simple Print/Say Question
my %buckets = (
w = {
count = 4,
scale = 10.5,
},
x = {
count = 6,
scale = 7,
},
y = {
count = 12,
scale = 3,
},
z = {
count = 18,
scale = 2,
},
);
for %buckets.values - $arg_for {
$arg_forarray = [ ( 0 .. $arg_forcount ) »*« $arg_forscale ];
}
my int @results;
my int $target = 35;
for %bucketswarray.kv - $i, $w {
say To 4: $i;
last if $w $target;
for %bucketsxarray.kv - $j, $x {
say To 6: $j;
last if ($w, $x).sum $target;
for %bucketsyarray.kv - $k, $y {
last if ($w, $x, $y).sum $target;
for %bucketszarray.kv - $l, $z {
if( $target == ($w, $x, $y, $z).sum ) {
@results.push( [$i, $j, $k, $l] );
}
}
}
}
}
for @results.kv - $idx, $result {
say $idx: $result.join(' | ');
}
I assume all those temporaries that I cleaned out were there for
speed, in which case this will run slower, but they were too
unsightly to keep around.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Simple Print/Say Question
Hi Martin,
* Martin Kjeldsen [EMAIL PROTECTED] [2006-05-24 11:50]:
Just curious does this actually run? I'm trying on pugs 6.2.11
and it complains quite a bit. First of all shouldn't
for %buckets.values - $arg_for
be
for %buckets.values - $arg_for is rw
since $arg_for is modified?
No, $arg_for is not modified.
And then I get an error telling me 'No such method in class
Scalar: kv' in the line
for %bucketswarray.kv - $i, $w {
Strange. I did this just by looking at synopses, though, so my
syntax is probably slightly off.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Simple Print/Say Question
* Daniel Hulme [EMAIL PROTECTED] [2006-05-24 12:45]: $arg_forarray = [ ( 0 .. $arg_forcount ) »*« $arg_forscale ]; btw, shouldn't the * be * as the right-hand operand is a scalar? I don’t know. S03 says: | If either argument is insufficiently dimensioned, Perl | upgrades it: | | (3,8,2,9,3,8) - 1; # (2,7,1,8,2,7) So I assume my syntax was correct, though it might not have been necessary. I don’t understand one-sided hyper-operators well yet. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Simple Print/Say Question
* Ovid [EMAIL PROTECTED] [2006-05-24 18:00]:
First off, thanks to Aristotle for clearing some of my
thinking.
NP, it’s a good way for me to pick up the disparate Perl 6 clues
I picked up haphazardly over time, too.
In my version of Pugs (6.2.11 (r10390)), that fails for two
reasons, both of which I suspect are bugs.
These definitely sound like bugs – both of them.
for %bucketswarray.kv - $i, $w {
Is .kv supposed to work there? You're accessing an array, not
a hash.
Yes, `.kv` is supposed to work on arrays, where it returns a list
of `$index = $value` pairs. This is very high on the list of
Perl 6 features I am anticipating eagerly, as it means you can
use natural `for(LIST)` constructs even when you need indices
while iterating, instead of having to use the familiar ugly
construction from Perl 5:
for my $i ( 0 .. $#array ) {
# use both $i and $array[ $i ] here
}
In Perl 6, indexing into [EMAIL PROTECTED] explicitly will *not* be
necessary here. Hooray!
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
