Re: This week's summary

2004-07-26 Thread Kurt Starsinic
On Mon, 26 Jul 2004 10:29:15 -0700, Brent 'Dax' Royal-Gordon
[EMAIL PROTECTED] wrote:
 The Perl 6 Summarizer wrote:
The infinite thread
  Pushing onto lazy lists continued to exercise the p6l crowd (or at
  least, a subset of it). Larry said that if someone wanted to hack
  surreal numbers into Perl 6.1 then that would be cool.
 
 Care to explain what those are, O great math teacher?
 
 *ducks*

Just for those following along from home:


http://www.amazon.com/exec/obidos/tg/detail/-/0201038129/qid=1090866301/sr=1-1/ref=sr_1_1/103-7396197-3600620?v=glances=books

- Kurt


Re: Unicode in Emacs (was: Semantics of vector operations)

2004-02-04 Thread Kurt Starsinic
On Feb 03, David Wheeler wrote:
 On Feb 3, 2004, at 7:13 AM, Kurt Starsinic wrote:
 
 No joke.  You'll need to have the mule-ucs module installed.
 A quick Google search turns up plenty of sources.
 
 Oh, I have Emacs 21.3.50. Mule is gone.

I'm afraid you're on your own, then.  I'm using 21.3.1.  If you
work it out, please post.

- Kurt



Re: Semantics of vector operations

2004-02-03 Thread Kurt Starsinic
On Feb 02, David Wheeler wrote:
 On Feb 2, 2004, at 9:53 PM, Kurt Starsinic wrote:
 
 I realize this is a tad OT, but can anyone tell me how I can get Emacs
 to properly display Unicode characters? I expect that others on the
 list could benefit, too.
 
 (require 'un-define)
 
 Since I really don't understand Lisp, and since that simply didn't 
 work, I'm going to assume it was some kind of joke. :-) Am I right?

No joke.  You'll need to have the mule-ucs module installed.
A quick Google search turns up plenty of sources.

You'll also need to have the appropriate fonts installed, of course.
You may need to set your $LANG environment variable to a suitable value
(I use en_US.UTF-8).

- Kurt



Re: Protocols

2003-07-25 Thread Kurt Starsinic
On Jul 24, chromatic wrote:
 On Thursday, July 24, 2003, at 05:28 PM, Benjamin Goldberg wrote:
 If this were Java, the way to do this would be to define a Thingie
 interface, and then an (archetypical) ThingieObject class... any time
 that we want to actually *create* Thingies, we would use new
 ThingieObject, but everywhere else, we would use the typename
 Thingie.  This way, when we want a class which acts like a Thingie,
 but without inheriting any of it's innards, simply implement the 
 Thingie
 interface, instead of inheriting the ThingyObject class.
 
 Yes, that's the Java way to do it.  Surely we can do it better in Perl 
 6.
 
 The problem with Java interfaces is that you have to rely on the 
 library writer to have expected you to use an interface.  Given the 
 amount of CPAN modules that, for example, expect a glob and preclude me 
 from passing in an IO::Handle with code like this:
 
   croak Need a glob unless ref $thingie eq 'GLOB';
 
 I'm not sure that the Java style is helpful.  I'd rather not multiply 
 entities needlessly.
 
 For our isa operator, and (perhaps more importantly) for
 multimethod dispatch and/or sub prototype checking, we only check if an
 object inherits from a class's magic parent interface, and *don't* 
 check
 if it *really* inherits from that class itself.
 
 heretic
 Why should an implementor inherit from the interface?
 
 If inheritance and polymorphic equivalence are two different things, 
 they ought to be handled two different ways.  If anything, inheritance 
 is a specific case of the general mechanism of marking polymorphic 
 equivalence.
 
 Again, the interesting question isn't Does this thing derive from 
 something I know about? It's Does this thing support the operations I 
 expect it to support?  I don't care how, just that it does.
 
 I don't want to call $mock_foo-isa( 'foo' ) because $mock_foo *isn't* 
 a foo.  I don't want to call $delegates_to_foo-isa( 'foo' ) because 
 $delegates_to_foo *isn't* a foo.  They can both handle foo-methods, but 
 neither is a foo.
 /heretic

My two cents:  the best possible use of an interface/protocol is
to define a set of methods *and their semantics*, and *not* their
implementation.  In pseudocode:

protocol Window {
method print;
method close;
method bringToFront;
}

class MyWindow:  implements Window;

You're saying that MyWindow has print, close, and bringToFront
methods.  You're not saying whether they're inherited, or implemented
from scratch.  You *are* saying that close() will erase a graphical
rectangle on a display, not disconnect a filehandle or return true
if it's nearby.

So the useful feature of this abstraction is that, given an
anonymous object, you don't ask, do you implement method called
so-and-so, e.g., $anon-can('print'); you ask it, do you do the
things that a Window does, e.g., $anon-implements('Window').

So a class shouldn't inherit from an interface.  It should
assert that it implements it.

- Kurt



Re: Protocols

2003-07-24 Thread Kurt Starsinic
On Jul 24, David Wheeler wrote:
 On Wednesday, July 23, 2003, at 05:57  PM, chromatic wrote:
 
 The first is a deeper question -- besides inheritance, there's 
 delegation, aggregation, and reimplementation (think mock objects) 
 that can make two classes have equivalent interfaces.  I'd like some 
 way to mark this equivalence *without* having to inherit from an 
 abstract base class and I wish that interface equivalence were checked 
 before inheritance, as per Luke's idea.
 
 Sounds like you want Java-style interfaces to me.

Follow the thread back.  Objective-C had them way first, and their
ur-name is protocols.

- Kurt



Re: Perl and *ML

2003-03-26 Thread Kurt Starsinic
On Mar 26, Robin Berjon wrote:
 Dan Sugalski wrote:
 I think that the issue here isn't so much good perl support for XML as 
 it is good support for attributed DAGs, something which would be of 
 general good use for perl, since the ASTs the parser feeds to the 
 compiler will ultimately be DAGs of a sort.

++good

 So, rather than jumping on the XML [insert verb here]! bandwagon, 
 perhaps we'd be better served figuring out what would be useful 
 operations and support for/on DAGs and suchlike things?
 
 Fast and efficient graphs of all sorts would be very useful. A way to 
 define a complex graph of interlinked arbitrary objects while being 
 reasonable on memory and good with GC would be a definitive big win, 
 especially if it can be lazy. Especially with nice ways to write visitors 
 and easy searches in the graph based on object properties (but I could be 
 asking for too much ;).
 
 DAGs wouldn't enough though, most XML tree representations aren't really 
 trees, they're very cyclic.

Pardon me?  Could you please provide an example?

- Kurt