Re: Smooth numeric upgrades?
From: Bob Rogers <[EMAIL PROTECTED]> Date: Sat, 4 Oct 2008 22:08:10 -0400 From: "Patrick R. Michaud" <[EMAIL PROTECTED]> Date: Sat, 4 Oct 2008 18:15:57 -0500 . . . All of the mechanisms I've been able to find in Parrot for converting an arbitrary PMC to a number seem to result in the code for infix:<*> that we have now. I'm open for suggestions to improve this, though. Pm Hmm. My instinct would be to rely on MMD . . . This exposes an MMD bug (it runs forever) . . . Wrong; Parrot was replacing my Integer with the FixedPMCArray. (Grr.) Here is an improvement: .sub 'infix:*' :multi(Perl6Array,_) .param pmc a .param pmc b $I0 = a $P0 = new 'Integer' $P0 = $I0 .return 'infix:*'($P0, b) .end .sub 'infix:*' :multi(_,Perl6Array) .param pmc a .param pmc b $I0 = b $P0 = new 'Integer' $P0 = $I0 .return 'infix:*'(a, $P0) .end It works for some cases: [EMAIL PROTECTED]> ../../perl6 -e 'my @a = ; say @a * 483648;' 1450944 [EMAIL PROTECTED]> ../../perl6 -e 'my @a = ; say 483648 * @a;' 1450944 [EMAIL PROTECTED]> ../../perl6 -e 'my @a = ; say 483648 * 483648 * @a;' 701746163712 [EMAIL PROTECTED]> ../../perl6 -e 'my @a = ; say 483648 * 483648 * 483648 * @a;' 339398128586981376 [EMAIL PROTECTED]> But not others: [EMAIL PROTECTED]> ../../perl6 -e 'my @a = ; say @a * 2147483648;' -6442450944 [EMAIL PROTECTED]> ../../perl6 -e 'my @a = ; say 2147483648 * @a;' get_bignum() not implemented in class 'Float' current instr.: 'infix:*' pc 16030 (src/gen_builtins.pir:10014) . . . -- Bob
Re: Smooth numeric upgrades?
From: "Patrick R. Michaud" <[EMAIL PROTECTED]> Date: Sat, 4 Oct 2008 18:15:57 -0500 One of the big problems with Parrot's n_* opcodes is that they often assume that the type of the result should be the same as the type of the first operand . . . I kinda thought it wouldn't be that easy. Sigh. All of the mechanisms I've been able to find in Parrot for converting an arbitrary PMC to a number seem to result in the code for infix:<*> that we have now. I'm open for suggestions to improve this, though. Pm Hmm. My instinct would be to rely on MMD: .sub 'infix:*' :multi(Perl6Array,_) .param pmc a .param pmc b $P0 = new 'Integer' $P0 = a .return 'infix:*'($P0, b) .end .sub 'infix:*' :multi(_,Perl6Array) .param pmc a .param pmc b $P0 = new 'Integer' $P0 = b .return 'infix:*'(a, $P0) .end This exposes an MMD bug (it runs forever), but something like this should work once it's fixed. -- Bob
Re: Smooth numeric upgrades?
From: "Patrick R. Michaud" <[EMAIL PROTECTED]> Date: Sat, 4 Oct 2008 09:41:22 -0500 On Fri, Oct 03, 2008 at 09:47:38PM -0700, Larry Wall wrote: > On Fri, Oct 03, 2008 at 11:57:30PM -0400, Michael G Schwern wrote: > : What's the status of numeric upgrades in Perl 6? Is see the > : docs say "Perl 6 intrinsically supports big integers and rationals > : through its system of type declarations. Int automatically > : supports promotion to arbitrary precision" but it looks like it's > : doing the same thing as Perl 5. > > The status of numeric upgrades in Perl 6 is fine. It's rakudo that > doesn't do so well. :) Correct. I suspect that eventually the Rakudo developers will have to develop a custom set of PMCs for Perl 6 behaviors rather than relying on the Parrot ones. The Parrot behavior in this case may be closer than you think. After applying the patch below, I get the expected output from Rakudo: [EMAIL PROTECTED]> ./perl6 -e 'say 2**40' 1099511627776 [EMAIL PROTECTED]> ./perl6 -e 'say 2**50' 1125899906842624 [EMAIL PROTECTED]> ./perl6 -e 'say 2**1100' 13582985290493858492773514283592667786034938469317445497485196697278130927542418487205392083207560592298578262953847383475038725543234929971155548342800628721885763499406390331782864144164680730766837160526223176512798435772129956553355286032203080380775759732320198985094884004069116123084147875437183658467465148948790552744165376 [EMAIL PROTECTED]> It does produces >300 spectest_regression failures, though, so I don't claim the patch is right. Parrot doesn't currently downgrade BigInt PMCs to Integer when it should, though. -- Bob Rogers http://rgrjr.dyndns.org/ Make and DTRT for Int => BigInt promotion. May break other numeric behaviors. Index: languages/perl6/src/builtins/op.pir === --- languages/perl6/src/builtins/op.pir (revision 31592) +++ languages/perl6/src/builtins/op.pir (working copy) @@ -59,21 +59,12 @@ ## exponentiation .sub 'infix:**' :multi(_,_) -.param num base -.param num exp -$N0 = pow base, exp -.return ($N0) +.param pmc base +.param pmc exp +$P0 = n_pow base, exp +.return ($P0) .end - -.sub 'infix:**' :multi(Integer,Integer) -.param num base -.param num exp -$N0 = pow base, exp -.return '!upgrade_to_num_if_needed'($N0) -.end - - ## symbolic unary .sub 'prefix:!' :multi(_) .param pmc a @@ -140,21 +131,13 @@ ## multiplicative .sub 'infix:*' :multi(_,_) -.param num a -.param num b -$N0 = a * b -.return ($N0) +.param pmc a +.param pmc b +$P0 = n_mul a, b +.return ($P0) .end -.sub 'infix:*' :multi(Integer,Integer) -.param num a -.param num b -$N0 = a * b -.return '!upgrade_to_num_if_needed'($N0) -.end - - .sub 'infix:/' :multi(_,_) .param num a .param num b
Parrot 0.7.0 "Severe Macaw"
On behalf of the Parrot team, I'm proud to announce Parrot 0.7.0 "Severe
Macaw." Parrot (http://parrotcode.org/) is a virtual machine aimed at
running all dynamic languages.
Parrot 0.7.0 is available via CPAN (soon), or follow the download
instructions at http://parrotcode.org/source.html. For those who would
like to develop on Parrot, or help develop Parrot itself, we recommend
using Subversion on the source code repository to get the latest and
best Parrot code.
Parrot 0.7.0 Highlights:
* The new concurrency implementation makes its debut in 0.7.0. See
http://www.parrotcode.org/docs/pdd/pdd25_concurrency.html for more.
* Rakudo (Perl 6) now supports class attributes and multiple dispatch,
plus some metaclass support, among others.
Parrot 0.7.0 News:
- Specification
+ PDD27: add multisub lookup
- Implementation
+ new concurrency implementation (see PDD25)
+ Exception PMC now captures a return continuation
+ improved PMC encapsulation (Iterator, Key, Pair)
- Languages
+ Cardinal (Ruby):
- class variables
- parsing improvements
- minor additions to class builtins
- add support for block parameters to functions
+ Lua:
- various language fixes
- refactor all libraries (namespace, method registration)
- add a OpenGL binding (still incomplete)
- lost user back trace (see ppd25 & pushaction)
+ Pipp (PHP):
- add support for while- and for-loops
- add support for increment and decrement
- designate PHP 5.3 as the reference implementation
- improve support for string literals
+ Pugs (Perl 6):
- removed due to bit rot
+ Rakudo (Perl 6):
- now over 2200 passing spectests
- updated the Rakudo roadmap
- Perl 6 multi dispatch
- dispatch with slurpies
- class attributes ("my $.x")
- anonymous classes
- OO and metaclass improvements (.WHAT, .WHICH, .WHENCE)
- additional builtin methods and subs
- improved make test targets and harness
+ Tcl:
- implement [lreverse], [lsort -command]
- allow [incr] to autovivify
- update tclsh spec target to 8.5.3
- fix bug in TclDict PMC, allowing ~200 more [dict] spec tests to pass
- update 'make spectest' fudging, using TODO instead of SKIP if possible
- Compilers
+ PCT:
- :scope('register') for PAST::Var nodes
- allow invocant specification in attribute scope PAST::Var nodes
- correct ordering of sub generation from POST
- add 'loadinit' attribute to PAST::Block for block initialization
+ PIRC:
- PIR registers now use the vanilla register allocator
- all PASM output now uses PASM registers
- all .locals and $registers are mapped
- clean-up of grammar, back-end and documentation
- implemented constant folding
- implemented instruction selection
- Configuration
+ tests now clean up after themselves
+ improved parallel test support
+ ports/cygwin added
+ Darwin problems fixed
- Tools
+ parrot_debugger renamed from pdb, numerous tweaks
- Miscellaneous
+ IMCC cleanups
+ :vtable implies self in PIR
+ modest core speed improvements
+ Cygwin support improved
+ "say" now an opcode (was dispatched to a method; see Deprecations)
- Deprecations
+ ".pragma n_operators" is deprecated
+ old PASM register syntax (without "$") is deprecated
+ bare (unquoted) method names are deprecated
+ "#line" will be replaced with ".line"
+ ".HLL_map" syntax will change
+ ".loadlib" is now separate from ".HLL"
+ mmdvtregister and mmdvtablefind opcodes are deprecated
+ removed getfd, getclass opcodes
+ removed IMCC syntax that treated some methods as builtins
+ removed numeric get_attr and set_attr vtable entries
Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 16 Sep 2008.
Enjoy!
-- Bob Rogers
http://rgrjr.dyndns.org/
Re: Allowing '-' in identifiers: what's the motivation?
From: TSa <[EMAIL PROTECTED]>
Date: Tue, 12 Aug 2008 09:25:27 +0200
. . .
What's so different in $foo-bar versus $foo*bar, $foo+bar or
$foo/bar? The latter might e.g. indicate path variables.
FWIW, one sees "hyphen substitution" like this only very rarely in
Common Lisp code, despite the fact that programmers have unbelievable
freedom to use arbitrary characters in identifiers, even parens (with
quoting). There are a few visual conventions that use characters you
won't see in Java, such as "*foo*" for a global, "+foo+" for a global
constant, "%foo" or ".foo." for something internal, etc. But if the
name is long enough to require several words, people almost invariably
use "-" internally, because out of all this variety (surprise) it's
still easiest to type.
So IMHO it would be a shame to support the extra complexity in order
to provide a freedom that is used so rarely that it mostly just trips
people up. (That's an argument against "$foo*bar" et. al., but I admit
it tends to support "$foo-bar". Unless we all switch to Emacs. ;-)
Or imagine a coding convention where junctive variables bear their
generating operator: $foo|bar, $foo&bar and $foo^bar.
That gives these variables names that add no information, which sounds
like a bad idea. I have sometimes seen similar code, e.g.
(defun solve-quadratic (a b c)
(let ((sqrt[b^2-4*a*c] (sqrt (- (* b b) (* 4 a c
(2*a (* 2 a)))
(values (/ (+ (- b) sqrt[b^2-4*a*c]) 2*a)
(/ (- (- b) sqrt[b^2-4*a*c]) 2*a
Every token that is not "(" or ")" or whitespace is a valid CL
identifier. But in this case, "sqrt[b^2-4*a*c]" is better called
"sqrt-discriminant" anyway.
-- Bob
Re: Allowing '-' in identifiers: what's the motivation?
From: Austin Hastings <[EMAIL PROTECTED]> Date: Mon, 11 Aug 2008 10:02:06 -0500 That sounds cool. Did you do it at the editor level, or at the keyboard level? =Austin In Emacs; see rgr-c-electric-dash-mode in [1], or other similar solutions in [2]. That way, I can turn it on for C and Perl (among others), and off for Lisp and text. Of course, that's just the tip of the iceberg, but this is OT, so I'll keep the Emacs evangelism off-list. ;-} -- Bob [1] https://rgrjr.dyndns.org/svn/rgr-hacks/trunk/rgr-c-hacks.el [2] E.g. http://www.emacswiki.org/cgi-bin/wiki/ElectricDotAndDash, http://svn.clouder.jp/repos/public/yaml-mode/trunk/yaml-mode.el
Re: Allowing '-' in identifiers: what's the motivation?
From: "Mark J. Reed" <[EMAIL PROTECTED]> Date: Mon, 11 Aug 2008 09:07:33 -0400 I'm still somewhat ambivalent about this, myself. My previous experience with hyphens in identifiers is chiefly in languages that don't generally have algebraic expressions, e.g. LISP, XML, so it will take some getting used to in Perl . . . Amen. I've long since reprogrammed "-" to give "_" if pressed once and "-" if pressed twice, when editing languages with C-like identifiers. So from my perspective, the added visual complexity is not worth it. -- Bob Rogers http://rgrjr.dyndns.org/
RE: [svn:parrot] r28689 - trunk/languages/perl6/t ("-" versus "_")
From: Conrad Schneiker <[EMAIL PROTECTED]> Date: Wed, 2 Jul 2008 12:25:58 -0700 Moritz Lenz wrote (on perl6-compiler) > Patrick R. Michaud wrote: > > but I > > suspect people have good reasons for preferring underscores. One reason (probably not a good one) is to use the same convention as programming language variable names (which is typically more of a "CamelCase" versus "not_Camel_case" issue). A better reason for preferring hyphens is that they do not require shifting, and are therefore easier on the pinkies. -- Bob
Re: Chained Comparisons ?
From: "Patrick R. Michaud" <[EMAIL PROTECTED]> Date: Thu, 17 Apr 2008 07:22:20 -0500 On Wed, Apr 16, 2008 at 11:19:33PM -0400, Bob Rogers wrote: > . . . but IIUC "and" is not short-circuiting. "and" is short-circuiting. Aha. I was misled by the presence of "andthen", and was too sure of my interpretation to look them up. Thanks, and sorry for the noise. -- Bob
Re: Chained Comparisons ?
From: "Brandon S. Allbery KF8NH" <[EMAIL PROTECTED]>
Date: Wed, 16 Apr 2008 09:39:52 -0400
. . .
Yes, they use multiple-typed values such that (3 < 5) returns (5 but
True), which used in a numeric context is a 5 that can be chained
with further infix:{'<'}s but in a boolean context is True.
Pardon a lurker, but I'm not sure I understand the point of this. In:
if $x < $y < $z { ... }
I would expect a sensible compiler short-circuit the "$x < $y" part, and
indeed the "Chained comparisons" section of S03 (version 135) says
A chain of comparisons short-circuits if the first comparison
fails . . .
But the definition of chaining associativity under "Operator precedence"
says this is equivalent to:
if ($x < $y) and ($y < $z) { ... }
(modulo multiple evaluation), but IIUC "and" is not short-circuiting.
Which is intended? I am hoping the "Operator precedence" definition
should be "andthen"; I would find non-short-circuiting behavior rather
surprising.
Assuming that the intent is for short-circuiting, the compiler
*can't* in general produce code that invokes subsequent chained ops, as
that would require evaluating subsequent arguments. So when would these
"Num but True" values ever be needed?
And wouldn't it also be helpful to implement chaining in such a way
that a specialized chained op implementation couldn't mess it up by
returning plain True?
My apologies if this is spelled out somewhere; I couldn't find
anything about this application of multiple-typing in S03.
-- Bob Rogers
http://rgrjr.dyndns.org/
Symbolic references and OUTER
From: "John M. Dlugosz" <[EMAIL PROTECTED]> Date: 11 Apr 2008 20:12:41 - . . . What happens? The OUTER scope no longer exists at CALL 3. Does a symbolic reference to OUTER require that the entire scope be retained, just in case? If "OUTER" itself (or OUTER::OUTER::...) is symbolic, it would need to remember everything always, just in case. I would assume so. This is no different than the "lexical-then-dynamic" rule for "goto", which always requires metadata for each label to identify them to dynamic callers. But, in both cases, it ought to be possible to do this using static metadata, incurring no runtime penalty. Yet in CALL 1, the use of OUTER makes sense, and is a normal use. This situation should be allowed, or you'll have a hard time describing exactly when OUTER may be used symbolically, since the simple description now is that all blocks are closures, but most can be optomized down. Agreed. Now look at CALL 2. The situation is similar in that the outer scope still exists, but it is much harder for OUTER to figure out where to look. Does this work? If not, again, its hard to explain just when it should or shouldn't, because cases that do are just automatic degenerate forms of "every block is a closure". --John I don't see that this is any harder; unless I'm misunderstanding you, this is just another normal closure usage case. The OUTER scope is always the one defined by outersub, no matter how many calls back in the dynamic chain it might be. -- Bob Rogers http://rgrjr.dyndns.org/
Re: Nomenclature Question - BEGIN etc.
From: Larry Wall <[EMAIL PROTECTED]> Date: Thu, 10 Apr 2008 14:00:53 -0700 On Thu, Apr 10, 2008 at 03:41:19PM -0500, John M. Dlugosz wrote: > >> Well, lessee. The Common Lisp spec calls them "situations" in the > definition of (eval-when)... That's not bad. FWIW, eval-when only does BEGIN and INIT; CATCH, LEAVE, etc. are handled by other special forms. Other languages call them "ON" blocks and such. AFAIR, only languages that use "ON" as the keyword to introduce them. > OK, so people already want to say "The BEGIN block". So the set of > them are "The XXX blocks" where XXX is the collective name for > those keywords . . . Not sure I like the stage/phase/chapter metaphor, really. Too static. On the other hand, situation seems to convey more ad hoc-ness than strictly necessary. . . . Larry How about "daemon blocks"? That suggests to me that they are invoked as required, and not necessarily in synchrony with their containing blocks. -- Bob Rogers http://rgrjr.dyndns.org/
non blocking pipe
From: Bob Rogers <[EMAIL PROTECTED]> Date: Sun, 23 Mar 2008 15:53:51 -0400 From: Spocchio <[EMAIL PROTECTED]> Date: Sun, 23 Mar 2008 09:10:42 -0700 (PDT) Hi, i'm writing a gui tool, I need to open a non blocking pipe in read mode, to avoid the block of the gui when the stream become slow.. Is it possible to open a non blocking pipe in read mode whitout using threads or fork()? I like simple things, i only need something return me undef is there is no input, IIUC, it's the read operation, not the open, that is nonblocking. You might want to look at IO::Select. And this is OT, since this list is for Perl 6, not Perl 5. (I had thought I was replying to something on boston-pm. ) -- Bob
non blocking pipe
From: Spocchio <[EMAIL PROTECTED]>
Date: Sun, 23 Mar 2008 09:10:42 -0700 (PDT)
Hi, i'm writing a gui tool, I need to open a non blocking pipe in read
mode, to avoid the block of the gui when the stream become slow..
Is it possible to open a non blocking pipe in read mode whitout using
threads or fork()?
I like simple things, i only need something return me undef is there
is no input,
IIUC, it's the read operation, not the open, that is nonblocking. You
might want to look at IO::Select.
-- Bob Rogers
http://rgrjr.dyndns.org/
Parrot 0.5.2 Released
On behalf of the Parrot team, I'm proud to announce Parrot 0.5.2 "P.e. nipalensis." Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.5.2 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.5.2 Highlights: * "make perl6" uses the new pbc_to_exe tool to build a Perl 6 executable. It's still a ways from being a finished implementation of Perl 6, but we're working on that. Come join us! * Parrot now has a LOLCODE implementation! Not an "enterprise-class" computing language, you say? We don't expect anyone to use it for their next app, but at less than 500 lines of source code (and most of that in a subset of Perl 6), it demonstrates the power of the Parrot Compiler Toolkit. See http://lolcode.com/news/i-haz-a-parrot for more. Parrot 0.5.2 News: - Documentation + PDD27 (multiple dispatch) - debut of new design + Numerous small updates to glossary.pod, etc - Compiler Toolkit + NQP: optional, named, and named/required parameters + PIRC: cleanups + PAST: "defined-or" - Languages + New mk_language_shell.pl script creates language stubs + LOLCODE: new + Lua: various + Eclectus: start with support for local variables and procedures, use SXML as intermediate representation + Perl 6: list builtins, compiler directives, command-line options, etc. + "make perl6" now builds a Perl 6 executable + punie: more builtins, control structures, code refactoring + pynie: builtin stubs, more tests - Implementation + New "pbc_to_exe" utility turns bytecode to executables + New set_outer method for subs + Further configuration refactoring for testability + All functions now completely headerized + Concurrency: interpreter schedulers - Deprecations + DYNSELF (changes to SELF; SELF to STATICSELF) + METHOD (replaced by renaming PCCMETHOD) + pmcinfo op (superseded by 'inspect') + get_attr, set_attr, and 8 other vtable methods + See DEPRECATED.pod for details - Miscellaneous + Many bug fixes + Minor speed enhancements with UTF-8 string handling + Debian packaging + consting, attribute marking, warnings cleanup, memory leaks plugged ... The next scheduled Parrot release will be five weeks from today, on 19 February 2008. Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy!
[svn:perl6-synopsis] r14359 - doc/trunk/design/syn
From: [EMAIL PROTECTED]
Date: Wed, 28 Mar 2007 19:28:30 -0700 (PDT)
Author: larry
Date: Wed Mar 28 19:28:28 2007
New Revision: 14359
Modified:
doc/trunk/design/syn/S09.pod
Log:
User-definable array indexing hammered out by TheDamian++ and Dataweaver++
. . .
+To declare an array of fixed size, specify its maximum number of elements
+in square brackets immediately after its name:
+
+my @dwarves[7]; # Valid indices are 0..6
+
+my @seasons[4]; # Valid indices are 0..4
Huh?? I assume you didn't mean to throw in an extra season . . .
-- Bob Rogers
http://rgrjr.dyndns.org/
Re: my $temperature is ro
From: Larry Wall <[EMAIL PROTECTED]> Date: Fri, 16 Feb 2007 12:42:27 -0800 . . . so maybe there's some general syntactic relief for rw/ro that is orthogonal to everything else. But that means it wouldn't be a trait, a type, a sigil, or a twigil, if it's really orthogonal. I don't just want to go with bare rw and ro markers because I think they're too easy to confuse. It's more like we want an initializer that says "lock this after I change it". If used on the initializer of a declaration it would have the force of a readonly declaration. Some variant on or near the =, in other words, that could also be a variant on normal assignment . . . Sounds like you want a way to specify single assignment. Maybe use ":=" or something similar to say that the assignment is really a definition. Though probably that doesn't address the "is context is rw" issue. And it's not clear to me what it would mean without something like "my" that introduces a new scope . . . -- Bob Rogers http://rgrjr.dyndns.org/
Re: Automatic coercion and context
From: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: Sat, 30 Sep 2006 17:23:54 -0500
On Sat, Sep 30, 2006 at 11:48:04AM -0700, Joshua Choi wrote:
> How does automatic coercion work?
[ deletia ]
> 1. C automatically coerces its C arguments into C
> parameters because C.
Wouldn't it be better to do the coercion explicitly? E.g.:
multi sum ( Str $addend1, Num $addend2 --> Num ) { sum 0+$addend1, $addend2 }
multi sum ( Num $addend1, Str $addend2 --> Num ) { sum $addend1, 0+$addend2 }
After all, there may be more than one way to do the coercion, especially
for something more complicated than a number.
> 2. C then automatically coerces its C arguments into
> C parameters because C.
>
> ...Or am I completely off the mark?)
I hope you're way off the mark. Automatic coercion was one of the
annoyances I remember from C++. Debugging becomes more difficult when
you have to not only chase down things that are a Foo, but anything
you've compiled that might know how to turn itself into a Foo.
I tend to agree, FWIW.
-- Bob Rogers
http://rgrjr.dyndns.org/
Re: renaming "grep" to "where"
From: [EMAIL PROTECTED] Date: Tue, 19 Sep 2006 14:26:30 -0400 As a random alternative, I note that Ruby's analog to grep is called "find_all" (though it also has a "grep" that behaves differently from Perl's). Personally, I'm not enamored of "filter" because it has connotations of removal... Hmm. Is this because Perl 5 grep can be used to modify a list in place? Does Perl 6 grep also allow that? The Lisp equivalent is remove-if-not, which otherwise seems like a perfect description of what Perl grep does. On 9/19/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: > . . . > > That said, I'm in favor of the term "filter" because, as Damian > mentioned, that term is used in several other languages. In that vein, "select" from SQL should also be mentioned. (I'm not so sure that "filter" is broadly standard, as Damian asserts, but maybe I haven't used enough languages.) -- Bob Rogers http://rgrjr.dyndns.org/
Re: MMD as an object.
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Thu, 10 Mar 2005 10:53:11 +0100
Rod Adams <[EMAIL PROTECTED]> wrote:
> It seems to me that there are several advantages to making a group of
> multi with the same short name a single object, of type
> MultiSub|MultiMethod, which internally holds references to the all the
> various routines that share that short name.
Discussion seems to have went off into esoteric cases of locally
overriden dispatcher policies and what not.
What I'd like to know is more basic things:
1) is there a MultiSub object with one short name that holds all
possible long names (and function references)?
If yes, who is creating it: the Perl6 compiler emits code to do so or
it's up to Parrot to do the right thing?
FWIW, Common Lisp specifies a "generic function" [1] that collects all
methods defined for a given operation name. (In Perl/Parrot, the
generic function name for your examples would be the string "foo"; in
Lisp, it would be the symbol "FOO" in some package, but the practical
difference should be slight.) The important thing is that the GF has
all the information required to make method dispatch decisions.
GFs can be created explicitly with defgeneric [2], or implicitly by
defining methods. According to that model, the Perl6 compiler would
emit code for each method, and ask Parrot to add it to the appropriate
MMD object, which may cause effective methods to be recomputed (or be
marked as invalid for lazy recomputation).
Mind you, I haven't read up on p6 objects, so my $0.02 might not be
worth very much. If so, please rub my nose in the relevant apocalypses,
etc., and I'll shut up. But on the other hand, the CL community has
more than 15 years of experience with MMD, so I wanted to be sure
everyone was aware of it.
2) namespaces of (multi) subs.
A non-multi method is in the classes' namespace. In Parrot terms that's
currently:
%globals{"\0class_name"}{"method_name"}
I'm not quite sure, if the method hash shouldn't live inside the class.
Is naming at this level really important here? The operation itself
needs a name (so that people can call it), and classes need class names
(maybe), but all methods are implicitly named by the combination of
operation plus argument signature. Which would seem to mean that,
unlike perl5, the package in which a multimethod is defined doesn't
matter; all that is captured by the argument signature. Or is it
possible to have more than one method with the identical signature? And
if so, what does that mean?
The "long name" is therefore a list of class names, which suggests
that the single-dispatch naming above is backwards. Of course, I'm
probably out of my depth here . . .
A multi method is similar, except that their can be more then one
with the same short name (which probably means that there has to be a
MultiSub object holding the long names)
I'm not sure it is meaningful to give a sub a "short name," certainly
not in the sense that perl5 methods can also be called as subs with the
right package qualification. You can't guarantee that they will be
unique, correct?
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{"foo"} --> MultiSub{"foo_A_B" => Sub, ...}
This sounds right to me. Or perhaps
%globals{"foo"} --> MultiSub{["foo", 'A', 'B'] => Sub, ...}
just to belabor the point a bit.
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Is this really different? After all, the operation "foo" should be just
a string in either case. Or is this just my ignorance showing?
-- Bob Rogers
http://rgrjr.dyndns.org/
[1] http://www.lispworks.com/documentation/HyperSpec/Body/t_generi.htm
[2]
http://www.lispworks.com/documentation/HyperSpec/Body/m_defgen.htm#defgeneric
