-bits.pod
Log Message:
---
[S02] remove section on "Properties"
it seems that "properties" refer to either traits or run-time mixins with
infix but.
Both are described much more accurately and less out-of-date in S12 and S14
IMHO some details of Unicode property support seem unspecified:
1) Assumption: *ALL* Unicode properties and all of their aliases should
be supported.
E.g. this will also include the derived properties 'Grapheme_Base' and
'Grapheme_Extent' (missing in Perl 5 - obvious
I don't understand why you think you need the eval here?
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
> There is syntax to define trait and properties
> but is there an API?
>
> my $b = eval '$a but true'; # setting a true property
>
On Fri, May 13, 2005 at 09:40:51PM +0200, Stéphane Payrard wrote:
: And what about the getter part of my question? :)
A12 discusses the relationship of traits and properties in great
detail. Any trait's metadata can be stored as properties at compile
time, and such metadata can be retriev
On Fri, May 13, 2005 at 12:56:19PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Should I construe the fact that you didn't comment on the ::() to mean
: that the symref syntax works here?
Offhand I don't see any reason for it not to.
Larry
On 5/13/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote:
> : my $b = $a is foo($bar);
>
> As we currently have it, that is not legal syntax. "is" may only
> be applied to declarations.
Sorry, think-o. I meant 'but' in my e
On Fri, May 13, 2005 at 12:31:09PM -0700, Larry Wall wrote:
> On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote:
> : Well, the value's pretty easy--just pass in a variable:
> :
> : my $b = $a is foo($bar);
>
> As we currently have it, that is not legal syntax. "is" may
On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Well, the value's pretty easy--just pass in a variable:
:
: my $b = $a is foo($bar);
As we currently have it, that is not legal syntax. "is" may only
be applied to declarations. You must use "does" or "but" to mixin
On 5/13/05, Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> > > There is syntax to define trait and properties
> > > but is there an API?
> > >
> > > my $b = eval '$a but true'; # setting a true property
> > > # API to do it without a
On Fri, May 13, 2005 at 06:37:50PM +, [EMAIL PROTECTED] wrote:
>
>
> > There is syntax to define trait and properties
> > but is there an API?
> >
> > my $b = eval '$a but true'; # setting a true property
> > # API to do it without an eva
There is syntax to define trait and properties
but is there an API?
my $b = eval '$a but true'; # setting a true property
# API to do it without an eval?
A trait setter probably does not make sense but for the
implementer because it should not be set at run time.
Incident
Larry wrote:
: Indeed, if Larry were to give the word, I'd be delighted to add support for
: it to the Perl6::Rules module.
Execute! (I hope that's the right word...)
I believe, Captain, the correct word would be: "Engage!"
Data^H^Hmian
On Tue, Mar 02, 2004 at 04:58:38PM +1100, Damian Conway wrote:
: FWIW, I'm strongly in favour of adding & to rules.
:
: Indeed, if Larry were to give the word, I'd be delighted to add support for
: it to the Perl6::Rules module.
Execute! (I hope that's the right word...)
Larry
Larry noted:
> There's a lot to be said for being able to write
things like:
[ & + ]
Now I'm supposing that & binds tighter than | as usual, so the
brackets wouldn't always be necessary:
& +
|
& +
FWIW, I'm strongly in favour of adding & to rules.
Indeed, if Larry were to gi
[ + | + ]
or really, just
& <|>+
That last is likely to be the fastest, since a decent implementation
of character properties should cache swatches of the bitmap like Perl 5
does, or at least memoize something somewhere to keep from having
to recalculate what's french and what's swahili...
Larry
string-like things via scalar
: strings+ or objectrefs.
Okay, I supposin'. But I'd rather not call them traits, since that
already means two other things right now. Properties is more like...
: You want to do something like "search for all occurrences of the word
: 'From
Another hypothetical:
Suppose you have a browser (which understands "language" traits) or a word processor
(which stores "style" and/or "font" information) that is storing some not-text-only
string-like things via scalar strings+ or objectrefs.
You want to do something like "search for all occu
Is there a list of the properties for the builtin types? My searches
through the archives leads me to believe there is no such beast. Is
there any consensus on what some of the properties will be? I am not
looking for a complete or authoritative list. I am just trying to
finish off a
SUPER::STORE($newval but [EMAIL PROTECTED]) }
> }
> @bar but= property_wrap(false, foo);
>
> ? The examples I remember from the As and Es all have round brackets
> around trait parameters (Hmm. And I can only remember is-trait examples
> too). Granted, the universe c
On Thu, Dec 04, 2003 at 05:57:52PM -0700, Luke Palmer wrote:
> Hodges, Paul writes:
> > I'd *like* to be able to predeclare a trait or property to be distributed
> > across any values placed in this array, but only this array. For example, it
> > would be nice if I could have the default aspects of
Paul Hodges writes:
> Luke Palmer:
> > Something likely more like:
> >
> > my role property_wrap[Property [EMAIL PROTECTED] {
> > method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) }
> > }
> > @bar but= property_wrap[false, foo];
>
> ...square brackets?
> ...r
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Hodges, Paul writes:
> > How about
> >
> > use Baz; # assume object type
> > my property foo;
> > my @bar of Baz is false but foo; # maybe not what you meant?
>
> Definitely not what you meant. Fortunately, the compiler will teach
> you a thing
Hodges, Paul writes:
> How about
>
> use Baz; # assume object type
> my property foo;
> my @bar of Baz is false but foo; # maybe not what you meant?
Definitely not what you meant. Fortunately, the compiler will teach you
a thing or two about it: C is not a trait.
But indeed foo would a
How about
use Baz; # assume object type
my property foo;
my @bar of Baz is false but foo; # maybe not what you meant?
If you apply a trait like false to an array, I expect it to apply to the
"array instance object" itself and not the content, so that
push @bar, Baz.new();
if @bar{
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Hodges) writes:
> > I am not seeing unicode.
>
> Don't worry because, and I honestly don't mean this disparagingly -
> by the time Perl 6 is ready for prime-time, you will. Larry got this
one
> right.
lol -- I think you're rig
[EMAIL PROTECTED] (Paul Hodges) writes:
> I am not seeing unicode.
Don't worry because, and I honestly don't mean this disparagingly - by the
time Perl 6 is ready for prime-time, you will. Larry got this one right.
--
"Jesus ate my mouse" or some similar banality.
-- Megahal (trained on
> And as far as I know, << and >> are exactly equivalent to æ?? and æ??
> in all cases.
lol I get the idea, but I foresee these unicode bits as becoming an
occasional sharp spot in my metaphorical seat of consciousness. :)
I am not seeing unicode.
__
Do you Y
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
> > Didn't know "is" would do that. Good to know!
> > And in my meager defense, I did reference MikeL's operator
> > synopsis as of 3/25/03, which said ^[op] might be a synonym
> > for
On Tuesday, December 2, 2003, at 12:37 PM, Luke Palmer wrote:
Michael Lazzaro writes:
There were also vaguely threatening proposals to have <> and
>>op<<
do slightly different things. I assume that is also dead, and that
<> is (typically) a syntax error.
Ack. No, slightly different things would
Luke Palmer writes:
> And as far as I know, << and >> are exactly equivalent to æ and æ in all
> cases.
By which I mean  and Â, of course. :-/
(mutt is kind of a pain in this area)
Luke
Ã
Michael Lazzaro writes:
>
> On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
> >Didn't know "is" would do that. Good to know!
> >And in my meager defense, I did reference MikeL's operator synopsis as
> >of
> >3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry,
> >n
On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
Didn't know "is" would do that. Good to know!
And in my meager defense, I did reference MikeL's operator synopsis as
of
3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry,
no
fancy chars here. :)
Hey, that was *March*
; (Sorry, no
fancy chars here. :)
> C doesn't seem like a trait you would put on a property. C
> is a run-time property, and I think it would be awfully confusing to
> make it a trait as well. If you're talking about some kind of
> initialization, you might use:
>
>
ght use:
my property (foo,bar,baz) is first(1);
Or C might be correct if you're -- somehow -- deriving these
properties from the C property. But I don't think that was the
intent.
> I'm pretty sure that syntax is way wonky -- would "is" be a
> vectorizab
> From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
> On Mon, Dec 01, 2003 at 10:42:09AM -0500, Hodges, Paul wrote:
> >
> > module IHL::Roles;
> > @ISA = 'Exporter';
> > @EXPORT_OK = qw/ fatal verbose allow setvals /;
> >
> > our role fatal is property {
> > has $.fatal is rw;
> >
On Mon, Dec 01, 2003 at 10:42:09AM -0500, Hodges, Paul wrote:
> So is this a good time to divert this topic into an elaboration of roles?
I can wait for A12, but in the mean time ... :-)
> So if I want to implement a package of related roles that I commonly use in
> our In-House code, such as to
#x27;m attempting to take their concept and unify it with
> properties, interfaces, generics, aspects, and mixins. Among other
> things...
Ok, having read this now (at least corsorily) and compared it with what I
believe I understand about the way P6 is implementing
traits/properties
On Thursday, November 27, 2003, at 04:21 , Larry Wall wrote:
(Oh, apparently C# 2.0 is thinking along the same lines with its
"partial classes", though I haven't looked at those in detail.)
My reading was that C# 2's partial classes were merely a mechanism for
placing long method definitions in
,
um, yes.
> Now the hard question.
>
> my $tst = Baz.new();
>
> How do I set a zippy property on $tst explicitly using Bar's zippy?
Probably just
$tst but= Bar::zippy;
I imagine that properties work just like other names, so they can be
stuck in package symbol ta
With apologies, I'm already seeing blunders. *sigh*
> my Baz @ray = ( Baz.new() );
No reason to type that. Should be
my @ray = ( Baz.new() );
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
> : And "exportation"???
>
> Exportation is just aliasing some name inside a scope to somewhere
> outside the scope. Importatation is the same operation from the
> viewpoint of the importing scope.
I just wasn't thinking clearly when you said it the first time.
> Perl 5 didn't allow exportation
> : but it confuses me. Does that mean you're leaning more toward
> : allowing undeclared properties, or just that you're still trying
> : to give both sides of the argument thorough consideration?
>
> I'm not doing either of those things... :-)
Yayy! :)
> : Ju
On Sat, Nov 29, 2003 at 12:53:50PM -0800, Paul Hodges wrote:
:
: --- Larry Wall <[EMAIL PROTECTED]> wrote:
: > On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
: > : hmm... lexical propertiesI've read the rest of the message,
: > : and I see how this could be a
confuses me. Does that mean you're leaning more toward allowing
: undeclared properties, or just that you're still trying to give both
: sides of the argument thorough consideration?
I'm not doing either of those things... :-)
: Just for my vote, I want to be able to declare new pr
--- Paul Hodges <[EMAIL PROTECTED]> wrote:
> print "foo" is $x;
With deeply sincere apologies, that should have been
print "foo" if $x;
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
> : hmm... lexical propertiesI've read the rest of the message,
> : and I see how this could be a problem. Just to be clear on it,
> : what exactly would it mean for
restriction; people who know
> : > how to read a property would also expect to be able to set it in
> : > the same way.
> :
> : I'd think that would depend on the current status of strictures.
> : Assuming no strictures at all, I'd rather expect Perl to autovivify
&g
On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
: hmm... lexical propertiesI've read the rest of the message, and I
: see how this could be a problem. Just to be clear on it, what exactly
: would it mean for a property or trait to be lexical? If a value or
: container with
me way.
:
: I'd think that would depend on the current status of strictures.
: Assuming no strictures at all, I'd rather expect Perl to autovivify
: properties much the way hash elements are created when you assign a
: value to a previously nonexistant key, but that's exactly
ty you have to say:
> >
> > $x but= bar;
>
> I think that would be an unPerlish restriction; people who know
> how to read a property would also expect to be able to set it in
> the same way.
I'd think that would depend on the current status of strictures.
Assumi
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 27, 2003 at 08:08:05PM -0800, Paul Hodges wrote:
> : --- Larry Wall <[EMAIL PROTECTED]> wrote:
> : > ... in fact, we may be limiting the creation of properties
> : > to predeclared names, so that even
>
sh restriction; people who know how to
read a property would also expect to be able to set it in the same way.
> ... as long as we limit the .bar notation to rvalues or to lvalues on
> already-created properties. And in fact, we may be limiting the
> creation of properties to predeclare
On Thu, Nov 27, 2003 at 08:08:05PM -0800, Paul Hodges wrote:
:
: --- Larry Wall <[EMAIL PROTECTED]> wrote:
: > ... in fact, we may be limiting the creation of properties
: > to predeclared names, so that even
: >
: > return 0 but ture;
: >
: > can be caught at comp
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> ... in fact, we may be limiting the creation of properties
> to predeclared names, so that even
>
> return 0 but ture;
>
> can be caught at compile time.
Excellent, so long as we can define new properties explicitly.
[EMAIL PROTECTED] (Larry Wall) writes:
> P.S. I think we deserve a $rubyometer-- for bypassing mixins.
I think you deserve loud and wild applause for an object model I want
to use Right Now Dammit.
--
Overall there is a smell of fried onions. (fnord)
On Thu, Nov 27, 2003 at 12:02:30AM -0700, Luke Palmer wrote:
: Here's a series of questions/confirmation requests about how properties
: work (but specifically run-time properties, not traits):
:
: Use C to assign a property to a I:
:
: $a = $b but foo; # $a has property foo, $b
Here's a series of questions/confirmation requests about how properties
work (but specifically run-time properties, not traits):
Use C to assign a property to a I:
$a = $b but foo; # $a has property foo, $b does not
Properties are just out-of-band methods:
if $x.foo { prin
Another one of my little annonyances in the current state of P6 is how
run-time properties are accessed. Accessing properties as methods is
pretty, but I see it as potentially dangerous.
Adding a new method to a class that happens to be the same as
somebody's property would be lucky to get
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> > A lightweight, typedef-like mechanism behaves differently:
> >
> > class Foo is Bar;
> > typedef Baz is Bar;
> >
> > Foo.isa("Baz") == TRUE;
>
> Ah, I get it. But why would you want that -- treating Foo and Baz as
>
> synonymous?
Treati
> Ah, I get it. But why would you want that -- treating Foo and Baz as
> synonymous? Shouldn't you always be using Baz instead of Foo, if you
> really mean Baz and not Foo, and vice versa? Because later on, if you
> changed it such that:
>
> class Foo is Bar;
> typedef Baz is Bar is
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
: This may have been asked before, and I apologize if I somehow missed it,
: but can junctions be used for multiple properties?
:
: I can see it possibly being useful in a situation like the
: following(which may be completely off
, evil man for reminding me of this. I have yet to
brainvomit about stack-streams. (I have found an interesting analogy
between subs/blocks and streaming video compression, but it is too
large to fit in the margin :-)
> And since A6 indicates that the signature, traits, and even
> implement
On Thursday, March 13, 2003, at 01:23 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
Defining a Class for this is also overkill.
Ye.. well, no. Why?
class Foo is Bar; # normal inheritance
class Baz is Bar; # the thing that we are over-killing
Foo.isa("Baz") == FALSE;
A lightweight, typedef-
it like this, I wonder?
Since C is itself a class, you can subclass it. And since A6
indicates that the signature, traits, and even implementing body are
just properties of a given C "object", you should be able to
override them individually if you want, for example, an alternate
. Thanks. Still I wonder a bit about
the idea of mutually exclusive properties, where one can take effect if
the other(s) doesn't make sense in the current context.
Getting mired in life can really detract from following the developments
in this community.
Michael Lazzaro wrote:
Defining a Class for this is also overkill.
Ye.. well, no. Why?
class Foo is Bar; # normal inheritance
class Baz is Bar; # the thing that we are over-killing
Foo.isa("Baz") == FALSE;
A lightweight, typedef-like mechanism behaves differently:
class Foo is Bar;
ty
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> On Thursday, March 13, 2003, at 12:04 PM, Mark Biggar wrote:
> > What we do need is some way of bundling a bunch of traits together
> > under a simple name.
>
> Yes, yes, yes.
>
> > Defining a Class for this is also overkill.
>
> Ye.. well, no.
On Thursday, March 13, 2003, at 12:04 PM, Mark Biggar wrote:
What we do need is some way of bundling a bunch of traits together
under a simple name.
Yes, yes, yes.
Defining a Class for this is also overkill.
Ye.. well, no. Why?
So instead of saying:
my %pet is Hash of Array of Array of
Jonathan Scott Duff wrote:
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be
On Thu, Mar 13, 2003 at 01:13:27PM -0600, Jonathan Scott Duff wrote:
: I don't think that junctions make sense here. Besides, the "is" is
: optional:
:
: class Foo {
: method bar is public rw const frob knob { ... }
: }
That feature is still in Schroedinger's little bo
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
> This may have been asked before, and I apologize if I somehow missed it,
> but can junctions be used for multiple properties?
>
> I can see it possibly being useful in a situation like the
> following(which may be
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be completely off, as I'm still digging my way
through A6):
class Foo {
method b
> I believe you'd have to create a class for such things, derived from Array:
>
> class AppOnlyArray is Array {
> method STORE(int $index, $value) {
> fail "Can't modify existing element"
> if 0 <= $index < .length;
>
Austin Hastings asked:
How do I specify an array which may be appended/pushed, but whose
values cannot change?
I believe you'd have to create a class for such things, derived from Array:
class AppOnlyArray is Array {
method STORE(int $index, $value) {
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> > It is explicitly stated that "is rw" on a slurpy parameter
> distributes
> > across all the components.
> >
> > Is there some way of differentiating array of const vs. array of
> rw?
> >
> > That is, creating a hash or
On 2003-03-11 at 10:12:17, Damian Conway wrote:
> Austin Hastings wrote:
>
> >It is explicitly stated that "is rw" on a slurpy parameter distributes
> >across all the components.
> >
> >Is there some way of differentiating array of const vs. array of rw?
> >
> >That is, creating a hash or array t
Austin Hastings wrote:
It is explicitly stated that "is rw" on a slurpy parameter distributes
across all the components.
Is there some way of differentiating array of const vs. array of rw?
That is, creating a hash or array that can be extended without
overwriting?
I'm not sure I follow what you'
Having just read through the declaration bits (not the calling bits,
yet):
It is explicitly stated that "is rw" on a slurpy parameter distributes
across all the components.
Is there some way of differentiating array of const vs. array of rw?
That is, creating a hash or array that can be extended
On Sat, Mar 01, 2003 at 11:58:39PM +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Allison Randal) writes:
> > > Oh well, it was only two letters. There wasn't anything about
> > > approximate matching in A5, was there?
> >
> > I'm not sure what you mean, could you give an example?
>
> This was
Simon wrote:
> > > Oh well, it was only two letters. There wasn't anything about
> > > approximate matching in A5, was there?
>
> This was a [MZ]u[nr]ich joke, I think.
* Allison trundles off to caffeinate her brain.
[EMAIL PROTECTED] (Allison Randal) writes:
> > Oh well, it was only two letters. There wasn't anything about
> > approximate matching in A5, was there?
>
> I'm not sure what you mean, could you give an example?
This was a [MZ]u[nr]ich joke, I think.
--
Term, holidays, term, holidays, till we l
On Sun, Mar 02, 2003 at 12:02:42AM +0100, Paul Johnson wrote:
> On Sat, Mar 01, 2003 at 02:58:04PM -0600, Allison Randal wrote:
>
> > [0] STL = St. Louis - June 2002, ETH = ETH campus in Munich - Sept.
>
> ETH is in Zurich. The Mini::Conference there was immediately followed
> by YAPC::Europe in
On Sat, Mar 01, 2003 at 02:58:04PM -0600, Allison Randal wrote:
> [0] STL = St. Louis - June 2002, ETH = ETH campus in Munich - Sept.
ETH is in Zurich. The Mini::Conference there was immediately followed
by YAPC::Europe in Munich. All these old European cities speaking funny
German just merge t
hrough all the list mail. :)
C is gone now anyway.
> A note: It is *impossible* to tell whether these are properties or
> methods, built-ins or user-defined. This has never been stated
> anywhere, with the exception of "constant" and "dim", which Damian
> says (in
[EMAIL PROTECTED] (Simon Cozens) writes:
> Can someone please compile a list of all the "is foo" properties that
> have been suggested/accepted as being pre-defined by the language?
> I can't keep track of them all.
Well, here's a start. Here are the ones I
ssions, variables
>> and whatever else I've forgotten about. Properties can be attached to
>> some of these. Can we generalise this at all?
>
>> Of course, the applicability of this is not limited to code coverage,
>> so it would be nice to have something as general
else I've
> forgotten about. Properties can be attached to some of these. Can we
> generalise this at all?
> Of course, the applicability of this is not limited to code coverage, so it
> would be nice to have something as general and multi purpose as possible.
> But I don't wan
to
design something useful into Perl 6 from the start.
So I would like to see able to tag arbitrary information onto just about
everything, including files, packages, classes, subroutines, blocks,
control structures, statements, lines, expressions, variables and
whatever else I've forgotten
On Tue, 22 Oct 2002, Erik Steven Harrison wrote:
: On Mon, 21 Oct 2002 16:49:57
: Dan Sugalski wrote:
: >
: >Almost. At least perl 5's macros look like C. Emacs' macro horrors
: >make C look like Lisp...
:
: This is because C is _clearly_ a dialect of Lisp . . .
Yeah, look at all the extra p
--
On Mon, 21 Oct 2002 16:49:57
Dan Sugalski wrote:
>
>Almost. At least perl 5's macros look like C. Emacs' macro horrors
>make C look like Lisp...
This is because C is _clearly_ a dialect of Lisp . . .
-Erik
>--
> Dan
>
>-
Dan Sugalski wrote :
>
> And, FWIW, emacs is written in C. Granted a much macro-mutated
> version of C, but C nonetheless.
Just like Perl 5 ;-)
> I didn't call the problem unreasonable, I was objecting to its
> characterization as an "essential feature". It isn't. A useful thing,
> definitely, but there are a lot of those. It's hardly essential any
> more than, say, a hash that automagically maps to the current
> directory's files (ite
At 7:22 PM + 10/21/02, Rafael Garcia-Suarez wrote:
Dan Sugalski wrote :
And, FWIW, emacs is written in C. Granted a much macro-mutated
version of C, but C nonetheless.
Just like Perl 5 ;-)
Almost. At least perl 5's macros look like C. Emacs' macro horrors
make C look like Lisp...
--
/
At 11:09 PM -0600 10/20/02, Luke Palmer wrote:
>What's the plan on having properties, or attributes (depending on how
>far we're taking it), on individual characters in a string? I think
>it's an essential feature, as Lisp has shown us. If there's an
>
[EMAIL PROTECTED] (David Whipp) writes:
> It should be possible to define the bookmark methods on the basic string
> class to rebless the object onto a more powerful subclass.
That makes it a doubly good candidate for modulehood.
--
It's 106 miles from Birmingham, we've got an eighth of a tank
ki <[EMAIL PROTECTED]> wrote:
At 11:09 PM -0600 10/20/02, Luke Palmer wrote:
>What's the plan on having properties, or attributes (depending on
how
>far we're taking it), on individual characters in a string? I think
>it's an essential feature, as Lisp has shown
Jonathan Scott Duff wrote:
> > Ok, how about this: Is there a reason I to? Or
> > should I not go there?
>
> Off hand, it sounds expensive. I don't see a way to only let
> the people who use it incur the penalty, but my vision isn't
> the best in the world.
It should be possible to define the
On Mon, Oct 21, 2002 at 02:20:56PM -0600, Luke Palmer wrote:
> Fair enough. Then tell me how you solve this problem: You have a text
> file in a string, that the user has marked several places in. He's
> referring to words for which he wants to keep bookmarks in. Now, he
> deletes text (using su
At 11:09 PM -0600 10/20/02, Luke Palmer wrote:
What's the plan on having properties, or attributes (depending on how
far we're taking it), on individual characters in a string? I think
it's an essential feature, as Lisp has shown us. If there's an
argument otherwise, I
10/20/02, Luke Palmer wrote:
> >What's the plan on having properties, or attributes (depending on how
> >far we're taking it), on individual characters in a string? I think
> >it's an essential feature, as Lisp has shown us. If there's an
> >argumen
1 - 100 of 273 matches
Mail list logo
