Re: Perl5 -> Perl 6 Translations Design Document

[Aaron Crane]

Sage La Torra writes:
> http://infohost.nmt.edu/~slatorra/conversionstageone.txt

You say this:

  -Hash in interprative context: "%hash" -> "%hash{}" (also @{[...]} ->
   {...})

Hashes don't interpolate in Perl 5, so that's not an issue (unless I'm
misunderstanding what you meant).  But using "{...}" instead of "@{[...]}"
is definitely a good thing.

-- 
Aaron Crane

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Udo Güngerich]

Thomas Wittek wrote:

>> Noone other than Mediawiki uses the Mediawiki syntax. I posit
>> that the reason is that that syntax blows chunks.
> 
> I have to agree. 'bold and italic' is definitely not what I
> understand as an intuitive syntax.
 
Hi everyone, 

I'd like to mention that the mediawiki syntax is mainly borrowed from
UseModWiki, which is written in Perl and quite easy to use. I do drive my
own homepage with it (http://www.udo-guengerich.de - and sorry for all the
nasty German on it ;)) and are quite content with it, apart from some small
minor annoyances. The version I use is a patched one with some patches from
myself, it does:

* not care whether people prefer CamelCase or [[Free Links]], because you
can configure it
* execute  tags
(http://www.udo-guengerich.de/cgi-bin/wiki.pl?Die_Password)
* Include files (containing UseModWiki syntax:
http://www.usemod.com/cgi-bin/wiki.pl?TextFormattingRules) for enhancing
modularity
* InterWiki-Links
* diff stuff and revision control plus rollback

It is far from being perfect, but it implements some interesting ideas.
Still I found it - using it not as wiki but as mini-CMS for my homepage -
being constricting at some points.

> I did some work on designing an easy wiki syntax for a wiki plugin for
> my (yet another...)[1] webdev framework. I looked at the syntax of
> several wikis and tried to create an easy to write (and to parse)
> syntax: http://gedankenkonstrukt.de/konstrukt/syntax.html

So there came another idea to my mind which I thought you might want to
consider for a possible perl6-wiki that might push advocacy?!

Why not doing a wiki system that does NOT have a fix syntax but rather
allows defining its syntax rules in e.g. YAML and thus being entirely
flexible?
It could be distributed with a default set of rules reflecting the
UseMod/MediaWiki/Markdown syntax, but any versatile computer user could
just as easyly define another ruleset, maybe even for just a subset of
pages (e.g. a code related section where you need less common formatting
stuff and more highlighting).

It should have a proper user/groups system as well...

Another idea was formed by the problem of page renaming, typo correction,
etc., etc.

Why not give the wiki a web service API for being easily able to create bots
without being forced to use libcurl or that kind of thing? Then you could
be able to create whole sections on your website that are automatically
updated, following your rules. (And no, I would not use XML for the
webservice API, rather YAML, because it has a much better data/user data
rario)

> This actually has been implemented and works fine. It's not released yet
> and also not intended to be a base for a perl6-wiki. I'm just posting it
> to suggest a possible syntax. Interestingly it is very similar to
> Markdown although I never heard about it before :)
> 
> Regards,
> -Thomas
> 
> [1]: I believe everyone has to build one on its own ;)

I can share this believe ;)

Regards,

Udo
-- 
That which is not good for the bee-hive cannot be good for the bees.

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Steffen Schwigon]

Ask Bjørn Hansen <[EMAIL PROTECTED]> writes:
> Woah, we are getting really far away from talking about perl6
> here...

Kind of a usenet law or corollary? "Every discussion about wikis ends
in a discussion about the best wiki syntax."

Steffen
-- 
Steffen Schwigon <[EMAIL PROTECTED]>
Dresden Perl Mongers 

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Thomas Wittek]

Udo Güngerich schrieb:
> Why not doing a wiki system that does NOT have a fix syntax but rather
> allows defining its syntax rules in e.g. YAML and thus being entirely
> flexible?
> [..]
> It should have a proper user/groups system as well...
> [..]
> Why not give the wiki a web service API [..]

Good ideas. But maybe we should start a bit smaller ;)
It might be a good idea to create a list of features separated in
several increments (releases) to get a running system early.

I could imagine increments like "Parsing/Converting", "Storage
backend/Revision control", "User management", ...

Unfortunately you probably have to throw away/heavily modify earlier
increments, if you add features like a flexible syntax, which will need
a different internal infrastructure.

