Re: Multimethod/multisub thought...
--- Piers Cawley [EMAIL PROTECTED] wrote:
In my quest to eliminate as many explicit conditionals from my code
as
possible, I found myself wondering if Perl 6's multidispatch
mechanism
would allow one to write:
sub gmttime ( $time = time() ) is in_scalar_context {
strftime( $perls_default_time_format, $time );
}
sub gmttime ( $time = time() ) is in_list_context {
...
}
where 'in_scalar_context' and 'in_list_context' are place holders for
better syntax.
Thoughts?
I think that if RFC 21 is approved (general-purpose Cwant(), with
smartmatch flavors) the information to dispatch these should be
available.
OTOH, it also seems like this is asking for trouble, MMD-wise.
=Austin
Re: Array/Colon question
On Thursday, January 23, 2003, at 02:24 PM, Brent Dax wrote: I suspect that the prototype for '..' is like this: So the 'step' use of colon may _only_ be used in conjunction with a ranged list, e.g. C.., correct? In _any_ other context, it means something else. In looking at A3, I also can't seem to find anything definitive on the allowed operands to C..: specifically, if they can be anything but literals, or integers. Would all of the following therefore be syntax errors? @a : 2 1 .. $a 1 .. $a : 2 $a .. $b $a .. $b : 2 $a .. $b : $c 1 .. 10 : $c 2.5 .. 10.0 : 0.5 MikeL
Re: Multimethod/multisub thought...
At 7:30 AM + 1/24/03, Piers Cawley wrote: In my quest to eliminate as many explicit conditionals from my code as possible, I found myself wondering if Perl 6's multidispatch mechanism would allow one to write: Okay, I think I remembered the problem. Assume the following: list bar(int); # bar takes an int, returns a list scalar bar(int); # bar takes an int, returns a scalar and also assume the following: xyzzy(scalar); # xyzzy takes a scalar xyzzy(list); # xyzzy takes a list and then we make the call: xyzzy(bar(1)); Which bar do we call? And which xyzzy? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Array/Colon question
Michael Lazzaro:
# On Thursday, January 23, 2003, at 02:24 PM, Brent Dax wrote:
# I suspect that the prototype for '..' is like this:
#
# So the 'step' use of colon may _only_ be used in conjunction with a
# ranged list, e.g. C.., correct? In _any_ other context, it means
# something else.
In *all* contexts, it's a supercomma. C.. interprets whatever comes
after the supercomma as being a step.
# In looking at A3, I also can't seem to find anything
# definitive on the
# allowed operands to C..: specifically, if they can be anything but
# literals, or integers.
They can be variables in Perl 5, so I suspect Perl 6 is fine with it
too.
# Would all of the following therefore be syntax errors?
#
# @a : 2
This isn't a syntax error, but it doesn't do what you want.
# 1 .. $a
# 1 .. $a : 2
# $a .. $b
# $a .. $b : 2
# $a .. $b : $c
# 1 .. 10 : $c
# 2.5 .. 10.0 : 0.5
To my knowledge, these are all fine.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Re: Multimethod/multisub thought...
--- Dan Sugalski [EMAIL PROTECTED] wrote: At 7:30 AM + 1/24/03, Piers Cawley wrote: In my quest to eliminate as many explicit conditionals from my code as possible, I found myself wondering if Perl 6's multidispatch mechanism would allow one to write: Okay, I think I remembered the problem. Assume the following: list bar(int); # bar takes an int, returns a list scalar bar(int); # bar takes an int, returns a scalar and also assume the following: xyzzy(scalar); # xyzzy takes a scalar xyzzy(list); # xyzzy takes a list and then we make the call: xyzzy(bar(1)); Which bar do we call? And which xyzzy? In theory, if there's a return type expected, we could use that as the final arbiter. If not, but if it looks like a scalar ... xyzzy(bar 1); # Scalar xyzzy(bar(1)); # Scalar xyzzy(bar((1))); # List? xyzzy(bar(list(1))); #List xyzzy(bar(scalar(1))); # Scalar Optionally, we whinge about ambiguous method invocation at line ... and punt; requiring the user to cast or establish context. Welcome to namespace hell. Woo-hoo! It's just like the C++, only with one more dimension to consider. =Austin
RE: Multimethod/multisub thought...
Dan Sugalski:
# At 7:30 AM + 1/24/03, Piers Cawley wrote:
# In my quest to eliminate as many explicit conditionals from
# my code as
# possible, I found myself wondering if Perl 6's multidispatch
# mechanism
# would allow one to write:
#
# Okay, I think I remembered the problem. Assume the following:
#
# list bar(int); # bar takes an int, returns a list
# scalar bar(int); # bar takes an int, returns a scalar
#
# and also assume the following:
#
# xyzzy(scalar); # xyzzy takes a scalar
# xyzzy(list); # xyzzy takes a list
#
# and then we make the call:
#
# xyzzy(bar(1));
#
# Which bar do we call? And which xyzzy?
This is also a problem with using want().
If we don't provide wants_scalar/wants_list, someone will build it with
want(), so we might as well try to address it. I suggest that want()
return a special value when the calling context is ambiguous, and any
wants_scalar/wants_list property be designed to accommodate this
(probably by specifying which one should be the default).
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Re: Multimethod/multisub thought...
On Fri, Jan 24, 2003 at 10:02:13AM -0800, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 7:30 AM + 1/24/03, Piers Cawley wrote: In my quest to eliminate as many explicit conditionals from my code as possible, I found myself wondering if Perl 6's multidispatch mechanism would allow one to write: Okay, I think I remembered the problem. Assume the following: list bar(int); # bar takes an int, returns a list scalar bar(int); # bar takes an int, returns a scalar and also assume the following: xyzzy(scalar); # xyzzy takes a scalar xyzzy(list); # xyzzy takes a list and then we make the call: xyzzy(bar(1)); Which bar do we call? And which xyzzy? In theory, if there's a return type expected, we could use that as the final arbiter. If not, but if it looks like a scalar ... xyzzy(bar 1); # Scalar xyzzy(bar(1)); # Scalar xyzzy(bar((1))); # List? xyzzy(bar(list(1))); #List xyzzy(bar(scalar(1))); # Scalar Strange. I think parameters to subroutines are in list context unless stated otherwise. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Arc: An Unfinished Dialect of Lisp
On Wed, Jan 22, 2003 at 10:16:50AM +, Andy Wardley wrote: On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote: I'm not a Lisp enthusiast, by and large, but I think he makes some interesting observations on language design. Take a look if you're feeling adventurous... I can't help feeling slightly deflated. Given the chance to re-design Lisp from scratch, the tasks on the top of my TODO list to address would be: * getting rid of some/all those damn parenthesis * renaming cons/car/cdr to something meaningful Alas, these are about the only parts he's not changing. He promises that Arc will have a syntax one day, but there isn't one yet. These slides are over a year old. There hasn't been much of Arc since Paul Graham's early musings on it. But one of the things he did do was rename lambda to fn. This is proof that the holy grails can be tossed out of the window. The problem with cons/car/cdr is that they're fundemental operations. Graham *has* learned from perl, and is receptive to the idea that fundemental operators should be huffman encoded (lambda - fn). It would be easy to simply rename car/cdr to first/rest, but that loses the huffman nature of car/cdr. Austin mentioned that the syntax has eliminated the need for some of the parens, so that's a start. Perhaps a real syntax can follow. :-) The other comments that caught my eye were that Arc is designed for Good Programmers[tm] and that it was particularly targetted at developing web applications. Alas, my experience seems to suggest that most of the people writing web applications are monkeys who would rather have something designed for Bad Programmers, like PHP. Good Programmers [tm] has been a theme of Graham's work. Figure that less than 10% of programmers make this cut. Lisp hackers like to assert that good programmers eventually migrate to Lisp or something lisp-like (er, functional). Count up all of the Lisp/Scheme/ML/Haskell programmers you know relative to the total number of programmers, and that's the percentage of web programmers he's targeting. The fact that a good many web programmers want ASP/PHP doesn't really have an impact on what he's trying to do. A bigger problem is that employers demand large numbers of these folks to do the job that someone Good [tm] could do in a day. Alone. While reading email. Z.
RE: Multimethod/multisub thought... [x-adr]
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] Okay, I think I remembered the problem. Assume the following: list bar(int); # bar takes an int, returns a list scalar bar(int); # bar takes an int, returns a scalar and also assume the following: xyzzy(scalar); # xyzzy takes a scalar xyzzy(list); # xyzzy takes a list and then we make the call: xyzzy(bar(1)); Which bar do we call? And which xyzzy? So the question is: if the calling context is ambiguous, do we dispatch to the implementation matching: 1) first valid signature w/ warning 2) most valid signature w/ warning 3) default calling context w/ warning 4) exception when ambiguous I'd take what's behind door number 1... Brent Dax wrote: This is also a problem with using want(). If we don't provide wants_scalar/wants_list, someone will build it with want(), so we might as well try to address it. I suggest that want() return a special value when the calling context is ambiguous, and any wants_scalar/ wants_list property be designed to accommodate this (probably by specifying which one should be the default). Where special value is a junction: 'scalar' | 'list'? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: Multimethod/multisub thought... [x-adr]
Garrett Goebel:
# Brent Dax wrote:
#
# This is also a problem with using want().
#
# If we don't provide wants_scalar/wants_list, someone will
# build it with want(), so we might as well try to address
# it. I suggest that want() return a special value when
# the calling context is ambiguous, and any wants_scalar/
# wants_list property be designed to accommodate this
# (probably by specifying which one should be the default).
#
# Where special value is a junction: 'scalar' | 'list'?
Actually, I was thinking Cundef, though a junction of all the possible
contexts might be good too. Remember, want() is more than just
scalar/array now.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Re: Multimethod/multisub thought...
At 10:02 AM -0800 1/24/03, Austin Hastings wrote: --- Dan Sugalski [EMAIL PROTECTED] wrote: At 7:30 AM + 1/24/03, Piers Cawley wrote: In my quest to eliminate as many explicit conditionals from my code as possible, I found myself wondering if Perl 6's multidispatch mechanism would allow one to write: Okay, I think I remembered the problem. Assume the following: list bar(int); # bar takes an int, returns a list scalar bar(int); # bar takes an int, returns a scalar and also assume the following: xyzzy(scalar); # xyzzy takes a scalar xyzzy(list); # xyzzy takes a list and then we make the call: xyzzy(bar(1)); Which bar do we call? And which xyzzy? In theory, if there's a return type expected, we could use that as the final arbiter. If not, but if it looks like a scalar ... xyzzy(bar 1); # Scalar xyzzy(bar(1)); # Scalar xyzzy(bar((1))); # List? xyzzy(bar(list(1))); #List xyzzy(bar(scalar(1))); # Scalar There's also the fun of: Dog bar(int); Cat bar(int); and xyzzy(Dog); xyzzy(Cat); with the call of: xyzzy(bar(1)); Just one of the many brain-benders that I'm glad Larry has to deal with, not me. (Though this may be one of the reasons A6 is taking so long...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Multimethod/multisub thought...
On Fri, Jan 24, 2003 at 10:15:48AM -0800, Brent Dax wrote: Dan Sugalski: # Okay, I think I remembered the problem. Assume the following: # # list bar(int); # bar takes an int, returns a list # scalar bar(int); # bar takes an int, returns a scalar # # and also assume the following: # # xyzzy(scalar); # xyzzy takes a scalar # xyzzy(list); # xyzzy takes a list # # and then we make the call: # # xyzzy(bar(1)); # # Which bar do we call? And which xyzzy? This is also a problem with using want(). If we don't provide wants_scalar/wants_list, someone will build it with want(), so we might as well try to address it. I suggest that want() return a special value when the calling context is ambiguous, and any wants_scalar/wants_list property be designed to accommodate this (probably by specifying which one should be the default). What? A junction of all the possible contexts valid here? ducks Nicholas Clark
RE: Multimethod/multisub thought...
From: Brent Dax [mailto:[EMAIL PROTECTED]] Garrett Goebel: # Brent Dax wrote: # # This is also a problem with using want(). # # If we don't provide wants_scalar/wants_list, someone will # build it with want(), so we might as well try to address # it. I suggest that want() return a special value when # the calling context is ambiguous, and any wants_scalar/ # wants_list property be designed to accommodate this # (probably by specifying which one should be the default). # # Where special value is a junction: 'scalar' | 'list'? Actually, I was thinking Cundef, though a junction of all the possible contexts might be good too. Remember, want() is more than just scalar/array now. sure, sure... I was ambiguously referring back to Dan's example, were xyzzy(scalar) and xyzzy(list) were the only valid options. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: Multimethod/multisub thought...
Garrett Goebel:
# From: Brent Dax [mailto:[EMAIL PROTECTED]]
# Actually, I was thinking Cundef, though a junction of all
# the possible contexts might be good too. Remember, want()
# is more than just scalar/array now.
#
# sure, sure...
#
# I was ambiguously referring back to Dan's example, were
# xyzzy(scalar) and
# xyzzy(list) were the only valid options.
Ah. Then yes, that would be fine.
I suggest that we might require a special property to say dispatch on
return value, which would give us a place to put in some information to
resolve conflicts.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Re: Multimethod/multisub thought...
Dan Sugalski wrote: There's also the fun of: Dog bar(int); Cat bar(int); and xyzzy(Dog); xyzzy(Cat); with the call of: xyzzy(bar(1)); Just one of the many brain-benders that I'm glad Larry has to deal with, not me. (Though this may be one of the reasons A6 is taking so long...) -- Ada handles this kind of problem. This is what used to be called operator overloading, before the phrase was coopted by C++ (before C++ came along, the limited version of operator overloading used in C++ was called *operand* overloading, since you're only allowed to overload based on operand types). To disambiguate a call in the presence of full operator overloading, two full complete passes over the expression tree are required. The first pass is a bottom-up pass to collect all the potential return types; the second is a top-down pass that uses the context to eliminate some (hopefully all but one) of the available return types computed in the first pass. In Ada, if the second pass doesn't completely disambiguate the expression, it's considered an error. I studied this stuff for my masters thesis, for which I added (Ada style) operator overloading to a Modula-2 compiler. When it was all over, I decided that I much prefer (C++ style) operand overloading. The computation to decide what the programmer meant is too complicated. For the user, not the compiler. Although the compiler can do it [the code is bulky, but not difficult to understand], I think that the programmer will be left in the dust. And I think that's a bad thing. In all but the simplest cases, the coder will have a very difficult time figuring out what the compiler's actually going to do. As a matter of fact, I always thought that Cwantarray was a nice compromise: let the programmer decide exactly what to do in the small number of cases where it's really useful. So here's *my* vote against return-type multi-method disambiguation. =thom Don't use that word [fantastic] to a lawyer; straining at gnats and swallowing camels is a required course in law school -- _Stranger_in_a_Strange_Land_
Re: Arc: An Unfinished Dialect of Lisp
The problem with cons/car/cdr is that they're fundemental operations. Graham *has* learned from perl, and is receptive to the idea that fundemental operators should be huffman encoded (lambda - fn). It would be easy to simply rename car/cdr to first/rest, but that loses the huffman nature of car/cdr. hmm...ML uses hd and tl. I believe that is pretty coded :)
Re: Arc: An Unfinished Dialect of Lisp
On Fri, Jan 24, 2003 at 01:00:26PM -0500, Tanton Gibbs wrote: The problem with cons/car/cdr is that they're fundemental operations. Graham *has* learned from perl, and is receptive to the idea that fundemental operators should be huffman encoded (lambda - fn). It would be easy to simply rename car/cdr to first/rest, but that loses the huffman nature of car/cdr. hmm...ML uses hd and tl. I believe that is pretty coded :) Good point. I've used Scheme and Lisp, but not ML... Z.
RE: Multimethod/multisub thought...
--- Brent Dax [EMAIL PROTECTED] wrote:
I suggest that we might require a special property to say dispatch
on return value, which would give us a place to put in some
information to resolve conflicts.
In keeping with the notion of a language for good programmers, I
think that the very act of defining two methods which are equivalent in
all but name is pretty much a deliberate statement of intent to
dispatch on return value.
Perhaps an is ambiguous keyword to stuff the warning which we should,
in all fairness, emit for those who didn't actually mean what they
typed.
In the event that two modules export functions that collide, the
warning should prompt the user to add:
Dog bar($p is int) is ambiguous is default;
==
10 minutes and a visit to RFC-land later, I have some guy named after a
70's comedian writing:
http://dev.perl.org/rfc/256.html#Handling_dispatch_failure
However, experience indicates that sometimes the more specialized
variants of a multimethod are only provided as optimizations, and a
more general variant (in this case, the (Peg,Hole) variant) would
suffice as a default where such an ambiguity exists. It is proposed
that an additional parameterized attribute -- :default(ambiguous) -- be
provided so that one particular multimethod can be nominated as the
dispatch recipient in cases of ambiguity:
sub put_peg(Peg,Hole) : multi default(ambiguous) {
print some kinda peg in some kinda hole\n
}
Now, whenever a call to put_peg can't be dispatched because it's
ambiguous, this default variant will be called, rather than throwing an
exception.
==
Man, it gripes my wagger when he gets there first... :-/
Where two xyzzy functions could invoke different bar functions, the
list of bar() multis to invoke is as above, and the dispatch distance
is 1 in each case.
So either there is a Cbar(?) is default(ambiguous) or there's an
exception.
Look, the water still beads!
=Austin
Re: Array/Colon question
On Friday, January 24, 2003, at 10:10 AM, Brent Dax wrote: # 1 .. $a # 1 .. $a : 2 # $a .. $b # $a .. $b : 2 # $a .. $b : $c # 1 .. 10 : $c # 2.5 .. 10.0 : 0.5 To my knowledge, these are all fine. Thanks, you're right. I was confusing the 'lazy' discussion with the 'range' discussion. All of those should work. As should $a .. Inf but not Inf .. $a :-) MikeL
Re: Arc: An Unfinished Dialect of Lisp
Adam Turoff [EMAIL PROTECTED] writes: On Wed, Jan 22, 2003 at 10:16:50AM +, Andy Wardley wrote: On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote: I'm not a Lisp enthusiast, by and large, but I think he makes some interesting observations on language design. Take a look if you're feeling adventurous... I can't help feeling slightly deflated. Given the chance to re-design Lisp from scratch, the tasks on the top of my TODO list to address would be: * getting rid of some/all those damn parenthesis * renaming cons/car/cdr to something meaningful Alas, these are about the only parts he's not changing. He promises that Arc will have a syntax one day, but there isn't one yet. These slides are over a year old. There hasn't been much of Arc since Paul Graham's early musings on it. But one of the things he did do was rename lambda to fn. This is proof that the holy grails can be tossed out of the window. The problem with cons/car/cdr is that they're fundemental operations. Graham *has* learned from perl, and is receptive to the idea that fundemental operators should be huffman encoded (lambda - fn). It would be easy to simply rename car/cdr to first/rest, but that loses the huffman nature of car/cdr. ISTR that he was also a fan on the 'composibility' of car and cdr, giving operators like (caar list), which means (car (car list)). I can see where he's coming from, but I can also see that those tricks could also be dismissed as clever dickery.
AW: Multimethod/multisub thought...
Strange. I think parameters to subroutines are in list context unless stated otherwise. -Scott I agree. Do we miss something ? Murat
