Re: Coupla Questions
On Wed, Jun 06, 2001 at 04:30:56PM +0100, Simon Cozens wrote: > I'm sure I'll think of some more questions Are properties subscriptable? (Can the value of a property be a reference that can be dereferenced?) Can properties have properties? -- The complex-type shall be a simple-type. ISO 10206:1991 (Extended Pascal)
Re: Should we care much about this Unicode-ish criticism?
Dan Sugalski <[EMAIL PROTECTED]> writes: > >It does bring up a deeper issue, however. Unicode is, at the moment, >apparently inadequate to represent at least some part of the asian >languages. Are the encodings currently in use less inadequate? I've been >assuming that an Anything->Unicode translation will be lossless, but this >makes me wonder whether that assumption is correct. One reason perl5.7.1+'s Encode does not do asian encodings yet is that the tables I have found so far (Mainly Unicode 3.0 based) are lossy. -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
Re: $foo.Foun (was Re: Properties and stricture)
On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote: > > > Larry's MMV on that ;-) > > Man I really need to get up to speed with these > acronyms. I know YMMV, is MMV a distant > cousin perhaps? Same idea, except it's Larry's Milage in question, rather than Yours. dha -- David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/ Shut up, listen, and dance. - Madness
Re: Properties and stricture and capabilities
Michael G Schwern wrote: > Symbol table manipulation will work as long as your mucking about > doesn't alter the strict class's signature. ie. you can shove a code > ref onto the symbol table as long as a stub for that method was > defined at compile time. a read-only hash of any kind makes it more safe we could overload C to make a hash read-only and return a coderef that can be run to make it r/w again (aka "the capability") That would prevent further shoving of anything onto the symbol table without "proper authorization" as defined by holding the capability.
Re: $foo.Foun (was Re: Properties and stricture)
On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote: > > B&D languages > > What's B&D? Bondage and Discipline, scum! You're not a good enough programmer to be trusted not to make mistakes! Now drop and give me fifty! -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Now I fight for wisdom. http://sluggy.com/d/010204.html
Re: 1 until defined(getvalue()); return $^d;
On Wed, Jun 06, 2001 at 02:20:25PM -0500, David L. Nicol wrote:
> Since this thread made it into this week's Official Perl6 Summary,
> here goes a defense of C as a shorthand for the thing that last
> had C or C queried of it.
Ya know, I hate myself to admit it but I'm liking this idea. The one
that got me was this:
foreach my $uid (@users) {
print it if is_luser($uid);
}
I like the way it reads. If 'it' is read-only it limits the potential
complications. Yes, you can do similar things with grep...
print grep is_luser($_), @users;
but TMTOWTDI.
I am a bit worried about having to do so much pointer copying to
support this feature.
PS 'it' could take many forms
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Monkey tennis
Re: Coupla Questions
On Thu, Jun 07, 2001 at 08:15:46AM +0100, Simon Cozens wrote:
> On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
> > Damian Conway wrote:
> > > $ref.{a}can be $ref{a}
> > which can also be
> > $ref.a
>
> Dereferencing a hashref is the same as accessing a property?
IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.
So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}
This would have the benefit of not loosing encapsulation and
also the performance of not having to call a method which would
just look like
sub a(Foo $self) :lvalue { $self->{a} }
(Did I get that syntax right ? probably not :)
Graham.
Re: Properties and stricture
Ok, I've realized a few things. 1) There's two sorts of type-checking going on here. Compile-time and run-time. 2) Run-time type checking is fairly easy and imposes few limitations. In fact, you can even do it now through ad hockery. 3) Compile-time type checking is a bit harder. Any module/class which wishes to be compile-time checked must not have its *signature* altered at run-time. By "signature" I mean the methods, functions, global variables and inheritence tree of a strict class must be defined at compile time. All the external stuff. The internals can change at any time. This means you can still AUTOLOAD, so long as the function signature is defined beforehand. But you can't use AUTOLOAD to define brand new methods of the strict class. eval STRING still works, just so long as it doesn't modify a strict class. It can call methods of a strict class, and this is all checked at the eval's compile-time. Dynamic method calls ($obj->$method()) works, it will be run-time checked. Subroutine refs, same thing. Symbol table manipulation will work as long as your mucking about doesn't alter the strict class's signature. ie. you can shove a code ref onto the symbol table as long as a stub for that method was defined at compile time. Automatic method generation will work, but only for those known at compile-time. Which is fine. So mod_perl, Apache::Registry, AutoLoader, Class::Accessor, Exporter, Template Toolkit can all still work, with a bit of reworking. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One My feet hurt... with destiny! http://sluggy.com/d/010204.html
Re: Properties and stricture
On Wed, Jun 06, 2001 at 10:28:41AM -0400, John Porter wrote: > Michael G Schwern wrote: > > It will have to go for strict classes. @ISA will have to be locked. > > "strict classes"? > "strongly typed class"? Can a man make up gibberish in peace? ;) Basically, any class which wants to be type-checked at compile time. > I agree that an (optional) strong-typing mechanism would > be nice to have in perl6. However, I don't think it > should not have a run-time component. > I.e. "strong typing can only be done at compile time". > We'll do what we can at compile time, but this is Perl... Yes, very true. I missed that entirely. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One That which stirs me, stirs everything. -- Squonk Opera, "Spoon"
Re: Properties and stricture
On Wed, Jun 06, 2001 at 07:06:49PM -0700, Dave Storrs wrote: > But if we did, how could we hope to get a good new Star Trek > series? :> You're still hoping for a new, good Star Trek series??? You must be a Cubs fan. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One If you'll mount me, I'll let you bomb Canada until they swoon.
RE: Should we care much about this Unicode-ish criticism?
From: David L. Nicol [mailto:[EMAIL PROTECTED]] > Russ Allbery wrote: > > > > a caseless character wouldn't show up in > > either IsLower or IsUpper. > > maybe an IsCaseless is warrented -- or Is[Upper|Lower] > could return UNKNOWN instead of TRUE|FALSE, if the > extended boolean attributes allow transbinary truth values. non-zero, zero, undef Outside of using a regex, we don't have anything equivalent to Is[Upper|Lower] in Perl 5 do we? I'm feeling in need of some context. Anyone got a use case for when someone would be processing characters and NEED to know that they're caseless? Trying to convert a string of Roman Latin chars from lowercase to upper when there isn't any case to convert? Couldn't that be a no-op? If Perl knows the character is caseless why not let it DWIM?
Re: Properties and stricture
Michael G Schwern wrote: > Basically, any class which wants to be type-checked at compile time. I think the meaning of that is still not clear, given what "strong typing" usually means. -- John Porter
Re: Properties and stricture
Michael G Schwern wrote: > you can even do it now through ad hockery. Or odd hackery. :-) -- John Porter
Re: Properties and stricture
This is similar to the solution they use in Java. You have an interface, which is compile time checked. Then, when you load a class at runtime, you check at load time that it satisfies the interface. You either get an exception right then, or you're fine. Daniel Michael G Schwern wrote: > Ok, I've realized a few things. > > 1) There's two sorts of type-checking going on here. Compile-time and > run-time. > > 2) Run-time type checking is fairly easy and imposes few limitations. In > fact, you can even do it now through ad hockery. > > 3) Compile-time type checking is a bit harder. Any module/class which > wishes to be compile-time checked must not have its *signature* > altered at run-time. > > By "signature" I mean the methods, functions, global variables and > inheritence tree of a strict class must be defined at compile time. > All the external stuff. The internals can change at any time. > > This means you can still AUTOLOAD, so long as the function signature > is defined beforehand. But you can't use AUTOLOAD to define brand new > methods of the strict class. > > eval STRING still works, just so long as it doesn't modify a strict > class. It can call methods of a strict class, and this is all checked > at the eval's compile-time. > > Dynamic method calls ($obj->$method()) works, it will be run-time > checked. Subroutine refs, same thing. > > Symbol table manipulation will work as long as your mucking about > doesn't alter the strict class's signature. ie. you can shove a code > ref onto the symbol table as long as a stub for that method was > defined at compile time. > > Automatic method generation will work, but only for those known at > compile-time. Which is fine. > > So mod_perl, Apache::Registry, AutoLoader, Class::Accessor, Exporter, > Template Toolkit can all still work, with a bit of reworking. > > -- > > Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ > Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One > My feet hurt... with destiny! > http://sluggy.com/d/010204.html
Re: Coupla Questions
> > $ref.{a}can be $ref{a}
>
> which can also be
>
> $ref.a
>
> can it not?
Err..no.
$ref.{a}/$ref{a} is an access on a hash element through the hashref in $ref.
$ref.a is a call to the method a() of the object referred to by $ref.
Damian
Re: 1 until defined(getvalue()); return $^d;
David L. Nicol wrote: > I really don't know enough about perl 5 internals to go on; I > am certain that this feature is a no-brainer though Besides the fact which, how it might be added to perl5 does not say much about how it might be implemented in perl6. And it is perl6 we're talking about, right? -- John Porter "It's turtles all the way down!"
Re: 1 until defined(getvalue()); return $^d;
John Porter wrote:
> Huh? What did I say?::
you said there would be no performance hit in rewriting
defined|exists to store the pointer to the thing that was
found to be defined or exist somewhere.
After looking at the source code for what might have been the
wrong part of /usr/src/perl/perl-5.6.1/Perlapi.c (or something
like that) I determined that adding this feature would cause
two writes to static variables per function invocation that found
something and one or perhaps zero writes per invocation that found
nothing.
These writes would dirty a code page, which might result in a stall
as the modification is propagated up from the CPU.
Since the rest of the variables local to that routine are declared
as registers, the routine (at least the one I looked at) currently
uses only the stack and registers, and very little of the stack.
There would be a slight performance hit, caused by the two extra
assignments. (one to zero the pointer on entry, one to set it on found.)
pp_exists, found in pp.c, is a wrapper for special cases
involving subroutines -- no comment on what
if (PL_op->op_private & OPpEXISTS_SUB) {
is testing for --
and then is a wrapper for the three kinds of container lookup,
hv_exists_ent, av_exists, and avhv_exists_ent
I examined hv_exists_ent. Its arguments are
HV *hv, SV *keysv, U32 hash
which appear to be sufficent to describe the location of
an item, directly.
something like
struct IT_EXISTS_STASH_TYPE {
HV *hv;
SV *sv;
U32 hash;
}
should be sufficient for the
static IT_EXISTS_STASH_TYPE IT_exists;
definition which would have to appear somewhere.
I really don't know enough about perl 5 internals to go on; I
am certain that this feature is a no-brainer though and will try
to refrain from responding further about it
--
David Nicol 816.235.1187
Re: 1 until defined(getvalue()); return $^d;
John Porter wrote: > > David L. Nicol wrote: > > I really don't know enough about perl 5 internals to go on; I > > am certain that this feature is a no-brainer though > > Besides the fact which, how it might be added to perl5 > does not say much about how it might be implemented in > perl6. And it is perl6 we're talking about, right? Yes! Another reason to NOT write and submit a patch.
Re: Should we care much about this Unicode-ish criticism?
Nick Ing-Simmons <[EMAIL PROTECTED]> writes: > Dan Sugalski <[EMAIL PROTECTED]> writes: > > > >It does bring up a deeper issue, however. Unicode is, at the moment, > >apparently inadequate to represent at least some part of the asian > >languages. Are the encodings currently in use less inadequate? I've been > >assuming that an Anything->Unicode translation will be lossless, but this > >makes me wonder whether that assumption is correct. > > One reason perl5.7.1+'s Encode does not do asian encodings yet is that > the tables I have found so far (Mainly Unicode 3.0 based) are lossy. Er, are the Unicode tables going to be embedded in /usr/bin/perl6? That doesn't give me a warm, cozy feeling about Perl-6 support of Unicode. I think it's great that Perl internals will be able to handle arbitrary strings of Unicode characters (using some version of UTF-*), but may I suggest that anything that relies on the properties of characters (case, conversions, combining, visibility, etc) require explicit library support? We'd lose some things, like normalization, but we wouldn't have to carry around huge tables, either. > > > -- > Nick Ing-Simmons > who is looking for a new job see http://www.ni-s.u-net.com/
RE: Should we care much about this Unicode-ish criticism?
Dan Sugalski <[EMAIL PROTECTED]> writes: > >I think I'd agree there. Different versions of a glyph are more a matter of >art and handwriting styles, and that's not really something we ought to get >involved in. But the human sitting in front of the machine cannot see the bit pattern, they can only push the available keys and look at the presented glyphs. There is indeed a similarity to locales - without a choice of glyph being presented then asian texts will be as readable to a native as if english was rendered in cyrillic or greek alphabets. (Would you recognise Delta-alpha-nu as "Dan" ?) >The european equivalent would be to have many versions of "A", >so we could represent the different ways it was drawn in various >illuminated manuscripts. That seems rather excessive. Not entirely true. Consider German "ß" vs "ss" or French not normally putting accents on upper-case vowels, or even in english I detest spell checkers which prefer naive vs naïve role vs rôle. > > Dan > >--"it's like this"--- >Dan Sugalski even samurai >[EMAIL PROTECTED] have teddy bears and even > teddy bears get drunk -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
