If one uses MAIN with arguments, one simply cannot get strings like
"Bool::True" and "True" from the command line into the same argument,
regardless of whether one uses no type constraint, a Str, a Str(), or a
slurpy. See the quote below from rakudo #2794
<https://github.c
S22-package-format.pod
Log Message:
---
META6.json describe how to denote no license or no assertion
S19-commandline.pod
Log Message:
---
suppress mention of dormant or defunct projects
Update for the current state of rakudo
erday. They smoothly speak about adding methods to
> objects etc. They speak about types and objects in a very natural way.
> They don't speak about undef objects to contain types, which are used
> as object factory. I have not found the need for :U there.
I've also not used :U in
eak about adding methods to
objects etc. They speak about types and objects in a very natural way.
They don't speak about undef objects to contain types, which are used
as object factory. I have not found the need for :U there.
> Perl 6 still has classes and instances, but Perl 6 also adds
* Moritz Lenz (mor...@faui2k3.org) [151013 07:18]:
> >In Perl5, you get slower code when you test for definedness... in Perl6
> >you get faster (better optimized) code. That's a big difference.
>
> Do you? Did you actually measure that?
For Perl6? Well, Liz tells us that it can be optimized be
you have to use :_
explicitly if you want to allow all.
Oh, use :U for that. Ehhh already in use.
:U means "undefined", :_ means "defined or undefined, I don't care"
And I don't know if we can change it now without creating a huge havoc
in the existing ecosy
lementation of mixins and roles.
> For me, a "Car" is not "a vehicle which is not yet there", but is a
> featural and functional template of a thing. The template describes the
> interface of a car, not the instance of a car. A type is scientific,
> an object is
aybeing (Any) \n 1 \n
Which actually means
"unstantiated (Any)" versus "instantiated (Int) value=1"
for me personally painfully imbalanced.
my Car $a; my Car $b; Now I have two different types. Eh, wait
they are both Cars. No, not the same because types are real objects.
O
On 2015-10-12 1:25 PM, Patrick R. Michaud wrote:
On Mon, Oct 12, 2015 at 09:51:13PM +0200, Mark Overmeer wrote:
Can you give me an example? Many other languages are capable to live
without undef and have first class type objects.
Keep in mind that what Perl 6 calls a "type object" isn't quite
On Mon, Oct 12, 2015 at 09:51:13PM +0200, Mark Overmeer wrote:
> > method new(MyClassHere:U: *@args) { ... }
> >
> > in the constructor, which would be quite hostile to newbies. It's still
> > not clear to me how to avoid that.
>
> It is also unclear to me what this means. It is a method whi
* Moritz Lenz (mor...@faui2k3.org) [151012 15:32]:
> > . are they using :D correctly?
>
> Yes, though not everybody uses :D as much as they do. Do you check that
> all the parameters that your Perl 5 methods/subs receive are defined? If
> not, you wouldn't use :D in Perl 6 either.
In Perl5, you
Hi,
On 10/12/2015 03:41 PM, Mark Overmeer wrote:
>
> Hi all,
>
> Liz and Tux demonstrate powerful Perl6 code at each monthly meeting of
> our Mongers in Amsterdam. Looking at their examples, I collected a few
> questions of which I want to discuss the first one in this thread.
>
>
> When I lo
explain to students
to add this smiley everywhere.
Can someone explain this to me? (Or point me to the correct place)
--
Thanks in advance
MarkOv
Mark Overmeer MScMARKO
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: d8509e2513b01c9ec7f1335be2e0c714d172f5d4
https://github.com/perl6/specs/commit/d8509e2513b01c9ec7f1335be2e0c714d172f5d4
Author: Moritz Lenz
Date: 2014-12-19 (Fri, 19 Dec 2014)
Changed paths:
M S19-co
ically? lazy cycling a la
?
No auto-reset, please. Just return nil or throw an exception. In other
words, make it easy to understand that the coro has been exhausted. It
should be next to trivial to reset back to the initial state. The need
to automatically reset to initial state is unusual, so d
Current parrot behaviour for exhausted yields is dying with "Cannot
resume dead coroutine."
parrot coros are designed after lua, but lua does return nil and as
2nd return value announces also "cannot resume dead coroutine". most
lisp's also behave the same way.
As third version the parrot book ann
S99-glossary.pod
Log Message:
---
S99: added or filled entries for pseudo-scopes
-documentation.pod
Log Message:
---
document semantics of multiple #| or #=
-operators.pod
Log Message:
---
range smartmatch coerces when real or stringy
-control.pod
Log Message:
---
make try an eager (or sink) contextualizer
-operators.pod
M S32-setting-library/Containers.pod
Log Message:
---
limit unary hypers to declared shape or flat
Also add .duckmap and .deepmap to give the less huffmanly desirable
semantics.
-setting-library/Str.pod
Log Message:
---
force exceptions to lc or uc
-bits.pod
M S06-routines.pod
Log Message:
---
more priming cleanup, spec .assuming * or Nil
on one wants to surpress backtraces -- are there others?)
So I guess the exception object could contain a hint whether the error
is a user error or a programming error. All those errors that are thrown
by the Perl 6 compiler count as programming error, but we can still
provide a X::UserError class,
/Containers.pod
Log Message:
---
[S32] typo or thinko in Hash.push signature
Message:
---
Add missing "or"
Message:
---
structs come as either values or objects
The treatement of a compact struct as a value or as an
object depends on whether there are mutators.
Log Message:
---
random errant "or"
f an
> array/etc.
>
> Any thoughts on this?
We could allow separator characters within the literal, such as white
space plus [[,.;:]] - and/or allow adjacent Blobs to concatenate
0b'0:01;0
1110
1, 00,
0:10' 0o'52, 35, 04, 37, 6' 0x'A7.0.5E'
# 0010111010
pugs-comm...@feather.perl6.nl wrote:
=item *
+Blob literals look similar to integer literals with radix markers, but are
+distinct in their details. A Blob literal has 1 format with 3 radix
+options:
+
+0b<00101110100010> base 2, 1 bit per column
+0o<523504376> base 8,
Author: Darren_Duncan
Date: 2010-07-12 03:01:55 +0200 (Mon, 12 Jul 2010)
New Revision: 31630
Modified:
docs/Perl6/Spec/S02-bits.pod
Log:
S02 : add initial formats for Blob (or Buf) literals
Modified: docs/Perl6/Spec/S02-bits.pod
Hi there,
I `m looking into MMD, example:
> multi t (@a) {1}
> multi t (Array $a) {2}
> multi t (Positional $a) {3}
> multi t (Positional[Array] $a) {4}
> say t()
1
> say t(Array.new)
2
> my $foo does Positional; say t($foo)
1
> my @a; say t(@a)
2
I am expected some sort of ambiguous there.
Tha
Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote:
⨷ perhaps? It only makes sense that a Unicode operator be used to
pull in all of Unicode.
Bravo.
If you can't type that, you won't find it useful!
On May 30, 2009, at 15:38 , Larry Wall wrote:
Perhaps something like
use *;
should pull in all the Unicode operators. Which if course means that
any golfing would start with
*;
⨷ perhaps? It only makes sense that a Unicode operator be used to
pull in all of Unicode.
--
brandon s
On May 29, 2009, at 22:33 , Jon Lang wrote:
"also" is an ordered, short-circuiting version of "&" (and thus
"all"). For some time now, I've wanted an analog for '|' and 'any' -
but the only name I can think of for it would be 'else', which has
some obvious clarity issues.
I have seen "x (alt.
Larry Wall larry-at-wall.org |Perl 6| wrote:
Indeed, getting "close enough" is one of the underlying design themes
of Perl 6. As to whether we're close to do the operator aliasing in
a mostly digraphic fashion, I'm not sure. Currently a macro for an
infix would be given the AST of the left argu
On Sat, May 30, 2009 at 04:50:02PM -0500, John M. Dlugosz wrote:
> Note that ≥ and ≤ are "bidi mirroring" characters in the Unicode
> Properties. So if someone were crazy enough to use them as brackets,
> then the digraph equivalent should work as well, right?
No, they'd only function as digr
ard meanings. For example, if there is no ∑,
somebody might be tempted to use it for multiplication; or to use √
for checking something; or + for concatenating strings, etc.
I agree. The original non-ASCII characters, introduced 9 years ago, are
at least Latin-1. But in for a penny, in
On Sat, May 30, 2009 at 01:09:01PM -0600, David Green wrote:
> I think that one's ambiguous as to whether $bar exists as a key or a
> value.
>
> $bar ∈ @foo; $bar ∈ %foo.keys; $bar ∈ %foo.values; ∃ %foo{bar}
Generally when hashes have been used as sets we've taken the k
It occurs to me that, while I don't want to pull in all the
possible Unicode operators by default, we should make it easy
to do so. Perhaps something like
use *;
should pull in all the Unicode operators. Which if course means that
any golfing would start with
*;
to pull in all the pos
no ∑,
somebody might be tempted to use it for multiplication; or to use √
for checking something; or + for concatenating strings, etc.
However, I think some set ops could also be used with hashes. For
example, an alternate way of spelling "exists %foo{$bar}" is "$bar
∈ %fo
e purpose. Having distinct xnor and xor operators is
>> useful from partly a documentation perspective and from
>> error-checking; a strict compiler or runtime should complain if
>> non-Bool inputs are given to them.
>
> With the heritage as a free-typed language, the use
On Fri, May 29, 2009 at 08:45:06PM -0700, Darren Duncan wrote:
> So does anyone else have thoughts on that?
Actually, I think ~x is kinda ugly. And I like the mnemonic value of
x returning one thing and xx returning multiple things. And in the
bitwise ops ~ doesn't indicate postprocessing. And
On Fri, May 29, 2009 at 11:06:46PM -0700, Darren Duncan wrote:
> Larry, did you choose = for assignment and == etc for comparison because
> you thought that looked prettier, or because that was the C/etc
> convention that you decided to copy?
Neither beauty nor convention, really. I
current design, === and !=== just happen to
have the same semantics as logical xnor and xor when given 2 Bool inputs, and so
they serve the purpose. Having distinct xnor and xor operators is useful from
partly a documentation perspective and from error-checking; a strict compiler or
runtime shou
signify better what the
operation is doing; the '~' in this case means catenation and the '*'
is meant to invoke 'multiply', not 'whatever'. So '~*' means
"catenate a multiple of times".
This would then free up 'x' to be use
Darren (>):
> Firstly, regarding the string replication ops as documented in Synopsis 3,
> 'x' and 'xx', I'm wondering whether it might be better to have something
> that incorporates a '~', since that operation is about catenation.
>
> Would perhaps '~*' work better than 'x' to signify better what
ators, not all of which make sense to
have.You name 10.
I think you answered your own criticism right there. The ones I didn't mention
are ones that don't make sense to have.
2 of the 16 dyadic operators always result in false or true respectively,
regardless of the arguments, s
On Fri, 29 May 2009, Darren Duncan wrote:
Timothy S. Nelson wrote:
How about if xx became x, and then we did things like:
[~] @list x $count
...to get the string replciation?
Maybe you meant this?
[~] $item x $count
No, I'm pretty sure I meant what I wrote. But if x coerce
d "A only if B" is "A→B": in both of the original statements, the
>> implication flows right to left.
>
> I thought that the direction did matter, and that's why there are distinct
> versions in each direction. It's like how < and > are the same thin
am discussing are meant to be read as infix
> ops only.
>
> These are the boolean/logical ops you already have:
>
> Niladic ops aka value literals / constants:
> * Bool::False
> * Bool::True
>
> Monadic:
> * not aka !, but ¬ alias could be added
>
> Dyadic:
>
Timothy S. Nelson wrote:
How about if xx became x, and then we did things like:
[~] @list x $count
...to get the string replciation?
Maybe you meant this?
[~] $item x $count
I like that a lot.
And we could still have ~x as a shorthand for that specific case since it would
li
Jon Lang wrote:
I wouldn't mind 'x' becoming '~x' and 'xx' becoming 'x'; it strikes me
as a lot more intuitive - and I've wanted to see this done for a while
now. I suppose that you might also introduce a '?x' and/or a '+x
less sure about that.
Thoughts?
I wouldn't mind 'x' becoming '~x' and 'xx' becoming 'x'; it strikes me
as a lot more intuitive - and I've wanted to see this done for a while
now. I suppose that you might also introduce a '?x' and/or a '
ution for 'xx', I'm less sure about that.
>
> Thoughts?
I wouldn't mind 'x' becoming '~x' and 'xx' becoming 'x'; it strikes me
as a lot more intuitive - and I've wanted to see this done for a while
now. I suppose that you
7;. So '~*' means "catenate a multiple of times".
This would then free up 'x' to be used for something else, if anything.
As for a substitution for 'xx', I'm less sure about that.
Thoughts?
Was that operator called 'x' because it was the b
adicts Larry's statement that .perl
autothreads. I think it can't autothread because we expect
it to put the junction constructor in front of the values
or the right operator as infix. So .perl is junction aware!
But it threads the .perl method through the eigenstates,
of course.
> >
On 3/15/09 11:19 AM, Richard Hainsworth wrote:
The following (the n:> is to mark the lines) are legal:
1:> my @x = 1,2,3,4; ([+] @x).say; # output 10
2:> my @x = 1|11,2,3,4; ([+] @a).perl.say; # output any(10,20)
3:> my @x = 1|11,2,3,4; ([+] @a).eigenstates.min.say; # output 10
However, the nex
On 2009-Mar-17, at 2:16 am, Jon Lang wrote:
$choice.perl will return the same thing that the following would:
any($choice.eigenstates.«perl)
That is, it would return a Junction of Str, not a Str. So the
question is how to get something that returns an expression to the
effect of:
'any('
hing that the following would:
any($choice.eigenstates.«perl)
That is, it would return a Junction of Str, not a Str. So the
question is how to get something that returns an expression to the
effect of:
'any(' ~ $choice.eigenstates.«perl.join(',') ~ ')'
Or, if
Jon Lang wrote:
Darren Duncan wrote:
Jon Lang wrote:
Larry Wall wrote:
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does
e that $j.perl does what I'd expect of an indeterminate item,
and that the trick is in getting a perlization of the Junction itself?
If so, cool.
> So maybe $j.Str returns the
> eigenstring, while prefix:<~> autothreads. Or maybe there's a method
> named .eigenstring or som
nt by
: >>> any mere mortal any time in the next 100 years, give or take a year.
: >>> If someone does happen to be programming quantum mechanics in Perl 6,
: >>> they're probably smart enough to work around the presence of a
: >>> reserved--well, it's n
Darren Duncan wrote:
> Jon Lang wrote:
>> Larry Wall wrote:
>>> This is basically a non-problem. Junctions have one public method,
>>> .eigenstates, which is vanishingly unlikely to be used by accident by
>>> any mere mortal any time in the next 100 years, give
Jon Lang wrote:
Larry Wall wrote:
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be programming quantum
Larry Wall wrote:
> This is basically a non-problem. Junctions have one public method,
> .eigenstates, which is vanishingly unlikely to be used by accident by
> any mere mortal any time in the next 100 years, give or take a year.
> If someone does happen to be programming quantum
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be programming quantum mechanics in Perl 6,
they're pro
Larry Wall wrote:
> Sigh. The current design of Junctions is quite extensible *because*
> it is based on a real type. You can easily write operators that
> work only on Junctions, just as you can easily write operators that
> are transparent to Junctions or autothread on Junctions
Sigh. The current design of Junctions is quite extensible *because*
it is based on a real type. You can easily write operators that
work only on Junctions, just as you can easily write operators that
are transparent to Junctions or autothread on Junctions by declaring
their arguments to take
at a solution tot he problem was to add
a "grep" meta-operator that would enable an operator-based collapse of
junctions. My suggested syntax from that thread was:
my @values = 0..21 |==| $junc_value;
Or
my @values = Int |==| $junc_value;
The idea was to match the range against the (po
On Sun, Mar 15, 2009 at 07:26:00PM +0100, Jonathan Worthington wrote:
> You can detect junctions by smart-matching against the Junction type
> (e.g. $sum ~~ Junction).
>
> my @s=1|11,2,3,4,5,6;
> loop {
>my $sum = [+] @s.pick(3);
>say $sum ~~ Junction ?? $sum.eigenstates.min !! $sum;
> }
This isn't the first (or second, or third, or fourth...) time that
I've seen complications arise with regard to junctions. Every time,
the confusion arises when some variation of the question "is it a
junction?" is raised. Ultimately, this is because Perl is trying it&
Jonathan Worthington wrote:
Richard Hainsworth wrote:
Eg.
$ perl6
> my @s=1|11,2,3,4,5,6;my @x; loop {...@x=@s.pick(3);([+]
@x).eigenstates.min.say}
8
6
Method 'eigenstates' not found for invocant of class 'Integer'
>
You can detect junctions by smart-matching against the Junction type
(e.
isnt
4:> my @x = 1,2,3,4; ([+] @a).eigenstates.min.say; # Method
'eigenstates' not found for invocant of class 'Integer'
But suppose I dont know until runtime whether @x contains a junction
or not, eg.,
my @s = 1|11,2,3,4,5,6,7; # as in the value of an ace in 21
my @x;
lo
,2,3,4; ([+] @a).eigenstates.min.say; # Method
'eigenstates' not found for invocant of class 'Integer'
But suppose I dont know until runtime whether @x contains a junction or
not, eg.,
my @s = 1|11,2,3,4,5,6,7; # as in the value of an ace in 21
my @x;
loop {
@x = @s.pick(
On Thu, Feb 12, 2009 at 06:37:26AM -0800, dev.null.box wrote:
: Hi...
:
: I´m used to test oneliners on the perl6 irc channel when i´m at
: home... But, at work, latetly i´m having lots of free time (this week
: has been sooo boring).
:
: But, i have irc blocked at my office (and yes, i´ve tried
.nl/, which is a web-based irc for #perl6.
however, it looks like that's not working right now. maybe some
volunteer feather admin can have a look and see what's broken or
missing, and get it going again, so you can join in the fun.
~jerry
Hi...
I´m used to test oneliners on the perl6 irc channel when i´m at
home... But, at work, latetly i´m having lots of free time (this week
has been sooo boring).
But, i have irc blocked at my office (and yes, i´ve tried alternative
ports for irc on freenode)... so, i wonder, is there is a websit
Can I make a suggestion? From my point of view, it'd be nice if the
trim method supported:
- left/right (leftmost/rightmost part of the string; language-independent)
- start/end (start and end of string; could be leading/trailing instead)
- both
How would that work?
eady have the ability to do that in function calls. I'd like to
see exactly the same semantics apply when assigning (or binding) to a
signature. So I don't regard it as magic, just a fundamental feature of
the language.
my :(*...@a, *%b) = 1, 2, 3, b => 4;
@a and %b have to be slurpy so that you don't get a signature
mismatch. There's also the matter of how a signature with an invocant
would handle the assignment:
my :($a: *...@b, *%c) = 1, 2, 3, b => 4;
Either $a == 1 and @b == (2, 3) or $a
Daniel Ruoso wrote:
Hmm... I think that takes the discussion to another level, and the
question is:
"what does a capture returns when coerced to a context it doesn't
provide a value for?"
I'd like to take one step further, and ask what it is that introduced
capture semantics in the first pl
TSa wrote:
> Jon Lang wrote:
>> item($x) # Dwimmey use of item context.
>
> IIRC this is the same as $$x, right? Or does that
> extract the invocant slot without dwimmery?
Umm... good question. This is a rather nasty paradox: on the one
hand, we want to be able to stac
On Tuesday, 6. January 2009 22:01:36 Jon Lang wrote:
> item($x) # Dwimmey use of item context.
IIRC this is the same as $$x, right? Or does that
extract the invocant slot without dwimmery?
> list($x) # Dwimmey use of list context.
> hash($x) # Dwimmey use of hash context.
>
o named args,
> return an array
> d) if several named args, but no positional args,
> return a hash
> e) if no args at all, return undefined Object
> f) return itself otherwise
> 2) in list context, without positional arguments
> a) if one or more named argume
named argument, return it as a pair
c) if several positional args, but no named args,
return an array
d) if several named args, but no positional args,
return a hash
e) if no args at all, return undefined Object
f) return itself otherwise
2) in list context, without posit
%b = sub s2 { return a => 1, b => 2 }
my %c = sub s3 { return 'a', 1, 'b', 2, a => 1, b => 2 }
my %d = sub s4 { return 1 }
my %e = sub s5 { return 'a', 1, 'b', 2 }
my %f = sub s6 { return 1: }
my %g = sub s7 { return }
Should @a == (), or should @a == ( a => 1 )? Or maybe even @a == ( 'a', 1 )?
Likewise with @b and @f.
Should %e == {} or { a => 1, b => 2 }?
--
Jonathan "Dataweaver" Lang
Em Seg, 2009-01-05 às 20:32 +0100, Moritz Lenz escreveu:
> Daniel Ruoso wrote:
> > would force item context in the capture, and here is the problem, as a
> > capture in item context was supposed to return the invocant.
> Maybe we could have a different rule for captures in scalar contexts
> that do
there are times when the difference
between an item and a one-item list is fuzzy. We _could_ kludge it by
saying that when a sub returns an item $x, it gets returned as a
capture object ($invocant := $x: $param1 := $x) or some such; but this
_is_ a kludge, which has the potential for unexpect
Daniel Ruoso wrote:
> Hi,
>
> As smop and mildew now support ControlExceptionReturn (see
> v6/mildew/t/return_function.t), an important question raised:
>
> sub plural { return 1,2 }
> sub singular { return 1 }
> my @a = plural();
> my $b = plural();
> my @c = singular();
> my $d = singular
On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote:
> Just stumbled across this, but I can't tell from S09 if this is a bug or
> feature:
>
> $ ./perl6 -e 'my %foo; if %foo {}; say %foo.perl'
> {"a" => undef}
It's a bug. In order to simp
On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote:
: Just stumbled across this, but I can't tell from S09 if this is a bug or
feature:
:
: $ ./perl6 -e 'my %foo; if %foo {}; say %foo.perl'
: {"a" => undef}
Definitely bug. Rvalues aren't supposed to autovivify.
Larry
Just stumbled across this, but I can't tell from S09 if this is a bug or
feature:
$ ./perl6 -e 'my %foo; if %foo {}; say %foo.perl'
{"a" => undef}
I wasn't expecting auto-vivification there. The examples in S09 use HoH
instead of a flat hash:
e spec, so that a
capture in item context return the first positional argument if there is
only one positional argument or a list coerced to item of all the named
arguments. This would mean that $b in the above code would contain [1,2]
while $d would contain simply 1.
It's important to realize t
r 1 .. $x {
> match here
> if ($x-1) % $n == 0 {
> do substitution
> }
> }
>
> (CC'ing p6l, since it defines language semantics, albeit just a bit)
The problem with this reasoning is that :nth doesn't have to be an
integer -- S05 also allows things li
On Sun Dec 07 07:24:07 2008, masak wrote:
> The .subst method in Rakudo r33599 can understand :x()...
>
> $ perl6 -e 'say "foo1foo2foo3foo4".subst("foo", "bar", :x(2))' # yes
> bar1bar2foo3foo4
>
> ...and :nth()...
>
> $ perl6 -e 'say "foo1foo2foo3foo4".subst("foo", "bar", :nth(2))' # yes
> foo1
gt; is $f2(:a), "Bool", "in '\$f2(:a)', ':a' is a named";
>
> However, S02 says that C<:a> corresponds to C<< a => 1 >> in
> fatarrow notation, which seems to argue that C<:a> should in
> fact have an Int value.
>
> Are the tests correct here, or am I reading too much into
> the synopsis description?
Most likely the tests are wrong.
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
':a' is a named";
However, S02 says that C<:a> corresponds to C<< a => 1 >> in
fatarrow notation, which seems to argue that C<:a> should in
fact have an Int value.
Are the tests correct here, or am I reading too much into
the synopsis description?
Pm
te list hold every method name that matches, or does
it do simpler parameter matching based on number of arguments,
required named arguments, etc.?
There is hopefully a complete specification what constitutes
applicability. There can hardly be differing simpler versions.
In other words there is
1 - 100 of 312 matches
Mail list logo
