Funky «vector» operator
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, but now that I know that it's been hiding there in my keyboard all along and I didn't need to do anything special to set it up, I don't feel so uneasy about it being a Perl 6 operator. A
Re: Mutating methods
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)
A
Re: Mutating methods
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?bar:baz; Or am I missing.something? A
Re: Semantics of vector operations
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 said again, but this is a really bad idea, IMHO. Sure, make Perl Unicode compliant, right down to variable and operator names. But don't make people spend an afternoon messing around with mutt, vim, emacs and all the other tools they use, just so that they can read, write, email and print Perl programs correctly. A
Re: Compiler writing tools
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 ? and ?): Check out the new scanner module for Template Toolkit v3. It does this exactly that. It allows you to specify as many different tag styles as you like and uses a composite regex to locate them in a source document. It extracts the intervening text, and then calls back to your code to do whatever you like with them. It takes care of the surrounding text and handles things like counting line numbers so that you don't have to worry about it. The code is still in development so you'll need to get it from CVS. See: http://tt3.template-toolkit.org/code.html Everything is raw and undocumented, but examples/scanner.pl shows an example of what you want to do. Be warned that I'm working on this right now, so things are changing often. Having said that, the scanner is pretty much stable, although the handler object that it interacts with isn't. A
Re: This week's summary
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
Re: enums and bitenums
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::green == Color::red [...] I don't know the syntax for disambiguating on the green end yet. Maybe one of $foo ~~ Color::green $foo ~~ Color.green $foo ~~ Color[green] Or maybe something else. How about a single colon? Color:green This is the same syntax employed in XML namespaces and URIs, for example: xml xmlns:color=http://example.com/xml/color.xsd; color:green/ /xml Don't tell me, we can't use : because we're using that for something else. :-) Presumably, the parser could be smart enough to entuit the role on either side of a comparison if the other is specified. $foo:Color ~~ Color:green $foo ~~ Color:green # assumes $foo:Color $foo:Color ~~ green # assumes Color:green I'm thinking the ordinary method $foo.Color implies $foo.as(Color) What if your $foo object has a regular method called Color? Would it get called in preference? A
Re: enums and bitenums
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 fulfills the Byte constraint, but that's getting kind of strange. If the roles are first class objects then their traits are defined as methods, right? Boolean.true($foo) Color.red($bar) Int.byte($baz) Then assuming that certain objects inherit certain roles, you could use something like the Perl 5 $self-SUPER::new() syntax. Only it would look more like this: $foo-Boolean.true $bar-Color.red $baz-Int.byte Another implication is that, if properties are subtypes, we can't use the same name as a cast method. Since $baz.Byte only returns true or false, we'd need something like (yuck) $baz.asByte [...or...] $baz.as(Byte) Or: $baz-Byte That would make something like this: $foo-Color.red the same kind of thing as: $foo.as(Color).red A
Re: Next Apocalypse
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 the compiler that it's safe to resolve method names to slot numbers at parse time, IIRC. Seems like a nice idea. A
Re: Next Apocalypse
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 Something like: We're working on Perl 6 and have hashed out the details of Perl 6 but are having problems with users who keep wanting regular updates :-) A
Re: == vs. eq
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* one? Godel seems to think there is an answer, but he doesn't know what it is. Turing is trying to working it out on a piece of paper, but he can't say when (or if) he'll be finished. :-) A
Re: Embedded foreign syntax (was Re: P6ML?)
Miko O'Sullivan wrote:
We already have the ability to embed foreign languages (XML, HTML,
whatever) using here docs:
$myml = MyXmlParser-new( '(MARKUP)');
thingy
blahblah blah/blah
/thingy
(MARKUP)
True, but what kind of magic is hiding inside MyXmlParser?
One problem is that writing MyXmlParser to parse and validate XML and
then generate some corresponding Perl data structure is difficult and
error prone.
In the simple case, XML::Simple is your friend. But as Robin points
out, the simple approach falls down work when you need finer control
over what you're doing.
You can use the XML::Schema modules (if you're feeling brave) and that
will generate a validating parser with control over the generated data
structure. But it's big and bulky and the complexities of XML Schema
itself make it a daunting task.
There are various other modules and techniques which can acheive the
desired result, but I've yet to find one that was both easy to use and
powerful (although I need to check out those links that Robin posted).
So I'm thinking that if the Perl 6 parser is as flexible and powerful
as promises, then can we adapt it to simplify the task of parsing XML
into internal data structures?
One benefit of inlined XML over the example above is that it would be
parsed at compile time, not runtime. When our modified parser
sees this:
use Perl6::XML;
thingy
blahblah blah/blah
/thingy
It would effectively re-write it as if written:
my $thingy = {
blah = 'blah blah',
}
and then generate the appropriate opcodes to implement it at runtime.
A further benefit would be that your parsed and validated XML markup
could then be stored as Parrot bytcode. You would effectively be
compiling XML into bytecode that you could load into other programs
with a simple use. That would be neat.
As and when we need more control over the XML validation or code
generation, we would write our own modified XML grammar modules.
Apocalypse 5 suggests this would be a simple matter of defining a
few new 'rule' constructs. For example, we might want to add a rule
for matching thingy/blah that constructs a list rather than a scalar.
Thus, the XML would be parsed as if written:
my $thingy = {
blah = [ 'blah blah' ],
}
This is all largely hypothetical, of course. Hence the continued hand
waving and general lack of detail. Consider it an open thought in process.
:-)
A
Re: P6ML?
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 camel turds that has been over-designed and over-engineered by committee for 4 decades and still isn't any closer to being pleasant or easy to use. Convergence is good, unless you're converging in a bad place. Now all our markup is verbose, difficult to parse, memory hungry, tiresome to manipulate, and so on, (unless you're using YAML of course). XML is Yet Another Silver Bullet Bandwagon that we all jumped on because the XML software vendors told us to. Anyway, this isn't the time or place for an anti-XML rant. Suffice it to say that at least one of us is hoping that we can do markup better in Perl 6. A
Re: P6ML?
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 replaceable. The goal is to provide support for little languages by separating Perl the language from perl the interpreter. It will be possible to modify or replace Perl the grammar so that perl the program can parse other languages, including Python, Ruby and presumably, XML. So instead of writing Perl programs to parse and manipulate XML, it should be possible to modify Perl itself so that it parses the XML directly into some internal form suitable for programmatical manipulation. I presume that it should also be possible to extend the rules of a default non-validating XML parser grammar with additional rules to encode an XML schema. On top of that it should be possible to define further production rules that are invoked as the source document is parsed, i.e an XML schedule (schema/schedule ~= pattern/action). How exactly this will manifest itself, I cannot tell. Nor can I say if this is actually a sensible thing to do or not. But unless my understanding is warped, support for parsing XML and other markup languages could be moved down into the core of the parser internals for Perl 6. For example, it might be possible to do something like this: use Perl6::XML; thingy blahblah blah/blah /thingy use Perl6; print $thingy.blah; This is all speculation and hand-waving, of course. But the point is that Perl 6's extending parsing capabilities could well provide a much greater level of integration between Perl, XML and various other programming and markup languages. My rant against the XML machine was really an aside. Take everything I say with a pinch of salt. :-) A
Re: Object spec
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 orthogonal to them. Dave Whipp wrote: An association is a mechanism that permits one object to navgigate to another. If the association is bidirectional, then it is possible to also navigate from the target back to the source. Each direction of navigation should be given a unique identifer. Category theory has something to say about this. I hope I can provide an essence of it, despite my limited understanding of the subject... A category is defined by a collection of elements (objects in this case) and a number of morphisms (relations) that provide mappings between the different elements. There are many different kinds of morphisms: epimorphisms (one-to-), monomorphisms (-to-one), isomorphisms (one-to-one), polymorphisms (-to-many) and so on. In category theory, morphisms are dual, so that for each relationship represented by an arrow between two objects, there is a reciprocal relationship travelling back down the arrow in the opposite direction. Traditional databases and object systems are based on set theory. Set theory is in fact just one kind of theory that is described by category theory (think of Category Theory as a class and Set Theory as an instance). The category morphisms that are defined by set theory are 'identity' and 'contains' (insert general paraphrasing and hand-waving warning here). The 'identity' isomorphism gives each element in the set a unique identifier so that you know which one you're talking about at any time. 'contains' is a polymorphism that defines which elements are contained by which other elements. If you want to make it an ordered set, then you need to add another morphism, 'before' (and its dual morphism 'after') which tells you which of any two elements in a set is ordered before the other. If you want to make a tuple, hash, queue, stack, bag, stream or multi-coloured, cross-referenced, hyper-indexed, double-camel Larry space in 9 + 3i dimensions, then you just need to add a few more morphisms that define those extra relations that are characteristic of that kind of information space. In summary: Category == [ Elements, Morphisms ]# math terminology == [ Objects, Associations ] # programming == [ Records, Relations ] # database An association is either consitant, or inconsitant. I think it is better to assume that there is no such thing as an inconsistent morphism. If the shoe doesn't fit, then don't wear it! Find another shoe or go barefoot. :-) While it it is obvious that associations can be implemented using attributes, it seems to me that, to do so, is [ ...not so good... ] Agreed. Associations are no more part of an object than an electric current is part of an electron. The field is defined by the interaction between fundamental particles but is not an inherent part of the particles themselves (wave/particle duality and other quantum mechanical chicanery aside). The only reason that we are currently forced to use attributes to represent our relations is because our OO systems and databases are based on set theory. An object or database record is conceptually nothing more than a set containing attributes. We define relations using attributes as foreign keys because there's no other way to do it. If instead we borrow the conceptual model from category theory and provide a mechanism for defining elements and relations *separately*, then it should be possible to build all kinds of fancy information spaces with any number of different inter-element relationships defined. The only language that I'm aware of that implements something like this is CAML (although I'm sure there must be others). Reading from http://caml.inria.fr/ercim.html : It is possible to define a type of collections parameterized by the type of the elements, and functions operating over such collections. For instance, the sorting procedure for arrays is defined for any array, regardless of the type of its elements. Anyway, the gist of this long rambling post is that In My Humble Opinion, if Perl 6 is to provide the ability to define associations between objects, then it should do so as part of a larger category mechanism rather than as an extension to the class/object mechanism. A
Re: newline as statement terminator
Allison Randal wrote: It's a balance, like everything else in design. use Yin::Yang; s/design/life/g; A
Re: Arc: An Unfinished Dialect of Lisp
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 the huffman nature of car/cdr. Good point, but I can't help thinking that list/head/tail or list/item/rest (for example) would be preferable to cons/car/cdr. More meaning at the cost of a character or two. I doubt there are few people who remember, ever knew or even care that car is Contents of the Address Part of the Register and cdr is Contents of the Decrement part of the Register (yes, I had to look them up :-). Even when you know what the acronyms stand for, they still doesn't make a great deal of sense. A
Re: Arc: An Unfinished Dialect of Lisp
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 Lisp from scratch, the tasks on the top of my TODO list to address would be: * getting rid of some/all those damn parenthesis * renaming cons/car/cdr to something meaningful Alas, these are about the only parts he's not changing. He promises that Arc will have a syntax one day, but there isn't one yet. The other comments that caught my eye were that Arc is designed for Good Programmers[tm] and that it was particularly targetted at developing web applications. Alas, my experience seems to suggest that most of the people writing web applications are monkeys who would rather have something designed for Bad Programmers, like PHP. A
Re: L2R/R2L syntax (was Re: Everything is an object.)
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 and it doesn't look anything like an arrow. Viewing it on a web browser with the tilde centered vertically does indeed bring out the arrow-ness of it. A
Re: L2R/R2L syntax (was Re: Everything is an object.)
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 concept of equality, be it
testing equality, enforcing equality by assignment, equality in terms of
matching a pattern, setting a parameter to equal a value, testing is
something is equal or less than equal to something else.
The use of '=' seems entirely consistent in these operators.
-- decrement
-difference
-= subtraction
- dereference
-X file op
The first 3 all relate to the familiar concept of 'minus', or more
precisely a delta between two values. The last uses '-' as 'dash',
another familiar concept which doesn't grate against the first usage,
IMHO. The arrow is a special case. I don't read that first character
as '-', I think of the operator as one. I guess the visual cue forces
me to see it like that.
These operators may not be internally self-consistent, but I don't think
it's a problem having different meaning for '-', given that both meanings
are well understood to anyone who knows basic math and has used a command
line program with a -x argument.
I'm just suggesting the same for the ~ character:
~~ smart-match
~concatenate
~| stringy bitwise OR
~ append args
~ invocate
This is where I get lost. I see 4 different concepts being overloaded
onto '~'.
In the first it indicates 'match' just as it always has for =~ and !~.
In the second, it is being used for concatentation - nothing to do with
matching. In the third it is being used to cast stringwisely - nothing
to do with matching or concatenation. In the fourth and fifth it is being
used to re-order arguments - nothing to do with matching, concatenation
(well, possibly concatenation of argument lists) or stringwise casting.
Now that I look at it again, the '~~' operator bothers me in particular.
The first '~' seems to indicate 'stringwise' in keeping with '~|'
and the second implies 'match' in keeping with '=~'.
I find it questionable to use the same character twice in one operator
and have different semantics implied for each. '~' should either be
'match' or 'stringwise' but not both.
I would like to see '~' kept for matching and just matching. It is well
known in this role and is analogous to the roughly equals operator
in the Real World (extended ASCII character 247 - just don't ask me to type
it).
I also think '_' should be used for concatenation because it's in keeping
with the existing use of 123_456.
As a prefix character to indicate stringwise (numberwise, bitwise, etc)
casting, can we not use a single character prefix, e.g. 's' for string,
'n' for number, 'b' for bitwise, 'v' for 'vector', and so on?
$a s| $b;# stringwise
$a b| $b;# bitwise
$a n| $b;# numberwise
@a v| @b;# vector
@a vsn| @b; # vector stringwise bitwise
I see these as being similar to regex flags. In a regex we don't
have two separate metacharacters for matching \w case sensitively or
insensitively. Instead we use the 'i' flag outside the regex or
within the regex, scoping the parts of the pattern to which it applies:
m/foo/i
m/(?i:foo)/
m:i/foo/
I think we should adopt the same strategy for regular operators. Rather
than create umpteen new operators to perform every operation in every
different style, we should keep the operation orthogonal to the context
in which the operator is applied. So instead of having a vector addition
operator, we have an addition operator and a vector flag which can be
applied to it.
I mean, compare:
@a ~ grep {...} ~ map {...} ~ sort ~ @a;
with:
@a | grep {...} | map {...} | sort | @a;
I don't know about *your* font, but in mine the ~ and ~ versions are
at least twice as readable as the | and | ones.
In my font, or perhaps more importantly, to my eye, the | and | are
more readable. But regardless, I think it's more important to make the
operators consistent with each other, than to make them look pretty or
easy to read. The latter is important, of course, but I personally believe
that it's no use making something easy to read if the meaning is still hard
to comprehend. Better to make something harder to read but easier to
understand.
A
Re: L2R/R2L syntax (was Re: Everything is an object.)
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 perhaps even 'stringify left' and 'stringify right' with a different reading of '~'. I would prefer something like | and | which has a more obvious connotation (to me at least) of pipe left or pipe right. Damian is my hero regardless. :-) A
Re: PRE / POST in loops
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 happens before the next item, POST happens after each item. I hope this clarified things. It has failed to refrain from unenlightening me. :-) A
Re: right-to-left pipelines
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 compile time that a given object conforms to a particular set of method signatures? The method is still resolved for dispatch at runtime, depending on the object type, multimethod arguments, etc. At compile time we don't know which method will be called, but, thanks to the interface, we do know what argument(s) it will be expecting. A
Re: Unifying invocant and topic naming syntax
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 water into wine, etc. The essence is about limiting what you can access (and therefore screw up) from a particular scope. It's like a mild form of the no side effects policy of certain functional programming languages. I'm not sure how applicable it's going to be to Perl 6, but here's the view from 30,000 feet. Object Form of Law of Demeter - Do not talk to strangers. Within a method, messages can only be sent to the following objects: 1. A parameter of the method, including the enclosing object (this or self); 1.1. For pragmatic reasons: a global object; 2. An immediate part object (computed or stored): 2.1 An object that a method called on the enclosing object returns, including attributes of the enclosing object; 2.2 An element of a collection which is an attribute of the enclosing object; 3. An object created within the method. Usenet Form of Law of Demeter - * You can play with yourself. * You can play with your own toys (but you can't take them apart), * You can play with toys that were given to you. * You can play with toys you've made yourself. Interested parties should Google[ law of demeter ] for the full story. A
Re: Unifying invocant and topic naming syntax
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 iterator.
It has a nice mnemonic, looking as it does like a '_' stacked on top
of another.
while $something {
if ($=.first) {
# first iteration
}
elsif ($=.last) {
# last iteration
}
}
You could then use $==, $===, etc., to access outer iterators:
while $foo {
while $bar {
if ($==.first) {
# first foo
}
if ($=.first) {
# first bar
}
}
}
A
String concatentation operator
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 the effect of the + sign is. Not one of them has ever suggested that the + sign is illegally attempting to add the address of the locations of the first two characters of the two literal strings. Without exception they believed that the + should concatenate the two strings. Makes perfect sense to me. Can we overload + in Perl 6 to work as both numeric addition and string concatenation, depending on the type of the operand on the left? I realise the answer is probably not, given the number/string ambiguity of Perl variables: my $a = 123; my $b = 456; $a + $b; # 579 or 123456? I quite like '_' as the string concatenation operator (so much so that I added it to the Template Toolkit some time ago, confidently telling people that it's what Perl 6 would use :-). It ties in nicely with the 123_456 numerical style. On the other hand, I'm not a big fan of using '~' to indicate string context. The tilde (aka wobbly operator) seems much better suited to smart matching, IMHO, being reminiscent of the almost equal to operator (which I would attempt to include here if I had the slightest clue how to make my keyboard speak Unicode). Another option: could we quote operators to indicate string context? $a + $b This would tie in nicely with using [ ] to indicate vectorised operators, although I realise that particular syntax has been disvogued of late. a [+] b A [1] http://www.csse.monash.edu.au/~damian/papers/ [2] [2] Good paper, well worth a read. That Conway chap seems to know his cookies. His name rings a bell, too...
Re: Interfaces
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've turned composition back into inheritance, and I think it's important to be able to distinguish between the two. The car is definately not a CD player, it just has one. I think we need a more flexible syntax for specifying how interfaces should be constructed in the case of composed objects, rather than turning composition into inheritance to avoid the problem. A
Re: Subject-Oriented Programming
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 Oriented Programming (IBM) * Aspect Oriented Programming (Xerox Parc) * Composition Filters * Adaptive Programming - Demeter Method and Propagation Patterns They're all attempting to achieve the same goal - a clear separation of concerns - and although the details are different, the overlying principal is the same. They are all metaprogramming layers which allow you to put wrappers around your code, and in particular your objects. These wrappers intercept method calls and can modify them, redirect them, and otherwise jiggle around with them in all sorts of interesting ways. For example, AOP identifies cross-cutting aspects (like error handling, logging, etc) which cut across an entire system. It's considered bad form to implement logging is each of the 20 object classes you're using because you've lost the separation of concerns. If you want to change the way logging is handled, you have to go and change 20 classes. You can use inheritance or delegation to acheive a clear separation of concerns, but these have their own problems. The inheritance route tends to lead to large and cumbersome object hierarchies that are fragile to change and beset with the problems of multiple inheritance. Delegation is sometimes better, but tends to lead to highly fragmented programs where it is difficult to see the wood for the trees. AOP tackles this problem by allowing you to define different aspects of your program (e.g. database access, user interface, error handling, logging, etc.) and then weave them together by defining join points and leaving the pre-processor to join up the dots. Template processing systems are a simple example of AOP. If you write a CGI script with Perl code and HTML fragments interleaved then you make it hard to read, update and understand. Better is to define your Perl code in one place (the implementation aspect, or model in another parlance) and your HTML markup in another (the presentation aspect, or view) and then leave it to your favourite template processor to weave the two together. The approach of SOP is to define an object-like entity, the subject which is a wrapper around one or more objects. This acts like a facade around the inner objects, allowing method calls to the subject to be directed to the appropriate inner object, possibly with various forms of manipulation taking place en route. For example, you might have an employee object defined by your accounts department which includes payroll number, employee information, salary, etc. You might want to reuse this object in another application but without exposing salary details for employees. By defining a subject to enclose the object, you can effectively hide these fields. You can also create composite subjects where an employee has a dozen fields, methods, etc., which are implemented by 3 different underlying object classes. Or you might want to implement some kind of security layer in your subject so that only certain privileged people have access to sensitive information. You do all these things in the subject wrapper and don't need to change your underlying objects. Composition Filters are very similar but substitute subject for filter. You compose collections of object and define how the method calls to them should be filtered. Adaptive Programming is slighty different in that it defines a methodology for modelling a problem domain, and provides tools for generating code (C++) to implement it. The Demeter Method is a best-practice approach for designing your underlying objects so that they fit nicely together. Propagation patterns are used to say, in effect, the shoulder bone is connected to the arm bone, you turn the handle and out comes your code, with everything connected together and working in harmony as it should be. This is a form of Generative Programming, which is the general term for any process whereby you define a high-level model of a program and have generators actually write the program for you (or more commonly, just the wiring code between existing objects). This is slightly different from the usual metaprogramming approach of AOP and SOP which make extensive use of C++ templates to pre-process your program code. As for Perl implementations... hmmm. The key step is to identify/implement a mechanism whereby we can put hooks into object vtables, allowing user code to intercept methods called against objects. Ruby has an AOP module (AspectR ISTR) which does this, making it trivially easy to intercept calls to a particular object method and perform some action on the way. For things like debug tracing, logging, security layers, etc., this is invaluable. With such a
Perl 6 types: ref() vs isa() (was: Just reading up on Pike...)
[EMAIL PROTECTED] wrote: [...] whose type is simultaneously Cstr and Cint. 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 Cref() of something and the type(s) that Cisa() returns? In keeping with the lower case Cstr and Cint examples above, will the builtin Perl types ARRAY, HASH, SCALAR, etc., have lower case equivalents? Is this an opportunity to replace the ill-named CARRAY with CLIST, or rather Clist? (I'm sure I've heard Larry say that, with hindsight, he wishes he had spelled 'ARRAY' as 'LIST', so I hope I'm not speaking out of line). Could we also come up with a snappier name than CSCALAR to denote a single item reference? Perhaps Citem, or just plain Cref? Presumably, Cref() would continue to work as it always has, while Cisa() returns the most specific type for a variable when called in scalar context, or a list of the type and all supertypes when called in list context. var ref isa - \@foo ARRAYlist / ref \%bar HASH hash / ref \$baz SCALAR item / ref my Dog $spotDog Dog / Animal / obj / ref blah blah -str 3.14-num 42 -int / num The only RFC I can find that's related is 224, where Damian talks about making ref() more magical. http://dev.perl.org/rfc/224.pod Any other thoughts on this floating around out there? A
The Past, Present and Future of Continuations (was: Perl 6 Summary)
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 that 'continuation' is too long a word for lazy Perl folk to bandy around at will, and possibly too ivory tower for most people to grok. Another way of looking at it is that a continuation is a hypothesis about the future, and calling the continuation is a way of saying oops about that hypothesis. My suggestion was along the lines of using .past, .now and .future to reference the calling, current and future continuations, respectively. I also wondered if .here and .there would somehow fit in to reference the current context, or remote context of a continuation. I was thinking along the lines of a continuation being a here and now, a collection of space and time (or in the context of a continuation, the shape and state of the program) bundled up to be transported safely over there to a future now where it can be unpackaged and used much like a wormhole. Maybe a continuation is like a nipple pierced in the fabric of space and time through which many different threads can be strung? Or like a Quantum Entanglement - a Bose-Einstein Condensate spread along the length of an camel's hair, merrily transporting perlons back and forth? But I must admit that my understanding of continuations (and the fabric of reality) is incomplete, and quite possibly flawed, being limited to what I've read on this list and read (but mostly not understood) in Appel's book. I'm sure I don't yet understand how it all fits together, and I certainly can't see how to make the syntax fall into place. That's a job for a linguist and a mad scientist. :-) Basically, we need to find the right oversimplification to make people think they understand it. Absolutely. But talking about time travel, particuarly in the future, half-past-imperfect, stepping-sideways-through-time tense will never having to had been a simple matter for us to hoov comprehended. [*] Now I know I'm talking nonsense, so I'll stop right here and now. :-) A [*] said with a tip of the hat to the fond memory of Douglas Adams
Re: Apoc 5 questions/comments
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 modules released in the Grammar:: namespace. Including Grammar::Romana, Grammar::Klingon, Grammar::Buffy, Grammer::Mispelt, and others... :-) A
Re: Unary dot
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 uniform access principle.
This was something that I was very keen to exploit in the Template Toolkit
where foo.bar is interpreted as Do(t) The Right Thing to access the
'bar' part of 'foo', be it the 'bar' key in the 'foo' hash or the 'bar'
method of the 'foo' object. The result is, of course, that you can use
a hash of static data one day (great for mocking up web pages for example)
and later upgrade it to an object which fetches/generates data on demand
(e.g. from a database) when you put your pages into production.
Alas, I also designed a flaw into the system by introducing virtual
methods that TT automatically applies onto various data types, equivalent
to various Perl functions, e.g. somehash.keys or somelist.size. As
convenient as this is, the problem lies in the fact that you can't
differentiate somehash.keys between the Perl equivalents of Ckeys %$hash
or C$hash-{keys}.
So my thought for version 3 of TT is to introduce somehash.{keys} as
a syntax to mean only the 'keys' key/method of the 'foo' hash/object
but *NOT* the 'keys' virtual method and to leave somehash.keys resolving
to the virtual method as it currently does.
Am I right in thinking that this would then be (roughly) consistent with
the Perl 6 syntax?
e.g.
TT3 Perl 6 Perl 5 (hash) Perl 5 (obj)
foo.keys $foo.keys keys %$foo $foo-keys()
foo.{keys} $foo.{keys} $foo-{keys} $foo-keys()
Hang on, now I'm a little confused - I thought that hashes were supposed
to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
But then that would then violate the uniform access principle because
hash/key access has a different syntax from object/method?
Have I missed a vital clue?
A
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
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 their flow control than try, while, loop or foreach. Yes, they are unusual. They're more like come froms than gotos. They need to stop people cold from trying to read them as inline code. People are naturally uncomfortable when they get shouted at, and that's as it should be. A little bit of shouting is OK, but it's easy to switch off when you get shouted at all the time. These constructs are likely to be used right throughout a typical Perl program and I don't want to be made to feel uncomfortable *all* the time when I'm trying to concentrate on what the program does. It is distasteful that a policeman should have to turn on his lights and siren when he wants to get your attention, but the practice is a useful bit of society nonetheless. But if he kept doing it all day, every day, it would be police harrassment. :-) A
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
On Aug 16, 8:21pm, Perl6 RFC Librarian wrote:
# this is perl6
sub foo :lvalue ($new) {
$variable = $new;
}
A nice idea, but one of the reasons for the original proposal was
to make
$foo-bar = $x;
behave the same as:
$foo-bar($x);
Your proposal provides a neat solution for lvalues, but at the cost of
the original aim (or my aim, at least). If you wanted to accept either
of the above then your code would end up looking something like this:
sub foo($argnew) : lvalue($rvalnew) {
$variable = want('lvalue') ? $rvalnew : $argnew;
}
I think that's likely to make things more complicated in the long run.
I'm inclined to say that assignments of the form:
$foo-bar(@baz) = @boz;
Are allowed, but just plain stupid. It's the same as:
$foo-bar(@baz, @boz)
and you're right, Perl can't tell the lvalues and rvalues apart. So
don't do that. If we can fix Perl so that it can tell the above
apart, then good, but I think it's a separate problem to the lvalue
subs.
A
--
Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated.
[EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Aug 15, 3:16pm, Russ Allbery wrote:
Wholeheartedly agreed. If something is an array, it should start with @.
If we're adding language changes that introduce arrays that don't start
with @, that's the mistake.
Agreed, but with a slight change of perspective. I don't think it's
so important that a variable that _holds_ a list be prefixed with a '@'.
What's more important is that when you _use_ a variable, you prefix it with
a '@' to indicate the expected return type. At that point, Perl can DWIM
or FOAD accordingly.
e.g.
$foo = [ 1, 2, 3 ];# it's a list (ref), but starts with a '$'
@bar = @$foo; # but now we "cast" (deref) it to look like a list
The confusion comes (IMHO) in having to add funny characters together,
or doing funky "casting" to make the right kind of value come from the
right kind of variable.
@$foo; # '$foo' is the list, dereferenced to a list '@'
$foo{bar} # '%foo' is the hash, accessed to return a scalar '$'
@foo{bar,baz} # '%foo' is the hash, sliced to return a list '@'
@$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 RFC which should hopefully do away with
much of this confusion.
A
--
Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated.
[EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
(Fwd) Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 idea. I've read your proposal, but I'm afraid I still think it's a bad idea. Those funny characters tell the programmer what's going on, and they tell the compiler what the programmer thinks is going on. I'm all in favour of cleaning up some of the syntax and removing some of the ambiguity (hence RFC 9) but I've long since learnt that the funny characters are a strength of Perl, and the concept is sound even if the implementation is a little shaky in places. A -- Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated. [EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
On Aug 16, 9:06am, Jonathan Scott Duff wrote:
Passing the lvalue via some other means eliminates this problem. I
forget who suggested it (Buddha Buck?) but
sub foo : lvalue($value) { ... }
That should tie in with function prototypes in general, but I suspect
that the 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 PROTECTED] For a good time: http://www.kfs.org/~abw/
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
On Aug 16, 8:32am, Nathan Wiger wrote: Maybe this is the confusion. I'm not saying subs should ONLY be lvalue. I think they should be both rvalue and lvalue at the same time. Point noted and understood, but I'm with the general consensus here. Lvalue subs should have to be explicitly marked as such. This could, of course, be done automatically for you by a Cuse lvalue 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/
Re: RFC 95 (v1) Object Classes
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:
$foo::bar::baz = 10;
Yes, but the semantics change. A key feature of this proposal is that
object/class variable and methods are indistinguishable to the user.
The dot operator does the right thing to call a method (if defined),
or instead access a variable, or follow a delegation reference, etc.
i.e.
$foo.bar
is something like (assuming a blessed hash)
UNIVERSAL::can($foo, 'bar') ? $foo-bar() : $foo-{'bar'};
'-' and '::' won't do that, and shouldn't. If we tried to overload
'::' or '-' to be more magical then we would break things all over
the place.
There are also tons of methods of inheritance in Perl's existing object
and package structure as-is, through SUPER, CORE, and many other
methods.
Yes, there's nothing that you can't already do in Perl in one way or
another. Perl 5's OO is very elegantly bolted onto the side of the
language. It's very powerful, flexible and reasonable easy to use.
On the other hand, you sometimes have to jump through lots of hoops
to do some very simple OO stuff that in other OO langugages is taken
for granted.
If you just want to tighten up certain aspects of packaging and
classing, it seems like this could be done with a pragma or a couple new
keywords, instead of redoing the entire package structure of Perl, which
I quite like.
No, I don't want to tighten up anything about Perl's existing package
and blessed reference system. It's fine the way it is. I *ALSO*
want a more formally defined OO system for times when I'm feeling more
structured, or when the scale or scope of the project I'm working on
demans it. This should definately, absolutely, without doubt be an
"as well as" option and not "instead of". Hence the new kind of package,
and the new kind of operator, rather than messing around with the old ones.
A
Re: RFC 95 (v1) Object Classes
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 things like this. A
Re: RFC 90 (v1) Builtins: zip() and unzip()
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
Re: RFC 83 (v1) Make constants look like variables
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 considered good programming practice. ISTR it's what Ruby uses. It works well for all those Perl-provided variables (e.g. $ME) that *should* be read-only, but not so good for those that are supposed to be read/write (e.g. @INC). A
Re: RFC 57 (v1) Subroutine prototypes and parameters
In the meantime, is there a reason the suggestion of: foo($x := 10, $y := 20) was dropped? It seems pretty obvious to me. Or what about: No, nothing's been dropped. I'll summarise all suggestions that don't otherwise get toasted in the next version of the RFC. A
Re: RFC 55 (v1) Compilation: Remove requirement for fina
On Aug 7, 10:12am, Nathan Torkington wrote:
Is there any reason you couldn't use "die" instead?
This isn't an objection to the proposal, but one example of where I'm
relying on the value returned by require() for a reason other than
error reporting.
I'm building Perl sub-routines (from templates) and writing them to
a file as:
sub {
# blah blah blah
}
And then I can
eval { $mysub = require $filename };
Of course, I should point out that I've already been burnt by this.
If the file has already been required then require() returns 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/
Re: New Group proposed: subs (was Re: named parameters)
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' and we get to annoy both sets of religious zealots at once. :-)= A
Re: RFC: Highlander Variables
On Aug 2, 4:37pm, Ted Ashton wrote: With all due respect, it appears that you are trading two characters for six with little to show for it. Currently, we have @array -- the array as a whole [...] $array__list -- the array as a whole I didn't make that part clear. 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 -- Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated. [EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
