I'm so happy! I just found out, totally by accident, that I can type
the « and » characters by pressing AltGr + Z and AltGr + X,
respectively.
Apologies if this is common knowledge, but it was news to me, and I
thought I'd share this little Perl6 of wisdom.
Your mileage may vary, of course,
Larry Wall wrote:
> Yet another approach is to *replace* dot with something that mutates:
>
> @array!sort
> @array?sort
>
> Either of those would work syntactically in that case, since neither !
> nor ? is expected as a binary operator.
What about ? is as a ternary operator:
@foo?ba
Larry Wall wrote:
> multi sub *scramble (String $s) returns String {...}
[...]
> Or you can just call it directly as a function:
> scramble("hello")
Can you also call scramble as a class method?
class String is extended {
method scramble { ..etc... }
}
String.scramble("hello")
Luke Palmer wrote:
> I think $() will help somewhat, as will interpolating method calls, but
> for a compiler, I'd really like PHP-like parse switching. That is, I
> could do something like (I'll use $< and $> for ):
Check out the new scanner module for Template Toolkit v3. It does this
exactly
Luke Palmer wrote:
> But I'm still sure that the unicode-deficient would rather write:
I suspect the unicode-deficient would rather write Ruby.
Adding unicode operators to Perl will just reinforce its reputation as
a "line noise" language.
I know it has been said before, and I'm sure it will be
Uri Guttman wrote:
> i say we just sell them a license to use the US constitution.
Bill Gates wrote:
> What is it with these Linux guys?
> i say we just sell them a license to use Windoze.
:-)
A
Larry Wall wrote:
> Well, we can't use -> because we're using that for something else.
> But it's certainly true that we'll have to have some mechanism for
> disambiguating Color.green from Blackberry.green. After all,
>
> Blackberry.green == Color.red
>
> Or maybe it's
>
> Blackberry::
Larry Wall wrote:
> 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
> $bar.red
[...]
> $bar.red
[...]
> $baz.Byte
>
> it's asking whether the Int property
chromatic wrote:
> The thinking at the last design meeting was that you'd explicitly say
> "Consider this class closed; I won't muck with it in this application"
> at compile time if you need the extra optimization in a particular
> application.
In Dylan, this is called a sealed class. It tells t
Jonathan Scott Duff wrote:
> This is mostly just a gratuitous message so that Piers has something
> to talk about in the next summary
I bet Leon has something to say about that.
> Better would be "We're working on X and have hashed out the details
> of Y but are having problems with Z"
Somethi
Tom Christiansen wrote:
> Anyway, all fun and games with Messrs Engineer and Mathematician,
> you still want to find some sensible way of comparing lazily evaluated
> infinite lists so that you could get some sort of answer. But what
> is that answer? Or what is *an* answer? Can there even *be*
Miko O'Sullivan wrote:
> We already have the ability to embed foreign languages (XML, HTML,
> whatever) using here docs:
>
> $myml = MyXmlParser->new(<< '(MARKUP)');
>
> blah blah
>
> (MARKUP)
True, but what kind of magic is hiding inside MyXmlParser?
One problem is that writing My
Robin Berjon wrote:
> I just have yet to see someone point at one place
> where Perl 5 hinders XML processing in such a way that Perl 6 could help.
If my understanding of the design of Perl 6 is correct, the lexer, parser
and any other related components will be highly configurable and/or
repla
Robin Berjon wrote:
> But as someone that also had to parse other people's random
> formats before we had XML, I would like to stress strongly the fact that
> the current situation is *much* better than it was.
True, but you're also missing the point that XML is a festering pile
of steaming cam
Sam Vilain wrote:
>Associations *are* fundamental object things. Presenting them in terms of
>attributes is the real hack.
Associations *are* fundamental things, but I don't think they are part
of an object.
They describe relationships between objects and should exist independantly
and orthogo
Sam Vilain wrote:
> No. All I'm saying is that this sort of construct:
>
>*{$_} = \&{"Class::$_"} foreach (qw(method method2 method3));
Like mixins? Perhaps something like this:
class My::Class;
mixin My::Random::Number::Generator qw( rand );
mixin My::Serialisation::Marshall qw( fre
Allison Randal wrote:
> It's a balance, like everything else in design.
use Yin::Yang;
s/design/life/g;
A
Adam Turoff wrote:
> The problem with cons/car/cdr is that they're fundemental operations.
> Graham *has* learned from perl, and is receptive to the idea that
> fundemental operators should be huffman encoded (lambda -> fn). It
> would be easy to simply rename car/cdr to first/rest, but that loses
On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote:
> I'm not a Lisp enthusiast, by and large, but I think he makes some
> interesting observations on language design. Take a look if you're
> feeling adventurous...
I can't help feeling slightly deflated. Given the chance to re-design
Lis
Paul Johnson wrote:
> When I later saw it using mutt in an xterm, the tilde was at the top of
> the character, where I was more used to seeing it and it didn't look like
> an arrow any more, nor did it look very good to me.
Ah yes, that's the problem. On all my fonts, the tilde appears at
the top
Damian Conway wrote:
> Really? We don't have any trouble in Perl 5 with an = character
> being used in various unrelated operators:
>
> == comparison
> =assignment
> ~= match
s/~=/=~/
> => comma
> <= less than or equal to
But these are all roughly related to the
Damian Conway wrote:
> [...] <~ and ~>
Michael Lazzaro wrote:
> I too think this idea is fabulous. You are my hero.
I also think this is semantically fabulous but syntactically slightly
dubious. '~' reads 'match' in my book, so I'm reading the operators
as 'match left' and 'match right'. Or p
Luke Palmer wrote:
> The difference between POST and NEXT is simply that POST fails to
> refrain from executing after the final iteration, while NEXT does not.
Or in other words:
The difference between POST and NEXT is that POST executes after the final
iteration, while NEXT does not.
NEXT happ
Simon Cozens wrote:
> Once again we're getting steadily closer to inventing Ruby.
Agreed, but I don't think this is necessarily a Bad Thing.
Larry said ~~ "People have been borrowing ideas from Perl for a long time,
now it's time to borrow some back".
I like Ruby, I like dot ops, and I like bein
Michael Lazzaro asked:
> foo $a, $b, $c, $d; # how many args?
Damian Conway wrote:
> Yep. Can't be known unless predeclared and hence compile-time discernible.
> And methods can't be discerned in the presence of run-time dispatch.
Is that not the purpose of an interface? That is, to specify at
Me wrote:
> Well, I could argue that c) already exists
> in the form of passing parameters in parens.
This reminds me of the Law of Demeter. It specifies what your methods
should and shouldn't be able to do if you want to build a bright, shiny
system that never has bugs, maintains itself, turns w
Larry Wall wrote:
> So I was thinking it'd be better to use something different to
> represent the outer topic...
How about this:
$_ # current topic
$__ # outer topic
$___ # outer outer topic
...etc...
I also wondered if $= might be a suitable alias to the current ite
Quoted from "Seven Deadly Sins of Introductory Programming Language
Design" [1] by Linda McIver and Damian Conway:
We have shown over one thousand novice programming students
the C/C++ expression:
"the quick brown fox" + "jumps over the lazy dog"
and asked them what they believe
Michael Lazzaro wrote:
[...some good points...]
> and has resulted in us revisiting decisions *repeatedly*
Simon Cozens wrote:
[...some good ideas...]
> [1] You can tell I've been rereading MMM...
Maybe there's some benefit to be had from revisiting old material? :-)
I can't think of any non-tr
Nicholas Clark wrote:
> I think that the first syntax
>
> class Car::Q is Car renames(eject => ejector_seat)
> is CD_Player renames(drive => cd_drive);
>
> makes it more clear that I'd like to pick and choose which methods
> the composite object gets from which parent.
But now you'
John Williams wrote:
> Reaction #2: Inheritance would automatically delegate all those
> methods, so again, in what way does inheritance _not_ solve the problem?
Many real life systems are composed from elements, not inherited from
elements. A car is not a wheel, but is composed from 4 (or more
On Mon, Sep 30, 2002 at 11:22:02PM -0400, Michael G Schwern wrote:
> Last year at JAOO I stumbled on this thing called Subject-Oriented
> Programming which looked interesting.
There are a bunch of "advanced" programming techniques like this that
all fit under the same umbrella:
* Subject Ori
[EMAIL PROTECTED] wrote:
> [...] whose type is simultaneously C and C.
Has any thought yet gone into the builtin Perl types and what they will
be called in Perl 6? Will there be a difference between the C of
something and the type(s) that C returns?
In keeping with the lower case C and C exa
A short time ago, in a nearby thread, Larry Wall wrote:
> Perhaps we should just explain continuations in terms of time travel.
Funny. I wrote a message to this effect the other night, but decided
not to send it (too tired to decide if I was talking sense or nonsense).
I was about to propose t
On Tue, Jul 02, 2002 at 03:20:35PM -0500, Dan Sugalski wrote:
> I'm pretty sure the iterators they build are just closures with named
> arguments, and behave as any other closure would behave.
Not quite. Ruby iterators expect a block. This is very much like a closure
except that block paramet
On Sat, Jun 08, 2002 at 06:51:19AM +1000, Damian Conway wrote:
> I have no doubt that, once Perl 6 is available, we'll see a rash of modules
> released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML.
I have no doubt that, once Perl 6 is available, we'll see a rash of module
On Fri, Apr 26, 2002 at 08:49:23AM +1000, Damian Conway wrote:
> for $results.get_next() {
> FIRST { print "Results:"; }
> NEXT { print ""; }
> LAST { print "Done."; }
> print $_;
> }
How about something like this:
for $results.each() {
print
On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
> So the main reason that objects can function as hashes is so that the
> user can poke an object into an interface expecting a hash and have it
> "make sense", to the extent that the object is willing to be viewed like
> that.
AKA the
On Wed, Jan 23, 2002 at 08:30:41AM -0800, Larry Wall wrote:
> : INIT, DESTROY, AUTOLOAD, etc., all make sense to me. They really are
> : special blocks that normally only occur once in a file. But CATCH and
> : NEXT are part of normal syntax. I don't think they're any more "unusual"
> : in the
xplicitly marked as such. This could,
of course, be done automatically for you by a C pragma, or
something similar, but it shouldn't be the default case.
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
he prototype should be on the function name, not on the attribute.
sub foo ($value) : lvalue { }
Thus the prototype covers both cases:
$x->foo($y);
$x->foo = $y;
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTE
Darn, I sent this to perl6-announce instead of perl6-language.
Let's try again.
--- Forwarded mail from "Andy Wardley" <[EMAIL PROTECTED]>
I thought very carefully about this before writing the Highlander
Variables RFC, and came to the conclusion that it's a bad ide
ist '@'
@$foo{bar,baz} # '$foo' is a hashref, sliced to return a list '@'
You get these weird situations where you're accessing a variable as
'@something' but it's actually coming from '%something'. Hence the
Highlander Variables
erfully
advanced and globally cool namespace facility, then so much the
better. At the moment, I've only got 'package' to work on, and
the 'class' concept is, significantly different, IMHO, as to warrant
a new "working title" for now. Nevertheless, I accept the above point.
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
> Since you didn't mention it in your references, you may want to
> check out RFC 92, Extensible Meta-Object Protocol -- Method Search
> at http://tmtowtdi.perl.org/rfc/92.pod
I saw it after I posted the RFC. Yes, this is exactly the kind
of support that we need in the core to allow us to do th
> Couldn't:
>my $u = User.new('abw', 'Andy Wardley', '[EMAIL PROTECTED]');
> just be
>my $u = User->new('abw', 'Andy Wardley', '[EMAIL PROTECTED]');
>
> And:
>$foo.bar.baz = 10;
> Just be:
> Spinning off from Larrys syntactic comment and Mike
> Pastores example, how about some of the following:
How about any variable created in UPPER case is a constant?
Quite restrictive, and likely to screw many things up, admittedly,
but it's an easy rule to remember and one which is generally
> I know other languages call it zip, but personally I dislike that name
> as zip() is commonly used with reference to compression. Although
> I do not have a good alternative.
fold() and unfold()?
merge() and cleave()?
A
1 instead
of the subref. So I have to delete $INC{ $file } before I require it.
There are other ways I could easily do the same thing (the Data::Dumper
approach for one).
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
> Before it's too late - please, don't impose either '$self' or '$this',
> but make this a per-module choice. I deal with people of both these
> religions...
What about '$me'? It ties in nicely with 'my' (although perhaps for the
wrong reasons), it's half as much typing as 'self' or 'this' an
at no point did I suggest making exceptions for
$ARGV/@ARGV, etc. I just flagged them as issues that needed addressing.
A
--
Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated.
<[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
ar. I was simply suggesting that this would
one possible way for the Perl5-Perl6 translator to handle the case where
a script uses more than one variable of the same name. It would need
to change the name of one or more of the variables to avoid conflict.
@array would still be @array.
A
=head1 TITLE
Highlander Variables
=head1 VERSION
Maintainer: Andy Wardley <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Version: 1.0
Mailing List: perl6-language
Number: TBA
=head1 ABSTRACT
Perl5 supports three distinct variable types for any given variable
name correspond
53 matches
Mail list logo