But targeting such a "feature monster" will probably take too much
development time.

Maybe a "feature complete" version could be targeted as "the"
Perl6-Wiki-Software.
But before this one a "Lite Version", which will be used to have a wiki
quickly available, could be developed.

-Thomas

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Daniel Hulme]

> Ask Bj�rn Hansen <[EMAIL PROTECTED]> writes:
> > Woah, we are getting really far away from talking about perl6
> > here...
> 
> Kind of a usenet law or corollary? "Every discussion about wikis ends

You're being a bit optimistic there, aren't you? The only way you'd end
a my-wiki-is-better-than-yours thread would be to move over to some less
controversial issue, like text editors or the Iraq invasion.

> in a discussion about the best wiki syntax."

-- 
"And I see losing love is like a  window in your heart:  everybody sees 
 you're  blown  apart;  everybody  sees  the  wind  blow  in Graceland."
 -- Paul Simon, 1986 ... I am the Dance Commander, and I order FUN! 
http://surreal.istic.org/ - Installing Windows in your heart since 2003.


pgpzDqG9HxT4B.pgp
Description: PGP signature

Re: namespace bug 2?

[Leopold Toetsch]

Am Dienstag, 18. April 2006 18:19 schrieb Chip Salzenberg:
> > On a side note, is there a way to get at the parent namespace if you have
> > a namespace? I don't see anything in the PDD about it. (Seems you can
> > only walk *down* the hierarchy, not up.)
>
> That's true.  Given aliasing there may not be just one parent, but I don't
> suppose the distant chance of that will keep you from wanting this
> feature...?

NameSpace.parent() is now implemented. I don't see, how we could get multiple 
parents, though.

leo

[perl #39313] [TODO] or [BUG] improve PMC compiler

[via RT]

# New Ticket Created by  Leopold Toetsch 
# Please include the string:  [perl #39313]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=39313 >


It's easy to add 'invalide' code to .pmc files. E.g. I had defined:

METHOD parent() {
return PMC_pmc_val(SELF) ? PMC_pmc_val(SELF) : PMCNULL;
}

Due to the absence of a return value, the PMC compiler just ignores this 
'method' without further notice.

This also is happening, if there's just a whitespace before the '*':

METHOD PMC *parent() {
return PMC_pmc_val(SELF) ? PMC_pmc_val(SELF) : PMCNULL;
}

This totally valid C type declaration is just ignored.

Fixes welcome,
leo

~~ with *

[Daniel Hulme]

I only vaguely recall the discussions a while back about what
smart-matching against Booleans should do. IIRC, there are two
positions, and a good argument for either side:

C<$foo ~~ True> means C; C<$foo ~~ False> means C
or
C<$foo ~~ True> means C; C<$foo ~~ False> means C

The first of these adds expressiveness to given/when, and behaves the
intuitive way when both the RHS of a match is a Boolean-valued variable
(I would intuitively expect C<$bool1 ~~ $bool2> to do Boolean equality).
The second means that the default case of a while can be syntactic sugar
for C, and I see that we went for the latter on those
grounds.

However, if we make the Whatever star on the RHS always match, we can
make C equivalent to C, reminiscently of a shell
script, and we can also make C<$bool1 ~~ $bool2> do the obvious thing.
I don't immediately see any big wins for being able to say C<$foo ~~ *>,
nor any big loses for it no longer falling through to MMD.

Any thoughts?

-- 
"Twelve? Who needs twelve? Couldn't we make do with six?"  -- Lew Grade,
   trying to cut production costs on 'Jesus of Nazareth'
  "The illegal we do immediately,
the unconstitutional takes a little longer."  Henry Kissinger, June 1972


signature.asc
Description: Digital signature

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Matt Todd]

Iraq invasion indeed wait, shouldn't go there.

I particularly like the syntax of Textile or even Markdown (preferring
the former). In Ruby-land, these exist as RedCloth and BlueCloth. I
understand porting isn't fun, but I think that this is a viable
option, if not a great choice.

Not that this is a great example, but Instiki uses the
Textile/RedCloth syntax for textual formatting.

As an aside, I must apologize for interrupting in a conversation that
I've only been privileged to see the last four responses. I'm
extremely interested in learning Perl6 and in particular seeing this
Wiki come to fruition (if not participating myself).

Thought I'd offer up my suggestion about syntax. I'll wait on
participating more until I've read more of what's already been said.

M.T.

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Hezekiah M. Carty]

