Re: New specdoc available
HaloO,
John M. Dlugosz wrote:
I posted my current work at
http://www.dlugosz.com/files/specdoc.pdf
Please look.
In 24.28.1 abs you define
our ::?CLASS multi method abs ( $x: )
I would rather nail down the return type to 'Num where {$_ = 0}'.
The latter might also get a nice name, e.g. Abs. This in turn would
make the abs multi method/sub kind of redundant.
I guess that the standard set of functions/methods mustn't contain
a norm as extension to the above.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: New specdoc available
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
In 24.28.1 abs you define
our ::?CLASS multi method abs ( $x: )
I would rather nail down the return type to 'Num where {$_ = 0}'.
The latter might also get a nice name, e.g. Abs. This in turn would
make the abs multi method/sub kind of redundant.
I guess that the standard set of functions/methods mustn't contain
a norm as extension to the above.
I think I listed a single method of this class because it was mentioned
in the synopses somewhere. That is, just gathering what is already
stated, not fleshing it out yet.
Shouldn't abs return the same kind of class it was run on? That is, Int
in this case, not Num. Should it be generic and simply work for all
types that have the +/- concept? Count on member dot syntax deferring
to sub calls to still allow $x.abs instead of abs($x) to work.
my Int $y = $x.abs;# should be Int without complaint, not
# coersion of Num back to Int.
For factoring out such things, we need to better define the interfaces
that will be used for generic code. For example, we can have
ispositive/isnegative tests without full ordering, and perhaps generic
code that called .isnegative would be more efficient than comparing 0
especially when you need to remember to turn 0 into the correct type.
--John
Re: New specdoc available
John M. Dlugosz wrote:
Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote:
John M. Dlugosz wrote:
I posted my current work at
http://www.dlugosz.com/files/specdoc.pdf
and .odt.
3.1.1 Normalization uses a constant without a sigil - is that really
allowed?
Yes, it's in the Synopses.
3.1.2 BOM - can you detect UTF-32 U+FEFF painlessly? If so, you could
allow that
3.1.3 The =encoding is used only for POD in perl 5. And if you force it
to be on the first line, you forbid #!/usr/bin/perl lines. What about
'use encoding('ISO-8859-1');' instead? Any other thoughts?
No problem if it can read that 'use' line in the first place.
Does a BOM also interfere with #!/usr/bin/perl ?
Sadly, yes.
I used vim with
:set nobinary fileencoding=utf-8 bomb
:w
./foo.pl
bash: ./foo.pl: cannot execute binary file
moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
signature.asc
Description: OpenPGP digital signature
Re: New specdoc available
nice work, I think this kind of redrafting can be a good foundation for refactoring ... though I would go further and suggest an xml based format ... if u have a .odt you can convert this to docbook ;) one nit pick; drop 'rigorous' in title Jim Fuller
