On Monday, June 16, 2003, at 10:39 AM, Edwin Steiner wrote:
I'm content if this will be revisited (hopefully by someone with
better overview than mine). It just should not be ignored.
Oh, it definitely won't be ignored. :-) It's come up several times
before -- try searching for "stringification"
On Monday, June 16, 2003, at 11:04 AM, David Storrs wrote:
On Mon, Jun 16, 2003 at 10:15:57AM -0700, Michael Lazzaro wrote:
(I've been operating under the
assumption that an "untyped scalar" doesn't _remove_ the type of
something, it just can store values of _any_ type, and is
On Monday, June 16, 2003, at 11:49 AM, Austin Hastings wrote:
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
Or, if we have "output rules" just like we have "input rules", could
something quite complex be expressed simply as:
"You have <$x as MoneyFormat
On Thursday, August 14, 2003, at 07:00 AM, Alberto Manuel Brandão
Simões wrote:
On Thu, 2003-08-14 at 14:49, Simon Cozens wrote:
Just a hint: don't try writing it and revising it as the language
changes.
I wrote a Perl 6 chapter for a book in December and it is now almost
unusable
due to the pac
On Tuesday, November 18, 2003, at 06:38 AM, Simon Cozens wrote:
Given that we've introduced the concept of "if" having a return status:
my $result = if ($a) { $a } else { $b };
Would that then imply that
sub blah {
... # 1
return if $a;# 2
...
Would that then imply that
sub blah {
... # 1
return if $a;# 2
... # 3
}
...would return $a if $a was true, and fall through to (3) if it was
false?
It sure should, provided there were a correct context waiting, which
would
quite nicel
On Wednesday, November 19, 2003, at 12:28 PM, Smylers wrote:
Larry Wall writes:
: Michael Lazzaro wrote:
:
: >return if $a { $a }
No, it's a syntax error. You must write
Excellent!
I too was quietly hoping someone would say that. These hurt my
admittedly ever-shrinki
On Tuesday, November 18, 2003, at 12:15 PM, Luke Palmer wrote:
Oh, and if you really want to do that return thing without using a
C, you can just:
sub blah {
return $a || goto CONT;
CONT:
...
}
I don't see what's wrong with that. :-p
Umm... refresh my/our memory. Did we
On Monday, November 24, 2003, at 03:28 PM, Luke Palmer wrote:
Damian Conway writes:
In which case I think we just fall back to:
try{$opus.write_to_file($file); CATCH {die "Couldn't write to
$file:
$!"}}
which is, after all, only 5 characters longer than:
$opus.write_to_file($file) c
On Wednesday, November 26, 2003, at 12:13 PM, chromatic wrote:
On Wed, 2003-11-26 at 11:39, Michael Lazzaro wrote:
I think we also need to be skeptical of the false economy of putting
such sugar into CP6AN, if a sizable portion of the community is going
to download it anyway.
A more interesting
On Wednesday, November 26, 2003, at 01:50 PM, Michael Lazzaro wrote:
my $c = (defined($a) ? $a : $b);
Sorry, P5.
Before the grammar police attack...
my $c = (defined($a) ?? $a :: $b);
Parens for clarity.
MikeL
On Wednesday, November 26, 2003, at 12:29 PM, Larry Wall wrote:
If you contrast it with an explicit try block, sure, it looks better.
But
that's not what I compare it with. I compare it with Perl 5's:
$opus.write_to_file($file) or die "Couldn't write to $file: $!";
That has some known prob
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*
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, slightl
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 $b
On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote:
But the agreement could be implied by silence. If, by the time the
entire program is parsed, nobody has said they want to extend an
interface, then the interface can be considered closed. In other
words, if you think you *might* want to
On Tuesday, December 16, 2003, at 09:07 AM, Larry Wall wrote:
Seriously, I hope we can provide a framework in which you can screw
around to your heart's content while modules are being compiled,
and to a lesser extent after compilation. But we'll never get to a
programming-in-the-large model if we
On Tuesday, December 16, 2003, at 12:20 PM, Gordon Henriksen wrote:
finally by default? None for me; thanks, though.
I don't think so; we're just talking about whether you can extend a
class at _runtime_, not _compiletime_. Whether or not Perl can have
some degree of confidence that, once a prog
On Tuesday, December 16, 2003, at 03:00 PM, Luke Palmer wrote:
But Perl hinges on laziness, doesn't it? Eh, I trust that Perl 6 will
make it easy to figure that out in most cases. I was coming from the
perspective that 90% of my projects don't need speed; but I can say no
such thing on account of
On Tuesday, December 16, 2003, at 04:01 PM, Chip Salzenberg wrote:
According to Michael Lazzaro:
As someone who has 90% of their projects relying very critically on
speed
... an anecdote ...
Yes.
and who has had to battle a number of clients' IT departments
over the years in defense of
On Tuesday, December 16, 2003, at 05:36 PM, Chip Salzenberg wrote:
Speed is for users. PR is for non-users.
You want speed? OK, we can talk about the actual speed you actually
need based on your actual usage patterns. But from a design
perspective you're a collection of anecote, not a user base
On Sunday, September 29, 2002, at 05:11 PM, Michael G Schwern wrote:
> Here's some open problems:
>
> Would this be the default behavior for overridden methods, or will the
> parent class/methods have to be declared "is interface" for the
> signatures
> to be enforced on subclasses?
Heck, I'll
On Monday, September 30, 2002, at 05:23 PM, Michael G Schwern wrote:
> OTOH, Java interfaces have a loophole which is considered a design
> mistake.
> An interface can declare some parts of the interface optional and then
> implementors can decide if they want to implement it or not. The
> u
On Tuesday, October 1, 2002, at 12:33 PM, Michael G Schwern wrote:
> Perhaps a way to sharpen the focus on this is to expand the discusson
> of
> strictness to include not just method prototypes but Design-By-Contract
> features as well (pre and post conditions and invariants). Should DBC
> co
> On Tue, Oct 01, 2002 at 03:43:22PM -0400, Trey Harris wrote:
>> You want something like
>>
>> class Car is Vehicle renames(drive => accel)
>> is MP3_Player renames(drive => mp3_drive);
I *really* like this, but would the above be better coded as:
class Car is Vehicle ren
On Tuesday, October 1, 2002, at 02:49 PM, Michael Lazzaro wrote:
> Which implies, I assume, that "interface" is not the default state of
> a class method, e.g. we do need something like "method foo() is
> interface { ... }" to declare any given method
Flipp
On Wednesday, October 2, 2002, at 03:11 AM, Andy Wardley wrote:
> There are a bunch of "advanced" programming techniques like this that
> all fit under the same umbrella:
>
> * Subject Oriented Programming (IBM)
> * Aspect Oriented Programming (Xerox Parc)
> * Composition Filters
> * Ada
> Makes sense, no?
I like that quite a lot.
One question I still have is the syntax of pre/post conditions, e.g:
> method turn($direction, $how_sharp) {
>pre { $how_sharp <= 20 } is private;
>...implementation...
> }
This is obvious
On Thursday, October 3, 2002, at 03:18 PM, Paul Johnson wrote:
>> (As a lame aside, are we going to have a concept of "private" vs.
>> "protected" vs. "public", or just private/public?
>
> No protected. Even Stroustrup admits it was a mistake in D&E.
Oh, thank God. I was hoping people would sa
On Thursday, October 3, 2002, at 04:25 PM, Michael G Schwern wrote:
> On Thu, Oct 03, 2002 at 03:54:09PM -0700, Michael Lazzaro wrote:
>> I have no *good* syntax proposals for this, I don't think I've ever
>> seen the problem solved with syntax that I rea
Observation: We're doing a *lot* of talking past each other.
Proposed Remedy: We need to better document our discussions so that we
don't keep having them.
---
I volunteer (*shudder*) to be another grunt secretary and start
compiling a preliminary document, written as a tutorial for newbies
On Friday, October 4, 2002, at 12:52 PM, [EMAIL PROTECTED] wrote:
> Perhaps to go with Apocalypses and Exegeses we could have Psalms, a
> bunch
> of bitsize perls of wisdom. Except, um, psalms are, by definition,
> sacred,
> so, um, I dunno, just a thought. Larry?
Perhaps "Prophecies". Or
(Disclaimer: My purpose in proposing this is not to recommend it, but
to document whether the idea should be endorsed, or shot down, and any
proposed canonical syntax. Note that the later implications of these
choices are quite substantial. Please discuss!)
[Draft Proposal: Attributes: "publ
(Disclaimer: My purpose in proposing this is not to recommend it, but
to document whether the idea should be endorsed, or shot down, and any
proposed canonical syntax. Note that the later implications of these
choices are quite substantial. Please discuss!)
[Draft Proposal: Declaring Classwi
(Disclaimer: My purpose in proposing this is not to recommend it, but
to document whether the idea should be endorsed, or shot down, and any
proposed canonical syntax. Note that the later implications of these
choices are quite substantial. Please discuss!)
[Draft Proposal: Symmetry between
Thanks, if it's looking like lvalues are really out I'll edit that draft
to take out the lvalue stuff and do it the other way. (And if Damian's
happy with slots, that probably means we can get a lot of the other
attribute recipies out of the way pretty quick. Huzzah!)
I had mixed feelings abou
Dan Sugalski wrote:
>
> There won't be any direct access to attributes outside class methods
> of the class that defines the attributes, unless Larry changes his
> mind in a big way. (And, honestly, probably not even then) Instead
> it'll all be accessed via lvalue methods. If an attribute is exp
On Wednesday, October 9, 2002, at 10:35 AM, Larry Wall wrote:
> Except then we couldn't use it to mean what Ruby means by it, which
> might be handier in real life. (It means to exclude the endpoint,
> so 0...4 is the same as 0..3. But then, that's kind of odd too.)
Uh-oh: my life is gonna s
Yes, you heard right. A cookbook describing stuff that hasn't yet been
designed, for a language that doesn't yet exist. Having flashbacks to
your college years, anyone?
The purpose of the Cookbook is to foster discussion on perl6 OO
concepts, and to start documenting the decisions that are
On Wednesday, October 9, 2002, at 07:54 PM, Chris Dutton wrote:
> One first thing I notice while I'm supposed to be doing homework. :-)
>
> Wasn't "class MyClass;" supposed to work along the line of Perl5's
> "package MyClass;" and make everything following that statement the
> definition of
On Thursday, October 10, 2002, at 02:33 AM, Angel Faus wrote:
> Just a silly note:
>> Recipe 1.9: Using Subroutines as Objects
> I think it was said that the way to avoid the ambiguity here is to add
> & to sub name.
Thanks, applied.
MikeL
On Thursday, October 10, 2002, at 11:23 AM, John Williams wrote:
> my $obj = MyClass(...);
>
> This seems to assume that objects have a default method if you treat
> them
> like a subroutine. Kinda tcl-ish, but I don't recall anything like
> this
> in the apocalypes.
>
> my $obj = MyClass;
Ok, it's only been 24 hours and I've already decided this needs
extending. People like the concept, but want a way to more easily
contribute to it. And as it turns out, it's not as entirely useless as
I had feared. :-)
So I'm completely reversing what I just told a bunch of people via
email.
On Friday, October 11, 2002, at 01:10 AM, Simon Cozens wrote:
> [EMAIL PROTECTED] (Michael Lazzaro) writes:
>> -- A way to submit fixes & new stuff.
>> -- The ability to add (threaded) comments & questions,
>> to encourage less important d
On Friday, October 11, 2002, at 04:11 PM, Larry Wall wrote:
> has Nose $.snout;
> has Ear @.ears is cut("long");
> has Leg @.legs;
> has Tail $.tail is cut("short");
>
> method Wag () {...}
> }
What's the rationale again for the dot in $.snout? Does it imply
Trey Harris wrote:
>
> In a message dated Sun, 13 Oct 2002, Piers Cawley writes:
> > I like that idea:
> >
> >class SomeClass {
> > method class_method ( Class $class: ... ) { ... }
> > method instance_method ( SomeClass $self : ... ) { ... }
> > method dont_care_metho
On Monday, October 14, 2002, at 10:28 AM, Larry Wall wrote:
> On Mon, 14 Oct 2002, Larry Wall wrote:
> And I should point out that this approach would be good not just for
> type purity, but because it optimizes for the common case. Class
> methods
> are much rarer than instance methods. And
On Monday, October 14, 2002, at 11:57 AM, Trey Harris wrote:
>> class SomeClass {
>> cmethod class_method {...} # via a keyword
>> method instance_method {...} # via another keyword
>> sub dont_care_method {...} # check it yourself, as
On Monday, October 14, 2002, at 07:54 PM, Mark J. Reed wrote:
> Heh, indeed. :) But seriously, you could do worse. JavaScript
> receives
> a lot of (IMHO) undeserved criticism. The name is a blatant marketing
No, I've had to use it off-and-on for the past year... it deserves it.
:-) But
I was writing up a quick beginner-level summary on variables &
assignment yesterday evening, mostly to get my head around the syntax
as it currently stands. You can see it at
http://cog.cognitivity.com/perl6/var.html
if desired. The 3 or 4 parts in red are things that I'm making up
On Tuesday, October 15, 2002, at 01:07 PM, Luke Palmer wrote:
>> Any value may be forced, however, into being an explicit type: this is
>> commonly known as casting or typecasting. Typecasting is the act of
>> transforming a value of one type into a value of another type. The
>> typecasting ope
Where is the most definitive list of known Perl6 (not Parrot) builtin
types?
The following have been specified/implied by the A/Es:
scalar
bit (== bool? == boolean?)
num
int
str
bigint
bignum
bitarray (maybe)
ref
rx (or regex,rule?)
code
classname
Object
arra
The Perl6 OO Cookbook, v0.2 is online.
http://cog.cognitivity.com/perl6/
Changes include:
[] *Much* better accuracy in most of the early recipes (better matching
to Apos/Exes and perl6-language: see the 'Status' fields of each
recipe.) More fixes coming very soon.
[] Ability to annotate se
On Thursday, October 24, 2002, at 11:22 AM, Larry Wall wrote:
But we also have to balance it against the desirability of using ~ for
concatenation. Requiring whitespace around _ is a bit of a
rationalization
after the fact, and ~ escapes that problem in most cases.
So (w/out whitespaces):
Brent Dax wrote:
Can the new nefarious use be concat? Pretty please?
On Wednesday, October 23, 2002, at 07:46 PM, Damian Conway wrote:
I guess the only concern is the potential for nasty surprises between:
$str =~ s/a/b/; substitute a for b in $str
and:
$str ~= s/a/b/; substitute a
Since it's been a full month since the start of the monster "operator
precedence" thread, here's what I've been able to gather as the
revised, new-and-improved list of Perl6 operators, IF we did all the
xor/cat/regex-related changes as discussed as of this moment. ;-) I
think this list is ac
On Friday, October 25, 2002, at 01:00 PM, Larry Wall wrote:
Not clear how many of these are just universal or near-universal
methods.
Which would make some of them list-op variants, if we follow Perl 5
rules...
What's the Official Perl difference between a named unary op and a
one-arg univer
On Thursday, October 10, 2002, at 05:11 PM, Larry Wall wrote:
my MyClass $obj = .new;
my new MyClass $obj;
Thanks for the clarification. I like those two OK, personally. If I
were chained to one of those, I wouldn't chew my leg off.
Tying it together with the other thread to mak
On Friday, October 25, 2002, at 02:38 PM, Austin Hastings wrote:
In the manner of Accent, I'd like @ reserved as the RPC operator.
The Role Playing Character operator? Hmm, that has possibilities.
What would this statement do?
+--+
|..@...|
|d.|
|..|
+--+
MikeL
Here's try #2. Things that are not true operators or have other
caveats are marked, where known. LMKA.
unary (prefix) operators:
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not - force to bool context, negate
Chris Dutton wrote:
> So many operators...
Well, this seems a good as time as any to jump in with what's been
sticking in my brain for a while now. Last June, Simon C. wrote a
little philosophical thing, "Half measures all around", which generated
the appropriate amount of good discussion. I wan
Larry Wall wrote:
> : > Now I'm wondering whether these should be split into:
> : >
> : > +&+|+! - bitwise operations on int
> : > +&= +|= +!=
> : >
> : > ~&~|~! - bitwise operations on str
> : > ~&= ~|= ~!=
Well, wait, these mi
> Larry wrote:
> > If one were going to generalize that, one would be tempted to go the Ada
> > route of specifying the radix explicitly:
> >
> > 0123# decimal
> > 2:0110 # binary
> > 8:123 # octal
> > 16:123 # hex
> > 256:192.16
Smylers wrote:
> This is only objecting to having English operators as synonyms for
> symbolic ones. None of the above would apply if where English forms
> were used they were to be the _only_ forms, with no symbolic
> equivalents.
Yes, I think we're basically saying the same thing, but in differ
John Siracusa wrote:
> Larry's just thinking out loud, right?
Yes, and so is everyone else. Most posts here, including Larry's, are
stream-of-conciousness. Heck, in one of the last ones I swear there
were, what, 6 or 7 possible ways to say the same "binary op" things.
90% of everything proposed
FWIW, if people are really eager to keep ^ for xor (I don't think
anything's clicking great as a replacement), we could of course switch
hyper to ~. That would give us, in part:
? ! + - _ # unary prefixes
+ - * / % ** x xx# binary
+=-=
Michael Lazzaro wrote:
> Heck, I'd even argue that "$a mat $b" works, too.
> What does "mat" do? It "mats". If "grep" is a word, "mat" can be a
> word. :-) Or "lik". Or "sma".
Or just z, as in "ma
Simon Cozens wrote:
> I just see code like
> ~~ sub (@x) { map { _ => _ } @attrs x Inf ^, @x }
> and get the screaming heaves.
I agree, it's like the punchline to a perl-haters joke. We're supposed
to explain _that_ to people? :-/ NORMAL people? 8-/ And not get
punched in the face?
Maybe t
If \ meant xor, and some of the other discussed changes:
unary (prefix) operators:
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not - force to bool context, negate
+ - force to numeric context
- - force t
On Sunday, October 27, 2002, at 12:57 PM, Michael Lazzaro wrote:
.&= .|= .\= <<= >>= - (depending on operants)
s/operants/operands/
Sorry bout that. Typing too fast.
MikeL
On Monday, October 28, 2002, at 09:58 AM, Jonathan Scott Duff wrote:
Does xor really need the punctuation? Does xor really need to be a
primitive?
Though bitwise xor is seldom used for most people, other versions are
likely to be more frequent: the 'superpositional' flavor, for example,
is
On Monday, October 28, 2002, at 01:09 PM, Larry Wall wrote:
No. "unless" reads well in English. How do your read $a ! $b ! $c?
"nor"? Maybe it's "$a nor $b"?
MikeL
Okay, take 4, with 'X' meaning xor, so you can see it in context. I
warn ya, I'm gonna keep doing this until there's a "Final" version, for
some value of "Final". ;-) Again, I'm wondering if we're going about
this wrong way -- perhaps we need to go to more effort to save ^ as
xor, and use s
On Monday, October 28, 2002, at 01:57 PM, Austin Hastings wrote:
If we're going to kill the alternate radix literals, better to do
something like hex:123 or hex "123". I'd hate to try to comprehend
$a = -x:123;
more than a week from now.
That x:123 part was my placeholder -- my bad, I forgot th
On Tuesday, October 29, 2002, at 09:08 AM, Jonathan Scott Duff wrote:
Statements like this bother me. Not because I don't think it might be
true, but because it's in future tense. If someone (named Damian :-)
wrote a superposition synopsis that showed the many and varied uses of
superpositions
On Monday, October 28, 2002, at 01:25 PM, Michael Lazzaro wrote:
Again, I'm wondering if we're going about this wrong way -- perhaps we
need to go to more effort to save ^ as xor, and use something
different for hypers, like h<+> or h[+] or `+ or ~+ or ~~+, etc?
OK, I'
On Tuesday, October 29, 2002, at 11:21 AM, Damian Conway wrote:
My personal favorite solution is to use square brackets (for their dual
array and indexing connotations, and because they highlight the
operator
so nicely):
$count = @a + @b;
@sums = @a [+] @b;
Any ideas on what
{ $^a op $^b
On Tuesday, October 29, 2002, at 11:47 AM, Luke Palmer wrote:
[i.e. this change doesn't make any difference]
Doh! You're right, of course. For some reason I was thinking a long
while back that it would be confusing to have
{ $^a op $^b }
if ^ went back to meaning xor. But there's the s
On Tuesday, October 29, 2002, at 01:50 PM, Damian Conway wrote:
PS: Is anyone collecting these examples. It would make writing that
perl.com
article much easier for me ;-)
But of course! Piers is summarizing this entire thread -- right,
Piers? :-)
Aaron Crane wrote:
@x [+]= @y;
I g
Okay, For those of you playing the home game, Take 5, with Damian &
Larry's latest inputs. ^ means xor again, and a few things have been
removed. Comments?
Note that I will next post a list of hyperoperators _separately_.
If the design team could take a look, esp. at the remaining questions,
For this version of the operator list, (since I am unsure that _every_
unary/binary op has a meaningful hyper, and some tentatively have
_two_) I have placed all of them in EXPLICITLY. Please check that I
didn't miss any, or put any in that are incorrect.
hyperoperators:
[op] - as prefix
Larry Wall wrote:
> :... - [maybe] range, exclusive of endpoint [Damian votes No]
>
> Could have ^..^ and ^..too, for all that.
OK, I just gotta say, that's _d*mn_ clever. "Exclusive of endpoint" --
It looks like what it is, and vice versa. I guess that's why you're our
fearless leader.
Brent Dax wrote:
> Larry Wall:
> # There's also an issue of what (1..10) - 1 would or should
> # mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
Actually, I would at first glance think, based on the parens, that:
(1..10)-1
means
((1-1)..(10-1))
means
(0..9)
On Wednesday, October 30, 2002, at 09:25 AM, Larry Wall wrote:
So despite the beauty of
@a [+] @b
I think it cannot survive in its current form. It overloads square
My own backup proposals would be:
h<+>
h[+]
or similar, e.g. give the brackets a prefix to differentiate them
fir
[.]foo() # What does this mean?
One could argue that several ways, depending on what's in the current
topic. It's the exact same thing as the binary form of dot, but with
the left side being implied, as 'the current topic':
topic is a scalar: hyperdot does nothing (scalar hyperop sca
On Wednesday, October 30, 2002, at 11:58 AM, Larry Wall wrote:
I'd even be willing to give up ´foo bar bazª meaning qw(foo bar baz)
for this.
I can't see that right (MacOSX Jaguar) in the email; to me it looks
like a forwardtick and an, um, underlined 'a' -- but in spite of that,
I'm game.
On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
for @a; @b -> $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be solved
if the above were just written:
for (@a;@b) -> ($x is rw; $y) { $x = $y[5] };
Would that suffice to make it cle
On Wednesday, October 30, 2002, at 01:28 PM, David Wheeler wrote:
But given that I don't even know where to go to type them in, and
doing so will likely be a PITA...even though I *love* the idea of
using these characters, might it be better to abandon them for now?
Oh, don't say that! I alre
On Wednesday, October 30, 2002, at 01:46 PM, David Wheeler wrote:
But let me ask you -- how did you input those characters?
Applications/Utilities/"Key Caps" (Again, OSX) which shows you where
they all are.
The «» quotes, for example, are option-\ and shift-option-\
:-)
MikeL
On Wednesday, October 30, 2002, at 03:07 PM, Damian Conway wrote:
In creating my operator list I deliberated shied away from the unary
and binary
multimorphic forms. But I do see Graham's point and would favour
retaining
polymorphic unary C<^> at least.
Meaning that the list:
+ - force
OK, by my count -- after editing to reflect Larry's notes -- only a few
issues remain before the ops list can be completed.
1) Need a definitive syntax for hypers,
^[op] and «op»
have been most seriously proposed -- something that keeps a
bracketed syntax, but solves ambiguity i
Here is an extensive FAQ for Unicode and UTF-8:
http://www.cl.cam.ac.uk/~mgk25/unicode.html
and here is a test file that will show you how many of the "most common
glyphs" (WGL4, via Microsoft) you are capable of displaying in your
current setup:
http://www.cl.cam.ac.uk/~mgk25/ucs/wgl
And if you really want to drool at all the neat glyphs that the
wonderful, magical world of math has given us, check out:
http://www.unicode.org/charts/PDF/U2A00.pdf
now *theres* some brackets!
MikeL
Here is more to think about. No freaking out, this is just for
mulling...
If we, for the moment, assume the use of «op» for hypers, that
obviously raises the _possibility_ of using some other Unicode/UTF-8
characters for other "very special" tasks. I'm not actually advocating
most of these (
On Thursday, October 31, 2002, at 12:18 PM, Chip Salzenberg wrote:
According to Michael Lazzaro:
?? ?? ?? ??? ??? ??? ??? ??? ???
??? ??? ??? ??? ??? ??? ??? ??? ???
??? ???
??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ???
Am I the only person who discovered Korean
While writing documentation: a trivial question on the boolean type,
C:
my bit $light_switch;
Q: Can bits/bools be undefined?
Perl conventions would indicate yes. Does that mean that an array of
bits:
my bit @bitfield;
takes up, at minimum, two bits per, um, bit?
Sorry if this ques
On Thursday, October 31, 2002, at 03:47 PM, Deborah Ariel Pickett
wrote:
(Whine: my Perl undergrad students are too young to remember or
appreciate text adventures. At least some of you oldsters here will
understand.)
Hey! We're not old, we're just version 1.0!
Can we have a "grue" operator
Larry Wall wrote:
> Please don't think of C as a boolean type. There is no boolean
> type in Perl, only a boolean context. Or looking at it from the
> other direction, *every* type is a boolean type.
Er... dang. While I certainly agree with the concept in principle, I'm
having a hard time stick
Adjusted for the most recent notes: includes «op» as the preferred (and
possibly only) spelling of "vectorize". Everything but a few hyperop
issues appears to be close to final, by my count: if/when Larry sticks
a fork() in it, it's done.
hyperoperators:
«op» - When used with any unary or
On Friday, November 1, 2002, at 08:02 AM, Mark J. Reed wrote:
When someone asks "what's the boolean type in Perl?" I'd rather
answer "bit" than "Perl doesn't have one", if for no other reason
than the latter answer will completely freak them out. :-)
Why? Plenty of languages get along just f
1 - 100 of 297 matches
Mail list logo