On Tue, 2006-06-06 at 10:59 -0400, Matt Todd wrote:

> I particularly like the syntax of Textile or even Markdown (preferring
> the former). In Ruby-land, these exist as RedCloth and BlueCloth. I
> understand porting isn't fun, but I think that this is a viable
> option, if not a great choice.


For what it's worth, there is an existing Textile implementation in
Perl5 (Text::Textile on CPAN), and it seems reasonably functional from
my (very) limited time playing with it.  That should at least ease the
initial porting - or the module could be used as-is (hooray for P5 -> P6
interoperability!), and ported over time.

I'd also like to second the Textile suggestion.  Of the "prepackaged"
wiki syntax styles I've seen, it seems to be one of the cleanest while
still being nicely expressive.

Hez

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Juerd]

* Markdown does not have tables.
* Textile does not have paragraphs in table cells.
* Kwiki does not have paragraphs in table cells.

Unless someone comes up with another way to do side-by-side layouts
(extremely useful for showcasing differences between Perl 5 and Perl 6),
all of these formats are not suitable.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

statement-ending } with if

[Daniel Hulme]

Can someone explain to me how } on a line on its own can end a statement
(as described in the second section of S04), but the following still
works?

if $condition
{
  ...
}
else
{
  ...
}

i.e. Why doesn't the } on the fourth line terminate the if statement,
leaving the compiler terminally confused when it sees a bare else? Is
this defined as a special case, and if so, could it be mentioned in S04?
Alternatively, is the else a magic separate statement all of its own?

-- 
And for mile after mile you'll never see me tire/You'll never me me slow
down for a while/'Cause I am the fox, like it or not/I'm always gonna be
there  running over the rock/ Yes I am the fox,  a fascinating cross/ Of
sharp as a whip and tough as an ox  Bernie Taupin, 'The Fox'


signature.asc
Description: Digital signature

OT: "my wiki syntax is better than yours" (was: $1,000 prize for Perl 6 Wiki written in Perl 6)

[A. Pagaltzis]

* 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 // 

Re: namespace bug 2?

[Chip Salzenberg]

On Tue, Jun 06, 2006 at 04:32:27PM +0200, Leopold Toetsch wrote:
> Am Dienstag, 18. April 2006 18:19 schrieb Chip Salzenberg:
> > > On a side note, is there a way to get at the parent namespace if you have
> > > a namespace? I don't see anything in the PDD about it. (Seems you can
> > > only walk *down* the hierarchy, not up.)
> >
> > That's true.  Given aliasing there may not be just one parent, but I don't
> > suppose the distant chance of that will keep you from wanting this
> > feature...?
> 
> NameSpace.parent() is now implemented.

Cool.  I'm afraid it needs to be set_parent() and get_parent(), though, for
when someone wants to transplant a namespace into a (new?) location.

> I don't see, how we could get multiple parents, though.

If a namespace is imported, so that it has multiple names, that implies
there are two parent namespaces from which it can be reached.  But I'm not
interested in fully modeling that situation.  One parent is plenty.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: namespace bug 2?

[Leopold Toetsch]

On Jun 6, 2006, at 20:11, Chip Salzenberg wrote:


NameSpace.parent() is now implemented.


Cool.  I'm afraid it needs to be set_parent() and get_parent(),


It is now get_parent().
leo

Re: OT: "my wiki syntax is better than yours" (was: $1,000 prize for Perl 6 Wiki written in Perl 6)

[Matt Todd]

There are alternatives to using tables for side-by-side using
paragraphs. Simply having one cell for each line, for instance, allows
for highlighting green the added lines and red the removed ones, etc.

Also realize that it is not necessarily the duty of Textile (et al) to
handle that aspect beyond text formatting. A diff or history-revision
view goes beyond the context of the tool.

Lastly, I'm not sure paragraphs belong in table cells. You could
certainly argue that a paragraph could full well be tabular data, but
I find it hard to believe that it fits the bill. (This is speaking on
an XHTML 1.0 Strict basis.)

So, in that regard, I don't believe that this is an issue. The real
reason to use Textile (for instance) is the natural ease of using it
for most things we need.

Just a thought.

M.T.

Re: OT: "my wiki syntax is better than yours" (was: $1,000 prize for Perl 6 Wiki written in Perl 6)

[Daniel Hulme]

> Also realize that it is not necessarily the duty of Textile (et al) to
> handle that aspect beyond text formatting. A diff or history-revision
> view goes beyond the context of the tool.

