Re: roles (Was: enums and bitenums)
Paul Hodges wrote:
> Jonathan Lang <[EMAIL PROTECTED]> wrote:
> > Incidently, I think I've caught on to _one_ of the concepts in the
> > upcoming object-orientation proposal: linguistically, there's a triad
> > of "basic verbs" - namely "be", "do", and "have". If I'm following
> > things properly, one could think of an object's properties as things
> > that it has, its methods as things that it does, and its roles as
> > things that it is.
>
> Beautiful. This has a lot of potential, although some of it is
> potential to twist young minds. It makes me want to add commas
> where commas should not be.
>
> my Dog $Spot is Pet, will { Sit() }, has @.fleas;
>
> See what I mean? :op
Technically, it would be "will do { Sit() }" or "does { Sit() }" or even
"does sit()"; but yes, I can see what you mean.
> But seriously, how much of that actually is valid?I doubt @.fleas will
> fly (no pun intended, honest).
I don't see why not; must every member of an aobject be a scalar? Can't
any of them be lists or hashes?
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: roles (Was: enums and bitenums)
On Thu, 2003-12-11 at 18:15, Jonathan Lang wrote: > Based on the source material pointed to as your inspiration for roles, I'm > a little confused as to how roles and classes could be unified. From what > I read in the source material, a key point of a role (well, they weren't > actually calling it a 'role' there, but I'm not recalling the term that > they did use) is that you get to bypass the "diamond inheritence" problem > by relegating member variables to classes, so that when you use multiple > roles to construct a class you don't have to worry about deciding which > version of the variable to access in any given method. That's true, but that's incidental to the point of roles. It falls out from the important thing about roles. > Without that restraint, exactly how does a role differ from a multiple inheritence > model? Roles are a *more general* means of polymorphism and code reuse than inheritance. Inheritance is a *means* of performing a role, but it's not the only one. What's important about a role is that it marks the most important question (at least for polymorphic purposes): does this thing do what I'm about to ask it to do? It can do that role because of inheritance, but it can also do it because you've reimplemented all of the necessary methods, because you've aggregated an object that perform that role, or because you're delegating to an object that performs the role. If the only tool in your toolbox is isa(), you must either fake up some inheritance scheme or go without the three other allomorphic techniques. That's a shame. Roles exist because you can't fit all of the useful behavior in a system into a rigid class hierarchy -- some bits apply across classes -- without creating a mess. Again, inheritance is only one way a class can fulfill a role. It's not the only way and it's not necessarily the best way. See Class::Roles on the CPAN. -- c
Re: roles (Was: enums and bitenums)
--- Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Incidently, I think I've caught on to _one_ of the concepts in the
> upcoming object-orientation proposal: linguistically, there's a triad
> of "basic verbs" - namely "be", "do", and "have". If I'm following
> things properly, one could think of an object's properties as things
> that it has, its methods as things that it does, and its roles as
> things that it is.
Beautiful. This has a lot of potential, although some of it is
potential to twist young minds. It makes me want to add commas
where commas should not be.
my Dog $Spot is Pet, will { Sit() }, has @.fleas;
See what I mean? :op
But seriously, how much of that actually is valid?I doubt @.fleas will
fly (no pun intended, honest).
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: Macros, PIR, and PASM
At 06:06 PM 12/11/2003 -0500, Dan Sugalski wrote: Folks, As IMCC's in some flux and likely to get gutted and reworked, the question of macros has come up. (They cause some grammar issues) So, to make life easier: Parrot's built-in PIR and PASM parsing modules do *not* need to do macros. (Though they do need to do .const things) Macro assemblers are for people, not compilers, and as such a separate tool (which can be a loadable compiler later if someone wants) is appropriate in this circumstance. So... As long as there's a macro-assembler preprocessing program that understands the macro system and spits out macro-expanded PIR and PASM, the macro facilities built into IMCC can get tossed out. (Time for someone to write Macro-Parrot.pl, methinks) There is already a nifty macro processor in imcc.l that probably should be salvaged and possibly moved to a separate lib. -Melvin
roles (Was: enums and bitenums)
I'm invoking the principle that the only stupid question is the one not
asked:
Larry Wall wrote:
> if indeed properties can be unified with roles (and roles with
> classes).
Based on the source material pointed to as your inspiration for roles, I'm
a little confused as to how roles and classes could be unified. From what
I read in the source material, a key point of a role (well, they weren't
actually calling it a 'role' there, but I'm not recalling the term that
they did use) is that you get to bypass the "diamond inheritence" problem
by relegating member variables to classes, so that when you use multiple
roles to construct a class you don't have to worry about deciding which
version of the variable to access in any given method. Without that
restraint, exactly how does a role differ from a multiple inheritence
model?
---
Incidently, I think I've caught on to _one_ of the concepts in the
upcoming object-orientation proposal: linguistically, there's a triad of
"basic verbs" - namely "be", "do", and "have". If I'm following things
properly, one could think of an object's properties as things that it has,
its methods as things that it does, and its roles as things that it is.
So
my Dog $Spot has $spots;
would be a way to create an object inheriting from type Dog which has a
property called $.spots (is there a way to do @.spots?);
my Dog $Spot will rollover {...};
would be a way to create an object inheriting from type Dog which has a
method called rollover ("will" is used because "does" is essentially a
synonym for "will do", and "do" is a built-in method which often gets
called implicitly to represent the object's primary function); and
my Dog $Spot is pet;
would be a way to create an object inheriting from type Dog which has a
role called pet.
In a similar way, roles can specify things which must be included in order
for the role to be complete. Just like "is", "will", and "has" could be
thought of as ways of including roles, methods, and variables in an
object, "like", "must", and "needs" could be used respectively to specify
that the object must have the methods and variables in question added to
it to be considered complete. "like" probably needs some clarification,
in that saying that an object is "like" a role means that the object takes
all of that role's methods and variables as requirements (that is, it
requires methods with the same name and signature and properties with the
same name and type), in addition to whatever requirements said role
normally contributes.
Am I following?
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: enums and bitenums
On Thu, Dec 11, 2003 at 04:18:19PM -0700, Luke Palmer wrote:
: Larry Wall writes:
: > Anyway, this all implies that use of a role as a method name defaults to
: > returning whether the type in question matches the subtype. That is,
: > when you say
: >
: > $foo.true
: >
: > it's asking whether the Boolean property fulfills the true constraint.
: > When you say
: >
: > $bar.red
:
: So are you saying that, eg.
:
: class Something does Color {...}
: my Something $flib;
:
: if $flib.red { print "Flib is red" }
: if $flib.true { print "Should be an error before now" }
:
: Since Something doesn't Boolean, true would be a "method not found"
: error?
Didn't answer your question. No, because methods that happen to be
class names are special, in this worldview.
: If that's the case, how do we attach out-of-band properties on objects
: that don't expect them, but only some of them (as was the original
: intent for properties, IIRC):
:
: my role onlyonced;
: sub onlyonce($arg is rw) {
: die "onlyonce called twice on the same value" if $arg.onlyonced;
: $arg but= onlyonced;
: }
:
: Either that doesn't work at all, because you get an "onlyonced not
: found" error, or it works because onlyonced is a declared role. But
: in the latter case I worry about namespace pollution.
Okay, maybe I understand your worry now. Are you worried that
every object implicitly has boolean methods corresponding to every
class/role/property name in scope? I can see where that might
cause some heartburn.
Larry
Re: enums and bitenums
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: > Or are you worried that these have to be declared at all? I think > we need to declare them or we can't use them as bare identifiers. > There are no barewords in Perl 6, so they have to be something > predeclared, or otherwise syntactically distinguished. We could > syntactically distinguish them in the presence of C, but that > doesn't let us use them anywhere else, and it makes C into more > of a macro than an operator, which seems unclean. Letting them be > bare identifiers under the predeclared classname rule seems to be > the most appropriate way to do it, if indeed properties can be > unified with roles (and roles with classes). And I suspect they can > be unified, and ought to be unified. My goal isn't so much to make > sticky notes as hard to use as subtypes, but to make subtypes as > easy to use as sticky notes. I think it ought to be easy for any > object to pretend to be some other kind of object. Allomorphism is > not just for untyped Perl scalars. > Well, I don't entirely understand either. One thing I do understand > is that people get scared when I start thinking out loud. :-) sounds like you are working on the grand unification. does string theory have any place here? and i rarely understand your thinking until it is set in concrete and then chopped up with a jackhammer into little itty bitty pieces by damian. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: enums and bitenums
On Thu, Dec 11, 2003 at 04:18:19PM -0700, Luke Palmer wrote:
: Larry Wall writes:
: > Anyway, this all implies that use of a role as a method name defaults to
: > returning whether the type in question matches the subtype. That is,
: > when you say
: >
: > $foo.true
: >
: > it's asking whether the Boolean property fulfills the true constraint.
: > When you say
: >
: > $bar.red
:
: So are you saying that, eg.
:
: class Something does Color {...}
: my Something $flib;
:
: if $flib.red { print "Flib is red" }
: if $flib.true { print "Should be an error before now" }
:
: Since Something doesn't Boolean, true would be a "method not found"
: error?
Well, true is perhaps a bad example, since everything is boolean one
way or another. Built-in types inherit a true method that depends on the
actual value, not on a property.
: If that's the case, how do we attach out-of-band properties on objects
: that don't expect them, but only some of them (as was the original
: intent for properties, IIRC):
:
: my role onlyonced;
That might need to be "my property" to get everything defaulted for
a property kind of role. But maybe not.
: sub onlyonce($arg is rw) {
: die "onlyonce called twice on the same value" if $arg.onlyonced;
: $arg but= onlyonced;
: }
:
: Either that doesn't work at all, because you get an "onlyonced not
: found" error, or it works because onlyonced is a declared role.
I think it works because it's declared, and because you're using it
in a boolean context, so it's not really testing the value of the
property, but it's presence. The .onlyonced method merely tests
whether the object "does" onlyonced.
: But in the latter case I worry about namespace pollution.
Which namespace are you worried about polluting? It seems to me that
restricting the name to a lexical namespace and to the current object is
about as good as you can get. We're not polluting the class's namespace,
nor are we polluting the global namespace. (Though there are times where
that's the right thing to do.)
Or are you thinking that you might want to apply a property more than
once to the same object? (That would make about as much sense as
inheriting more than once directly from the same base class.)
Or are you worried that these have to be declared at all? I think we
need to declare them or we can't use them as bare identifiers. There
are no barewords in Perl 6, so they have to be something predeclared,
or otherwise syntactically distinguished. We could syntactically
distinguish them in the presence of C, but that doesn't let us
use them anywhere else, and it makes C into more of a macro than
an operator, which seems unclean. Letting them be bare identifiers
under the predeclared classname rule seems to be the most appropriate
way to do it, if indeed properties can be unified with roles (and
roles with classes). And I suspect they can be unified, and ought
to be unified. My goal isn't so much to make sticky notes as hard to
use as subtypes, but to make subtypes as easy to use as sticky notes.
I think it ought to be easy for any object to pretend to be some other
kind of object. Allomorphism is not just for untyped Perl scalars.
That being said, there has to be a little discipline to it, or we'll
find ourselves in property hell. I think roles provide a nice level
of discipline.
: It's clear that I don't entirely understand all of this yet (er, as much
: as there is to understand... yet).
Well, I don't entirely understand either. One thing I do understand
is that people get scared when I start thinking out loud. :-)
Larry
Re: Namespaces
At 12:34 PM -0500 12/11/03, Melvin Smith wrote: At 11:57 AM 12/11/2003 -0500, Dan Sugalski wrote: That does, though, argue that we need to revisit the global access opcodes. If we're going hierarchic, and we want to separate out the name from the namespace, that would seem to argue that we'd want it to look like: find_global P1, ['global', 'namespace', 'hierarchy'], "thingname" That is, split the namespace path from the name of the thing, and make the namespace path a multidimensional key. Or I suppose we could just punt and toss the special global access entirely and make the global namespace a hash 'o hashes hanging off the interpreter and access it like any other variable, but that makes local obscuration of the namespace somewhat difficult and I'd rather not for right now. This'd be the time to weigh in on it, folks... I expect we need multiple options and let compiler writers figure out which ones they need. (see **) Well... I was hoping for a single option, so that everyone interoperates properly. I *know* that folks writing perl programs are going to want to stick methods into the ruby and python packages that they import. (And the feeling, I expect, is mutual :) It won't be optimal for everyone, but the needs of the dynamic languages are pretty similar so if we can satisfy them without being particularly onerous to the rest of the languages (most of whom won't make much use of namespaces at runtime anyway) I'll be happy. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: enums and bitenums
On Thu, Dec 11, 2003 at 02:01:17PM -0800, Michael Lazzaro wrote:
: So C would be for casting, not coercion, right?
:
: Suppose you have a class Foo, such that:
:
: class Foo does (Bar, Baz) {
: ...
: }
:
: ... or however that looks. May I then presume that
:
: $foo.Bar.zap# ($foo.as(Bar)).zap)
:
: calls the method C of role C, with $foo as the invocant?
Seems like that would be the case.
Larry
Re: enums and bitenums
Larry Wall writes:
> Anyway, this all implies that use of a role as a method name defaults to
> returning whether the type in question matches the subtype. That is,
> when you say
>
> $foo.true
>
> it's asking whether the Boolean property fulfills the true constraint.
> When you say
>
> $bar.red
So are you saying that, eg.
class Something does Color {...}
my Something $flib;
if $flib.red { print "Flib is red" }
if $flib.true { print "Should be an error before now" }
Since Something doesn't Boolean, true would be a "method not found"
error?
If that's the case, how do we attach out-of-band properties on objects
that don't expect them, but only some of them (as was the original
intent for properties, IIRC):
my role onlyonced;
sub onlyonce($arg is rw) {
die "onlyonce called twice on the same value" if $arg.onlyonced;
$arg but= onlyonced;
}
Either that doesn't work at all, because you get an "onlyonced not
found" error, or it works because onlyonced is a declared role. But
in the latter case I worry about namespace pollution.
It's clear that I don't entirely understand all of this yet (er, as much
as there is to understand... yet).
Luke
Macros, PIR, and PASM
Folks, As IMCC's in some flux and likely to get gutted and reworked, the question of macros has come up. (They cause some grammar issues) So, to make life easier: Parrot's built-in PIR and PASM parsing modules do *not* need to do macros. (Though they do need to do .const things) Macro assemblers are for people, not compilers, and as such a separate tool (which can be a loadable compiler later if someone wants) is appropriate in this circumstance. So... As long as there's a macro-assembler preprocessing program that understands the macro system and spits out macro-expanded PIR and PASM, the macro facilities built into IMCC can get tossed out. (Time for someone to write Macro-Parrot.pl, methinks) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Namespaces
Gordon Henriksen <[EMAIL PROTECTED]> wrote: > Leopold Toetsch <[EMAIL PROTECTED]> wrote: >> What about: >> >> getinterp P2 >> set P1, P2['global';'namespace';'hierarchy';'thingname'] > What if global.namespace happens to be autoloaded or otherwise magic? > Will the get_keyed break down and do something equivalent to this? > getinterp P2 > set P1, P2['global';'namespace'] > set P1, P1['hierarchy';'thingname'] > Meaning the construction of an extra multikey? Yech, maybe. That's absolutely the same. Multikeys work on the nested aggregates, at least if you are considering current PerlHash implementation. But - AFAIK - nothing was said yet, how the namespace hierarchy is done internally. It could be a HoHoH or a concatenated string key of an one level flat hash - the value being the symbol name. >> Constructing a multy-key by hand isn't that simple (or would need >> hacking imcc) (and Key componenent separator is a semicolon). > -> The nameless root namespace is an easy-to-get-to parrot or > interpreter global, so there's no need to have a separate interface > to access the global namespace vs. accessing a namespace in a PMC > register. set P1, P2["the_global"] # P2 is still the interpreter So there is no special case. > (Though interp-is-a-namespace is cute. Maybe too cute, if namespaces > are subclassable.) Different interpreters (threads), different global namespaces ... > -> Namespaces have methods/ops to look up a contained symbol (just > one level), where any string is a valid symbol. (And there's the > option of not recursing into parent namespaces; i.e., looking only > at "declared" members.) Considering Melvins f'up and that, it might be better, to move that functionality into a NameSpace PMC. That can be overridden and still does the right thing for the standard case. > -> Namespaces also have methods to traverse a path of symbols That seconds above statement a lot. > get_globals Py Ah the get me a namespace PMC - yep. leo
RE: [CVS ci] object stuff
On Thu, 2003-12-11 at 12:05, Gordon Henriksen wrote: > It is truly remarkable the lengths that Perl programmers seem to be > willing go to in order to hide a function call or obscure the existence > of an object. :) Not all of the poly- and allomorphism in the world comes from "traditional" object orientation. Syntax has to be good for something! -- c
Re: enums and bitenums
On Thursday, December 11, 2003, at 10:04 AM, Larry Wall wrote:
Explicitly:
$bar.does(Color)# does $bar know how to be a Color?
$bar.as(Color) # always cast to Color
Implicitly boolean:
$bar ~~ Color # $bar.does(Color)
?$bar.Color # $bar.does(Color)
if $bar.Color # if $bar.does(Color)
Implicitly non-boolean:
+$bar.Color # +$bar.as(Color)
~$bar.Color # ~$bar.as(Color)
$($bar.Color) # $($bar.as(Color))
@($bar.Color) # @($bar.as(Color))
So C would be for casting, not coercion, right?
Suppose you have a class Foo, such that:
class Foo does (Bar, Baz) {
...
}
... or however that looks. May I then presume that
$foo.Bar.zap# ($foo.as(Bar)).zap)
calls the method C of role C, with $foo as the invocant?
MikeL
Re: More object stuff
Dan Sugalski wrote: Yep, though that's a big part of it. postgres.pasm is generated from postgres.declarations, FWIW--there's a script in the library somewhere. Is /parrot/build_tools/build_nativecall.pl the script in question and if so whats its usage. I have done postgres.declarations, please see below. I have made guesses based on /parrot/build_tools/build_nativecall.pl where I was unsure as to the type to be used. Where I was not sure of the type I have included the declaration from libpq-fe.h as a comment just above the entry in the new postgres.declarations. All new entries from the 7.4 file have been included in the file as follows New In 7.4 New function The entries appear in the order they where encountered in libpq-fe.h which differs considerably from the 7.3 version. If anyone is interested the following URL will take you to the Postgres web interface for libpq-fe.h. http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/interfaces/libpq/libpq-fe.h Revision 1.100 As for the OO wrapper. Are you after a pasm library that takes advantage of objects and hides the details of libpq-fe.h? I think I could start something if no one else has already started anything. Yep, that's what I was thinking of. If you take a look, there are parts of the interface that are somewhat awkward to use from a higher level -- the record fetching code is definitely skewed down to the bottom end of things. Certainly fine enough, but it'd be nice to be able to get back an array or hash for a record rather than having to query individual fields. :) I will probably need a bit of help with this. To coin a phrase I am still very much slipping on the parrot guts. You guys seem to be producing material at a fair pace :-) If there is already any material, docs, examples or a wrapper already written for another library please point me at it. Harry [package] PostgreSQL [lib] libpq [defs] # From libpq-fe.h Revision 1.100 p PQconnectStart t i PQconnectPoll p p PQconnectdb t p PQsetdbLogin t t t t t t t v PQfinish p p PQconndefaults v PQconninfoFree p i PQresetStart p i PQresetPoll p #extern void PQreset(PGconn *conn); # This was set to "c PQreset p" was this correct. v PQreset p i PQrequestCancel p t PQdb p t PQuser p t PQpass p t PQhost p t PQport p t PQtty p t PQoptions p i PQstatus p # New In 7.4 i PQtransactionStatus p t PQparameterStatus p t i PQprotocolVersion p # t PQerrorMessage p i PQsocket p i PQbackendPID p i PQclientEncoding p i PQsetClientEncoding p t # New In 7.4 i PQsetErrorVerbosity p i # v PQtrace p p v PQuntrace p # Need function pointers. Can't do that yet # New IN 7.4 #i PQsetNoticeReceiver p p # # i PQsetNoticeProcessor p p p PQexec p t # New In 7.4 #extern PGresult *PQexecParams(PGconn *conn, # const char *command, # int nParams, # const Oid *paramTypes, # const char *const * paramValues, # const int *paramLengths, # const int *paramFormats, # int resultFormat); p PQexecParams p t i i 3 3 i #extern PGresult *PQexecPrepared(PGconn *conn, # const char *stmtName, # int nParams, # const char *const * paramValues, # const int *paramLengths, # const int *paramFormats, # int resultFormat); p PQexecPrepared p t i t 3 3 i # i PQsendQuery p t # New In 7.4 #extern int PQsendQueryParams(PGconn *conn, # const char *command, # int nParams, # const Oid *paramTypes, # const char *const * paramValues, # const int *paramLengths, # const int *paramFormats, # int resultFormat); i PQsendQueryParams p t i i t 3 3 i #extern int PQsendQueryPrepared(PGconn *conn, # const char *stmtName, # int nParams, # const char *const * paramValues, # const int *paramLengths, # const int *paramFormats, # int resultFormat); i PQsendQueryPrepared p t i t 3 3 i # p PQgetResult p i PQisBusy p i PQconsumeInput p p PQnotifies p # New In 7.4 #extern int PQputCopyData(PGconn *conn, const char *buffer, int nbytes); i PQputCopyData p t i #extern int PQputCopyEnd(PGconn *conn, const char *errormsg); i PQputCopyEnd p t #extern int PQgetCopyData(PGconn *conn, char **buffer, int async); i PQgetCopyData p t i # i PQgetline p t i i PQputline p t i PQgetlineAsync p t i i PQputnbytes p t i i PQendc
RE: [CVS ci] object stuff
Melvin Smith <[EMAIL PROTECTED]> wrote: > my $foo = Oracle::Instance::DEV1::db_block_buffers; > > The namespace lookup in Oracle::Init checks the Oracle config > parameters which is external code. > > All sorts of neat possibilities. :) It is truly remarkable the lengths that Perl programmers seem to be willing go to in order to hide a function call or obscure the existence of an object. :) -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
RE: Namespaces
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Okay, okay, I give -- hierarchic namespaces are the way to go. Makes
> > local overrides somewhat interesting, but we'll burn that bridge
when
> > we get to it.
> >
> > find_global P1, ['global', 'namespace', 'hierarchy'], "thingname"
So (excuse the Perl 5), $::thingie would be this:
find_global P1, [], "thingie"
(Or [], "$thingie".)
Makes it odd to actually name a symbol, since it's broken in one + N.
What's the good of separating the symbol name from the namespace name?
> > That is, split the namespace path from the name of the thing, and
> > make the namespace path a multidimensional key.
> >
> > Or I suppose we could just punt and toss the special global access
> > entirely and make the global namespace a hash 'o hashes hanging off
> > the interpreter and access it like any other variable,
>
> What about:
>
> getinterp P2
> set P1, P2['global';'namespace';'hierarchy';'thingname']
>
> That is get_pmc_keyed() on a ParrotInterpreter PMC with a multi-key,
> straight-forward. The set_pmc_keyed() stores a global.
What if global.namespace happens to be autoloaded or otherwise magic?
Will the get_keyed break down and do something equivalent to this?
getinterp P2
set P1, P2['global';'namespace']
set P1, P1['hierarchy';'thingname']
Meaning the construction of an extra multikey? Yech, maybe.
> Constructing a multy-key by hand isn't that simple (or would need
> hacking imcc) (and Key componenent separator is a semicolon).
YECH.
I can see y'all are already leaning away from this direction, but I
thought
I'd still bring them up as ideas:
-> The nameless root namespace is an easy-to-get-to parrot or
interpreter global, so there's no need to have a separate interface
to access the global namespace vs. accessing a namespace in a PMC
register.
(Though interp-is-a-namespace is cute. Maybe too cute, if namespaces
are subclassable.)
-> Namespaces have methods/ops to look up a contained symbol (just
one level), where any string is a valid symbol. (And there's the
option of not recursing into parent namespaces; i.e., looking only
at "declared" members.)
-> Namespaces also have methods to traverse a path of symbols, where
all but the last symbol in the path must itself be a namespace.
Symbol paths are mangled using a DEAD SIMPLE, absolutely canonical
encoding, with debug-friendly printable ASCII escapes. e.g.:
# Example only:
# '.' is path delimiter and '%' is escape char
# Using '\' would induce LTS in IMCC & C.
foreach (@path) {
s/\%/\%\%/g;
s/\./\%\./g;
}
$path = join(".", @path);
So unless you use a '.' or '%' in your symbol, it won't be mangled
at all, and if it started out printable ASCII, it'll stay that way.
And if you do use one of those reserved characters, the mangled form
won't be too terribly surprising.
This does presume that symbols must be in a charset with '.' and
'%'. My heart bleeds for those that aren't.
Bad Thought: If the empty symbol were prohibited (or ignored) in paths,
the delimiter . could be its own escape character, e.g.:
["float";"1.0"] could be float.1..0.
While a strawman symbol path lookup could be implemented in terms of
single-level symbol lookup, smarter namespace implementations might
optimize away the array (multikey) and extra strings. And this doesn't
require any massive restructuring of IMCC or PIR. (Unless you want them
to just do the mangling internally, rather than storing that ["", "",
""]
as an array constant. But why bother? ".." is shorter than ["", "", ""],
and doesn't suggest to a compiler author's mind "keep a struct { char**;
char*; } around for each symbol reference.")
This would make Dan's example into:
find_global P1, "global.namespace.hierarchy.thingname"
shorthand for:
get_globals Py
find_sym P1, Py, "global.namespace.hierarchy.thingname"
and functionally equivalent to the wildly pedantic:
get_globals Py
find_onesym Py, Py, "global"
find_onesym Py, Py, "namespace"
find_onesym Py, Py, "hierarchy"
find_onesym P1, Py, "thingname"
Spelling aside, anyhow. (e.g., where find_onesym yada might be spelled
set yada[].)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
RE: [CVS ci] object stuff
At 03:05 PM 12/11/2003 -0500, Gordon Henriksen wrote: Melvin Smith <[EMAIL PROTECTED]> wrote: > my $foo = Oracle::Instance::DEV1::db_block_buffers; > > The namespace lookup in Oracle::Init checks the Oracle config > parameters which is external code. > > All sorts of neat possibilities. :) It is truly remarkable the lengths that Perl programmers seem to be willing go to in order to hide a function call or obscure the existence of an object. :) I'm not an advocate of the feature, but it is novel. Tying is a requirement of Perl, or so Dan has told me. Now that I think of it, I'm not sure I've seen any official requirement for tying namespaces, but it is probably orthogonal to tying classes. You might not want to take my example seriously as I'm not a Perl6 authority. -Melvin
Re: Mac OS X Dynaloading less broken
At 9:51 AM -0800 12/11/03, Jeff Clites wrote: I have some other fixes for this--I'll clean them up and send them in. I got something working which doesn't crash, and which can find libraries in standard locations w/o knowing the path. It uses the native dyld API rather than dlopen--the dlopen which shipped with Panther is just the third-party dlcompat lib which was on Fink before, I believe. So I have ncurses.pasm working, although something is amiss--it's definitely invoking ncurses (I get the green generation count on the black background), but I don't see the life animation. But I suspect that the problem there isn't related to library loading. Cool -- I'd love to put this in. It'd fix the crippled version that's in 10.3 and leave us with a common code base across all versions of OS X, which'll make debugging so much easier... On Dec 11, 2003, at 8:46 AM, Dan Sugalski wrote: If you're on OS X 10.3, I unbroke (sort of) the dynaloading code, so it now uses the platform dlopen call. This handles .dylib files like, say, libncurses.dylib. That's good. The bad news, such as it is, is: *) Still crashes. Ick. a "ulimit -c unlimited" in the terminal will generate gdb-able core files if you want them. (They go in /cores, which I recommend cleaning out occasionally) *) The dlopen routine is really primitive compared to the rest of the known unix universe. You must specify the *exact* filename of the library. No library search paths or anything like that. (I've also fixed the dynaloading code to try the exact filename, so this does work now) If anyone wants to try figuring out why ncurses.pasm fails, go for it and good lukc. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: enums and bitenums
On Thu, Dec 11, 2003 at 02:48:06PM +0100, Stéphane Payrard wrote:
: Hi,
:
: I don't remember anything about enums and bitenums in the
: apocalypses. This is probably not very difficult to roll out
: something using macros but I feel that should belong to the
: standard language.
[Warning: speculation ahead.]
I've been thinking that enums might just be subtypes of roles/properties.
After all, when you say
0 but true
it might really mean
0 but Boolean[1]
whereas
1 but false
means
1 but Boolean[0]
That is, type boolean can be thought of as enum(false,true).
So we might have a role declaration somewhere that says something like:
role *Boolean[Bit ?$val] does Property {
bit $.boolean = $val;
}
role *false does Boolean[0];
role *true does Boolean[1];
That's what the semantics might look like, but of course people would
probably want an enum or bitenum wrapper macro for real code. No reason
it couldn't be a standard macro though. Or even part of the grammar--we've
never shied away from defining one construct in terms of another for
teaching purposes. We define C in terms of C and C,
and C in terms of C. Perl 6 will do more of that, because
it makes things easy to learn.
A lot of this is negotiable, but I think it's a feature that you
can't have an enum without it being associated with a unique type
name/property. It's also appealing to me that enum "values" live
in the type namespace, since they're really subtypes (that is, types
that restrict values ranges of "real" types). There's nothing says
a subtype has to have only one value:
role Bit[Int ?$val] does Int[0|1];
Of course, I'm handwaving a lot here by using a junction. For
integer subtypes you'd typically want a range:
role Byte[Int ?$val] does Int[0..255];
That implies that the argument to Int[] has to be able to take a range.
I confess I don't know what the real declaration of "Int" looks like
yet. Certainly the first arg isn't simply an "Int". That only works
for enums. The arg has to represent some kind of generic constraint.
Pity the optimizer...
Anyway, this all implies that use of a role as a method name defaults to
returning whether the type in question matches the subtype. That is,
when you say
$foo.true
it's asking whether the Boolean property fulfills the true constraint.
When you say
$bar.red
it's asking whether the Color property fulfills the red constraint.
I suppose when you say
$baz.Byte
it's asking whether the Int property fulfills the Byte constraint, but
that's getting kind of strange.
Another implication is that, if properties are subtypes, we can't use
the same name as a cast method. Since
$baz.Byte
only returns true or false, we'd need something like (yuck)
$baz.asByte
Since class names are valid as bare names, perhaps we can improve
that to
$baz.as(Byte)
(That doesn't mean you have to write an "as" method that contains a
switch. More likely "as" is a multi method within the class of $baz.)
Another possibility is that .Byte would have to be context sensitive.
In which case we have the small problem that
if $foo.boolean { print "true" } else { print "false" }
prints "true" even if $foo is 0. You'd have to say
if +$foo.boolean { print "true" } else { print "false" }
to force a numeric context on the type. (Or use $foo.true.)
Alternately, we use the type name as a cast always, and distinguish
the boolean test:
if $baz.does(Byte) { my $byte = $baz.Byte }
I kinda like that.
Since "does" is a generalization of "isa", we probably need to generalize
smart matching to test "does" rather than "isa" for class/type names.
On the other hand, it'd be a major pain to have to write $foo.does(true).
I suppose a cast could return undef if it fails, which means that
$foo.true would return 1 or undef. Except $foo.false would return 0 or
undef. Urg.
I suspect the right solution from a linguistic point of view is to make it
context sensitive but also make it easy to disambiguate.
Explicitly:
$bar.does(Color)# does $bar know how to be a Color?
$bar.as(Color) # always cast to Color
Implicitly boolean:
$bar ~~ Color # $bar.does(Color)
?$bar.Color # $bar.does(Color)
if $bar.Color # if $bar.does(Color)
Implicitly non-boolean:
+$bar.Color # +$bar.as(Color)
~$bar.Color # ~$bar.as(Color)
$($bar.Color) # $($bar.as(Color))
@($bar.Color) # @($bar.as(Color))
Then $foo.true and $foo.false work as expected. Still have to be careful
about ?$foo.boolean though.
Interestingly, we have
$foo = $bar.Color || 0xfff;
that is equivalent to
$foo = $bar.does(Color) ?? $bar.as(Color) :: 0xfff;
which means $foo could validly end up 0. Of course, // gets there by
a different route:
$foo = $bar.Color // 0xfff;
means
$foo = defined($bar.as(Color)) ?? $bar.as(Color) :: 0xfff;
I think I'm happy with that. Maybe.
Larry
Re: Namespaces
Dan Sugalski <[EMAIL PROTECTED]> wrote: >find_global P1, ['global', 'namespace', 'hierarchy'], "thingname" > That is, split the namespace path from the name of the thing, and > make the namespace path a multidimensional key. > Or I suppose we could just punt and toss the special global access > entirely and make the global namespace a hash 'o hashes hanging off > the interpreter and access it like any other variable, What about: getinterp P2 set P1, P2['global';'namespace';'hierarchy';'thingname'] That is get_pmc_keyed() on a ParrotInterpreter PMC with a multi-key, straight-forward. The set_pmc_keyed() stores a global. Constructing a multy-key by hand isn't that simple (or would need hacking imcc) (and Key componenent separator is a semicolon). leo
Re: Mac OS X Dynaloading less broken
I have some other fixes for this--I'll clean them up and send them in. I got something working which doesn't crash, and which can find libraries in standard locations w/o knowing the path. It uses the native dyld API rather than dlopen--the dlopen which shipped with Panther is just the third-party dlcompat lib which was on Fink before, I believe. So I have ncurses.pasm working, although something is amiss--it's definitely invoking ncurses (I get the green generation count on the black background), but I don't see the life animation. But I suspect that the problem there isn't related to library loading. JEff On Dec 11, 2003, at 8:46 AM, Dan Sugalski wrote: If you're on OS X 10.3, I unbroke (sort of) the dynaloading code, so it now uses the platform dlopen call. This handles .dylib files like, say, libncurses.dylib. That's good. The bad news, such as it is, is: *) Still crashes. Ick. a "ulimit -c unlimited" in the terminal will generate gdb-able core files if you want them. (They go in /cores, which I recommend cleaning out occasionally) *) The dlopen routine is really primitive compared to the rest of the known unix universe. You must specify the *exact* filename of the library. No library search paths or anything like that. (I've also fixed the dynaloading code to try the exact filename, so this does work now) If anyone wants to try figuring out why ncurses.pasm fails, go for it and good lukc. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] object stuff
I think a heirarchy is a good idea for namespacing in general. I've always wanted to be able to tie namespaces in Perl 5. It would only make sense that if I tie Foo::, that Foo::anything:: would also go through that tie to get the anything:: stash. What do you mean by "tie" here? Are you talking about namespace aliasing, so that I can alias "Foo" to "A::B::C::D::E", so that I can say "Foo::bar" rather than "A::B::C::D::E::bar"? If so, it seems that this would work with or without a hierarchical structure. Definitely useful, though. Tying a namespace will involve allowing a namespace to basically hide its implementation, have a custom lookup routine, back-store its symbols, etc. I might tie a namespace to an Oracle database, so a lookup is really a callout to database code. my $foo = Oracle::Instance::DEV1::db_block_buffers; The namespace lookup in Oracle::Init checks the Oracle config parameters which is external code. All sorts of neat possibilities. :) -Melvin
Re: Namespaces
At 11:57 AM 12/11/2003 -0500, Dan Sugalski wrote: That does, though, argue that we need to revisit the global access opcodes. If we're going hierarchic, and we want to separate out the name from the namespace, that would seem to argue that we'd want it to look like: find_global P1, ['global', 'namespace', 'hierarchy'], "thingname" That is, split the namespace path from the name of the thing, and make the namespace path a multidimensional key. Or I suppose we could just punt and toss the special global access entirely and make the global namespace a hash 'o hashes hanging off the interpreter and access it like any other variable, but that makes local obscuration of the namespace somewhat difficult and I'd rather not for right now. This'd be the time to weigh in on it, folks... I expect we need multiple options and let compiler writers figure out which ones they need. (see **) 1) Lookup a fully qualified name in the top level namespace (true globals, Foo::Baz::i) 2) Lookup a fully qualified name in a specific namespace (namespace handle in PMC or string) 3) Upward lookup of a fully qualified name starting at a specific namespace (I'm in Baz, resolve j = lookup in Baz, lookup in Baz->parent, lookup in Baz->parent->parent) Difference between 2 and 3 is that 2 does not recurse upwards to resolve the name. **We may also want variations of non-qualified name lookups (optimized not to worry about tokenizing the identifier). That's off the top of my head from having written a couple of toy compilers. Keyword = toy Of course we'll need forms tailored to object instances that will also have to deal with the semantics of inheritance. -Melvin
Re: [CVS ci] object stuff
On Dec 10, 2003, at 12:37 AM, Luke Palmer wrote:
Dan Sugalski writes:
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
set I2, P1["Foo\x00i"] # I1 == I2
gets currently the attribute idx (0) of "$Foo::i".
Q: Should the assembler mangle the "Foo::i" to "Foo\0i"
I don't like it either, but the alternative is to impose an external
hierarchic structure. Which we certainly could do, though it may make
some things more difficult.
I'm more than willing to entertain arguments for and against the
hierarchic structure, but we're closing in on the point where we fix
the scheme and don't change it any more.
I'm not sure mangling is a good idea: think about anonymous classes.
If
we assign a name to each lexical class, then there are problems when
one
instance of a class inherits from another instance of the same class.
That is:
sub make_class(Class $parent) {
return class is $parent {
has $.stuff;
}
}
my $class1 = make_class(Object);
my $class2 = make_class($class1);
So, if you name that lexical class _class_0001 or something,
"_class_0001\0$.stuff" refers to both attributes.
Melvin pointed out another reason why this shouldn't actually conflict,
but I'll also say: I would think that anonymous class wouldn't have
names (pretty much by definition), not even generated ones. So to
access class attributes of anonymous classes, you'd have to use
something like:
$class1->get_attribute(".stuff")
I don't know what actual syntax Perl6 would use, but what I mean to say
is that for an anonymous class you'd have to access anything about it
via a reference to the class object, not via name (since it won't have
one).
If you generate a name for each instance of a lexical class, you're
setting yourself up for some major runtime cost -- concatenating the
class name to the attribute on each access (or memory cost if you want
to cache).
I would think that we'd want to do it so that we don't have to do
by-name lookups behind the scenes if we're not doing that up front.
That is, I'd think that
$Foo::Bar::Baz::egg = 4;
would be doing a lookup to find the namespace "Foo::Bar::Baz" (may be
hierarchical or not), and then a lookup of "egg" in that. But that:
package Foo::Bar::Baz
sub something
{
$egg = 4;
}
would be able to do a more direct lookup. (That is, it would look up
"egg" in the package namespace without having to go find the package
namespace by name.)
I think a heirarchy is a good idea for namespacing in general. I've
always wanted to be able to tie namespaces in Perl 5. It would only
make sense that if I tie Foo::, that Foo::anything:: would also go
through that tie to get the anything:: stash.
What do you mean by "tie" here? Are you talking about namespace
aliasing, so that I can alias "Foo" to "A::B::C::D::E", so that I can
say "Foo::bar" rather than "A::B::C::D::E::bar"? If so, it seems that
this would work with or without a hierarchical structure. Definitely
useful, though.
JEff
Namespaces
Okay, okay, I give -- hierarchic namespaces are the way to go. Makes local overrides somewhat interesting, but we'll burn that bridge when we get to it. That does, though, argue that we need to revisit the global access opcodes. If we're going hierarchic, and we want to separate out the name from the namespace, that would seem to argue that we'd want it to look like: find_global P1, ['global', 'namespace', 'hierarchy'], "thingname" That is, split the namespace path from the name of the thing, and make the namespace path a multidimensional key. Or I suppose we could just punt and toss the special global access entirely and make the global namespace a hash 'o hashes hanging off the interpreter and access it like any other variable, but that makes local obscuration of the namespace somewhat difficult and I'd rather not for right now. This'd be the time to weigh in on it, folks... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Mac OS X Dynaloading less broken
If you're on OS X 10.3, I unbroke (sort of) the dynaloading code, so it now uses the platform dlopen call. This handles .dylib files like, say, libncurses.dylib. That's good. The bad news, such as it is, is: *) Still crashes. Ick. a "ulimit -c unlimited" in the terminal will generate gdb-able core files if you want them. (They go in /cores, which I recommend cleaning out occasionally) *) The dlopen routine is really primitive compared to the rest of the known unix universe. You must specify the *exact* filename of the library. No library search paths or anything like that. (I've also fixed the dynaloading code to try the exact filename, so this does work now) If anyone wants to try figuring out why ncurses.pasm fails, go for it and good lukc. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
enums and bitenums
Hi, I don't remember anything about enums and bitenums in the apocalypses. This is probably not very difficult to roll out something using macros but I feel that should belong to the standard language. -- stef
Re: [perl #24638] [PATCH] brushup of Getop_Long.imc and getopt_demo.imc
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > This patch mostly improves the embedded POD in Getopt_Long.imc and > getopt_demo.imc. > There are also some code beautifications, including a s/.pcc_sub/.sub/. Thanks, applied. leo
Q: Array vs SArray
The set_integer_native() vtable method of arrays is implemented inconsistently. The old historical way in Array was to set an initial size. My implementation in SArray OTOH only reserves the needed store, but doesn't change the element count. new P0, .SArray set P0, 2 set I0, P0 # SArray.elements() print I0 new P1, .Array # or .PerlArray set P1, 2 set I1, P1 # Array.elements() print I1 print "\n" end 02 This is bad. But it gets worse: You can do "push P0, x" twice on the SArray, filling the first 2 elements. You can't do that on Array. It would set the element #2 which is beyond the preset element count - push is currently not usable for Array PMCs. (PerlArray works basically like Array but does auto-extend) I'd like to unify the behavior and get best from these two worlds: 1) can set an initial store size and (if really needed) 2) can set an initial element count, not-yet set values are NULL. One further note, while at Array/PerlArray: the class dependency is suboptimal. PerlArray isa Array isa list. The underlying list is auto-extending and does no bounds checking. Array does bounds-checking. PerlArray doesn't bounds check. So for better performace and simpler code, the dependency of PerlArray and Array should be swapped. Comments welcome, leo
Re: Iterating through two arrays at once
On Wed, Dec 10, 2003 at 11:44:15PM -0500, Joe Gottman wrote:
>In Perl 6, how will it be possible to iterate through two arrays at the
> same time? According to Apocalypse 4, the syntax is
> for @a; @b -> $a; $b {
>
> According to the book "Perl 6 Essentials" the syntax is
> for zip(@a, @b) -> $a, $b {
>
> Which of these is right? (of course, this being Perl, both may be right).
FWIW, I like the former even though the latter has lots of precedent
in other languages.
> Whichever of these syntaxes is right, what happens when @a and @b are
> of different sizes? I can think of three possible behaviors, each with
> its potential drawbacks:
>
> 1) The loop executes min(+ @a, + @b) times, then finishes
>successfully.
> 2) The loop executes min(+ @a, + @b) times, then throws an
>exception because the arrays were not of the same size.
> 3) The loop executes max(+ @a, + @b) times. If @a has fewer
>elements than @b, then after @a's elements are exhausted $a is
>set to undef, and similarly if @b has fewer elements than @a.
>
> In cases 1) and 2), the problem is how to get the elements of the
> larger array that were never iterated over. Case 2) is probably better
> than case 1), because the exception that is thrown might contain
> information about which array was larger and which elements of it have
> yet to be examined. In case 3), the problem is differentiating between
> an undef returned because the arrays were of different sizes, and an
> undef returned because one of the arrays contained an undef.
I believe that case 3) is the "right" answer. Why do you need to
differentiate the undefs? If you cared about whether one array was
bigger than the other, surely you could check that yourself. In any
case, run-time properties (is this redundant?) can help you out.
Perhaps you get an "undef but out_of_bounds" kind of value back when
you run off the end of the shorter array.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
JIT failure with Fedora
I have just installed Fedora Core 1 on a Pentium 4 system, and various tests are segfaulting when trying to invoke a compiler. I tracked it down to Parrot_jit_build_call_func. If I undef CAN_BUILD_CALL_FRAMES then all tests pass. Also, everything segfaults using parrot -j. uname -a Linux peter4 2.4.22-1.2115.nptlsmp #1 SMP Wed Oct 29 15:30:09 EST 2003 i686 i686 i386 GNU/Linux gcc --version gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1) Please let me know if there is any further testing that would help. Regards Peter Gibbs EmKel Systems
