Re: Multimethod Dispatch
At 9:27 PM -0400 9/4/02, Ken Fox wrote: >Dan Sugalski wrote: >>At 9:10 AM -0400 9/4/02, [EMAIL PROTECTED] wrote: >>>So, just to clarify, does that mean that multi-dispatch is (by definition) >>>a run-time thing, and overloading is (by def) a compile time thing? >> >>No. They can be both compile time things or runtime things, >>depending on the characteristics of the language. > >I don't think so. Those terms are well understood by the OO community. >Bertrand Meyer wrote on the subject: >http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf Yeah, but what he wrote was "don't do that, in any of its forms." While an interesting argument, it's a touch late for perl. >Prior to C++ there might have been some ambiguity (for example, some >people have talked about run-time vs compile-time overloading), but >C++ has completely stolen the term. Here's a slide from one of Damian's >presentations that states multi-methods are "Like C++ overloading, >but polymorphic." >http://www.csse.monash.edu.au/~damian/TPC/1999/MultipleDispatch/Presentation/sld010.htm Hrm. I generally use "overloading" in the "operator overloading" sense, which is where the confusion comes in, I expect. Operator overloading can be a compile or runtime thing, depending on your preferences. Figuring out what function/method to call based on parameters and return types can also be a runtime or compile time thing, once again depending on preferences. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: First crack at Builtins.p6m
Brent Dax wrote:
> Aaron Sherman:
> sub abs($num is int){ return $num>=0 ?? $num :: -$num }
> ^
> I believe that should be (int $num).
and there is a »abs« in core.ops.
Anyway, before implementing a bunch of builtins, it should be organized
a little, where they should finally be stored.
The current Bultins.pm is not the place for it in the long run.
Builitins implemented in perl6 could go to a hierarchy of subdirs below
P6C/Buitins.
For builtins written as .imc or .pasm I'll do some sort of #include
mechanism in imcc. If they are stored as individual files in above
hierarchy or somewhere else should be discussed too. Actually they will
be bundled to some sort of runtime lib anyways.
my 2 ¢
leo
Re: Defaulting params (reprise)
From: Trey Harris [EMAIL PROTECTED] > Properties are meant to be out-of-band information; miko's > suggestion would have this property setting the *value* of > the variable. Ah, but my exact point is that the default *isn't* set immediately. The property is held until the sub is called. If the argument is passed, the default property is ignored. If it isn't set, only then is the default property used to set the value. That's why I don't think the property makes any sense except when used to define subroutine arguments. And then Damian said: > That's why we chose them for parameter defaulting as well. Ah well. Let's see how it plays in Peoria. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Hypotheticals again
On Wed, 4 Sep 2002 17:29:27 -0400 (EDT), Trey Harris wrote: > In a message dated Wed, 4 Sep 2002, Jonathan Scott Duff writes: > > So, each time I use a hypothetical, I have to be concious of which > > variables are currently in scope? Perl can't help be with this task > > because how does it know if I meant to hypothetically clobber that > > lexical or store something in the match object. This is only really a > > problem if you expect "let" variables to always show up in the match > > object and sometimes they don't. So why not make it so that "let" > > also always causes these variables to appear in the match object? > > It should. I think everyone has been proceeding under the assumption that > they are. If you use a variable name already defined, then you set both > the match object's attribute of the same name (minus the sigil if sigil is > '$') *and* the external variable. That was certainly my assumption, and I'm fine with that. However, what if, for some reason, you don't want to set the lexical which happens to be in scope. Or if you do, but you spell it wrong? There needs to be some way of indicating whether or not the lexical gets set - that way the strict pragma (or perl6 equivalent) can catch typos. -- Peter Haworth [EMAIL PROTECTED] "To be considered half as good as Microsoft, Linux has to work twice as fast. Fortunately, this is easy."
RE: First crack at Builtins.p6m
On Thu, 2002-09-05 at 01:47, Brent Dax wrote:
> Aaron Sherman:
> # Ok, so without knowing what the XS-replacement will look like
> # and without knowing what we're doing with
> # filehandle-functions (is tell() staying or does it get
> # removed in favor of $fh.tell()) and a whole lot of other
>
> I think that sort of thing is going. IIRC, the only built-in I/O thingy
> that's staying is open().
Ok, nuking everything with a parameter type of IO::Socket, IO::DirHandle
or IO::Handle I'll probably try my hand at retooling the IO modules
once there's an XS replacement. It will be a huge job, I'm sure.
> # stuff it's impossible to translate all of the Perl 5
> # functions to Perl 6. However, what I've done is take a quick
> # stab at creating at least function signatures for everything
> # that was in perlfunc and implemented some of the functions
> # that do not require any external junk (e.g. reverse).
>
> The one thing I notice all over the place is:
>
> sub abs($num is int){ return $num>=0 ?? $num :: -$num }
> ^
> I believe that should be (int $num).
Yeah, I thoguht so. I was just uncertain and flying through these in a
semi-autistic haze :)
I'll just C<< s:w:e/(\$) is ()/$2 $1/ >>
> push @newlist, $_ if &code(); # XXX - How does code get
> $_?
>
> It should be C. A closure that receives one argument and
> doesn't have a signature gets that argument put into $_.
Ok, thanks. I knew that syntax was around, but could not find it.
RE: First crack at Builtins.p6m
On Thu, 2002-09-05 at 01:47, Brent Dax wrote:
> Aaron Sherman:
> The one thing I notice all over the place is:
>
> sub abs($num is int){ return $num>=0 ?? $num :: -$num }
Another thing I'm not sure on... how do you force numeric, but not
integer typing on a parameter? Is that C or C<+$var>? I
don't think there's anywhere that it's super-critical, but some of Perl
(e.g. bitwise operators) will want to have two signatures, one for
numbers and one for general scalars.
Re: First crack at Builtins.p6m
On Thu, 2002-09-05 at 03:18, Leopold Toetsch wrote:
> Brent Dax wrote:
>
> > Aaron Sherman:
> > sub abs($num is int){ return $num>=0 ?? $num :: -$num }
> >^
> > I believe that should be (int $num).
>
>
> and there is a »abs« in core.ops.
I'll remove that then, and replace it with an INTERNAL comment
> Anyway, before implementing a bunch of builtins, it should be organized
> a little, where they should finally be stored.
>
> The current Bultins.pm is not the place for it in the long run.
> Builitins implemented in perl6 could go to a hierarchy of subdirs below
> P6C/Buitins.
> For builtins written as .imc or .pasm I'll do some sort of #include
> mechanism in imcc. If they are stored as individual files in above
> hierarchy or somewhere else should be discussed too. Actually they will
> be bundled to some sort of runtime lib anyways.
Sounds great. I'd be happy to do this work on a branch if someone gives
me commit privs.
I'll probably compile some of this down to IMC and then hand-optimize.
Things like the list operators come most strongly to mind here.
RE: First crack at Builtins.p6m
On 5 Sep 2002, Aaron Sherman wrote:
> On Thu, 2002-09-05 at 01:47, Brent Dax wrote:
> > Aaron Sherman:
>
> > The one thing I notice all over the place is:
> >
> > sub abs($num is int){ return $num>=0 ?? $num :: -$num }
>
> Another thing I'm not sure on... how do you force numeric, but not
> integer typing on a parameter? Is that C or C<+$var>? I
> don't think there's anywhere that it's super-critical, but some of Perl
> (e.g. bitwise operators) will want to have two signatures, one for
> numbers and one for general scalars.
To take a Pascal perspective, C?
Why would bitwise have anything but integer signatures. What does
4.56 | 2.81 mean? Also, should perl lossily convert real to int, or give
an error if it can't?
Luke
RE: First crack at Builtins.p6m
In a message dated Thu, 5 Sep 2002, Luke Palmer writes:
> Why would bitwise have anything but integer signatures. What does
> 4.56 | 2.81 mean? Also, should perl lossily convert real to int, or give
> an error if it can't?
Seems to me that that's a decision that has to be made for each function.
sub needsInt (int $a) {
# Perl will throw exception if passed real
...
}
sub convertIntSilently (real $a) {
$a = int($a);
...
}
sub warnUnlessInt (real $a) {
warn Error::LossyConversion.new(target => $a, to => int)
unless $a.isa(int);
$a = int($a);
...
}
(I'm just making up that warn statement, obviously...)
Trey
RE: First crack at Builtins.p6m
(Sorry for responding to my own post, and on a tangential point at that,
but...)
In a message dated Thu, 5 Sep 2002, Trey Harris writes:
> In a message dated Thu, 5 Sep 2002, Luke Palmer writes:
> > Why would bitwise have anything but integer signatures. What does
> > 4.56 | 2.81 mean? Also, should perl lossily convert real to int, or give
> > an error if it can't?
>
> Seems to me that that's a decision that has to be made for each function.
>
> sub needsInt (int $a) {
> # Perl will throw exception if passed real
> ...
> }
Hmmm. Since we'll have subroutine overloading in Perl 6, the exception
here has the potential to be unenlightening ("sub needsInt(scalar) not
found", or some such). I've found this really annoying in Java, because
you have to know the actual signature of the method you're calling as well
as the inheritance heirarchy of the argument you're trying to pass.
This is really getting down into nitty-gritty details way too early at
this point, but I hope that we can do better than Java in error messages
for this sort of thing. (Maybe do a reverse multimethod match, if you get
my drift, to figure out what the closest signature is you *couldn't* call,
and put that in the error message: "needsInt(real) called, expecting
needsInt(int)".)
I usually feel like I'm spending most of my time converting objects from
one class to another whenever I write Java. So that might be an argument
against using specific typing in Perl 6 builtins--converting arguments for
type conformance is a very un-Perlish thing.
Trey
Re: First crack at Builtins.p6m
On Thu, Sep 05, 2002 at 09:57:07AM -0400, Aaron Sherman wrote:
> On Thu, 2002-09-05 at 03:18, Leopold Toetsch wrote:
> > Brent Dax wrote:
> >
> > > Aaron Sherman:
> > > sub abs($num is int){ return $num>=0 ?? $num :: -$num }
> > > ^
> > > I believe that should be (int $num).
> >
> >
> > and there is a »abs« in core.ops.
>
> I'll remove that then, and replace it with an INTERNAL comment
$num can be floating point too, but I think someone has covered that.
Is the internal abs smart enough to know (on a 32 bit system) what to do
with the abs of the integer -2**31 - ie:
perl -lwe 'print abs -2147483648'
2147483648
If I understand things correctly, all the parrot ops dealing in integer
registers keep the result in integer registers, floating point in floating
point registers. By default the perl6 language will carry on treating
numbers as "numbers" attempting to hide the underlying representation.
This is potentially slow, so I'd expect the perl6 interpreter/compiler to
try to find ways to generate integer or floating point bytecode whenever
it can get away with it. But it does have to be mindful of overflow.
(and tied variables, or whatever supercedes them, and %caller::MY)
Or am I mis-interpreting "INTERNAL", because in this context "INTERNAL"
refers to an op that uses PMCs already existing?
Nicholas Clark
file names
In doing the builtins, I just named the file "Builtins.p6m" without thinking. In retrospect, I think it would be nice to have a file extension *in addition to* ".pm" that is unambiguously Perl 6. "p6m" would seem obvious. This way, you can have your own module's Foo.pm and Foo.p6m side-by-side while you're transitioning, and Makefile.PL can know which one to install based on which version of Perl is executing it. This is all getting WAY ahead of the game, but I thought I'd bring it up since I just stepped in it :)
Re: First crack at Builtins.p6m
Nicholas Clark wrote: [ PerlUndef vs int vs num ] > If I understand things correctly, all the parrot ops dealing in integer > registers keep the result in integer registers, floating point in floating > point registers. By default the perl6 language will carry on treating > numbers as "numbers" attempting to hide the underlying representation. Yep, currently P6C's basic scalar type is PerlUndef, which takes just every scalar value and should do the right thing. > This is potentially slow, so I'd expect the perl6 interpreter/compiler to > try to find ways to generate integer or floating point bytecode whenever > it can get away with it. But it does have to be mindful of overflow. Actually, yesterday sitting over my first attempts of imcc:optimizer and looking at mops.p6, the main loop could be converted to native int, imcc (via life analysis) has all the info to accomplish such an optimization. new P .PerlUndef , clone P,P would go, and with iteger arithmetik this would reach exactly mops.pasm's Mops (1 instruction kills the branch reordering already accounting for 1 % ;-) > (and tied variables, or whatever supercedes them, and %caller::MY) Are there already an ideas on tied variables? But anyway, imcc would know this variable is tied, so don't otimize it to a plain int. And on the second thing, of which I don't know, what it will be able to do, but, as I can imagine a lot of code retrospection ... > Nicholas Clark leo
Re: Argument aliasing for subs
Erik Steven Harrison wrote: > Is it just me or is the 'is' property syntax a little > too intuitive? Seems like everywhere I turn, the > proposed syntax to solve a problem is to apply a > property. That's because most of the problems we're discussing are solved by changing the semantics of a variable, subroutine, or class in some way, and C properties are the way to do that in Perl 6. > And is the is/but distinction still around? Oh, yes. > Since but's proposal I've not seen any use of it, and > the distinction between a compile time and run time > property was somewhat hazy to me anyway, so I can't be > sure that it's dead or just of rare use. Of rare use (nice turn of phrase, BTW). C is about changing the way a variable or sub operates, C is about changing what a value means. We'll see much greater use of C when people start developing new algorithms and programming idioms with Perl 6. Damian
Re: Argument aliasing for subs
Erik Steven Harrison wrote:
> I know that the property syntax is pseudo established,
> but I'm beggining to become a bit jaded about all the
> built in properties were building. What about good ol'
> aliases?
>
> sub hidden (str $name, int $force := $override) {...}
I'm not keen on it because it will be hard to explain
(or detect) the difference between that and:
sub hidden (str $name, int $force //= $override) {...}
What I most like about the C syntax is (like methods in
OO Perl), it associates a meaningful *name* with each
deviation from standard behaviour.
I find:
sub hidden (str $name, int $force is aka($override)) {...}
*much* more readable, since I can read it in English.
Damian
Re: Hypothetical variables and scope
Jonathan Scott Duff wrote:
> This continues to make no sense to me. The "hypotheticality" of a
> variable seems quite orthogonal to what you do with it (bind, assign,
> whatever). Why should these two things be intimate?
Because what you do with a hypothetical has to be reversible.
And binding is far more cheaply reversible than assignment.
It's also far cheaper in the forward direction. And that's
important in pattern matching, especially as we may be to-and-fro-ing
over the hypothetical many times.
> And if they are,
> does that mean that these:
>
> / (\S*) { let $x = .pos } \s* foo /
> / (\S*) { let $x; ... $x = .pos } \s* foo /
>
> throw some sort of exception or error?
Compile-time syntax error, I'd expect.
> That could be surprising if
> the ellipses are really some long bit of code. (Why is that scalar
> different from any other scalar? Because it's hypothetical.
Yes. Because it's "reversible".
> Suddenly we've a new "class" of variable that people have to be aware of)
Yes.
Damian
Re: Request for default rule modifiers in a grammar
Ken Fox wrote: > I'm messing around with regex code generation by > converting first to a grammar. The modifiers seem > to need intimate knowledge of regex -> grammar > conversion. This may be a quirk of my approach. > People using tree traversal or generating code > directly from the regex might see something else. > I suspect modifiers will still be deeply connected > with the internals. I would imagine that modifiers would be passed some kind of hierarchical representation of the rule they're modifying (i.e. a parse tree of it), and would be expected to manipulate that structure representation. The final state of the representation would be used as the (post-modified) rule. For example, perhaps the modifier would be passed the $0 from the parser rule that parsed the rule contents. Damian
Re: regex args and interpolation
On Wed, 2002-09-04 at 22:46, Ken Fox wrote:
>rule iso_date { $year:=(\d{4}) -
>$month:=(\d{2}) -
>$day:=(\d{2}) }
You mean C<< \d<4> >>, etc. I presume.
Re: Request for default rule modifiers in a grammar
Damian Conway wrote: > I would imagine that modifiers would be passed some > kind of hierarchical representation of the rule > they're modifying (i.e. a parse tree of it), and > would be expected to manipulate that structure > representation. Excellent. Will there be an abstract syntax for tree rewriting or is it Perl 6 all the way down? This is really amazing stuff. I was expecting some support for building mini languages on top of Perl 6, but it really looks like Perl 6 is going to become the de facto language prototyping tool. (Bye bye yacc!) In many ways Perl 6 is more language neutral than Parrot. - Ken
Re: Hypothetical variables and scope
Damian Conway wrote: > Because what you do with a hypothetical has to be reversible. > And binding is far more cheaply reversible than assignment. Why not leave it in the language spec then? If it's too hard to implement, then the first release of Perl 6 can leave it out. Someday somebody might come up with an implementation. BTW, I thought the Apocalypses were moving us away from the-tarball-defines-the-language. Am I wrong to think that Perl 6 "the spec" may have more than Perl 6 "the release"? - Ken
Re: Hypothetical variables and scope
On Thu, Sep 05, 2002 at 03:38:03PM +, Damian Conway wrote: > Jonathan Scott Duff wrote: > > This continues to make no sense to me. The "hypotheticality" of a > > variable seems quite orthogonal to what you do with it (bind, assign, > > whatever). Why should these two things be intimate? > > Because what you do with a hypothetical has to be reversible. I thought it was just the hypothetical's existence that has to be reversible. > And binding is far more cheaply reversible than assignment. > It's also far cheaper in the forward direction. And that's > important in pattern matching, especially as we may be to-and-fro-ing > over the hypothetical many times. Sounds like an optimization that should be in the hands of the programmer to me. Given that we've already given the programmer the ability to put arbitrarily complex code in the pattern, I think the expense of assignment versus binding may wash out in the forward direction. And the expense in the reverse direction may be equal if it just has to destroy the variable. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Argument aliasing for subs
On Thu, 2002-09-05 at 04:31, Damian Conway wrote:
>sub hidden (str $name, int $force is aka($override)) {...}
Hang on a moment! In your original answer to this question, you used
the "is named('alias')" syntax, but now you are suggesting using the
sigil in the syntax. So, should it really be
int $force is aka($override)
or
int $force is aka('override')
?
I much prefer the latter because: a) it unquestionably marks 'override'
as a label for $force, b) the subroutine author is likely to use either
$force or $override and not both, c) it gives meaning to things like
"$force is aka(@override)" because aliases would not have to be known at
compile-time.
Then again, if you have good reasons for the other syntax, I would be
more than happy to hear those as well.
Peter Behroozi
Second try: Builtins
This is still a monolith, but it's getting better. It's now stored in
P6C/Builtins/CORE.p6m in my tree. More functions are coded, and I now
differentiate between the functions that need external support (e.g.
POSIX/libc functions) and those that just need to be written (e.g.
sort).
I think I've covered all of the comments (other than breaking up the
file and making it part of the compilation process, which I'll work on
this weekend, and then submit this as a patch to p6i).
Anyone who wants to take a crack at answering any of the questions that
I've marked with "XXX" will be much appreciated. I'm out of town for the
weekend, but will be back and catching up on mail Sunday night.
#
# The core built-ins for Perl 6.
#
# Written in 2002 by Aaron Sherman <[EMAIL PROTECTED]>
# This file can be distributed/modified under the same terms as Perl itself..
module CORE;
# So how are we doing export? I'll look up the Exegeses later
# export:
# acos alarm asin atan2 bless caller chdir chmod chomp chomp
# chomp chop chop chop chown chr chroot cos cos crypt dbmclose
# dbmopen dump endgrent endhostent endnetent endprotoent
# endpwent endservent eval exec exp fork format formline
# getgrent getgrgid getgrnam gethostbyaddr gethostbyname
# gethostent getlogin getnetbyaddr getnetbyname getnetent
# getpgrp getppid getpriority getprotobyname getprotobynumber
# getprotoent getpwent getpwnam getpwuid getservbyname
# getservbyport getservent glob gmtime grep hex index int join
# kill lc lcfirst length link local localtime log log10 lstat
# map mkdir msgctl msgget msgrcv msgsnd oct open opendir ord
# pack pipe pop pos printf prototype push quotemeta rand read
# readlink readpipe ref rename reset reverse reverse rindex
# rmdir scalar select select select semctl semget semop setgrent
# sethostent setnetent setpgrp setpriority setprotoent setpwent
# setservent shift shmctl shmget shmread shmwrite sin sleep sort
# sort sort splice split split sprintf sqrt srand stat study
# symlink syscall system tan times truncate uc ucfirst umask
# umask unlink unpack unshift untie utime utime vec wait waitpid
# warn write
# XXX - This marker is used all over to indicate potential problems and
# quesitons about how Perl 6 works.
#
# XXX High-level questions:
#
# When declaring:
# sub foo($a, $b) {...}
# and
# sub foo($a, *@rest) { ... }
# What is the correct order, and/or is this even valid? I need to know,
# given the way I did sort and reverse in order to handle exploded
# argument lists and arrays efficiently.
#
# Generally need to know how the interface ot libc will work, so
# that all of this junk can be implemented.
#
# Do I need to "@array is rw"? I would think not
#
# Need to nail down when I should not be using "*@array", e.g. return?
# Some internal only markers for various sorts of unimplemented functionality
sub UNIMP($func) { die "Unimplemented: $func" }
sub LIBC($func,*@args) { die "Unimplemented call to external code: $func" }
sub NEVER($func) { die "Obsolete in Perl 6: $func" }
# Internal/IMC
# Functions that are implemented in IMC and/or the parser directly
# INTERNAL abs
# INTERNAL defined
# INTERNAL delete
# INTERNAL die
# INTERNAL do
# INTERNAL each
# INTERNAL eval(string)
# INTERNAL exists
# INTERNAL exit
# INTERNAL goto
# INTERNAL keys
# INTERNAL last
# INTERNAL lock
# INTERNAL m
# INTERNAL my
# INTERNAL next
# INTERNAL no
# INTERNAL our
# INTERNAL package
# INTERNAL print
# INTERNAL q, qq, qw
# XXX - how do I do quote-like operators? I know I saw someone say...
# Need to do: qr (NEVER("qr")) and qx
# INTERNAL redo
# INTERNAL return
# INTERNAL s
# INTERNAL sleep
# INTERNAL sub
# INTERNAL substr
# INTERNAL time
# INTERNAL undef
# INTERNAL use
# INTERNAL values
# INTERNAL wantarray
# INTERNAL y
# Math
# Mathematical functions and functions and conversions
sub atan2(real $y, real $x) { return LIBC("atan2",$y,$x) }
sub cos(real $num //= $_) { return LIBC("cos",$num) }
sub cos(real $num //= $_) { return LIBC("cos",$num) }
sub exp(real $num //= $_) { return LIBC("exp",$num) }
sub log(real $num //= $_) { return LIBC("log",$num) }
sub sin(real $num //= $_) { return LIBC("sin",$num) }
sub sqrt(real $num //= $_) { return LIBC("sqrt",$num) }
# From perlfunc
sub acos(real $num //= $_) { atan2( sqrt(1 - ($num * $num)), $num ) }
sub tan(real $num //= $_) { return sin($num) / cos($num) }
sub log10(real $num //= $_) { return log($num)/log(10) }
sub asin(real $num //= $_) { atan2($num, sqrt(1 - $num * $num)) }
# Conversions
sub int(int $num //= $_) { $num }
sub hex($string //= $_) {
my($tmp) = ($string =~ /^[0x]?(<[a-fA-F0-9]>+)/);
return 0 unless defined($hex) && $hex.length;
my $bit = 0;
my $result = 0;
for(my $i = $tmp.length-1;$i>=0;$i--) {
my $n = substr($tmp,$i,1);
given $n {
when