I don't think Juerd was talking about tables for the purposes of showing
version diffs, but so you can give pairs of examples of equivalent Perl
5 and Perl 6 code side-by-side.

-- 
"I tried snorting coke once, but the bubbles went right up my nose and I
knocked the glass over."   -- 'Sordid Confessions of a Teenage Innocent'
http://surreal.istic.org/It means peace.


pgpICvvt4Ocpz.pgp
Description: PGP signature

Re: OT: "my wiki syntax is better than yours" (was: $1,000 prize for Perl 6 Wiki written in Perl 6)

[Juerd]

Matt Todd skribis 2006-06-06 16:46 (-0400):
> There are alternatives to using tables for side-by-side using
> paragraphs. Simply having one cell for each line, for instance, allows
> for highlighting green the added lines and red the removed ones, etc.

Visually pleasing, but technically incorrect, and practically annoying:
selecting a block of code is no longer possible, let alone testing and
running it automatically.

> Also realize that it is not necessarily the duty of Textile (et al) to
> handle that aspect beyond text formatting. A diff or history-revision
> view goes beyond the context of the tool.

Not my point. A Perl 6 wiki needs to explain how Perl 6 differs from
Perl 5. Not with diff(1) output, obviously.

> So, in that regard, I don't believe that this is an issue.

Pity.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Ben Morrow]

Quoth [EMAIL PROTECTED] (Juerd):
> 
> * Markdown does not have tables.
> * Textile does not have paragraphs in table cells.
> * Kwiki does not have paragraphs in table cells.
> 
> Unless someone comes up with another way to do side-by-side layouts
> (extremely useful for showcasing differences between Perl 5 and Perl 6),
> all of these formats are not suitable.

This may be a stupid suggestion, but would it not be possible to
create some minimal set of extensions to pod which will do what we need?
Preferably something  rst-like?

Ben

-- 
   If you put all the prophets,   |   You'd have so much more reason
   Mystics and saints |   Than ever was born
   In one room together,  |   Out of all of the conflicts of time.
[EMAIL PROTECTED] The Levellers, 'Believers'

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Udo Güngerich]

Thomas Wittek wrote:

> 
> Good ideas. But maybe we should start a bit smaller ;)
> It might be a good idea to create a list of features separated in
> several increments (releases) to get a running system early.

Absolutely.

> I could imagine increments like "Parsing/Converting", "Storage
> backend/Revision control", "User management", ...
> 
> Unfortunately you probably have to throw away/heavily modify earlier
> increments, if you add features like a flexible syntax, which will need
> a different internal infrastructure.

Well, if object-oriented design has any advantage at all, here it is!

If we design this sort of wiki from the very beginning in a way that you can
just "load" a sort of storage backend, user management, rule engine (per
heritage or plugin-wise) you can start off creating the simplest storage, a
nearly nonexistent usermanagement and a very simple rule engine and just
swap when you've got a better one in stock ;)

Only you will have to define the abstract class or plugin bay from the first
minute in the right way (the "only" was softly ironic).

> But targeting such a "feature monster" will probably take too much
> development time.

I agree heavily. I only propose a flexible object-oriented or otherwise
modular design that enables programmers to weld stuff onto it and plug
other stuff into it and after transformation use it from outside as a
module to do something with it that noone has foreseen...

Ok, forget about the last bit, I'll be content with welding and plugging ;)

> Maybe a "feature complete" version could be targeted as "the"
> Perl6-Wiki-Software.
> But before this one a "Lite Version", which will be used to have a wiki
> quickly available, could be developed.
> 
> -Thomas

Maybe, just to get started, we should use as many perl5-modules as we can
and then substitute them one by one (thinking of CGI, YAML, DBI,
HTML::Template, etc., etc.)

Regards,

Udo
-- 
That which is not good for the bee-hive cannot be good for the bees.

OT: "my wiki syntax is better than yours" (was: $1,000 prize for Perl 6 Wiki written in Perl 6)

[A. Pagaltzis]

* Ben Morrow <[EMAIL PROTECTED]> [2006-06-07 01:25]:
> Preferably something  rst-like?

I was wondering why noone had proposed Kwid yet. Doesn’t anyone
like it?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Perl5 -> Perl 6 Translations Design Document

[Sage La Torra]

"interpolative context" ment the perl 5 side, where the double quotes should
cause interpolation. Maybe not the best phrase to identify it, now that you
mention it.

