t also will optimize access to finals, despite
> ] the fact that it's actually unsafe to do so.
I'm pleased to note that you made my point for me.
Sure, you can sneak in under the covers of the JVM and compromise the
immutability of its final data. But you do have to sneak in. And wh
"Carl Mäsak" wrote:
> > What is the point of marking things readonly if you can turn it off?
>
> There are many possible reasons, I think.
>
> * The code that declares the variable readonly might not be available
> to you (compiled to bytecode, fetched by RCP etc),
> * or it might be available b
"John M. Dlugosz" wrote:
> Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote:
> > Pm (>):
> >
> > > In Rakudo's case, we just haven't implemented read-only traits
> > > on variables yet.
> >>
> >
> > Goodie. I guessed as much.
> >
> >
> >> But yes, I expect that it will be caught as
> > > a
> A better fitting solution wouldn't focus on classic
> MMD, but simply "Dispatch", where type- and value-based
> dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls
> A better fitting solution wouldn't focus on classic
> MMD, but simply "Dispatch", where type- and value-based
> dispatching are two of many kinds of dispatching supported.
I've always liked the sound of Linda's tuple spaces
and view that as a nice generalized dispatch approach.
Procedure calls
>given baz(@args) { return $_ when defined }
>given baz(@args) { return $_ when $_ > 0 }
Sweet.
Shouldn't the latter example be:
given baz(@args) { return $_ if $_ > 0 }
In general, if a C condition clause contains
a C<$_>, chances are good that it's a mistake, right?
If a pipe short
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the first result has been
processed from the intervening elements?
--
ralph
> suggest using >> instead of -> for now,
> as a placeholder.
I like it as the real thing too. It stands
out better in a line, among other advantages.
>@source >> @out;# 'map' or 'assignment'-like
>@source >> grep { /foo/ } >> @out; # object-method-like
Yes, several
-> $_ { ... }
> given $foo sub { ... }
>
> Are all equivalent (if sub topicalizes its
> first parameter).
Oh. Now I understand C<->> rather differently!
The left-to-right flow/assignment viewpoint
had worked for me as an (incorrect) way to
interpret C<->>
> > [regarding -> as a left-to-right pipe-like operator]
>
> '->' isn't (in my mind) "a left-to-right
> flow/assignment operator." It's a unary
> operator, synonymous with "sub" without
> parens required around the argument list.
You seem to be forgetting:
given $foo -> $_
and cousins.
--
r
> push (/foo/ && @foo ||
> /bar/ && @bar ||
> /zap/ && @zap), $_ for @source;
Presumably, to avoid run time errors, that
would need to be something like:
push (/foo/ && @foo ||
/bar/ && @bar ||
/zap/ && @zap ||
@void), $_ for @source;
> But perhaps...
>
>
Michael said:
> I worry that C sounds too much like
> something class-related
'Classify' also seems wrong if some items are
thrown away. I like 'part':
(@foo,@bar) := part { ... } @source;
Headed off in another direction, having a sub
distribute its resul
> Dynamic scoping (take 2)
> ... a system of implicit argument passing ...
> Larry pointed out [an error about threads]
The system of implicit argument passing was
intended to eliminate the need to use globals.
I was wrong about threads but that doesn't
change my view that globals are mostly evil
I'm sorry, but I gotta get back on the
no-global grail trail for at least one
more post.
> The granularity [of currying] can be
> controlled on a sub-by-sub or on a
> class-by-class basis.
If one could do something like this:
{
my $src = 'oldname1';
my $dest = 'newname1';
use FileUt
Larry's earlier response means this 'yours'
idea is history, but for closure, yes, this
seems to be headed in the right direction,
at least in theory. It may have even been
practical to implement it thru the standard
property mechanism.
> so these two are equivalent ???
>
> {
> my $x is yours ;
>
Thanks for the clear answers.
Larry:
> I think that currying should be extended to
> handle any caller-instituted defaulting.
Argh. So obvious! (So of course I missed it.)
> Basically, the parameter list of the subroutine
> is already providing a limited namespace to be
> shared by caller and c
Warning: I just watched The Wizard Of Oz
for the first time tonight.
> $x is yours
>
> tells that $x is aliased to variable in
> some "secret scope symbol table" that
>( the table ) is shared between caller
> and callee
The "secret" place is MyYourca, a Subterranean
island. People think it's an
> I like more "shared" instead of "yours"
But that's because that's the way you are
thinking about the problem/solution.
I'm just talking about a very local trick
of having autoargs instead of explicitly
passing args in parens. The fact that this
ends up creating an elegant alternative to
dangero
> you propose a mechanism of passing [vars]
> between desired subroutins by default
> through all the dynamical chain of sub
> calls "connecting them.
There's more, or rather, less to it than that.
The same mechanism also includes a clean way
to pass "it", something that needs to be done.
And a
In summary, I am proposing that one marks
variables that are to be automatically
passed from sub to sub with 'is yours'
where appropriate.
An example of what I'm suggesting follows.
Code with brief comments first then explanation.
{
my $_; # $_ can't be touched
> [temp]
> [implicit args]
Here's a snippet of conversation on a
haskell list about implementation of
implicit args : http://tinyurl.com/2ym1
--
ralph
First, I'd like to confirm I've understood
C and C right:
1. C dynamically scopes changes to a
variable's value to the enclosing block.
It does not dynamically scope the name.
The variable can obviously be a global.
It can also make sense if it is lexical.
Is the latter currently al
> > Are you suggesting this?
> >
> > if($error) {
> > use visible '&croak';
> > require Carp;
> > import Carp: 'croak';
> > croak($error);
> > }
>
> No - that would be pointless as well as error-prone.
>
> My idea of "visible" is that it would make a lexically scoped thing
> accessible to an inn
special beyond establishing
a nested lexical scope:
$_ = 1; { $_ = 2 }; print; # 2
whereas '->' means the topic gets set and is
private to the block (ignoring aliasing effects):
$_ = 1; for @foo -> $_ { $_ = 2 }; print; # 1
It seems to me that a logical conclusion wou
> $_ = 1; mumble { $_ = 2 }; print;
>
> will print 1 or 2?
Least surprise, visually, is obviously 2.
This would be true if bare blocks (even
those passed as args) just pick up from
the surrounding lexical context. And if
that were true, mumble presumably could
not do anything about this (wit
> # I am thinking one should have to predeclare
> # in a sub's preamble that such a trick will
> # be going on.
> #
> # Thus something like:
> #
> # sub foo [&bar] { ... }
> #
> # is (part of what is) required to be allowed
> # to create a bar sub in the context of the
> # caller of foo.
>
>
> # I'm uncomfortable [that]
> # one can reach in to the caller's lexical
> # context from any place in a callee's body.
>
> We need that capability if we're going to
> have lexically-scoped exports:
I think I was a bit careless in how I worded
that.
My problem is not that one reaches in to the
c
> > Elements of this shared vocabulary might be
> > called 'locals' or 'yours'.
>
> I like the 'yours' idea from the point of
> view of the callee:
>
> my $inherited = your $_;
I like that syntax, but I'm uncomfortable
with an underlying principle, which is that
one can reach in to the ca
> inheriting a caller's topic isn't going to be
> that common a thing that it needs such a short
> name, is it?
15% of the perl 5 builtins do so.
I have suggested that, in some extreme
scenarios such as short scripts, perhaps
as many as 50% of subs might do so. But
then again I probably ate a lot
> c) the ability to break lexical scope
Well, I could argue that c) already exists
in the form of passing parameters in parens.
Of course, that doesn't feel like "breaking"
anything.
So instead I'll argue that the word "break"
is perhaps prejudicially perjorative.
I'd say, to steer away from be
> >> $_ # current topic
> >> $__ # outer topic
> >> $___ # outer outer topic
>
> [not sufficiently visibly distinct]
> [too much anyway]
Agreed.
Returning to the topic of binding/copying
from a caller to a callee, what about using
square brackets to mark implicit args
> > don't understand when one could do the
> > 'is given($_)' and not do the ($_ = $_).
>
> Any time that the caller's topic isn't
> supposed to be explicitly passed as an
> argument, but is still used within the
> subroutine.
>
> [example]
>
> And, yes, I could make it an optional
> argument, but
> > my sub foo ($_ = $_)
> >
> > to just propagate the outer $_ inward.
>
> That only works when $_ can somehow be
> shoe-horned into the parameter list.
> Whereas:
>
>my sub foo is given($_)
>
> works for *any* parameter list.
Other than the placeholder situation, I
don't understa
Larry:
> > sub bar(; $foo = ) {...}
Damian:
> topic [would be] C.
I assumed implied an 'is given'.
I don't see why it couldn't.
Damian:
> Hm. Given that the topic is in some sense
> a property of the lexical scope of the subroutine
> body, this might be a possibility:
>
> sub bar($foo i
> My complete knowledge comes from
> archive.develooper.com/perl6-language...
> (search for "superpositions").
I find google (rather than develooper's
archive/search) the best tool for most
searching of p6lang. Unfortunately even
google only goes back so far, and doesn't
search punctuation.
Perl
> "access caller's topic" is an unrestricted
> licence to commit action at a distance.
Right.
Perhaps:
o There's a property that controls what subs
can do with a lexical variable. I'll call
it Yours.
o By default, in the main package, topics are
set to Yours(rw); other lexicals are s
> > method f ($self : $a) { ... }
> > sub f ($a) is given ($line) { ... }
> >
> > what do you call $self
>
> The "invocant".
>
> > and $line?
>
> A lexical variable that happens to be
> bound to the caller's topic.
The "invokit" perhaps?
> placeholders create subroutines, not method
> You're confusing brevity of declaration
> with brevity of use.
One needs sufficient brevity of both call
and declaration syntax if the mechanism's
brevity is to be of use in short scripts.
> Making (limited) circumvention of [$_'s
> lexicality] depend on a verbose and
> explicit syntax will he
Damian:
> ["it" will be passed to about 5% of subs,
> regardless of whether the context is your
> 10 line scripts or my large modules]
If the syntax for passing "it" to a sub
remains as verbose as it currently is,
you are probably right that "it" won't
be used to achieve brevity! I think it's
a
In the hope this saves Allison time, and/or
clarifies things for me, I'll attempt some
answers.
> In your article at perl.com you describes
> various ways and situations when perl
> creates a topic and this is described as
> perl making the following binding on my behalf:
>
> Will there be some shorter-hand way to say these?
> [list comprehensions]
(bb clarified that this is about hash slicing.)
>From A2:
RFC 201: Hash Slicing
...Concise list comprehensions will require
some other syntax within the subscript...
And
There are many ways we could re
> Can currying include the given topic? Can
> I do something like:
>
> $foo = &bar.assuming( _ => 0)
>
> or whatever the latest syntax is?
Oops. More clearly:
sub bar is given($foo) {
...
}
$foo = &bar.assuming( foo => 0 )
--
ralph
> > My imagination suggests to me that in a
> > typical short perl 6 script
>
> That's some imagination you've got there! ;-)
:>
> My estimate (based on the -- not inconsiderable --
> code base of my own modules) is closer to 5%.
Your estimate of what oth
> relatively few subroutines need access
> to the upscope topic.
Well, this is a central issue. What are
the real percentages going to be here?
Just how often will one type the likes
of
-> is given($foo is topic) { ... }
rather than
-> $foo: { ... }
?
My imagination su
> > (naming) the invocant of a method involves
> > something very like (naming) the topic
>
> Generally, there's no conceptual link...
other than
> The similarity is that both are implicit
> parameters
which was my point.
Almost the entirety of what I see as relevant
in the context of dec
> people on the list who can't be bothered to read
> the documentation for their own keyboard IO system.
Most of this discussion seems to focus on keyboarding.
But that's of little consequence. This will always be
spotted before it does much harm and will affect just
one person and their software
> After all, there's gotta be some advantage to
> being the Fearless Leader...
>
> Larry
Thousands will cry for the blood of the Perl 6
design team. As Leader, you can draw their ire.
Because you are Fearless, you won't mind...
--
ralph
from the outside and makes
it the topic.
On its own this was no big deal, but it got
me thinking.
The key thing I realized was that (naming)
the invocant of a method involves something
very like (naming) the topic of a method,
and ultimately a sub and other constructs.
Thus it seems that wha
> > A ^ prefix visually interferes a lot more
>
> I know it clutters up things a bit, that's my very argument; that
> ^[ ] clutters up things even *more*. especially, with use of arrays:
>
> @array[1,2,3] ^[+=] @array[4,5,6];
>
> bleah.
>
> @array[1,2,3] ^+= @array[4,5,6];
>
> Not much of a i
> > 1) Need a definite syntax for hypers
> > ^[op] and <>
> > have been most seriously proposed -- something that keeps a
> > bracketed syntax, but solves ambiguity issues.
>
> hm. What was wrong with just '^' again?
Right. I didn't have a problem with ^ in the first place.
But...
A ^ prefix
> temp sub infix:^[] is force_hash_to_intersect ;
Right. A property used as you suggest is effectively
an adverb applied at op definition rather than use.
> maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of
> length 3 ;
Right. It's quite plausible that one would want to be
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection.
> > union:
> > intersection :
>
> How would this work for hashes with differing properties?
>
> %a ^is strict_keys;
> %b ^is no_strict_keys;
>
> What would happen?
That's one reason why I suggested control of this sort
of thing should be a property of the operation, not of
the operands.
--
ra
> > %a ^:union[op] %b
> >
> > %a :foo[op]:bar %b
>
> I think that any operators over 10 characters should
> be banished, and replaced with functions.
I'd agree with that. In fact probably anything over 4,
and even 4 is seriously pushing it.
I'll clarify that I am talking here about using
> hash ^[op] hash
> ...
> array ^[op] scalar
ie, generally:
term ^[op] term
> what to do if @a, @b in @a ^[op] @b have different length
> what to do if %a, %b in %a ^[op] %b have not the same set of keys
> what to do in %a ^[op] @a
>
> [what to do] resolved by hash property :
I'd exp
> So despite the beauty of
>
> @a [+] @b
>
> I think it cannot survive in its current form. It overloads square
> brackets too heavily.
What about using colon thus:
@a [:+] @b
or other character after the opening bracket, so long as that
character is not valid as the initial character
> : > I wonder if we can possibly get the Rubyesque leaving out of
> : > endpoints by saying something like 1..!10.
> :
> : Similarly: 1 >..< 10 == 2..9
> There's also an issue of what (1..10) - 1 would or should
> mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
> mean (2..10)?
>
> A
> And that's also why we need a different way of returning from the
> innermost block (or any labelled block). "last" almost works, except
> it's specific to loops, at least in Perl 5 semantics. I keep thinking
> of "ret" as a little "return", but that's mostly a placeholder in
> my mind. I've g
> Somebody fairly recently recommended some decent fixed-width
typefaces.
> I think it may have been MJD, but I can't find the reference right now
> (could be at work).
Michael Schwern recently suggested "Monaco,
Neep or, if you can find them, Mishawaka or ProFont".
I investigated and found this
> Nothing the matter with "our" for class attributes since they're
> already stored in the package if we follow Perl 5's lead. But using
> "my" for instance attributes is problematic if we allow a class to
> be reopened:
>
> class Blurfl {
> my $.foo;
> }
> ...
> class Blurfl is
I've looked before for discussion of the rationale behind
introducing attr/has and failed to find it. I noticed you
mention Zurich, so perhaps this decision followed from
discussion in living color (as against b+w).
Anyhow, what was deemed wrong with using my/our?
And...
> class Zap {
> my %.za
Problem:
You want to use delegation (rather than inheritance)
to add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
27;s where I add my other small niggle: it's not
clear to me /mnemonically/ which is which. Even if
you can tell which is a brace and which a paren, you
are still left wondering what each does when you're
learning this new stuff. I mean, which one of these is
executing some code t
> [EMAIL PROTECTED] (Me) writes:
> > 1. It's nice how the ':', '::', and ':::' progression indicates
> > progressively wider scope. But I would be surprised if
> > newbies don't say to themselves, "now just how wide a
> > sco
Backtracking syntax includes:
:, ::, :::, ,
I like the way the ':' looks in patterns. But I noticed I have
several niggles about a number of other aspects of the
above syntax. All the niggles are minor, individually, but
they added up to enough that I thought I'd see what the
bikeshed might
In several forms of courier, and some other text fonts
I view code in, I find it hard to visually distinguish the
pattern element:
<( ... )>
from:
<{ ... }>
What about replacing the former syntax with:
?
--
ralph
> I'm talking about just in the same namespace, how
> do we keep rules from messing with file-scoped
> (or any-scoped, for that matter) lexicals or globals.
> How do we get rule- or closure-scoped lexicals
> that are put into $0?
How about something like the following rework of
the capture/hypoth
I may be missing your point, but based on my somewhat
fuzzy understanding:
> Oh. Duh. Why don't we have such a mechanism for matches?
>
> m/ my $date := /
>
> is ambiguous to the eyes. But I think it's necessary to have a
lexical
> scoping mechanism for matches
The above would at least hav
> [run time control of assignment behavior when array contains pairs]
How much have I misunderstood things from a mechanisms
available point of view (as against a practical / nice way to
do things) when I suggest something along the lines of:
my sub op:= (*@list : %adverbs) {
...
> Damian Conway wrote:
> >>And is the is/but distinction still around?
> >
> >Oh, yes.
>
> Could someone please reference where this decision was
> made. I do not find any information describing the distinction.
The following May 2001 post was related. Poke around the
thread it was in, especial
> > $roundor7 = rx /<+[17]>/
> > That is: the union of the two character classes.
>
> Thank you; that wasn't in A5, E5 or S5. Will there be <-> as
> well?
>From A5:
The outer <...> also naturally serves as a container
for any extra syntax we decide to come up with for
charac
Current p6 rx syntax aiui regarding embedded code:
/
#1 do (may include an explicit fail):
{ code }
#2 do with implicit 'or fail'
<( code )>
#3 interp lit:
$( { code } )
#4 interp as rx:
<{ code }>
/
This feels cryptic. Do we need abbreviated syntax for
> : Would something like these DWIM?
> :
> : # match pat1 _ pat2 and capture pat2 match:
> : / pat1 { ($foo) = / pat2 / } /
>
> Yes
So a match in a closure starts where the outer match
was. Simple enough.
Will:
# match pat1 _ pat2 _ pat3 and capture pat2 match:
/ pat1 { ($foo)
I'm basically sold on Damian's conclusions. On the other
hand the 'otherwise' clause still feels to me like a CAPITALS
block.
So, as a tweak, I suggest:
while condition() {
...
}
NONE {
...
}
--
ralph
[modified repost due to warnock's dilemma]
Would something like these DWIM?
# match pat1 _ pat2 and capture pat2 match:
/ pat1 { ($foo) = / pat2 / } /
# match pat1 _ 'foo bar':
/ pat1 { 'foo bar' } /
# match pat2 if not pat1
/ { ! /pat1/ } pat2 } /
# match pat2 if
> when matching against something like "foo\nwiffle\nbarfoo\n"
>/(foo.*)$/ # matches the last line
/(foo[^\n]*)$/ # assuming perl 6 meaning of $, end of string
>/(foo.*)$/m # matches the first line
/(foo[^\n]*)$$/ # assuming perl 6 meaning of $$, end of line
or
/(foo.*?
> > : I'd expect . to match newlines by default.
I forgot, fourth, this simplifies the rule for . -- it
would become period matches any char, period.
Fifth, it makes the writing of "match anything but
newline" into an explicit [^\n], which I consider a
good thing.
Of course, all this is minor s
> : I'd expect . to match newlines by default. For a . that
> : didn't match newlines, I'd expect to need to use [^\n].
>
> But . has never matched newlines by default, not even in grep.
Perhaps. But:
First, I would have thought you *can't* make . match newlines
in grep, period. If so, then whe
Larry said:
> I haven't decided yet whether matches embedded in
> [a regex embedded] closure should automatically pick
> up where the outer match is, or whether there should
> be some explicit match op to mean that, much like \G
> only better. I'm thinking when the current topic is a
> match state
> /pat/i m:i/pat/ or // or even m ???
Why lose the modifier-following-final-delimiter
syntax? Is this to avoid a parsing issue, or
because it's linguistically odd to have a modifier
at the end?
> /^pat$/m /^^pat$$/
What's the mnemonic here? It feels the wrong
way round -- like a single
> Very nice (but, I assume you meant {$foo data})!
I didn't mean that (even if I should have).
Aiui, Mike's final suggestion was that parens end up
doing all the (ops data) tricks, and braces are used
purely to do code insertions. (I really liked that idea.)
So:
Perl 5Perl6
(data)
> [2c. What about ( data) or (ops data) normally means non-capturing,
> ($2 data) captures into $2, ($foo data) captures into $foo?]
which is cool where being explicit simplifies things, but
ain't where implicit is simpler. So, maybe add an op ('$'?)
or switch that makes parens capturing by d
g to Larry, run time properties will most often be used
to contradict a built-in or compile time property. If he is right
about the dominant case being a contradiction, 'but' works
better for me than anything else I can think of, including 'now'
(explained below).
-
Even if
Let me see if I understand the final version of your (Mike's)
suggestions
and where it appears to be headed:
Backwards compatibility:
perl5 extended syntax still works in perl6 if one happens to use it.
Forward conversion:
Automatic conversion of relevant perl5 regex syntax to perl6 is s
> The following syntaxes have been seen:
>
> foo()
> .foo()
> ..foo() ## rejected because ".." is different binary op
> class.foo()
> FooClass.foo()
> ::foo()
> Package::foo()
> $foo()
> $_.foo()
With a nod to Piers, and with apologes if this is silly in
the context of Perl 6 syntax, wh
> But suppose you want all .foo to refer to self and not
> to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or
"Non-yet-thrown exceptions must be a useful concept."
This is a bullet point from a list in Apo4 introducing
coverage of exception handling. Was Larry talking
about an exception object that hasn't yet been thrown?
Did he refer to this issue again anywhere else in the Apo?
--me
, then one could type:
LAST: {
or
last: {
--me
> [final, private]
I detest what these modifiers have done to me
in the past. They seem very unperlish to me.
ited and the code
is not. One can optionally not inherit the conditions
(at least preconditions, from another post I just read).
And one can optionally inherit the code (by calling it).
Right?
Btw, are you going to have an equivalent of super?
--me
lock you write clean up code that frees some
resources. If you inherit from that method, and do not
inherit the LAST block, then you've got a leak. This is
obviously a mild example.
--me
icitly break
> out of a topicalizer, it should not be last. I'd suggest break!
> So it looks to me like we need a break.
I'm glad Larry didn't suggest 'done', because I really enjoyed Apo4.
I'll suggest it instead.
> I also happen to think that Exception i
once at the time POST does.
Personally I'd leave this out until it became clear, well
past p6.0, whether it was really worth it, but it seems
worth mentioning.).
--me
> [concerns over conflation of post-processing and post-assertions]
Having read A4 thoroughly, twice, this was my only real concern
(which contrasted with an overall sense of "wow, this is so cool").
--me
>> What about if the symbol doesn't exist in the caller's scope
>> and the caller is not in the process of being compiled? Can
>> the new symbol be ignored since there obviously isn't any
>> code in the caller's scope referring to a lexical with that
>> name?
>
> No. Because so
Dan, I don't immediately see how per object/class dispatch
control helps to make multimethods pluggable. Perhaps a
multimethod (a set of methods) is a class/object? Is there
a general mop for dispatch?
More generally:
> Yes. Ordinary subroutine overloading (like that offered by C++)
> certainly
> If the dispatcher is drop-in replacable, what does its
> interface look like?
I'm thinking this is either deep in mop territory, or a probably quite
straightforward set of decisions about dispatch tables, depending
on how you look at things.
I found just one relevant occurence of 'mop' in perl
ean something utterly different
in other common languages. And I never did find 'multimethods'
appealing either.)
Even if the dispatcher is the heart of multimethods, perhaps it
would be nice if it were convenient to replace the dispatcher
in whole or part. Kinda reminds me of the story of the old mop.
> I haven't finished this idea yet but, I was talking with Andy Wardley
> and this may be the idea. Except it will be the Template Toolkit
> interfacing with wiki which means we can build filters that translate
> POD. Of course, if the wiki internal format isn't some type of
> DocBook, it's not
> 2. Format (quick to read, quick to write docs that link together;
> 2 paragraph intro that becomes a daily tip)
Are thinking of making a wiki a key part of the overall picture?
1 - 100 of 140 matches
Mail list logo
