subtype declarations
S12 says: subtype Str_not2b of Str where /^[isnt|arent|amnot|aint]$/; My brain parses this as: subtype Str_not2b[Str where /.../]; Or: subtype Str_not2b[Str] where /.../; Neither of which really reflect how it is really parsed. It looks like `subtype` has a special syntax. I find this to be free of special syntax and clearer to boot: type Str_not2b ::= Str where /^[isnt|arent|amnot|aint]$/; Why don't we just ditch the `subtype` keyword? Luke
Re: subtype declarations
Luke Palmer wrote:
S12 says:
subtype Str_not2b of Str where /^[isnt|arent|amnot|aint]$/;
My brain parses this as:
subtype Str_not2b[Str where /.../];
Or:
subtype Str_not2b[Str] where /.../;
I guess my mental parsing problems stem from the fact
that it was you who told me about the equivalence of
the brackets and 'of'.
Neither of which really reflect how it is really parsed. It looks like
`subtype` has a special syntax.
Could you enlighten me how it is actually parsed?
I guess from the corresponding form
subtype Str Str_not2b where /^[isnt|arent|amnot|aint]$/;
that subtype is modeled after sub declarations
subtype Str_not2b returns Str where /^[isnt|arent|amnot|aint]$/;
The thing stored under Str_not2b in the lexical namespace
is actually a closure
sub Str_not2b (Str $unconstrained) returns bit {...}
which is then referenced by variables, signatures etc.
I find this to be free of special
syntax and clearer to boot:
type Str_not2b ::= Str where /^[isnt|arent|amnot|aint]$/;
Why don't we just ditch the `subtype` keyword?
Wouldn't the above work as
::Str_not2b ::= Str where /^[isnt|arent|amnot|aint]$/;
so that type is just a short-cut?
--
TSa (Thomas Sandla)
Re: subtype declarations
On 2 May, Luke Palmer wrote: : S12 says: : : subtype Str_not2b of Str where /^[isnt|arent|amnot|aint]$/; : : My brain parses this as: : : subtype Str_not2b[Str where /.../]; : : Or: : : subtype Str_not2b[Str] where /.../; : : Neither of which really reflect how it is really parsed. It looks like : `subtype` has a special syntax. I find this to be free of special : syntax and clearer to boot: : : type Str_not2b ::= Str where /^[isnt|arent|amnot|aint]$/; Although, I'm aware, that introducing an idiom in favor of some, occasionally perceived, ancient C programming techniques, will do my reputation some harm among certain native programmer circles, I dare to continue stating the inobvious. If I compare last, given example against the previous ones, it is much more apparent, in my opinion, that we're in the process of becoming acquainted with the declaration of a subtype, regardless of the fact that we set ourselves back to common compile-time binding syntax; typedef is known amongst C knowledgables as a declaration of a synonym for a type and did inevitably trigger this recognition. But, I'd rather be cautious, to differentiate between what we had (C) and what we're striving for (Perl). : Why don't we just ditch the `subtype` keyword? I've the same feeling. : Luke Steven
Code classes
HaloO,
I don't know if this is usefull and if it is were this information
should be put. I've reworked the Code class chart from A06 to look
as follows:
invocant(s) : Code
_ :__ ___|___
| |: | |
SubMethod Method : SubBlock
___|: |___
| |: | |
Rule |: | Macro
|:__|
|:
MultiMethod :
role Code {...}
role Return{...}
role Dispatch[ ::How ] {...}
class Block does Code
class Sub does Code Return
{...}
class SubMethod does Code Return Dispatch of Class
{...}
class Method does Code Return Dispatch of Object
{...}
class Macro is Sub
{...}
class Ruleis Method
{...}
class MultiMethod is Method Sub does Dispatch of List
of Object
{...}
The vertical line of colons divides the methods from the subs basically.
This mirrors the declaration syntax of the invocants which are left of
the colon in a signature. The three underscore variables $_, @_ and %_
are right of the colon in my understanding and this is the main reason
for this mail: aliasing $_ in methods to the first invocant would badly
mix these two concepts!
Comments?
--
TSa (Thomas Sandlaß)
Re: Code classes
Hi,
Thomas Sandla wrote:
the main reason for this mail: aliasing $_ in methods to the first
invocant would badly mix these two concepts!
I think so, too.
I'd like to see:
$.foo# attribute of $?SELF
@.foo# ditto
%.foo# ditto
.foo# method of $?SELF
.foo# method of $?SELF
$_.foo# method of $_
This means that we've to write two additional letters in given {} and
map {} and somesuch...
@foo.map:{ $_.method 42 }
given $foo { $_.foo(42); $_.bar(23) }
...but it also means that
* . as secondary sigil ($.foo, @.foo, %.foo, .foo) is
consistent (always refers to $?SELF), and
* you don't have to use $self in methods again only because
you are (implicitly or explicitly) binding $_ to something
else.
IMHO, this advantages are worth the two extra chars.
--Ingo
--
Linux, the choice of a GNU | When cryptography is outlawed, bayl bhgynjf
generation on a dual AMD | jvyy unir cevinpl!
Athlon!|
Re: Junctions of classes, roles, etc.
David Storrs wrote:
Let's move this away from simple types like Str and Int for a moment.
If you consider them simple...
Tell me what this does:
class Tree {
method bark() { die Cannot instantiate a Tree--it is abstract! }
}
class Birch {
method bark() { return White, papery }
}
class Oak {
method bark() { return Dark, heavy }
}
class Dog {
method bark() { print Woof, woof!; return bow wow }
}
Four 'pure' classes so far.
class AlienBeastie isa Tree isa Dog {}
Here you get an error/warning of a composition time conflict between
Tree::bark and Dog::bark. BTW, it's 'is' not 'isa'. My preferred
syntax for multiple inheritance is the junctive notation 'is Tree Dog'
for subclassing because it nicely allows for superclassing with
'is Tree | Dog'.
class WhiteAlienBeastie isa Birch isa Dog {}
Same for Birch::bark and Dog::bark.
class HeavyAlienBeastie isa Oak isa Dog {}
Same.
sub Foo(Tree|Dog $x) { $x.bark() }
This might dispatch correctly for 'pure' Trees, Dogs etc.
but not for your mixed classes above.
Regards,
--
TSa (Thomas Sandlaß)
Re: Junctions of classes, roles, etc.
On Mon, 2 May 2005, [ISO-8859-1] Thomas Sandlaß wrote:
David Storrs wrote:
Tell me what this does:
class Tree { method bark() { die Cannot instantiate a Tree--it is
abstract! }
}
class Birch { method bark() { return White, papery }
}
class Oak { method bark() { return Dark, heavy }
}
class Dog {
method bark() { print Woof, woof!; return bow wow }
}
Four 'pure' classes so far.
class AlienBeastie isa Tree isa Dog {}
Here you get an error/warning of a composition time conflict between
Tree::bark and Dog::bark.
I don't think so; I had come to the same conclusion before realising that
we are talking inheritance here, not roles. So no trouble at class
composition time. Superclasses do not enter the picture while composing.
You'd be right if s/isa/is/ and then s/is/does/, of course.
When you dispatch, what happens would depend upon WALKMETH (according to
the pseudocode for CALLONE in A12). Usually the first inherited method
would get called.
TSa (Thomas Sandlaß)
regards,
abhijit
Open and pipe
Here's a basic proposal for the open and pipe builtins. It was discussed on #perl6 today and seemed okay to the people there. I'd like to hear your comments, since the internals side of much of this is ready and is looking for an interface. module Prelude-0.0.1; class IO; has Handle $:read_h; has Handle $:write_h; has Handle $:err_h; has Process $:process_h; multi sub open ( Str ?$filename = $?CALLER::_, Str ?$mode = '', Str ?$encoding = 'auto') returns IO; multi sub pipe ( Str ?$command = $?CALLER::_, Str ?$encoding = 'auto', +?to, +?from, +?skip_shell) returns IO; Notes / questions: Perl5-style open file is no more.[1] An earlier discussion about open here brought up URI open, but I think there was no final word, and it looks to me that the basic open should always mean file open, unless explicity modified. E.g., open could be used as a facade for pipe, open 'ls', '|-'; # or even open 'ls', :pipe = 'from' This pipe as it is can automatically do open2/3 if both :from and :to are given. I don't know if this is a good thing. Is it sane to have handle members when half of the time most of them are undef? (E.g. in ro open) One suggestion for the 'auto' encoding was to honor a BOM if it is present but default to ASCII otherwise. Or should we UTF-8 otherwise? Or what's in the environment...? And what about IO layers? :) What else belongs here? dirhandles, sockets? How are they specced? I was looking for a happy medium between overdwim and underlying library primitives level. [1] Should this be Perl(..5) style? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Open and pipe
Gaal Yahas skribis 2005-05-02 22:25 (+0300): open 'ls', '|-'; # or even open 'ls', :pipe = 'from' I dislike the hard-to-tell-apart symbols '' and '' for modes. 'r' and 'w' are much easier, and get rid of the awful left/right mnemonic that fails to make sense to GUI users. Spelling out 'write' and 'pipe' is even better, but sucks for oneliners and quick hacks. I already suggested a syntax like '+$write|w' for having multiple ways to say the same thing. I don't like an explicit :mode. Let Perl figure that out based on passed named arguments. But, if we're keeping these forms, then I think we should break tradition for the pipe. In Perl, we have called pipes '==' and '==', and I wonder why it would be much different for open. It also frees us from '|-' and '-|'. It took years before I knew which one to use without using the dictionary. Just use '==' and '=='. OTOH - people might think the '' and '' are also related to their operators. I see this as another good reason to not use \W symbols at all. This pipe as it is can automatically do open2/3 if both :from and :to are given. I don't know if this is a good thing. I think it's a good thing. It won't remove the traps, but it will make using bidirectional pipes much easier - an operator that can be done without the manual. One suggestion for the 'auto' encoding was to honor a BOM if it is present but default to ASCII otherwise. Or should we UTF-8 otherwise? Or what's in the environment...? Or guess it, -T alike. Browsers do a great (but of course not perfect) job at guessing. I want Perl to have such dwimmery too. And what about IO layers? :) I can imagine a similarity to sub wrapping: $fh.wrap(Class) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Formal Parameters To While Block
On Sat, Apr 30, 2005 at 10:06:32AM -0600, Luke Palmer wrote:
: Aaron Sherman writes:
: On Tue, 2005-04-26 at 09:37 -0600, Luke Palmer wrote:
:
: We're thinking at the moment that `while` will probably look like this:
:
: sub statement:while (cond is lazy, block) {
: [...]
:
: Just curious, why a sub and not a macro?
:
: Didn't need a macro. statement:while will probably end up generating
: parrot code directly, but this is a possible non-macro implementation.
Your sub declaration there strikes me as just an inside-out macro
declaration, insofar as it won't work unless the declaration is
visible as a predeclaration in the lexical scope, just like a macro.
It might be permissible as a form of syntactic sugar if we were
trying to encourage people to write braceless code, but I'm not
sure we want to encourage that. In fact, I'm pretty sure we don't.
Maybe is BRACELESSANDIREALLYMEANIT or some such... :-)
So maybe instead of sub that is told to be braceless on some arguments,
what we really want is a macro that can be told evaluate some of its
arguments normally rather than returning an AST. Not sure how this
links into the macro syntax though.
Larry
Re: Open and pipe
On 2005-05-02 15:52, Juerd [EMAIL PROTECTED] wrote: Gaal Yahas skribis 2005-05-02 22:25 (+0300): open 'ls', '|-'; # or even open 'ls', :pipe = 'from' I dislike the hard-to-tell-apart symbols '' and '' for modes. 'r' and 'w' are much easier, and get rid of the awful left/right mnemonic that fails to make sense to GUI users. Holy matter of opinion, Batman. and ¹ are much easier to tell apart than r¹ and w¹; r¹ and w¹ make me stop and think about how you spell read¹ and write¹, whereas and ¹ make instant visual sense, which should be appreciated by GUI users of all people. Left-to-right is hardly a mnemonic; you¹re writing in a language which parses left to right, because it was created by English-speakers, and English is written left to right. Since you pretty much have to learn English to learn Perl, I don¹t think this is too much of a hardship, even if it¹s counterintuitive to native speakers of Semitic languages. And since when is Perl targeting GUI users? It¹s a PROGRAMMING LANGUAGE. Even the original Mac developers used a command-line interface when writing the code.
Re: Open and pipe
I take some of that back actually, left-to-right directionality has almost nothing to do with understanding the and symbols. The arrow points in the direction information is flowing, which is left-to-right for but right-to-left for . I mean, ³filename² is pointing at the file, so the information is flowing into the file; ³filename² is pointing away from the file, so the info is flowing out of it. I don¹t see how it could be any clearer than that. On 2005-05-02 16:13, Mark Reed [EMAIL PROTECTED] wrote: On 2005-05-02 15:52, Juerd [EMAIL PROTECTED] wrote: Gaal Yahas skribis 2005-05-02 22:25 (+0300): open 'ls', '|-'; # or even open 'ls', :pipe = 'from' I dislike the hard-to-tell-apart symbols '' and '' for modes. 'r' and 'w' are much easier, and get rid of the awful left/right mnemonic that fails to make sense to GUI users. Holy matter of opinion, Batman. and ¹ are much easier to tell apart than r¹ and w¹; r¹ and w¹ make me stop and think about how you spell read¹ and write¹, whereas and ¹ make instant visual sense, which should be appreciated by GUI users of all people. Left-to-right is hardly a mnemonic; you¹re writing in a language which parses left to right, because it was created by English-speakers, and English is written left to right. Since you pretty much have to learn English to learn Perl, I don¹t think this is too much of a hardship, even if it¹s counterintuitive to native speakers of Semitic languages. And since when is Perl targeting GUI users? It¹s a PROGRAMMING LANGUAGE. Even the original Mac developers used a command-line interface when writing the code.
Re: Open and pipe
Mark Reed skribis 2005-05-02 16:13 (-0400): Holy matter of opinion, Batman. and ¹ are much easier to tell apart than r¹ and w¹; Obviously we disagree. What are the characters around the code supposed to be, by the way? Your mailer tells my mailer that you're sending iso-8859-1, but I seriously doubt that. r¹ and w¹ make me stop and think about how you spell read¹ and write¹, whereas and ¹ make instant visual sense, which should be appreciated by GUI users of all people. Good, now see: my $fooh = open 'foo', ''; my $barh = open 'bar', ''; my $fooh = open 'foo', :r; my $barh = open 'bar', :w; Or, funnier: or the equivalent: wrwrwwrrw r w r w w r r w or another equivalent, which in my opinion is clearer than any of the alternatives: my $fooh = open 'foo', :read; my $barh = open 'bar', :write; write read write read write write read read write read write read write write read read write I really do find it hard to believe that you find and visually more distinctive than r and w. And is read-write in \W-ish? I read that as != or ARGV. But of course, I also find it hard to believe someone's actually using Microsoft software to send something to a geek mailinglist. ;) Left-to-right is hardly a mnemonic; you¹re writing in a language which parses left to right, because it was created by English-speakers, and English is written left to right. It is indeed hardly a mnemonic. Hence my use of quotes around that word. There is nothing on the left side of my computer or screen that indicates reading, or anything on the right side that indicates writing. Worse, if you write open '/etc/passwd', ''; that visually parses as to /etc/passwd, because that's where the arrow is pointing. But does swapping the arguments make sense? It's in that order in Perl 5, but in Perl 6, I think we shouldn't want a text-justification like spreading of arguments over parameters, or to make the mode argument mandatory. And since when is Perl targeting GUI users? It¹s a PROGRAMMING LANGUAGE. PROGRAMMING LANGUAGE doesn't translate to LANGUAGE USED BY PEOPLE WHO ALL USE COMMAND LINE UTILITIES ALL THE TIME. In fact, many people use graphical IDEs and don't like the command line. They don't magically associate with reading and with writing. If there's any association at all, my guess is that it has to do with comparison or angle brackets. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Open and pipe
On 2005-05-02 16:35, Juerd [EMAIL PROTECTED] wrote: What are the characters around the code supposed to be, by the way? Your mailer tells my mailer that you're sending iso-8859-1, but I seriously doubt that. Argh. Bad Entourage, no biscuit. Back to Mail as soon as I get Tiger installed, I think. But of course, I also find it hard to believe someone's actually using Microsoft software to send something to a geek mailinglist. ;) I had good reasons for switching to it at one time. Honest! Besides, it¹s a work thing. PROGRAMMING LANGUAGE doesn't translate to LANGUAGE USED BY PEOPLE WHO ALL USE COMMAND LINE UTILITIES ALL THE TIME. In fact, many people use graphical IDEs and don't like the command line. I have nothing against IDEs; IDEA is pretty nice for Java coding, for instance. But to date most Perl programmers don¹t program Perl inside an IDE, although it would be nice if Perl 6 had an IDE coming out of the box. My point was simply that people who program are in general more technically savvy than those who don¹t. That doesn¹t mean they use the command line exclusively, or at all, but it does mean that they should be capable of understanding visual metaphors other than those of the GUI world.
Re: Open and pipe
On Mon, May 02, 2005 at 10:25:08PM +0300, Gaal Yahas wrote:
: Here's a basic proposal for the open and pipe builtins. It was discussed
: on #perl6 today and seemed okay to the people there. I'd like to hear
: your comments, since the internals side of much of this is ready and is
: looking for an interface.
:
: module Prelude-0.0.1;
:
: class IO;
:
: has Handle $:read_h;
: has Handle $:write_h;
: has Handle $:err_h;
: has Process $:process_h;
:
: multi sub open (
: Str ?$filename = $?CALLER::_,
: Str ?$mode = '',
: Str ?$encoding = 'auto') returns IO;
:
: multi sub pipe (
: Str ?$command = $?CALLER::_,
: Str ?$encoding = 'auto',
: +?to, +?from, +?skip_shell) returns IO;
I think I'd rather see something like:
multi sub open (
Str +$mode = 'r',
Str +$encoding = 'auto',
Str [EMAIL PROTECTED]) returns IO;
multi sub openuri (
Str +$mode = 'r',
Str +$encoding = 'auto',
Str [EMAIL PROTECTED]) returns IO;
multi sub openpipe (
Str +$mode = 'r',
Str +$encoding = 'auto',
Str [EMAIL PROTECTED]) returns IO;
multi sub openshell (
Str +$mode = 'r',
Str +$encoding = 'auto',
Str [EMAIL PROTECTED]) returns IO;
I don't think the command should default to $_, and I'd rather have pipes
use a list for input of the args. If we make open consistent with
that then we can open a list of files without having to clobber @ARGS.
: Notes / questions:
:
: Perl5-style open file is no more.[1] An earlier discussion about
: open here brought up URI open, but I think there was no final word,
: and it looks to me that the basic open should always mean file open,
: unless explicity modified. E.g., open could be used as a facade for pipe,
:
: open 'ls', '|-'; # or even
: open 'ls', :pipe = 'from'
:
: This pipe as it is can automatically do open2/3 if both :from and :to
: are given. I don't know if this is a good thing.
I think that's just
openpipe 'ls';
By the way, P5's pipe() should probably be renamed to syspipe() or some
such to avoid confusion.
: Is it sane to have handle members when half of the time most of them
: are undef? (E.g. in ro open)
Fine by me. I'm not fond of the deep class hierarchies some languages
put onto handles. On the other hand, with roles we might be able
to compose a shallow hierarchy, and that would be okay.
: One suggestion for the 'auto' encoding was to honor a BOM if it is
: present but default to ASCII otherwise. Or should we UTF-8 otherwise?
If it's a choice between those two, definitely UTF-8, but I think we
can be smarter than that. We can pretty easily autodetect text in
UTF-16 even without a BOM, as long as we don't also have to autodetect
some legacy character set. I'd love to render BOMs obsolete, at
least on input. (Be lenient on what you accept, and strict on what
you produce.)
: Or what's in the environment...?
More useful on output than input, I think, though it could be helpful
in telling the autodetector to look for a particular legacy character
set in addition to the UTFs.
I have another thought on that, which is that you often want a particular
output file to have the same format as some other input file. So maybe
we could have some kind of openfilter() that specifies both an input
and output file on the same (bidirectional) handle, with the assumption
that the output file will keep the format of the input file.
: And what about IO layers? :)
Yum. :-)
: What else belongs here? dirhandles, sockets? How are they specced?
Maybe something consistent like:
multi sub opendir (
Str +$mode = 'r',
Str +$encoding = 'auto',
Str [EMAIL PROTECTED]) returns IO;
multi sub opensocket (
Str +$mode = 'rw',
Str +$encoding = 'auto',
Str [EMAIL PROTECTED]) returns IO;
: I was looking for a happy medium between overdwim and underlying library
: primitives level.
We should probably reserve io() for the overdwim and sysopen() for the
underdwim, and then not sweat the middle so much. :-)
: [1] Should this be Perl(..5) style?
I think that'd be Perl-{1..5} style, as it currently stands, and
assuming you want to use the use syntax. Also, we haven't specced
a unary .. yet. It only saves one character, and I think it's clearer
to force people to say 0..5 or 1..5 (or even a..z).
Larry
Re: Open and pipe
On Mon, May 02, 2005 at 02:23:36PM -0700, Larry Wall wrote:
: : [1] Should this be Perl(..5) style?
:
: I think that'd be Perl-{1..5} style, as it currently stands, and
: assuming you want to use the use syntax. Also, we haven't specced
Er, make that Perl-(1..5) instead. One week in Russia and my brain
is rotting. Couldn't have been the vodka, since I didn't have any...
Larry
Re: Formal Parameters To While Block
On Sat, Apr 30, 2005 at 08:24:14PM -0600, Luke Palmer wrote: : Yeah, is lazy should be fine for now. The feature is definitely : there, but it might end up being called something different. is : braceless? I think is braceless is better, if only because it's longer. Though I still suspect it's really a macro in disguise, and we might be better off declaring it as a macro but with some kind of magic that blockifies its arguments rather than ASTifying it. Or maybe we should invent the submacro, whose block is assumed to be the runtime implementation, and all the thunks come in preblockfied, at least for args declared with . Then we get the advantages of the sub form while documenting that you can't take a runtime link to the macro and expect it to influence the parser. Larry
Re: S04 -- closure traits clarification
On Fri, Apr 29, 2005 at 10:57:01AM -0500, David Christensen wrote:
: 1) What type of introspection, if any, are we providing to the language
: level? I.e., are we providing something along the lines of
:
: %traits = ?BLOCK.traits
:
: where %traits is keyed on trait name (FIRST, LAST, whatever) and in
: turn is an array of closures? This would mean, for instance that we
: could say
:
: ?BLOCK.traitsFIRST
:
: to get the current block's FIRST closures, if any.
There is no .traits method. Traits store their values into properties,
and properties are just mixins, and you get at the properties by calling
methods. These particular traits push onto a correspondingly named
property, so you're probably looking for
$?BLOCK.firstlist
or some such.
: When parsing the
: block for traits, coming across a new FIRST block would be akin to
: saying:
:
: push ?BLOCK.traitsFIRST, {...block contents...}
:
: Specifically, I'm looking for definition of the syntax, which is only
: alluded to in the Synopsis.
Probably does something like:
?BLOCK does First; # no-op if it already does First
?BLOCK.firstlist.push(block);
: 2) If we accept the introspection at the block-level above, it seems
: clear that we should also accept the same .traits method on variables.
: I.e., in the above DBI example, we should get back the closure(s) for
: undoing by referring to $sth.traitsUNDO. Is a variable-level trait a
: single entry, or can we have multiple will undo {...} predicates on a
: single variable? (The utility of such is left as an exercise to the
: reader.)
The variable might not be aware that it has had such a trait applied
to it. Remember that traits are allowed to cheat. These traits need
only arrange to have block pushed onto the appropriate list after the
corresponding variable is successfully elaborated at run time, or otherwise
arrange not to run if their variable is not yet elaborated. If this
information also shows up as metadata on the variable, that's probably
okay, but the implementation is unlikely to use that property directly.
Of course, a trait like constant would be expected to an effect on
the variable itself.
: 3) User-definable traits. Now, this may be a closed domain of sorts,
: but do we need to allow for the possibility of user-defined traits?
: (I'm thinking here of variable-level will predicates.) If so, do
: user-defined traits get normalized to UPPER? It would seem like we
: would want consistency here, because if will undo {...} and UNDO
: {...} get stored in the same trait slot, we're obviously transforming
: one of the identifiers -- should this behavior be specific to our
: built-in ones, or to all traits?
Already specced in A12. As far as I know that part hasn't changed
significantly, but that could be because nobody's tried to implement
it yet. :-)
: 4) Which of the closure traits are supported as will predicates on
: variables? Not all of the closure traits make sense on the
: variable-level -- this information will be useful when trying to parse
: the will predicates.
As Luke mentioned, will is just syntactic sugar for is. A trait
is allowed to care about its semantics at compile time when you call
the trait handler, but this is totally transparent to the parser,
which will happily accept will qufklzuxfvklj {...}, turn it into
is qufklzuxfvklj({...}), and then fail to find an appropriate trait
handler in semantic analysis, or find some default trait handler that
scratches its head over qufklzuxfvklj before admitting defeat.
Or it may be that any trait that is unrecognized just gets applied as
a property of the variable. But I think it's better if we treat
traits as declared items so that we catch typos, unless someone has
explicitly declared a autoloading trait handler.
Larry
Re: Open and pipe
Larry Wall skribis 2005-05-02 14:23 (-0700): multi sub open ( multi sub openuri ( multi sub openpipe ( multi sub openshell ( Starting to look a lot like PHP there. How about open ::= File::open URI::open Sys::Pipe::open And put the other aliases in the module that CGI.pm-:standard-ishly pollutes the main namespace? I don't think the command should default to $_ Eh... Why?! Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: S04 -- closure traits clarification
On Mon, May 02, 2005 at 03:20:03PM -0700, Larry Wall wrote: : Probably does something like: : : ?BLOCK does First; # no-op if it already does First : ?BLOCK.firstlist.push(block); Probably shouldn't use up a normal name like First for that. Maybe we can just reuse the trait name as the role name ?BLOCK does FIRST; # no-op if it already does First ?BLOCK.FIRST.push(block); In this view, whether setting a trait clobbers an existing property or merely appends to it depends on the trait handler's implementation. I'm inclining more toward the view that all these blocks are pushed onto the FIRST property at BEGIN time, but the will first properties are wrapped in code that prevents them from running before their variable is declared. (Or maybe the wrapper just checks to see if the variable is defined? That would disable the block when you undef the variable. That might be construed as a feature.) Larry
Re: Open and pipe
On Tue, May 03, 2005 at 12:32:58AM +0200, Juerd wrote: : Larry Wall skribis 2005-05-02 14:23 (-0700): : multi sub open ( : multi sub openuri ( : multi sub openpipe ( : multi sub openshell ( : : Starting to look a lot like PHP there. And I care about that because PHP is such an unsuccessful language? :-) I'd just like all the opens to sort to the same place in the manual. : How about : : open ::= File::open : URI::open : Sys::Pipe::open : : And put the other aliases in the module that CGI.pm-:standard-ishly : pollutes the main namespace? I'm not too worried about polluting the main namespace, now that it's equivalent to Perl 5's third class keywords. I think that Perl 6 should end up with *more* names in the global namespace than Perl 5 had, as long as we don't end up with as many inconsistent names as PHP. : I don't think the command should default to $_ : : Eh... : : Why?! Because $_ is primarily for the use of inner loops, not outer loops, and open tends to be in the outer loop rather than the inner loop. And because if there is no inner loop we're doing some kind of slurp or io() pipe that bypasses open to begin with. And partly because of the mess in Perl 5 from 1-arg open, though that's probably irrational. Larry
Re: Code classes
On Mon, May 02, 2005 at 06:22:03PM +0200, Ingo Blechschmidt wrote: .foo# method of $?SELF .foo# method of $?SELF $_.foo# method of $_ We could also define them as: .foo # method on $?SELF .foo# method on $_ $_.foo # method on $_ The .foo syntax is very special, after all, so you can't really be consistent with it. I prefer it be the topic, in any case. -- wolverian signature.asc Description: Digital signature
Re: Code classes
On Mon, May 02, 2005 at 11:29:49PM +0300, wolverian wrote: : On Mon, May 02, 2005 at 06:22:03PM +0200, Ingo Blechschmidt wrote: : .foo# method of $?SELF : .foo# method of $?SELF : $_.foo# method of $_ : : We could also define them as: : : .foo # method on $?SELF : .foo# method on $_ : $_.foo # method on $_ : : The .foo syntax is very special, after all, so you can't really be : consistent with it. I prefer it be the topic, in any case. We're still discussing it on @Larry, but I think we can make that work. There are some ambiguities with .foo that depend on the declaration of it, but those can probably be resolved based on that declaration. This proposal is also consistent with the first invocant setting the topic, so when still works inside a method. So paint me back into the .foo == $_.foo camp this week, and now the .foo == $self.foo camp can start carping again. :-) By the way, this probably goes along with a policy of allowing $.foo, @.foo, and %.foo outside of the class as well. These would not refer to the actual attribute, but would call $self.foo() underneath (except in the class that actually defines the attribute). It seems to me that this would facilitate cut and paste of code, as well as the possibility of moving the attribute declaration to or from parent classes transparently. (To give credit where it's due, this was inspired by someone's misreading of S12 on PerlMonks a month or so ago.) Since the compiler is figuring out whether $.foo means an attribute or a method call on your behalf, to force a virtual call in the class itself, you'd have to say $self.foo(), which seems like a decent safety feature to me, insofar as it makes it harder to accidentally call yourself in an infinite regress. Which probably means that (just like $.foo) the .foo is devirtualized in any class that defines method foo, or we're back to the too-easy infinite regress. I think it probably works... Larry
Re: LABELS: block
On Tue, Apr 26, 2005 at 11:24:34AM -0600, Luke Palmer wrote: : That's true, but the former hasn't been accepted. That's not something : I considered when I was thinking about that proposal, but I think it's : a fairly minor issue. We'll ignore labels as we continue to weigh that : proposal, and redo label syntax later if we must. It's looking like we won't be needing to redo label syntax, if we accept the .foo() proposal for self calls. (The omitted indirect object syntax for self calls wasn't going to fly anyway, since foo bar: is then too ambiguous, quite apart from the tail marking issues.) In any event, none of the proposals that bury the label is going to be acceptable. As a vital visual element of control flow, the label has to be out front where it can be seen. Larry
Re: Open and pipe
LW == Larry Wall [EMAIL PROTECTED] writes: LW multi sub opensocket ( LW Str +$mode = 'rw', LW Str +$encoding = 'auto', LW Str [EMAIL PROTECTED]) returns IO; and how will that support async (non-blocking) connects? or listen sockets? i assume this is sorta the replacement for IO::Socket which is a pure key/value api (except for the shortcut single arg host:port which is nice to also support). for async you need to provide a callback in the signature (beyond all the other socket args), an optional timeout (with its own callback). the callbacks could be defaulted to subs in the current module/namespace but the coder may also want an OO callback which needs an object and method. another little optional argument is a private data field. sure an object callback could handle on a per object basis. but what if one object wanted to manage multiple async socket connections? each one needs to be identified in the callbacks which is what the private data is for. it is passed as an arg to the callback sub/method. LW We should probably reserve io() for the overdwim and sysopen() for the LW underdwim, and then not sweat the middle so much. :-) then io would be common blocking connects (which is what most socket connections are) and sysopen is for sockets. why not just support the standard socket subs as in perl5? they could be in a module but they are just simple wrappers around the system calls. i would prefer if opensocket's signature were fully fleshed out with named args (with some defaults). just passing in an extra list is a poor api as there are so many socket options. just read PBP (when it comes out) for damian's take on long arg lists. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Open and pipe
All~ On 5/2/05, Uri Guttman [EMAIL PROTECTED] wrote: LW == Larry Wall [EMAIL PROTECTED] writes: LW multi sub opensocket ( LW Str +$mode = 'rw', LW Str +$encoding = 'auto', LW Str [EMAIL PROTECTED]) returns IO; and how will that support async (non-blocking) connects? or listen sockets? i assume this is sorta the replacement for IO::Socket which is a pure key/value api (except for the shortcut single arg host:port which is nice to also support). for async you need to provide a callback in the signature (beyond all the other socket args), an optional timeout (with its own callback). the callbacks could be defaulted to subs in the current module/namespace but the coder may also want an OO callback which needs an object and method. another little optional argument is a private data field. sure an object callback could handle on a per object basis. but what if one object wanted to manage multiple async socket connections? each one needs to be identified in the callbacks which is what the private data is for. it is passed as an arg to the callback sub/method. Currying obviates the need for everything but a sub callback. If you want a callback to a method, curry the object. If you want private data, curry the data. After you are done currying you will have a simple sub to pass in as the callback, the peasants rejoice, and libraries will have a simpler interface. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Open and pipe
MF == Matt Fowles [EMAIL PROTECTED] writes: MF All~ MF On 5/2/05, Uri Guttman [EMAIL PROTECTED] wrote: LW == Larry Wall [EMAIL PROTECTED] writes: LW multi sub opensocket ( LW Str +$mode = 'rw', LW Str +$encoding = 'auto', LW Str [EMAIL PROTECTED]) returns IO; and how will that support async (non-blocking) connects? or listen sockets? i assume this is sorta the replacement for IO::Socket which is a pure key/value api (except for the shortcut single arg host:port which is nice to also support). for async you need to provide a callback in the signature (beyond all the other socket args), an optional timeout (with its own callback). the callbacks could be defaulted to subs in the current module/namespace but the coder may also want an OO callback which needs an object and method. another little optional argument is a private data field. sure an object callback could handle on a per object basis. but what if one object wanted to manage multiple async socket connections? each one needs to be identified in the callbacks which is what the private data is for. it is passed as an arg to the callback sub/method. MF Currying obviates the need for everything but a sub callback. If you MF want a callback to a method, curry the object. If you want private MF data, curry the data. After you are done currying you will have a MF simple sub to pass in as the callback, the peasants rejoice, and MF libraries will have a simpler interface. i like the concept but how would that work without actually creating closures? to convert a sub call to a method on an object is code, not just presetting args (which is what i gather currying is). now just using a closure would work but i am not in favor of allocating them just for this when other optional args can do the job. even with the full interface as i want it, you can use closures as your callbacks and keep it shorter. i just don't see the win of more code vs more args. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Junctions of classes, roles, etc.
On Mon, May 02, 2005 at 06:49:10PM +0200, Thomas Sandlaß wrote:
David Storrs wrote:
Let's move this away from simple types like Str and Int for a moment.
If you consider them simple...
When compared to
arbitrary-class-that-was-defined-by-
arbitrary-programmer-of-
arbitrary-and-unknown-skill-level
then yes, I consider them to be extremely simple.
Tell me what this does:
class Tree {
method bark() { die Cannot instantiate a Tree--it is abstract! }
}
class Birch {
method bark() { return White, papery }
}
class Oak {
method bark() { return Dark, heavy }
}
class Dog {
method bark() { print Woof, woof!; return bow wow }
}
Four 'pure' classes so far.
Dog is not pure according to the definition of pure class that I
know (no side effects in any method, constructor, or subclass). Maybe
'pure class' means something else to you?
class AlienBeastie isa Tree isa Dog {}
Here you get an error/warning of a composition time conflict between
Tree::bark and Dog::bark.
So that I'm clear, is this your opinion/preference or is it based on
material from the SEAs? If the latter, could you point me to the
relevant passage?
My preferred
syntax for multiple inheritance is the junctive notation 'is Tree Dog'
for subclassing because it nicely allows for superclassing with
'is Tree | Dog'.
Again, so that I'm clear--this is your preference, and is not derived
from any authoritative source, correct?
This might dispatch correctly for 'pure' Trees, Dogs etc.
but not for your mixed classes above.
As I noted above, Dog is not 'pure' by the definition I know so I'm
not sure what to make of this statement.
--Dks
Re: Junctions of classes, roles, etc.
David Storrs writes:
On Mon, May 02, 2005 at 06:49:10PM +0200, Thomas Sandla wrote:
David Storrs wrote:
class Tree {
method bark() { die Cannot instantiate a Tree--it is abstract! }
}
class Birch {
method bark() { return White, papery }
}
class Oak {
method bark() { return Dark, heavy }
}
class Dog {
method bark() { print Woof, woof!; return bow wow }
}
class AlienBeastie isa Tree isa Dog {}
Here you get an error/warning of a composition time conflict between
Tree::bark and Dog::bark.
So that I'm clear, is this your opinion/preference or is it based on
material from the SEAs? If the latter, could you point me to the
relevant passage?
As has been pointed out, there's no composition going on. But we are
getting rid of search order problems, so you'll get an ambiguous method
call error at some point. Whether this is at the time you create the
class or the time you try to call the method, I do not know.
My preferred
syntax for multiple inheritance is the junctive notation 'is Tree Dog'
for subclassing because it nicely allows for superclassing with
'is Tree | Dog'.
Again, so that I'm clear--this is your preference, and is not derived
from any authoritative source, correct?
Not authoritative. I, for one, really want the ability to superclass a
posteriori, but I'm not sure this is how you do it.
Luke
Re: Open and pipe
All~ On 5/3/05, Uri Guttman [EMAIL PROTECTED] wrote: MF == Matt Fowles [EMAIL PROTECTED] writes: MF All~ MF On 5/2/05, Uri Guttman [EMAIL PROTECTED] wrote: LW == Larry Wall [EMAIL PROTECTED] writes: LW multi sub opensocket ( LW Str +$mode = 'rw', LW Str +$encoding = 'auto', LW Str [EMAIL PROTECTED]) returns IO; and how will that support async (non-blocking) connects? or listen sockets? i assume this is sorta the replacement for IO::Socket which is a pure key/value api (except for the shortcut single arg host:port which is nice to also support). for async you need to provide a callback in the signature (beyond all the other socket args), an optional timeout (with its own callback). the callbacks could be defaulted to subs in the current module/namespace but the coder may also want an OO callback which needs an object and method. another little optional argument is a private data field. sure an object callback could handle on a per object basis. but what if one object wanted to manage multiple async socket connections? each one needs to be identified in the callbacks which is what the private data is for. it is passed as an arg to the callback sub/method. MF Currying obviates the need for everything but a sub callback. If you MF want a callback to a method, curry the object. If you want private MF data, curry the data. After you are done currying you will have a MF simple sub to pass in as the callback, the peasants rejoice, and MF libraries will have a simpler interface. i like the concept but how would that work without actually creating closures? to convert a sub call to a method on an object is code, not just presetting args (which is what i gather currying is). now just using a closure would work but i am not in favor of allocating them just for this when other optional args can do the job. even with the full interface as i want it, you can use closures as your callbacks and keep it shorter. i just don't see the win of more code vs more args. Curried functions are most likely implemented as closures internally. But perl6 has C .assuming which does most of the ugly syntactic work of creating the closure for us. As for the cost of allocating the closure, I tend not to worry about that till I know it is a problem. Most callbacks are created once and called many times, so the allocation costs are not a great concern. On the other hand, I view a simpler interface to a library as a big win. Yes, optional arguments could be added which allow for such things, but then the library has to document and manage all of these arguments, and the library user has to learn them all. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
