Re: OT: "my wiki syntax is better than yours"

[Fagyal Csongor]

Hi,

I have never understand this "my wiki syntax is better than yours" 
thing. It's like "my templateing engine is better than yours".


I feel like which should have "wiki.conf" with :

...
syntaxhandler = SuperbPerl6Wiki::Syntax::MediaKwikiMikiBiky
...

That shall please everyone. :)

- Fagzal

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

[Thomas Wittek]

Udo Güngerich schrieb:
> Thomas Wittek wrote:
>> 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!
> [..]
> 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).

Of course. But I guess that the architecture/design for such a flexible
piece of software will be relatively complex. I think that creating this
architecture might even take too long to get a running wiki quickly.
Where "quickly" of course is a term still to be defined ;)

-Thomas

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

[Thomas Wittek]

Juerd schrieb:
> * 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.

I suppose doing it the Perl-way: Stealing the best of each syntax,
adding what's missing.

I don't think that we have to choose an existing syntax, but can create
one that combines the best features of the existing ones.

Of course, this would be more work. Probably it will not be easy to get
a common agreement of what's "best". Additionally the mixed up syntax
shouldn't look too inconsistent - but that won't be too hard I think.
Also some restrictions have to be considered. E.g. if we want to allow
"block oriented" parsing (nested blocks in other blocks), the syntax
must be unambiguous on how to detect blocks (within other blocks).

That's mainly what I did as stated in my first post[1]. Look at several
wiki-syntaxes and combine, what _I_ think is the syntax suited best for
a wiki.

And I think that such a (then collaborative) process might be a good
idea for the definition of the syntax of this wiki.

-Thomas

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

[Thomas Wittek]

Damn, forgot the link.

Thomas Wittek schrieb:
> That's mainly what I did as stated in my first post[1]. [...]

[1]:
news://nntp.perl.org:119/[EMAIL PROTECTED]

OT: wiki engine architecture (was: $1,000 prize for Perl 6 Wiki written in Perl 6)

[A. Pagaltzis]

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