Re: A suggestion for a new closure trait.
Joe Gottman wrote: Since a FIRST block gets called at loop initialization time, it seems to me that it would be useful to have a block closure trait, RESUME, that gets called at the beginning of every loop iteration except the first. Thus, at the beginning of each loop iteration either FIRST or RESUME but not both would get called. Other possible names for this block include REENTER, SUBSEQUENT, or NOTFIRST. So RESUME would be to FIRST as NEXT is to LAST? -- Jonathan Dataweaver Lang
Re: Implicit current-index variable, scoped inside for-loops
Damian (), Ruud (), Damian (), Carl ():
But it can hardly be blamed for clarity.
That's a little unfair.
can hardly be blamed - can easily be praised g
Apologies to Carl if I misinterpreted. I read it as:
can hardly be blamed for (having) clarity
;-)
No, yours is the correct interpretation, Damian. Though my sentence is
very open to misinterpretation, as it, too, can hardly be blamed for
clarity.
Furthermore, I agree that the solution worked out by this thread is
good enough not to warrant a separate index mechanism. To me, naming
the variables $index and $value makes the meaning perfectly clear.
for @array.kv - $index, $value {...}
And if anyone still hates .kv's guts, and wants a magic index syntax,
that's probably perfect material for a Perl 6 module with some macro
goodness in it.
I gather that the below syntax should eventually work, too; right now
it doesn't in Pugs. But I guess I ought to brush up my Haskell and
contribute instead of complaining. :-)
map - $index, $value { $index, $value } == @array.kv
Scott ():
Having read this thread, I tend to think you're insane for bringing it
up again :-)
Why thank you sir. Well, one does one's best.
--
masak
Re: A suggestion for a new closure trait.
On 8/30/06, Jonathan Lang [EMAIL PROTECTED] wrote: Joe Gottman wrote: Since a FIRST block gets called at loop initialization time, it seems to me that it would be useful to have a block closure trait, RESUME, that gets called at the beginning of every loop iteration except the first. Thus, at the beginning of each loop iteration either FIRST or RESUME but not both would get called. Other possible names for this block include REENTER, SUBSEQUENT, or NOTFIRST. So RESUME would be to FIRST as NEXT is to LAST? It's like the SATs all over again... Sage
Re: return Types: what are the enforcement details?
On Tue, Aug 29, 2006 at 19:49:38 -0500, Mark Stosberg wrote:
I'm interested in helping to write some tests for return types, but
I'd like some clarifications about them first. Are they just
declarations that help Perl optimize stuff, or they actually contracts?
'of' is the contractual form, 'returns' is a constraint but it's
more like a cast.
demo:
sub foo of Array {
my %h = ( a = 1 );
return %h;
}
sub zoo returns Array {
my %h = ( a = 1 );
return %h;
}
# Hashes are happily returned, despite the Array return types.
my %b = foo(); say %b.perl;
my %c = foo(); say %c.perl;
^-- z ?
Intuitively I would say that both subroutines force the hash into an
array, at minimum, and foo might be checked more thoroughly.
In the case of foo(), foo itself might not compile, or my %b = foo()
might not compile, or both.
In the case of zoo(), i think it's just a runtime conversion to an
array. There's no reason why this conversion can't happen explicitly
as well as implicitly, like with my %h = () = %other_hash.
However, conversions that cannot be made could be cought at compile
time, emitting a warning on an error depending if the runtime is a
warning or an error.
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgprdGNAViO2E.pgp
Description: PGP signature
Re: Why does writing PMCs suck?
On Tuesday 29 August 2006 19:51, Matt Diephouse wrote: It's been said that writing PMCs sucks. This is your chance to tell the world why. Because for things to get better, we have to know what sucks. I'll get things started: 1) pmc2c.pl is very fragile - when it gets input it doesn't like, it just ignores it (see RT#39313) 2) You can't use :slurpy, :optional, or :named arguments. Even if there's support under the hood, there's no way to write a PMC with these arguments. 3) The documentation is poor. There's a lot of copy and paste coding occurring, and that leads to duplication. 4) There's a lot of required duplication. 5) The only code re-use mechanism is inheritance. Roles would be nice. -- c
Re: Implicit current-index variable, scoped inside for-loops
Damian Conway schreef:
[for @array - $index, $value {...}]
No. There's no such magic. I simply screwed up. I should have written:
for @array.kv - $index, $value {...}
:-(
Ah, much clearer now. g
--
Affijn, Ruud
Gewoon is een tijger.
Re: multi subs with identical signatures: should be a warning ?
Since nobody else has answered yet, I'll try to say something.
I'll post this also to perl6-language so that those who know better
can comment on this.
On 8/28/06, Mark Stosberg [EMAIL PROTECTED] wrote:
First, what's the recommended reference for learning how dispatching to
the right 'multi' sub is resolved. ?
http://dev.perl.org/perl6/doc/synopsis.html
S12 seems most relevant (e.g. the section Multisubs and Multimethods)
S06 might also be relevant
I'd like to know the expected behavior in this case:
multi sub foo () { say b: }
multi sub foo () { say a: }
foo();
I would expect it would throw an error or at least a warning, since
there's no clear way to choose a correct sub to dispatch to.
IMHO this is either the case where you define same sub twice, which is
an error (and so foo() would never get called) according to S06:
quote
Redefining a stub subroutine does not produce an error, but redefining
an already-defined subroutine does. If you wish to redefine a defined
sub, you must explicitly use the is instead trait.
/quote
or, if not that case, then this is defining two multi-subs which have
the same long-name. According to S12 the later multi-sub will then
hide the earlier one, and foo() would then allways call the second
multi-sub, saying a:
quote
For subs or methods declared multi, only one instance of the long name
can be in any namespace, and it hides any outer (or less-derived)
routines with the same long name.
/quote
Pugs currently dispatches to one anyway, without a warning.
If Pugs allways dispatches to the second one, then this might be the
right behaviour.
A more insidious version of the same case is the following, which
I accidentally wrote more than once already...and then wondered why
my code wasn't working as expected...
multi sub foo (%names?) { say b: }
multi sub foo (@pos?) { say a: }
There, I have distinct arguments, but they are both optional, making
them the same as the case above.
This isn't exactly the same as above. In this case the two multi-subs
just might have different long-names and so one would not hide the
another.
I'm not 100% sure about whether these have different long-name or
not as I don't know how exactly the long-name is created.
If I'm right that these do have different long-name then IMHO the
call to foo() would throw an exception because there's a tie between
two equally-good candidates for multi-dispatch and S12 says that in
such a case an exception is thrown:
quote
When you call a routine with a particular short name, if there are
multiple visible long names, they are all considered candidates. They
are sorted into an order according to how close the run-time types of
the arguments match up with the declared types of the parameters of
each candidate. The best candidate is called, unless there's a tie, in
which case the tied candidates are redispatched using any additional
tiebreaker long names (see below).
If a tie still results, only candidates marked with the default trait
are considered, and the best matching default routine is used. If
there are no default routines, or if the available defaults are also
tied, a final tie-breaking proto sub is called, if there is one (see
above). Otherwise an exception is thrown.
/quote
--
Markus Laire
Contextual::Return (was Re: could 'given' blocks have a return value?)
In a message dated Tue, 29 Aug 2006, Mark Stosberg writes:
my $rm = sub { given $rm_param {
when Code { $rm_param(self) }
when Hash { %rm_paramrun_mode }
default{ self.query.param($rm_param) }
}}();
This is eerily like Contextual::Return, which made me wonder if it's even
required in Perl 6.
Obviously we can do
return do given want {
when :($) { ... }
...
};
But return do given want flows so badly, I desperately want some sugar
for this. Is there some and I missed it?
Trey
Re: PMC Methods, Inheritance, and User-visible Classes
Matt Diephouse wrote: Joshua Juran [EMAIL PROTECTED] wrote: On Aug 28, 2006, at 12:18 PM, Matt Diephouse wrote: I would like to add some sort methods as well: quicksort(), mergesort(), etc. But as methods, there is potential for these to end up in a user-visible space. Say for example, that I add a mergesort method to AbstractPMCArray. Ruby's array class wouldn't be able to use AbstractPMCArray as a base class because there is no mergesort method on an Array in Ruby. Any thoughts? How about requiring array classes to implement swap(), and then implementing sort algorithms in terms of that, as in C++? Adding swap() would remove a level or two of indireciton, but this ignores the underlying problem of methods on PMCs leaking into user-visible spaces. Let's do what the STL does and have hundreds of parent classes that have only limited functionality in order to permit people to force themselves to recreate it. Seriously, what's so bad about adding functionality into a language? -- They who would give up an essential liberty for temporary security, deserve neither liberty or security --Benjamin Franklin
derived class generators and introspection
All, This email is part of a brain dump from my thoughts over the last week while I was away from a computer. If anything doesn't make sense, I will clarify or expand it in the following days. I believe that Perl 6 already has basically all of the necessary parts built-in for implementing a true relational database, and that any needed remainder can be added and integrated in an elegant fashion, as I will outline and/or ask about. -- At the center of this idea is the thought that the Tuple and Relation of the relational data are not each single classes, but rather are each roles / abstract interfaces that many classes can be composed of / implement. This is much the same as how I see the existing Array and Hash of Perl 6, where each is a role, and eg, that Array of Int and Array of Str are 2 different actual classes (or roles) that .does(Array); in this context, saying Array of ... is acting as a class generator which defines a new class that composes the Array role. I say that Array of Int and Array of Str are 2 different classes because the Perl 6 type system would treat each as being a repository for different sets of possible values, and would reject the assignment of one to the other. And so, a Tuple type is essentially defined using an ordinary class (or classless object type) definition that .does(Tuple) but that that it also has certain restrictions. A Tuple value is then simply an object of that class. The routines that the Tuple class provides are essentially just wrappers over certain meta-class and/or class routines, and Tuple does not add any new attributes nor hide any existing class functionality. The attributes of the Tuple and the attributes defined by the class are one and the same. The design restrictions that a Tuple doing class must obey, or appear to obey as far as its users can see, are such as these: 1. All significant attributes which together define the Tuple object's value must be public and/or have accessors with the same names as the attributes (extra implicit attributes that eg index those are not significant in this sense); an introspection method should also exist where one can inquire what the names and types of the significant attributes are; conceptually, a Tuple class is transparent. 2. The Tuple class must have a constructor that takes values for all significant attributes of the new object. Every logically distinct Capture of that constructor must produce a logically distinct new object. 3. A Tuple class needs to provide the interface details necessary that the Perl 6 type system can treat it as a value type. The === operator should return True just for 2 Tuple objects that are of the same class and where all pairs of corresponding significant attributes using === return True. Conjecture: As well, 2 Tuple objects that are of different classes, where at least one is anonymous, should compare like they were of the same class if their significant attribute definition sets are identical; this is so a system where most classes are generated from other classes DWIM correctly, like two distinct Array of Int have the same definition. 4. Conjecture: all Tuple classes should be immutable following their construction, either actually or in appearance, but this may not be essential for all uses of it. 5. Each significant Tuple attribute is mutually exclusive from all of the others, in that the interface to an attribute conceptually maps 1:1 to the attribute; reading or changing any of them does not have visible side-effects on any others. This is similar to how array or hash elements are exclusive. Now, a Relation type is one step removed; it is simply or in appearances to the user a Set of Tuple-doing-class or some-such that also .does(Relation), or perhaps alternately, a Relation type could be declared with Relation of Tuple-doing-type, which looks more natural. A Relation is a Set that is restricted to all of its members being of the same single class that is specified in the Relation type definition, and within that constraint, it is useable like any Set, and the Relation role adds several additional routines that wrap meta-class or class methods of the Set, but don't hide any existing features. Presumably any Tuple used in a Relation has to be immutable, since changing a Tuple that is a member of a Relation would have the same issues to contend with as when you change a mutable object that is used as a Hash key. Inherited from Set, a Relation class must have the necessary details that the Perl 6 type system can treat it as a value type, including that === works. It goes without saying that any attribute of a Tuple can be either a class that .does(Tuple) or that .does(Relation), as it can be any other class. Note that many of the methods which the Tuple and Relation roles provide will have the effect of generating new anonymous classes, along
Re: derived class generators and introspection
HI Darren, Generally I really like the idea of fixing the relational/OO mismatch problem by swallowing the relational model whole. :-) But I wonder if we are ready to say goodbye to the tyranny of disk seek? How will your proposed system use the disk? And if it does use the disk what about pesky problems like: indexing, locking, seek time etc? The days of limitless RAM are yet to arrive - until then databases must rely on the disk - what is the plan for storing the data? NIge In closing for now, I imagine that a lot of this stuff is connected to the meta-model, though doing it well will have clean support in the language syntax as well. Feedback is appreciated.
Re: could 'given' blocks have a return value?
Agent Zhang wrote:
According to S04, given {} is at statement level, so you can't use it
directly as an expression. But Perl 6 always allow you to say
my $foo = do given {...}
As well as
my $foo = do if foo {...} else {...}
I confirmed this both work now with pugs!
I think the 'do given' case is useful enough to document
more officially along with 'given'.
If you are thinking about the if/else case, ?? ... !! would be a
simpler way to write it.
Mark
Re: Stubborn coworkers
Jeff Stampes [EMAIL PROTECTED] writes: My bigger concern with the Perl6 syntax is that they expect humans to write it. This is a similar problem that Forth and Lisp had. You see how widely used those are now... It will always be difficult to compare Perl X against any other language. Perl5 and Perl6 look the same from a Lispish point of view. I would start with the fact that Perl5 *has* very widespread use and *is* still one of the mainstream languages. Once he accepts that fact, tell him Perl6 makes things better that are difficult in Perl5. So try to compare Perl6 with Perl5, not Perl6 with AnyOtherLanguage, because that's just the same old discussion since Perl's birthday. Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Re: PMC Methods, Inheritance, and User-visible Classes
On Wednesday 30 August 2006 04:12, Watson Ladd wrote: Seriously, what's so bad about adding functionality into a language? I once saw an overfilled waterbed that was almost as tall as I am. I would have called it PHP, but it didn't explode and throw cold water all over the house. -- c
Proposed patch
Currently compilation fails on OS X with gcc/g++, because -bundle as the first argument gets interpreted as a request to run the undle version of the compiler. It works fine as a later argument, so there's no need to break compatibility with the Apple compiler: Index: config/init/hints/darwin.pm === --- config/init/hints/darwin.pm (revision 14355) +++ config/init/hints/darwin.pm (working copy) @@ -36,7 +36,7 @@ link= 'c++', ld = 'c++', ld_share_flags = '-dynamiclib -undefined suppress', -ld_load_flags = '-bundle -undefined suppress', +ld_load_flags = '-undefined suppress -bundle', memalign= 'some_memalign', has_dynamic_linking = 1, # XXX when built against a dynamic libparrot installable_parrot records -- Mark J. Reed [EMAIL PROTECTED]
Re: Proposed patch
What version of OSX and gcc are you using? I haven't seen this problem on 10.4.7 PPC with gcc 4.0.1. Did it just break recently?? Not that I see any problem applying this patch, regardless. On Aug 30, 2006, at 4:55 PM, Mark J. Reed wrote: Currently compilation fails on OS X with gcc/g++, because -bundle as the first argument gets interpreted as a request to run the undle version of the compiler. It works fine as a later argument, so there's no need to break compatibility with the Apple compiler: Index: config/init/hints/darwin.pm === --- config/init/hints/darwin.pm (revision 14355) +++ config/init/hints/darwin.pm (working copy) @@ -36,7 +36,7 @@ link= 'c++', ld = 'c++', ld_share_flags = '-dynamiclib -undefined suppress', -ld_load_flags = '-bundle -undefined suppress', +ld_load_flags = '-undefined suppress -bundle', memalign= 'some_memalign', has_dynamic_linking = 1, # XXX when built against a dynamic libparrot installable_parrot records -- Mark J. Reed [EMAIL PROTECTED] -- Will Coke Coleda [EMAIL PROTECTED]
Re: Proposed patch
Whups, sorry, I meant to say OS X 10.3, with its gcc (3.3). I agree that it seems to build fine on Tiger. On 8/30/06, Will Coleda [EMAIL PROTECTED] wrote: What version of OSX and gcc are you using? I haven't seen this problem on 10.4.7 PPC with gcc 4.0.1. Did it just break recently?? Not that I see any problem applying this patch, regardless. On Aug 30, 2006, at 4:55 PM, Mark J. Reed wrote: Currently compilation fails on OS X with gcc/g++, because -bundle as the first argument gets interpreted as a request to run the undle version of the compiler. It works fine as a later argument, so there's no need to break compatibility with the Apple compiler: Index: config/init/hints/darwin.pm === --- config/init/hints/darwin.pm (revision 14355) +++ config/init/hints/darwin.pm (working copy) @@ -36,7 +36,7 @@ link= 'c++', ld = 'c++', ld_share_flags = '-dynamiclib -undefined suppress', -ld_load_flags = '-bundle -undefined suppress', +ld_load_flags = '-undefined suppress -bundle', memalign= 'some_memalign', has_dynamic_linking = 1, # XXX when built against a dynamic libparrot installable_parrot records -- Mark J. Reed [EMAIL PROTECTED] -- Will Coke Coleda [EMAIL PROTECTED] -- Mark J. Reed [EMAIL PROTECTED]
Help getting pugs working?
I told my coworkers I'd get pugs up and running for us, so we could start getting some hands on experience. I managed this on my home system in the past, but am completely stymied now. We're running Red Hat Enterprise 4, and I'm stuck at square one, trying to get GHC running. You need ghc working to compile ghc, or you need to bootstrap it. Reading the bootstrapping instructions, it assumes you have a system somewhere that has ghc working. That is not the case for me. The other option is to unpack existing .hc files over your source tree, but I am unable to find any. Is this really as hard as it seems to me? I used to think I was reasonably bright Thanks, ~Jeff
Re: Help getting pugs working?
Jeff Stampes [EMAIL PROTECTED] writes: We're running Red Hat Enterprise 4, and I'm stuck at square one, trying to get GHC running. You need ghc working to compile ghc, or you need to bootstrap it. Did you already try one of the binaries from http://www.haskell.org/ghc/download_ghc_641.html ? Is this really as hard as it seems to me? I used to think I was reasonably bright It should be easy, it's just the starting step that can be tricky, inherently to bootstrapping in general. But I can not really believe that RedHat doesn't have any old version of haskell available somewhere. Have a second look, try the URLs above for binaries and then it's really just a sequence of configure, make, make install (and some hours of waiting between those steps). If in doubt, read http://dresden-pm.org/cgi-bin/twiki/view/PM/PugsFirstBloodEnglish#Haskell to get a general idea of the easiness, although it's not RedHat-driven. GreetinX Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Re: Help getting pugs working?
Thanks to Steffen and others who sent me some help and words of encouragement...I believe I have it working now :)
Re: Contextual::Return (was Re: could 'given' blocks have a return value?)
Trey Harris asked:
This is eerily like Contextual::Return, which made me wonder if it's
even required in Perl 6.
Obviously we can do
return do given want {
when :($) { ... }
...
};
But return do given want flows so badly, I desperately want some sugar
for this. Is there some and I missed it?
No, the sugariest you'll find at the moment is probably:
return want.rw ?? $lvalue
:: want.count == 2 ?? (7,11)
:: want.item ?? 42
:: want.list ?? 1..10
::die Bad context;
but that still doesn't have the Awesome Power of C::R. ;-)
The simple answer is that C::R is probably the first module I will port to
Perl 6 (since it's the module I find myself using the most nowadays). The Perl
6 version will be cleaner and more efficient that the Perl 5 version, since
I'll be able to take advantage of macros.
Damian
Re: derived class generators and introspection
On Wed, 30 Aug 2006, Nigel Hamilton wrote: HI Darren, Generally I really like the idea of fixing the relational/OO mismatch problem by swallowing the relational model whole. :-) But I wonder if we are ready to say goodbye to the tyranny of disk seek? How will your proposed system use the disk? And if it does use the disk what about pesky problems like: indexing, locking, seek time etc? The days of limitless RAM are yet to arrive - until then databases must rely on the disk - what is the plan for storing the data? NIge While it is true that the broader design I am addressing should do away with any relational/OO impedence mismatch, since a complete relational model would by definition handle data types of arbitrary complexity (unlike many of today's pseudo-RDBMS products), I am certainly not proposing doing away with the disk. Rather, the proposal is focusing on what users of these data structures would / could see. The idea is that relational structures have the same ease of use and flexability that things like hashes or arrays or sequences or sets do now. They can of course just be stored in RAM like the aforementioned, when the working set of data is appropriately small, but just as a hash-doing class can have a disk-tied implementation as well, for scalability and/or persistence so can a relation-doing class. And this is one main reason why Relation etc is a role rather than a class, so people can choose how it works. -- Darren Duncan
RE: Stubborn coworkers
My bigger concern with the Perl6 syntax is that they expect humans to write it. This is a similar problem that Forth and Lisp had. You see how widely used those are now... ... How would you respond? I would expose and challenge the presumptions in the statement. My bigger concern... Do you have others? If so, what are they? If not, then what you really mean is My only concern is ... More significantly, ...they expect humans to write it. This implies that perl not only takes a little effort to learn (as does any language, or indeed, anything worth doing) but that its *extremely* difficult - well beyond the reach of most mere mortals. This is demonstrably false as perl has a very large following and most of us are common folk (Damian - you go stand over there for a minute :-) - indeed many of us are not even programmers by trade. As an aside, I believe it's an insult to those who have worked so hard on the language design, specifically $Larry - not because he did most of it but because he tries to make the language more intuitive and incrementally learnable - more or less the opposite of the accusation. Ask her to take a look at http://www.wall.org/~larry/natural.html. You don't learn a natural language even once, in the sense that you never stop learning it. Nobody has ever learned any natural language completely Others have already made the point - perl is not like most languages in that it offers many ways to do things and it's not expected that you necessarily know them all. The idea is you use the one that matches your brain or the particular problem at hand or that reflects the point you're at in learning perl. Other languages strive for one obvious way which offers the comfort of knowing your doing it the right way at the expense of being able to choose a more specific way that better matches you, the problem, the time frame you've got to solve it, whatever. I believe this is at the heart of you protagonists' statement. I'd suggest that statements like this reflect an anxiousness of not being capable of getting across the whole of the new language. The sad fact is that it doesn't matter. If you know a way that solves the problem in the time frame, then do that. You can learn a better way - whatever that means - next time the problem arises and you have the time to do so. This is a similar problem that Forth and Lisp had. How so? Are they multi-paradigmatic leading to a large and rich selection of syntax and approaches to choose from? Or do they try to shoe-horn you into a specific approach that suited some users/problems but is unsuitable to many? You see how widely used those are now... In certain problem domains each remains the language of choice. They weren't aiming to solve as broad a range of problems as perl does so one shouldn't expect them to have as high a profile. In fact, it's harder to think of better examples of languages that cannot be compared with perl. So, whatever problems they arguably have, I wouldn't expect to see those problems in perl - or at least, not necessarily. The other more simple point to make is to ask her - How much programming/experimenting with perl6 have you done? Can I have look at the results? If the answer is not much then the obvious question arises - then how do you know its going to be so hard to write? Perhaps the above is a little harsh (and unnecessarily long) but its how I'd tackle it. Martin
Re: Stubborn coworkers
Thank you Martin, and everyone else. We've had several other conversations, and I believe this boils down to just a natural pessimist. She wants to see perl continue to be a widely adopted successful language, and while she is willing to do whatever work it takes to learn, she doesn't have similar faith in the rest of the world. It's just her nature, and I should ignore it. (Can we let Damian out of the corner yet? :) -- NEVER swerve to hit a lawyer riding a bicycle -- it might be your bicycle.
Re: PMC Methods, Inheritance, and User-visible Classes
On 8/30/06, chromatic [EMAIL PROTECTED] wrote: On Wednesday 30 August 2006 04:12, Watson Ladd wrote: Seriously, what's so bad about adding functionality into a language? I once saw an overfilled waterbed that was almost as tall as I am. I would have called it PHP, but it didn't explode and throw cold water all over the house. Tons of people use PHP. Why? Because it gets the job done, and it has tons of functionality. The problem with PHP is not that it has too much functionality, but that it is organized extremely poorly. Luke
Re: PMC Methods, Inheritance, and User-visible Classes
On 8/30/06, Luke Palmer [EMAIL PROTECTED] wrote: The problem with PHP is not that it has too much functionality, but that it is organized extremely poorly. Amen. PHP is the poster child for namespace pollution. And PHP5 actually has the tools to stop the madness; it's just a question of backward compatibility. I also really hate the HTML-multivalued-input-names-have-[] hack. And I'm not fond of the arrays are just hashes with numeric keys philosophy (which it shares with JavaScript). But other than that, I love PHP. ;-) -- Mark J. Reed [EMAIL PROTECTED]
Re: PMC Methods, Inheritance, and User-visible Classes
On 8/31/06, Mark J. Reed [EMAIL PROTECTED] wrote: On 8/30/06, Luke Palmer [EMAIL PROTECTED] wrote: The problem with PHP is not that it has too much functionality, but that it is organized extremely poorly. Amen. PHP is the poster child for namespace pollution. And PHP5 actually has the tools to stop the madness; it's just a question of backward compatibility. I also really hate the HTML-multivalued-input-names-have-[] hack. My personal gripe is the bizarre way PHP handles scope--what with its hardcoded superglobals, globals, locals, so far so good I suppose, and then... shadowing all the globals when inside a function? Too weird. And I'm not fond of the arrays are just hashes with numeric keys philosophy (which it shares with JavaScript). That I don't mind so much--from a utility point of view, PHP's unified arrays/hashes are great, almost like a swiss army knife of data structures. But other than that, I love PHP. ;-) -- Mark J. Reed [EMAIL PROTECTED]
Re: derived class generators and introspection
At 5:31 AM +0100 8/31/06, Nigel Hamilton wrote: Rather, the proposal is focusing on what users of these data structures would / could see. The idea is that relational structures have the same ease of use and flexability that things like hashes or arrays or sequences or sets do now. They can of course just be stored in RAM like the aforementioned, when the working set of data is appropriately small, but just as a hash-doing class can have a disk-tied implementation as well, for scalability and/or persistence so can a relation-doing class. And this is one main reason why Relation etc is a role rather than a class, so people can choose how it works. OK. I can see that a tied-relation could help solve the talking to disk problem. But I wonder about some of the other RBMS things on offer - locking, indices etc? Some of these features are there to assist with getting data efficiently to and from the disk. Although they are not artefacts of the relational model they are important parts of what makes a database work. Could your relational model be tied to an existing physical database? NIge Yes it could. First of all, note in my explanation that I mentioned indices already, as examples of non significant (non value affecting) extra data that an object could hold or be tied to; these can be stored on disk and/or in memory as is appropriate. Next, the Software Transactional Memory concepts / interfaces in Perl 6, such as the concept of atomic code blocks or routines, would be mapped to ACID features of a disk store; the start of an atomic operation is like a start transaction and the successful completion of one is a commit; a retry or fail involves a rollback etc. Note that a proper system will need to (or will ideally) support nested transactions, so any given atomic block won't have to know whether it is inside another one or not to be itself atomic. As for locks, the Perl 6 interface / functionality for managing shared data between multiple threads or processes would map to appropriate locks or other mechanisms on disk where applicable. Truly, a database was never supposed to be a world separate from an application; as I recall, Cobol or something introduced the idea of databases and applications being at arms length, and it stuck, but that isn't the way things should be; how they should be is integrated, or at least to the point that a generic reusable module within an application is integrated; eg, DBM or BDB; also, the concept of servers is orthogonal to this; anything can be relegated to a server. Using the DBM analogy, what I propose is that the relational analogy of an in-memory Hash is built-in to Perl, and any extensions that make it tied to something external like a disk be language extensions / CPAN modules; all Perl 6 iteself has to do is make it easy to attach such extensions, and I think it more or less does so, save edge cases to hash out. -- Darren Duncan
