Hi Richard,
Not a complete answer to your question;
just an observation about your grammar:
> rule TOP{ ^ + $ };
>
> rule statement { '='
> | { { self.panic($/, "Declaration syntax incorrect") } }
> };
>
> rule endvalue { '(' ~ ')'
>
Dear fellow revellers in the dawning Golden Age of Perl 6,
I just had a colleague contact me, to express their surprise that Perl 6
does not rate a mention in:
https://en.wikipedia.org/wiki/Functional_programming.
The Perl 6 community (and Larry in particular) has already done an
incredible
Raiph Mellor wrote:
The .kxxv method name is a placeholder.
Phew! Thanks for taking the time to respond and
explain, Raiph.
The brief discussion that motivated introducing it is at:
http://irclog.perlgeek.de/perl6/2014-04-13#i_8582049
Larry has chimed in at:
It's an awesome language, which is exactly the problem. Inspiring
awe is not far from inducing panic and terror, especially in people
who aren't feeling too confident in the first place. We want to be
accessible to the people who start looking nervous when the modulus
operator is added to the
Spec Bag.kxxv
It's a clever name...but maybe too clever?
I find it unfortunate that a method that only returns keys has a 'v'
in its name.
Up to now, we've had a more predictable pattern to naming these accessors.
How about one of:
.weighted-keys
.distribution
instead???
And
Moritz wrote:
To spin the tale further, we need to think about what happens if
somebody writes
multi foo(1|2e0) { ... }
so now we have Int|Num. We could explore the most-derived common
ancestor (Cool), or look into role space (Real, Numeric come to mind),
or simply error out.
Or maybe we
Father Chrysostomos pointed out:
I said when, not whether. :-)
Isn't that just typical of me: confusing ontology with chronology. ;-)
I'm afraid don't know the implementation details for Rakudo. It may be
bound as the surrounding block is entered, or perhaps just-in-time when
the Code object
But by using the term ‘variable’, which is ambiguous, you are not
answering my question! :-)
Sorry. I tend to think of *every* variable name as merely being
an alias for some underlying storage mechanism. ;-)
Does
my $x;
for 1..10 - $x {}
cause the existing name $x to refer
Father Chrysostomos asked:
What I am really trying to find out is when the subroutine is actually
cloned,
Yes. It is supposed to be (or at least must *appear* to be),
and currently is (or appears to be) in Rakudo.
and whether there can be multiple clones within a single call of
the
Herbert Breunung asked:
what was you rational behind this decision.
I like it visually but my brain refuses to find any logic why only there
special vars should be different.
This change stems from another change that we made after discussions at
YAPC Riga last year. That change was to
Thank you damian, i will apply that patch,
Much appreciated, Herbert!
Damian
At least in #perl6 I've never seen anybody try to write an auto-deduced
sequence, and fail because of floating-point errors.
Except for Martin's 1, sqrt(2), 2...8
But, yes, the widespread use of Rats rather than Nums
means only the edgiest of edge-cases fails. And as you get
an explicit
yary suggested:
In a situation like this, I reach for a thesaurus
The standout from that list for me is: 'consonance'.
Second favorite is: 'gibe' or 'jibe'.
But the underlying operation is .ACCEPTS(),
so perhaps the operation should be referred to
as acceptance or acceptibility.
Damian
Actually, that one works fine in both niecza and rakudo, since those are Rats.
Oh, that's good to hear.
It doesn't change my underlying argument however. Any operations
performed on genuine floats are going to lose precision, and if we're
using such operations to infer relationships (such as
Patrick correctly observed:
On Rakudo on my system, sqrt(2) indeed produces a Num,
but since floating point arithmetic doesn't result in
sqrt(2) / 1 == 2 / sqrt(2), no geometric sequence is deduced
and the sequence fails with unable to deduce sequence.
Although, arguably, that might be
But unless we twist smartmatching semantics for that purpose,
No!
Please, no.
;-)
it means we cannot do the same fuzziness for the endpoint,
Except that we will be encouraging people to use: * = $END
as their standard endpoint pattern, which will provide
most of the necessary fuzz.
So
Is it possible to create a new range operator ':' such that:
Do you need to?
a:b:c is a range from 'a' to 'b' by steps of 'c'.
Perl 6 already has: $a,*+$c...* =$b
E.g. 2, 5 ...^ *=15 2,5,8,11,14
:b is the same as 0..b
Perl 6 already has ^$b
e,g, ^100 0..99
a: is the same
Interesting... but it doesn't seem to work in Rakudo Star (2012.02):
@(2,5..10)
You need three dots, not two.
Damian
Ok, so infix:... isn't what I wish for either... Can you help me
understand Damian's example?
Breaking down that example:
$a, # Start at $a
*+$c # Generate next number via: sub($prev_num} { $prev_num + $c }
... # Repeat until...
* =$b # ...this sub matches:
Carl asked:
class A {
method foo($x) {
PRE { $x 10 }
# ...
}
}
class B is A {
method foo($a, $b, $c) {
PRE { [] $a, $b, $c }
# ...
}
}
When CB.foo is called, are both CPRE blocks meant to be run?
My thanks to Kris and Moritz for reassuring me that
the Perl 6 initialization semantics remain sane. :-)
In response to yary's original observations, the extra work required to
achieve non-standard semantics doesn't seem unreasonable to me.
Especially as, should one need to do it regularly, one
yary wrote:
The current approach is violating the DRY principle. When you write a
.new method that wants to initialize private attributes, you have to
repeat all their names again in the signature of your BUILD submethod:
The other way of looking at this is that redefining the new() is about
Yary wrote:
If one wants to use any argument in the constructor other than a
public attribute (positional OR named other than an attribute name),
one must define a method new( ... ).
Huh? I know I've been out of the loop lately, but this seems fundamentally
wrong.
Constructor args certainly
Moritz clarified:
In BUILD, the object isn't yet fully constructed, and thus using $.attr
(which is really a virtual method call in disguise) is wrong. STD and
niecza already catch that at compile time, and I'm currently trying to
make rakudo catch it too (branch 'has-self' on github).
It's a trivial point, but why hidden_from_backtrace instead of
hidden-from-backtrace? Especially given that the associated
method is is-hidden, not is_hidden?
Are we consistently using underscores for multi_word traits
and hyphens for multi-word methods? Wouldn't it be nice to
have a consistent
The current stance seems to be that low-level things are spelled with
underscores, while we reserve the minus character for user-space code. Try
grepping the specs for identifiers of built-ins that have a minus in it -- I
didn't find any in a quick search.
I had a little more time to look and
Carl asked:
* What do we mean when we say 'has @.a is readonly'?
What do we want it to mean?
Not sure about we, but I want that to mean that nothing outside the
class can alter any component of @.a, no matter how deeply nested that
component may be.
* Are we fine with references from
Moritz wrote:
$value !~~ Junction $value ~~ $junction
In general this definition makes it impossible to return a list of
eigenstates from the junction. Just think of junctions containing Code
objects.
Well, that's a deficiency in smartmatching: that Callable ~~ Code doesn't
check for
Martin D Kealey suggested:
Well, I think returning or throwing an Unordered exception would be
the appropriate way to handle those, both for complex numbers and for
junctions.
For complex numbers that might be true, because the order relationship
between two complex numbers isn't expressible
Martin D Kealey asked:
Or do we not invert junctions, and run the risk of unexpected
action-at-a-distance instead?
I think our current approach is correct. That is: we invert
junctions on operators that are themselves intrinsically inverted
(such as !=, !~~, !), but do not invert on those that
Jon Lang wrote:
Personally, I don't think that it should be a public method: one thing
about junctions is that you can use them interchangeably with ordinary
scalars; giving them a public method breaks that. In particular, code
that makes use of a Junction public method would break if you
Ben Goldberg asked:
I'm probably missing something, but wouldn't it have been easier to
write that module by using eval STRING to create all of those infix
operators?
Sure. But the module is already slow to start up. I was concerned
that it would get even slower with an embedded eval. But, in
Dave Whipp noted:
I think that the two proposals are equivalent, in the sense that either can
be trivially implemented using the other.
Agreed.
However, I am a little concerned that the transjunction magically changes
an operator that returns a Boolean value into one that returns a list.
Brandon mused:
It occurs to me: If their purpose is that narrow, why are they wasting
conceptual space in the core language?
Well, mainly because their purpose isn't narrow at all: it's parallelized data
comparisons (all(@values) $threshold), and multiway comparisons
(all(@values) ~~
In general I like where this is going but need a little hand holding
here- I'm not an expert on junctions or anything perl6-
So I'm going to go on to propose that we create a fifth class of
Junction: the transjunction, with corresponding keyword Cevery.
It seems that by these definitions
Dave Whipp wrote:
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the narrow purpose
for which they were introduced.
Hmm. There are intentions, and then there are intentions. I know
what I intended when I
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
Specificially, in S32-setting-library_Containers.pod, we currently have:
=item !eigenstates
method !eigenstates (Junction $j: -- Parcel)
Leon Timmermans wrote:
For the love of $DEITY, let's please not repeat ithreads!
$AMEN!
Backwards compatibility is not the major design criterion for Perl 6,
so there's no need to recapitulate our own phylogeny here.
The problem is: while most people can agree on what have proved to be
On 30 September 2010 06:09, Moritz wrote:
After lengthy IRC discussion, we concluded that it's a good idea to provide
some form of introspection that doesn't bother about perceived privacy
borders, provided that the implementation makes it feasible.
Wow, that's the first time I've ever been
Carl wrote:
For what it's worth, we had exactly this discussion a couple of days
ago on IRC. I represented your views above, Damian.
Thank-you for that.
As long as C.perl works the way it does, there can be no real
privacy.
Sigh. That is indeed badly broken. Surely it ought to default to
Moritz wrote:
To re-iterate, Perl 6 has no real privacy by default -- both the
default .new and .perl methods give you access to private attributes,
unless you explicitly override them.
At least you *can* explicitly override them (and perhaps factor that out
into a role that you could always
Moritz writes:
Objects that you can't do that with don't make sense to be serialized and so
.perl can reasonably refuse to work on them.
method perl {
die Can't serialize objects of type $?CLASS, because ...;
}
Sure. But now the cautious programmer has to add that to *every* class
Jonathan wrote:
Sounds like the encapsulation breaking thingy probably wants to be looking
for some pragma to have been used in the lexical scope of the caller, maybe.
I'd rather that we called it something other than MONKEY_TYPING though.
Different evil, different pragma. :-)
As long as
Carl proposed:
The other path that seems reasonable to me would be to use the same
naming scheme as for the block types, i.e. reserve all-upper and
all-lower forms (and die if an unrecognized one of this form is
encountered), and let the custom ones live in the namespace of
mixed-case
Aaron wrote:
I dislike reserved in this context, but understand why the namespace has
to be shared. For config options, I'd say anything should go, but people
inventing their own config options should be aware that across N release
cycles, new options may be introduced.
...which means that
On 23 July 2010 01:41, Moritz Lenz mor...@faui2k3.org wrote:
Use the right tool for the right job:
square numbers: 0, 1, 4, 9, 16, 25, 36, etc.
(1..10).map(* ** 2)
Or even just:
(1..10) »**» 2
Note that you can also get most of the effects you want by using
@_ in the series'
Well, if we're not going to try to implement linguistically based
hyphenation/underscoriation rules (and I'd still argue that hyphenating
adjectives to nouns and underscoring everything else isn't exactly
rocket science), then I'd suggest we reconsider a radically different
proposal that was made
Personally, I'd prefer to see the English conventions carried over to
the use of general use of hyphen and underscore in identifiers in
the core (and everywhere else).
By that, I mean that, in English, the hyphen is notionally a
higher precedence word-separator than the space
(or than its
John Siracusa commented:
That's certainly an example of how hyphens might gain meaning in Perl
6 names, but I don't think I can endorse it as a convention. People
can't even use hyphens correctly in written English. I have very
little faith that programmers will do any better in code
But
Larry mused:
Alternatively, maybe there should be some way to express infinite sets.
Not sure I like the idea of an infinite junction, but something resembling:
subset PowersOf2 of Int where any(1,2,4...*)
enum Perms of PowersOf2 Read Write Exec;
say Exec; # 4
Presumably the
Daniel Ruoso pointed out:
Using bitsets in Perl 6 is just as easy as using in Perl 5 -- which
happens to be the same as using in C, but it's not C...
constant PERM_WRITE = 0b0001;
constant PERM_READ = 0b0010;
constant PERM_EXEC = 0b0100;
constant PERM_NAMES = { PERM_WRITE = 'Write',
Jonathan Lang wrote:
Wouldn't that be C = 0...* ?
Indeed. Thanks for the correction.
That said, don't we already have a means of assigning specific values
to individual members of an enum? I forget the exact syntax,
The exact syntax is:
enum Perms [Read = 1, Write = 2, Exec = 4, Fold
We could make enum declarators even more like constant declarators
by using a pseudo assignment. Then we could use = instead of parens:
enum Perms = Read Write Exec Fold Spindle Mutilate Z= 1,2,4...*;
Hmm. That doesn't seem very like constant declarators. In a
constant declarator,
the
An issue came up in a class I was teaching today...
There doesn't seem to be an easy way to create a type that allows a set
of enumerated bit-flags *and* all the combinations of those flags...and
nothing else.
For example:
enum Permissions ( Read = 0b0001, Write = 0b0010, Exec = 0b0100 );
Larry concluded:
I do freely admit that most Perlfolk are not used to thinking of
permissions in terms of set theory. But as I said, we're looking at
kind of a strange use case here, and perhaps not typical of the kinds
of sets of small numbers that people will be using in the future.
The
Surely this is not a common-enough requirement to warrant a special
syntax.
At 80-columns, you can represent integers up to ninety-nine
quinvigintillion, nine hundred ninety-nine quattuorvigintillion, nine
hundred ninety-nine trevigintillion, nine hundred ninety-nine
duovigintillion, nine hundred
+ rhyme((1,2),3,:miceblind) # rhyme has 2 arguments
Should that say 3 arguments?
I believe so.
(If not, please can somebody clarify what
the 2 arguments are.)
(1,2) and 3. Named arguments (mice in this case) are handled separately.
That interpretation is not consistent with the
Carl observed:
Partly that is because documentation isn't at the forefront of things
that need to be implemented for Perl 6 to be useful, so it's kind of
lagging behind the rest.
Partly it's because Damian is the owner of that synopsis, and he
practices a kind of drive-by-updating to it. As
Aaron Sherman asked:
Should there be an explicit way to step this down to just parsing the bits
that are called out as pod?
The original conception allowed for Pod to be independent of the
interleaved language. That has now been supplanted by a model that views
Pod as an integral part of Perl.
yary asked:
Can some concept/implementation of $=POD lazyness only incur the
memory and performance hit on access?
IANAImplementor, but I suspect that virtually all of the performance hit
could be incurred at run-time, if it happened to be implemented that
way. The memory hit too, if
Darren Duncan wrote:
pg 36 - About the Perl Best Practices book, you should be clear to
mention that what is considered best practices has evolved significantly
since that book came out, so teams can't simply agree on We'll just follow
PBP guidelines and call it a day, but should study more
Darren Duncan wrote:
So another proposal I have is to add to the slideshow mentions of the
Enlightened and Modern Perl movements and where one can go to read more,
this being supplemental to PBP.
With that suggestion I'd whole-heartedly concur.
My own opinion is that the modern best way to
Jon Lang elaborated:
I don't think that there will be a problem. First, #= is easy enough
to distinguish from #=; I don't foresee any confusion.
I'm not so sure. #= is a lot more like #= that =alias is. And the one
character of difference is on the non-significant (right-hand) side.
Need to
Jon Lang huh'd:
Huh. Would you be able to do something like:
=begin pod
Welcome to $?FILE.
...and have it interpolate the file's name? Or would you need some
special markup for this, such as:
=begin pod
Welcome to A$?FILE.
The latter. Variables are just too common in
Raiph elucidated:
Hmm. I was thinking Pod would be parsed by a P6/PGE grammar, one that
could be relatively easily edited/extended to suit another context, because,
I thought, it could then be made available as a stock --doc subsystem that
all PCT based languages get more or less for free.
Jon Lang kept his promise:
I promised some further thoughts; here they are:
Much appreciated.
As written, declarator aliasing attaches the alias to a piece of code,
and draws both the name and the alias from that. What about using a
special case of the declarator block for this? That is:
Smylers pointed out:
* Hence it must always parsed using full Perl 6 grammar: perl6 -doc
Having a multi-character option preceded by a single hyphen doesn't play
well with bundling of single-character options...
You make many good points. Changed to: perl --doc
Thanks,
Damian
Moritz wrote:
However it seems we have to pay a price: each act of rendering a Pod
file actually means executing the program that's being documented (at
least the BEGIN blocks and other stuff that happens at compile time),
with all the security risks implied. So we'll need a *very* good
Raiph commented:
Couldn't the pod processing be encapsulated, perhaps in PGE/NQP, so
that it could be reused in a different Parrot language, provided that
said language supports declarators and comments, or even just comments
(if one downgrades the impact of encountering an attached comment
Jonathan Dataweaver Lang enquired:
Will ther be any ambiguity between Pod and wraparound operators that
begin with =?
No. Lines that start with an '=' that is *immediately* followed by an
identifier are always Pod. If there's a space after the '=' it's always
an assignment. You could *create*
Could we also get =numbered and =term directives that are
equivalent to =item :numbered and =item :term, respectively, for
use with abbreviated blocks? E.g.:
=numbered First Item
=numbered Second Item
=numbered Third Item
That's just:
=item # First Item
=item # Second
Kyle suggested:
Pod itself is a DSL.
Sure. But to allow arbitrary processing and rendering of Pod, a DSL
isn't enough.
If we're committed to giving guns to books, can we default to having
the safety on? Can it be so that 'perl6doc foo.pl' does not execute
any code without an option to allow
Jonathan Dataweaver Lang proposed:
OK. Let me propose an alternative (which I expect will be immediately
shot down):
BANG!
;-)
Allow '=begin alias', '=end alias', and '=for alias' as special cases:
the Perl parser makes an exception for them and doesn't treat them as
the start or end of
Darren Duncan asked:
But one thing I'm not sure whether or not it was addressed is regards to
whether free-form documentation is still supported or can be effectively
combined with embedding documentation into the places that it is
documenting.
Yes and yes.
Normal Pod blocks weren't
Raiph Mellor raiph.mel...@gmail.com wrote:
Anyhoo, I'd love to see a session of brainstorming, with nitty gritty
detail, about possible ways to get what you guys and Mark and I and
perhaps others think we would like to see in the way of super tightly
woven together comments and code, where
Raiph Mellor raiph.mel...@gmail.com hyperpunned:
With this whiny man exchange ultimately having bourne supreme fruit,
the apocalypse watch for the post damian weekend begins...
ARRRG!
Damian ;-)
Mark J. Reed wrote:
My understanding is that the P6 way to do that is to return a Capture
containing the desired return values (which can lazily do things only
when accessed) in the appropriate slots.
Return a Capture or a more heavily overloaded object, depending on how
fine a degree of
Perl 6's approach to xor is consistent with the linguistic sense of
'xor' (You may have a soup (x)or a salad (x)or a cocktail), and also
with the IEEE 91 standard for logic gates. See:
http://ozark.hendrix.edu/~burch/logisim/docs/2.1.0/libs/gates/xor.html
for a concise explanation of both
Larry mused:
�...@a.mung
the .mung could return
A) a modified @a (treat @a as mutable)
B) a new array (treat @a as immutable)
C) a remapped array whose elements refer back to @a's elements
Currently .rotate is defined as A, but I could easily switch it to B,
I, for one, would
Daniel Carrera wrote:
This is a really good list. Mind if I copy it / modify it and post it
somewhere like my blog?
That's fine.
One question:
* Compactness of expression + semi-infinite data structures:
�...@fib = 1,1...[+] # The entire Fibonacci sequence
Very
Jon Lang suggested:
Start with the addition operator, '1 + 1'. Apply the reducing
metaoperator to it so that it works syntactically like a function:
'[+] 1, 1'. Instead of calling it, pass a code reference to it:
'[+]'.
No. [+] isn't the Code object for [+]; it's the Code object for
Mark J. Reed asked:
So how is this:
Any infix operator (except for non-associating operators) can be surrounded
by square brackets in term position to create a list operator
that reduces using that operation:
reconciled with this:
Any ordinary infix operator may be enclosed in square
Daniel Ruoso asked:
prefix:[+]
Is that really? I mean... [ ] is a meta-operator,
Sure. But once you []-meta an infix operator, you get a prefix operator.
See http://perlcabal.org/syn/S03.html#Reduction_operators, which states:
Any infix operator (except for non-associating operators) can
Here are a few of my favourite Perl 6 selling points:
* Compactness of expression:
say 'Hello, World!';
* Compactness of expression + semi-infinite data structures:
@fib = 1,1...[+]# The entire Fibonacci sequence
* Junctions make comparisons much more
Hinrik Örn Sigurðsson wrote:
I've been thinking lately about how Perl 6 might offer functionality
similar to Python's docstrings. That is, documentation which is tied
directly to a particular routine, class or module[1]. This is
something which would is very useful in a REPL, and for
Moritz Lenz wrote:
Instead we should provide a very DWIMmy way to (lazily) create objects
that behave differently in different contexts.
That's precisely what the Contextual::Return module does for Perl 5.
It's less than perfect in Perl 5, because it has to be implemented via
runtime
Richard Hainsworth conjectured:
1) Is the following true for an any junction?
any( ... , any('foo','bar')) === any(...,'foo','bar')
If yes, then
if an 'any' junction is contained in an outer 'any', the inner 'any' can be
factored out?
Yes. More precisely, an 'any' that is directly nested
I stand corrected. That said: with the eigenstates method now private,
it is now quite difficult to get a list of the eigenstates of the
above expression.
Yes, that's a concern. Most of the interesting junction-based algorithms
I've developed in the past rely on two facilities: the ability to
Jon Lang wrote:
For that matter, I'm not seeing a difference between:
any( 12 ) # any of all of (1, 2)
...and:
any( 1, 2 ) # any of (1, 2)
Those two are very different.
any(1,2) == 2 is true
any(12) == 2 is false
Nested heterogeneous junctions are extremely useful.
Earlier I wrote:
Maybe just something like one of the attached graphics
(only redone by someone with actual graphical design skills ;-)?
It occurs to me that this comment might be misread as an implied
criticism of Conrad's original artwork as well. Just wanted to make it
very clear that was
Larry wrote:
You have to have a way of talking about your own attributes *as if*
they were not your own attributes, and $.foo is that way.
When thinking about this, it's also important to remember that, in Perl 6, not
everything with a sigil is automatically writeable. For example:
On Sat, Sep 06, 2008 at 07:06:30PM +1100, Илья wrote:
: Hello there,
: what :foo should exactly produce?
: At first I was expecting:
: foo =
: but in Rakudo:
: foo = []
: and it looks like the right thing on the other hand.
At YAPC::EU I pointed out to Larry that we have an adverbial form that
Richard Hainsworth wrote:
Consider the position you put me, or another sponsor, in.
I want to endorse everything Richard then went on to say.
I have already contacted Uri and expressed my dismay at his entirely
inappropriate interjection of an advertisement for our Perl College event into
Mark Overmeer wrote:
Then, when you want to add some docs to the method, to help the
correct use, add it, for instance like:
method isValidPostalCode(str $postalcode) returns bool {...}
` Check wether the postal code confirms to the standards
`$postalcode: a string with blanks
Mark Overmeer wrote:
IMO, POD6 should not provide the possibility to build such tools: it
should *be* the tool. With a nice (compact) standard definition how
to document each of the designed features in Perl6
And this is a succinct statement of one half of our fundamental philosophical
Mark Overmeer wrote:
[...yet another honest and heartfelt plea for Pod 6 to be something
entirely different from what it is currently designed to be.]
The solution is simple, you know, Mark. Why not just write up your own
alternate S26, redesigning Pod 6 the way you think it should work, and
Smylers reported:
I was with you right up until the mention of C=encoding; what's that
got to do with anything?
CP bug. Patched. Thanks!
Damian
Juerd wrote:
Damian Conway skribis 2007-06-21 11:45 (+1000):
A dedicated OO documentation tool could certainly do a better job in that
case, I heartily agree. I'm looking forward to using one.
This dedicated OO documentation must be core, because Perl itself is
heavily OO.
Yes. I
brian asked:
Couldn't most of this be figured out by making Pod6 extensible (or
whatever the right term is). Pod6 would be more of the syntax and basic
operation, but other people could have custom directives that their
Pod6 translators and formatters could then use. That is, not all of
this
Here's the first draft (documented in Pod 6, of course ;-).
Feedback and suggestions are most welcome.
(But please don't bother explaining to me this feature won't suffice
as the high-level automatic code-to-documentation mechanism that Markov
has been championing. I promise that I'm very
1 - 100 of 1091 matches
Mail list logo