Sage

On 6/6/06, Aaron Crane <[EMAIL PROTECTED]> wrote:


Sage La Torra writes:
> http://infohost.nmt.edu/~slatorra/conversionstageone.txt

You say this:

  -Hash in interprative context: "%hash" -> "%hash{}" (also @{[...]} ->
   {...})

Hashes don't interpolate in Perl 5, so that's not an issue (unless I'm
misunderstanding what you meant).  But using "{...}" instead of "@{[...]}"
is definitely a good thing.

--
Aaron Crane

Inconsistent find_global 'not found' handling

[Bob Rogers]

   If given a namespace key with a single component, and a name that is
not found, e.g.

$P2 = find_global ["Foo"], "bazz"

Parrot says "Global 'bazz' not found", obeying
PARROT_ERRORS_GLOBALS_FLAG (presumably).  On the other hand, if the
namespace name is compound:

$P2 = find_global ["Foo";"Bar"], "bazz"

find_global just returns the null PMC, ignoring
PARROT_ERRORS_GLOBALS_FLAG.  I'm not exactly sure why -- compile-time
constant folding of the key? -- but the attached patch makes the latter
code also throw an error.  If nobody objects in the next day, I will
commit it.

-- Bob Rogers
   http://rgrjr.dyndns.org/

Index: src/ops/experimental.ops
===
--- src/ops/experimental.ops(revision 12894)
+++ src/ops/experimental.ops(working copy)
@@ -276,7 +276,7 @@
 }
 
 op find_global(out PMC, in KEY, in STR) {
-$1 = Parrot_find_global_p(interpreter, $2, $3);
+$1 = Parrot_get_global_p(interpreter, $2, $3);
 goto NEXT();
 }
 
Index: t/pmc/namespace.t
===
--- t/pmc/namespace.t   (revision 12894)
+++ t/pmc/namespace.t   (working copy)
@@ -6,7 +6,7 @@
 use warnings;
 use lib qw( . lib ../lib ../../lib );
 use Test::More;
-use Parrot::Test tests => 29;
+use Parrot::Test tests => 31;
 use Parrot::Config;
 
 =head1 NAME
@@ -155,6 +155,27 @@
 baz
 OUTPUT
 
+pir_output_like(<<'CODE', <<'OUTPUT', "find_global Foo::bazz not found");
+.sub 'main' :main
+$P2 = find_global ["Foo"], "bazz"
+$P2()
+print "ok\n"
+.end
+CODE
+/Global 'bazz' not found/
+OUTPUT
+
+# [this used to behave differently from the previous case.]
+pir_output_like(<<'CODE', <<'OUTPUT', "find_global Foo::Bar::bazz not found");
+.sub 'main' :main
+$P2 = find_global ["Foo";"Bar"], "bazz"
+$P2()
+print "ok\n"
+.end
+CODE
+/Global 'bazz' not found/
+OUTPUT
+
 pir_output_is(<<'CODE', <<'OUTPUT', "find_global Foo::Bar::baz hash");
 .sub 'main' :main
 $P0 = find_global "Foo"

Re: $1,000 prize for Perl 6 Wiki written in Perl 6

[Matt Todd]

I also agree that Object Oriented Design would work wonderfully well
here. The key here is prototyping its shape and then filling in the
details once it has taken this shape.

I like the term 'messages' for methods because it reminds me that the
objects must send requests, forms of communication, to the other
objects. That's always struck me as a great visual help (I'm a visual
learner).

With that in mind, we could full-well begin the structuring of the
project as it pertains to blocks of functionality: a component to
handle visual rendering (whether it include Textile, Markdown,
Wiki-whatever, or all three), data persistence layer (ORM, anybody?),
etc.

I'm sorry if I'm being obnoxiously obvious here, but I like to start
things out simple and I think it would be a good step towards a
product.

For what it's worth,

M.T.

Re: OT: "my wiki syntax is better than yours" (was: $1,000 prize for Perl 6 Wiki written in Perl 6)

[Matt Todd]

Juerd,

My mistake: I misunderstood what you were saying (probably due to haste).

But really, then, there are alternatives to using tables, such as
DIVs, as well as simply modifying the parsing step to also parse for
this special case in addition to Textile or what-have-you.

I guess if I said anything worth-while in my last reply it is that I
think s don't belong in s (and their children).

Sorry for the confusion (on my part).

M.T.