Re: -X's auto-(un)quoting?
Larry Wall skribis 2005-04-22 9:47 (-0700):
> : > my $page <== io("http://www.wall.org/~larry";);
> : "IO" used in this way denies that there's non-stream-based IO too.
> How so? Where's the xor?
Good point.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
On Fri, Apr 22, 2005 at 05:53:48PM +0200, Juerd wrote:
: > I kinda like the IO::All module, except for how it overloads < and >.
: > my $page <== io("http://www.wall.org/~larry";);
:
: "IO" used in this way denies that there's non-stream-based IO too.
How so? Where's the xor?
: Waiting for a certain wire to get shorted is input too, as is writing
: directly to graphic memory a form of output.
I don't see how an IO is prevented from being used like any other
handle. The handle type is there so MMD can pick out particular
behaviors for <== and syswrite(). And different subtypes of handles
can pick out different behaviors. Even the OS can keep track of
the types of file descriptors that are just integers as far as the
user is concerned.
Larry
Re: -X's auto-(un)quoting?
Larry Wall skribis 2005-04-22 8:42 (-0700):
> multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns
> Handle {...}
> Though that would potentially be problematic if you wanted to open
> a file whose name started with "http:"
open "./http://...";;
open "file://$CWD/http://...";;
:)
In fact, I'm a big proponent of using URIs instead of filenames where
possible. It can even provide a more portable way of saying
\\sambaserver\share, in smb://sambaserver/share, which can be translated
to whatever the system supports, possibly failing because it's just not
supported.
> I kinda like the IO::All module, except for how it overloads < and >.
> my $page <== io("http://www.wall.org/~larry";);
"IO" used in this way denies that there's non-stream-based IO too.
Waiting for a certain wire to get shorted is input too, as is writing
directly to graphic memory a form of output.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
Matt skribis 2005-04-22 14:44 (-0400):
> We're talking about the *built-in* functions here, right?
I don't know.
> Anyway, is there any other URI scheme besides for mailto: that doesn't use
> <://>?
I don't know, but if you want to find this out,
http://www.iana.org/assignments/uri-schemes is probably a good starting
point.
> mailto isn't something you can "open" really, for read at least.
No, but writing to it ought to simplify things :)
given open 'mailto:[EMAIL PROTECTED]' {
.say(q0:to<.>
Subject: Useful mailto open
User-Agent: Perl 6
In-Reply-To: <[EMAIL PROTECTED]>
Hello, world!
.
);
.close or fail;
}
> If it's for built-in, then only the most common protocols would be defined
> I imagine.
No, if it's built in, we should stick to the spec and interpret every
^\w+: (roughly - see RFCs for syntax specifics) as a scheme.
> >>Also, I don't know much about rules with regex yet, but could you do
> >>something like...
> >>multi sub open ($u of Str where //, [EMAIL PROTECTED])
> >> returns
> >>Handle {...}
> >>Where < > expands to < file:// >
> >Yes, but it's probably easier to just use a hash: %protocol.
> Easier or more efficient?
Yes.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
Matt skribis 2005-04-22 14:20 (-0400):
> Well why can't you define the functions like so:
Because a URI scheme ends in :. It http: followed by anything other than
// should fail because it is invalid, not fall back to file handling.
IFF you're handling URIs.
> multi sub open ($u of Str where /^mailto:\/\//, [EMAIL PROTECTED])
> returns
> Handle {...}
Well, it's mailto:[EMAIL PROTECTED], not mailto://[EMAIL PROTECTED]
> Also, I don't know much about rules with regex yet, but could you do
> something like...
> multi sub open ($u of Str where //, [EMAIL PROTECTED])
> returns
> Handle {...}
> Where < > expands to < file:// >
Yes, but it's probably easier to just use a hash: %protocol.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
On Fri, 22 Apr 2005 11:42:10 -0400, Larry Wall <[EMAIL PROTECTED]> wrote:
You speak of "open" as if it must be a single function. We're now
living in the age of MMD, so what you're asking for is a no-brainer.
If we decided to we could even do MMD with constraints:
multi sub open ($u of Str where /^file:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^ftp:/, [EMAIL PROTECTED]) returns Handle {...}
multi sub open ($u of Str where /^mailto:/, [EMAIL PROTECTED]) returns Handle
{...}
...
Though that would potentially be problematic if you wanted to open
a file whose name started with "http:", so we'd probably want to
give that suite of multis a different name. Call it io() maybe, if
we can unify the Handle and IO abstractions. As I've said before,
I kinda like the IO::All module, except for how it overloads < and >.
But Perl 6 has ==> and <== that can do that instead, which just happen
to be called "pipes", strange coincidence. :-)
Well why can't you define the functions like so:
multi sub open ($u of Str where /^file:\/\//, [EMAIL PROTECTED]) returns Handle {...}
multi sub open ($u of Str where /^http:\/\//, [EMAIL PROTECTED]) returns Handle {...}
multi sub open ($u of Str where /^ftp:\/\//, [EMAIL PROTECTED]) returns Handle {...}
multi sub open ($u of Str where /^mailto:\/\//, [EMAIL PROTECTED]) returns Handle
{...}
Also, I don't know much about rules with regex yet, but could you do
something like...
multi sub open ($u of Str where //, [EMAIL PROTECTED]) returns
Handle {...}
Where < > expands to < file:// >
Re: Blocks, continuations and eval()
On Fri, Apr 22, 2005 at 01:15:35PM +0200, Stéphane Payrard wrote: : Hi, : : I am making a presentation about Perl6 this week end. My point will : be: the next generation of applicative languages will be scripting : languages because they have come of age. : : Alternatives don't cut it anymore. Indeed C and C++ are memory : allocation nightmare; Java and C# don't have read-eval loop, a : necessary condition for rapid learning and development. Functional : languages like haskell or ocaml are very powerful but needs massive : wetware reconfiguration to get used to the syntax and semantic. : : So I will make do a presentation of Perl6 and Parrot features to make : my point about upcoming scripting languages. : : I have a few questions inspired by my recently acquired knowledge : about functional languages. Perl6 being the ultimate syncretist : language, I wonder if some functional features will make it : into Perl6. I know we already got currying. A lot of features are making it into Perl 6 that have historically been associated with "functional" programming. Off the top of my head: currying continuations tail recursion laziness autogenerating arrays [] pattern matching arguments : A very nice feature of Haskell and *ml is the possibility to define : complex datastructures types and the control flow that manipulate : these structures: constructors and pattern matching. With these : languages, in a very deep sense, control flow is pattern matching. Can : we expect Perl6 to propose something similar? We don't (yet) have a full unification engine, though Luke has thought about that some. But it probably wouldn't be the default in any case. MMD and [] matching is about as much as normal people can take in. And of course, we let people derive from the Perl grammar itself, and define macros based on parse rules, which is at least compile-time pattern matching. (Though we discourage use of backtracking parsers for dwimmery; the standard Perl parser will use backtracking only to produce more meaningful error messages.) : If yes, could be the matching part folded into the rule syntax? Rules : are about identifying "structures" in parsed strings and acting : accordingly. Partern matching is about identify typed structures and : acting accordingly. There is a similarity there. Also we may want to : match both at the structural level and at the string level. Or is : this asking too much of rules, that have already swallowed both lexing : and parsing. Perl 6 rules are a new language, and that language can be extended in various ways. Structural matching is one of those things that, while we aren't worrying about getting it into Standard Perl 6, we want to make sure it's possible to extend the mechanism in that direction. Though we've already said that you can match against an array, and recognize element boundaries with <,>, so we're most of the way there by some reckoning. If the matcher is cognizent of array element boundaries, it's also cognizant of array elements, and a subrule could presumably be taught to dive down into one of those elements. : The notion of data type become very useful in Perl6 for people who : want it. In fact, Perl6 is a mix of dynamic and static types : (bindings). I think type theory handles type inference in this kind : of langage with something called dependant type. Though I have to go : thru ATTaPl to get it. I'm not famaliar with that usage, but then, I haven't studied type inferencing in any kind of depth. : Perl, like many scripting language is very lax and, when needed, : converts implicitely values within expressions. This is nice, but I : think that makes type inference impossible. Type inference is good : because it allows to generate very efficient/strict code with very : little type annotations. Well, we hope to get some of those benefits from our optional type system. : Can we expect in a distance feature a pragmatic mode convention to : control automatic type conversions if any and the type inference : scheme chosen when/if implemented? If we design things right, I don't see how we can prevent it. :-) My only requirement is that each file starts at the top in Standard Perl and mutates into your language of choice by explicit lexically scoped declaration. Hmm, when you said "pragmatic modes", it occurred to me that I would have difficulty calling "use ML" a mere pragma, since pragmas are supposed to be about pragmatics, not syntax or semantics. I suppose if we wanted to ignore Greek entirely we could call a syntax mutator a synta and a semantics mutator a semanta, though of course these categories shade into each other, and something like "use Python" is going to have issues at all three levels. I don't know how much benefit there is to trying to keep these linguistic levels straight, except that we should probably reserve the actual language names for complete emulation, and use names like "Javalike" or "Lispish" fo
Re: -X's auto-(un)quoting?
On Fri, Apr 22, 2005 at 11:28:06AM +0200, Juerd wrote:
: Which brings me to the following: can open please use the same kind of
: $file, so that open $filehandle just checks $filehandle's mode and
: returns $filehandle again? That way, every library function that accepts
: a filename automatically also accepts an open filehandle, which has a
: thousand and one benefits.
You speak of "open" as if it must be a single function. We're now
living in the age of MMD, so what you're asking for is a no-brainer.
If we decided to we could even do MMD with constraints:
multi sub open ($u of Str where /^file:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^ftp:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^mailto:/, [EMAIL PROTECTED]) returns
Handle {...}
...
Though that would potentially be problematic if you wanted to open
a file whose name started with "http:", so we'd probably want to
give that suite of multis a different name. Call it io() maybe, if
we can unify the Handle and IO abstractions. As I've said before,
I kinda like the IO::All module, except for how it overloads < and >.
But Perl 6 has ==> and <== that can do that instead, which just happen
to be called "pipes", strange coincidence. :-)
Presumably you can write a "slurp" like this:
my $page <== io("http://www.wall.org/~larry";);
Larry
Re: Blocks, continuations and eval()
On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote: Thank you for your detailled answer. I still don't get what you mean by "[] pattern matching arguments". Do you mean smart pattern matching on composite values? > > A lot of features are making it into Perl 6 that have historically been > associated with "functional" programming. Off the top of my head: > ... > [] pattern matching arguments -- cognominal stef
Re: -X's auto-(un)quoting?
Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo(). I wish there were more keys on my keyboard...
I know it's a bit counter-cultural, but at the moment I'm wondering
if we can make this work instead:
given open 'mailto:[EMAIL PROTECTED]' {
_say(...);
_close or fail;
}
We do, after all, have better ways of declaring private methods and
functions now. so maybe we don't need to reserve _ for that anymore.
And it would save two characters over $_.foo(). But recovering C
I kind of like that, but see below.
programmers will scream, and probably prefer _.foo(), even if it only
saves one character. Maybe it's time to raid Latin-1 for the next
closest thing to a dot, "middle dot":
given open 'mailto:[EMAIL PROTECTED]' {
·say(...);
·close or fail;
}
But I'm sure some will argue that's too subtle. (Hi, @Larry.)
I agree, too subtle.
Well, hey, as long as we're looking at Latin-1, we could use superscripts
to indicate nested topic defaults.
given open 'mailto:[EMAIL PROTECTED]' {
say¹(...);
close¹ or fail;
}
Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().
Or we go back to .foo always meaning $_.foo and use ¹.foo to call the
first invocant, ².foo to call the second, ³.foo to call the third.
Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds
if we didn't autobox literal numbers.
Given I like _.foo(), we can get around the autobox problem by using
_2.foo(), _3.foo, etc. Even though those are legal(?) variable names
I've never seen them used in code anywhere.
But I rather like ` for user-defined literals. I suppose bare ^
is also available:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
This kind of works also. And it would allow ^2.foo(), ^3.foo(), etc. or
even ^^.foo(), ^^^.foo(), etc (nah!).
That almost makes sense, given that $^a is like $_. It also points vaguely
upward toward some antecedent. I could maybe get used to that, if I
tried real hard for a long time. Almost makes we wish we could rename
$_ to $^ though. Hmm...
Too late, maybe.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: -X's auto-(un)quoting?
On Fri, 22 Apr 2005 15:09:21 -0400, Juerd <[EMAIL PROTECTED]> wrote:
Matt skribis 2005-04-22 14:44 (-0400):
mailto isn't something you can "open" really, for read at least.
No, but writing to it ought to simplify things :)
given open 'mailto:[EMAIL PROTECTED]' {
.say(q0:to<.>
Subject: Useful mailto open
User-Agent: Perl 6
In-Reply-To: <[EMAIL PROTECTED]>
Hello, world!
.
);
.close or fail;
}
Good point, I didn't think of that :) That would be awesome if you could
do that in perl6 without needing any extra libraries.
What about ftp?
given open 'ftp://user:[EMAIL PROTECTED]:port' {
.say(q0:USER username
PASS password
);
.close or fail;
}
Though I'm not sure exactly how the FTP protocol works :)
Re: Blocks, continuations and eval()
On Fri, Apr 22, 2005 at 08:13:58PM +0200, Stéphane Payrard wrote:
> On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote:
>
> Thank you for your detailled answer. I still don't get what you mean
> by "[] pattern matching arguments".
> Do you mean smart pattern matching on composite values?
>
> >
> > A lot of features are making it into Perl 6 that have historically been
> > associated with "functional" programming. Off the top of my head:
> > ...
> > [] pattern matching arguments
Thx to people on #perl6, I got it. It is a form of pattern matching
on arguments. It is described in S06 in under the headers "Unpacking
hash parameters", "Unpacking array parameters".
sub quicksort ([$pivot, [EMAIL PROTECTED], ?$reverse, ?$inplace) {
...
}
So if we mix that with typing, we will end with full fledged unification?
--
cognominal stef
[announcement] tnx.nl/S03
FYI: I've added three lines to tnx.nl's 404 handler: /^A\d\d$/ and $_ = "http://dev.perl.org/perl6/apocalypse/$_.html"; and next; /^E\d\d$/ and $_ = "http://dev.perl.org/perl6/exegesis/$_.html"; and next; /^S\d\d$/ and $_ = "http://dev.perl.org/perl6/synopsis/$_.html"; and next; Which makes links like http://tnx.nl/S03 available. A handy tool for those who discuss Perl 6 on IRC. As with other tnx.nl redirects, they can be combined using a comma: http://tnx.nl/A05,S05 A list of these and other available redirection tags is at http://tnx.nl/404 Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
On Fri, Apr 22, 2005 at 09:09:21PM +0200, Juerd wrote:
: Matt skribis 2005-04-22 14:44 (-0400):
: > We're talking about the *built-in* functions here, right?
:
: I don't know.
:
: > Anyway, is there any other URI scheme besides for mailto: that doesn't use
: > <://>?
:
: I don't know, but if you want to find this out,
: http://www.iana.org/assignments/uri-schemes is probably a good starting
: point.
:
: > mailto isn't something you can "open" really, for read at least.
:
: No, but writing to it ought to simplify things :)
:
: given open 'mailto:[EMAIL PROTECTED]' {
: .say(q0:to<.>
: Subject: Useful mailto open
: User-Agent: Perl 6
: In-Reply-To: <[EMAIL PROTECTED]>
:
: Hello, world!
: .
: );
: .close or fail;
: }
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo(). I wish there were more keys on my keyboard...
I know it's a bit counter-cultural, but at the moment I'm wondering
if we can make this work instead:
given open 'mailto:[EMAIL PROTECTED]' {
_say(...);
_close or fail;
}
We do, after all, have better ways of declaring private methods and
functions now. so maybe we don't need to reserve _ for that anymore.
And it would save two characters over $_.foo(). But recovering C
programmers will scream, and probably prefer _.foo(), even if it only
saves one character. Maybe it's time to raid Latin-1 for the next
closest thing to a dot, "middle dot":
given open 'mailto:[EMAIL PROTECTED]' {
·say(...);
·close or fail;
}
But I'm sure some will argue that's too subtle. (Hi, @Larry.)
Well, hey, as long as we're looking at Latin-1, we could use superscripts
to indicate nested topic defaults.
given open 'mailto:[EMAIL PROTECTED]' {
say¹(...);
close¹ or fail;
}
Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().
Or we go back to .foo always meaning $_.foo and use ¹.foo to call the
first invocant, ².foo to call the second, ³.foo to call the third.
Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds
if we didn't autobox literal numbers. Though that would put a crimp
in the Rubyish
3.times:{ say "It's true!" }
Okay, that's kinda nuts. How 'bout we change ! to ¬ and then we can
say:
given open 'mailto:[EMAIL PROTECTED]' {
!say(...);
!close or fail;
}
Sigh. We could also take ` away from user-defined literals and say
given open 'mailto:[EMAIL PROTECTED]' {
`say(...);
`close or fail;
}
But I rather like ` for user-defined literals. I suppose bare ^
is also available:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
That almost makes sense, given that $^a is like $_. It also points vaguely
upward toward some antecedent. I could maybe get used to that, if I
tried real hard for a long time. Almost makes we wish we could rename
$_ to $^ though. Hmm...
: > If it's for built-in, then only the most common protocols would be defined
: > I imagine.
:
: No, if it's built in, we should stick to the spec and interpret every
: ^\w+: (roughly - see RFCs for syntax specifics) as a scheme.
Yes, especially the c: scheme. :-)
Larry
Re: -X's auto-(un)quoting?
> Anyway, is there any other URI scheme besides for mailto: that doesn't use > <://>? > > It¹s optional for news:; news:comp.lang.perl is a valid URI for accessing that > Usenet newsgroup via whatever your default news server is. > > There aren¹t any slashes in the aim: scheme (not part of the IANA standard, > but widely supported for accessing AOL-compatible IM clients from web > browsers). > > There are no slashes in tel: (telephone numbers), though I don¹t know what you > could do with those from Perl. :) > > And I¹m sure there are others. The syntax after the colon is pretty much > arbitrarily determined by the scheme prefix, so a global constraint on it is a > bad idea. > > -Mark
Re: -X's auto-(un)quoting?
On Fri, 22 Apr 2005 21:31:03 -0400, Larry Wall <[EMAIL PROTECTED]> wrote:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
That almost makes sense, given that $^a is like $_. It also points
vaguely
upward toward some antecedent. I could maybe get used to that, if I
tried real hard for a long time. Almost makes we wish we could rename
$_ to $^ though. Hmm...
I think ^ makes the most sense. I like how it points up. Like it's
saying "HEY! THE TOPIC IS UP THERE!"
Though, it IS still a bit odd. It seems more like a modifier on the
function, than a reference to the topic.
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)
Re: -X's auto-(un)quoting?
On Fri, 22 Apr 2005 14:24:25 -0400, Juerd <[EMAIL PROTECTED]> wrote:
Because a URI scheme ends in :. It http: followed by anything other than
// should fail because it is invalid, not fall back to file handling.
IFF you're handling URIs.
multi sub open ($u of Str where /^mailto:\/\//, [EMAIL PROTECTED])
returns
Handle {...}
Well, it's mailto:[EMAIL PROTECTED], not mailto://[EMAIL PROTECTED]
True, I did not think of that. But it can at least be defined for most
URI schemes to check for ://, in the case of HTTP, FTP, etc.
We're talking about the *built-in* functions here, right?
Anyway, is there any other URI scheme besides for mailto: that doesn't use
<://>? mailto isn't something you can "open" really, for read at least.
If it's for built-in, then only the most common protocols would be defined
I imagine. The ones I can think of that you can read from/stream in use
<://>, so I don't see why the methods for those protocols can't be defined
with <://>. Maybe I'm missing something here though.. which does happen a
lot ;)
Also, I don't know much about rules with regex yet, but could you do
something like...
multi sub open ($u of Str where //, [EMAIL PROTECTED])
returns
Handle {...}
Where < > expands to < file:// >
Yes, but it's probably easier to just use a hash: %protocol.
Easier or more efficient?
Re: Accepted abbreviations
Juerd skribis 2005-04-22 16:11 (+0200): > Those are for identifiers, so we don't end up with one function using :r > and another using :read. That'd be inconsistent. Although readline should not be made rline, and I still think both :r and :read should work! Bool +$read is short or preferrably with even simpler syntax: Bool +$read|r Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Accepted abbreviations
Aaron Sherman skribis 2005-04-22 10:00 (-0400): > On Fri, 2005-04-22 at 07:46, Juerd wrote: > > Can we together compile a list of accepted abbreviations, so they can be > > consistently applied? > Are you suggesting that these are accepted by the compiler or by us (for > discussion)? By us. Mostly for the purpose of choosing identifiers (str, and thus substr, not substring), but also for discussion (we talk about subs, not subroutines) and perhaps documentation. See below for further clarification. > You can decide to use whatever you like, but if you're honestly > expecting that people participating in this mailing list are going to > use your favorite abbreviations, you're the kind of person I think we > should have more of in the world: optimists (opmst for short). ;-) No, it's not to change the world. But whatever ends up in the official thing, should be consistent throughout. And for that, we need consensus. Because it can take a long time before people agree, I think we should begin as early as possible. Using identifiers consistently also helps when reading example code. For example, $fh is immediately clear, as are $dbh and $sth. But when someone uses $handle, $connection and $statement for these, it gets a bit harder. Learning something is easiest when in the explanation of one thing, you recognise parts of something you've already seen. And for that, you need consistent documentation, along with consistent usage in the language itself. To provide one example: a few years ago I had a very hard time trying to figure out what 'ary' stood for, simply because in the lots of Perl documentation and code, I had not seen it before. Things that come naturally for experienced programmers can be very intimidating for beginners, and wherever we can, I think we should provide consistency. Of course I'm NOT saying that we should start considering one of regex and regexp wrong. When it comes to reading, both are equally good and recogniseable to everyone subscribed to this mailinglist. But many beginners wonder what the p in regexp stands for! > What's more, I'd rather you didn't w comments with single-letter > abbreviations, as it would make it much harder for me to r. Those are for identifiers, so we don't end up with one function using :r and another using :read. That'd be inconsistent. I should have been clearer when I sent the initial list. I'm not trying to change the world. Sorry about that. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Accepted abbreviations
On Fri, 2005-04-22 at 07:46, Juerd wrote: > Can we together compile a list of accepted abbreviations, so they can be > consistently applied? Are you suggesting that these are accepted by the compiler or by us (for discussion)? > Some may be source of discussion, in which case I think it's better to > pick one -perhaps against someone's preference- than to use a dozen > abbreviations for the same thing. One such example is "regex", which > used to be spelled by most as "regexp". (Yes, I know we're using rules > now... :).) This makes it sound like you mean us, not the compiler. I'll work with that assumption. You can decide to use whatever you like, but if you're honestly expecting that people participating in this mailing list are going to use your favorite abbreviations, you're the kind of person I think we should have more of in the world: optimists (opmst for short). ;-) Seriously, do any of us have a hard time making out what someone means if they say "regexp" vs "regex"? What's more, I'd rather you didn't w comments with single-letter abbreviations, as it would make it much harder for me to r. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Accepted abbreviations
Can we together compile a list of accepted abbreviations, so they can be consistently applied? I'll begin with the most basic ones: arefarray reference boolboolean const constant elemelement err error fh filehandle funcfunction hrefhash reference int integer kv key/value num number obj object op operator, operation r read(able) ref reference regex regular expression rw read/write str string sub subroutine w write(able) Some may be source of discussion, in which case I think it's better to pick one -perhaps against someone's preference- than to use a dozen abbreviations for the same thing. One such example is "regex", which used to be spelled by most as "regexp". (Yes, I know we're using rules now... :).) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Blocks, continuations and eval()
Hi, I am making a presentation about Perl6 this week end. My point will be: the next generation of applicative languages will be scripting languages because they have come of age. Alternatives don't cut it anymore. Indeed C and C++ are memory allocation nightmare; Java and C# don't have read-eval loop, a necessary condition for rapid learning and development. Functional languages like haskell or ocaml are very powerful but needs massive wetware reconfiguration to get used to the syntax and semantic. So I will make do a presentation of Perl6 and Parrot features to make my point about upcoming scripting languages. I have a few questions inspired by my recently acquired knowledge about functional languages. Perl6 being the ultimate syncretist language, I wonder if some functional features will make it into Perl6. I know we already got currying. A very nice feature of Haskell and *ml is the possibility to define complex datastructures types and the control flow that manipulate these structures: constructors and pattern matching. With these languages, in a very deep sense, control flow is pattern matching. Can we expect Perl6 to propose something similar? If yes, could be the matching part folded into the rule syntax? Rules are about identifying "structures" in parsed strings and acting accordingly. Partern matching is about identify typed structures and acting accordingly. There is a similarity there. Also we may want to match both at the structural level and at the string level. Or is this asking too much of rules, that have already swallowed both lexing and parsing. The notion of data type become very useful in Perl6 for people who want it. In fact, Perl6 is a mix of dynamic and static types (bindings). I think type theory handles type inference in this kind of langage with something called dependant type. Though I have to go thru ATTaPl to get it. Perl, like many scripting language is very lax and, when needed, converts implicitely values within expressions. This is nice, but I think that makes type inference impossible. Type inference is good because it allows to generate very efficient/strict code with very little type annotations. Can we expect in a distance feature a pragmatic mode convention to control automatic type conversions if any and the type inference scheme chosen when/if implemented? -- cognominal stef
Re: -X's auto-(un)quoting?
Larry Wall skribis 2005-04-21 15:50 (-0700):
> There's one minor problem with -r -w $file, which is that it evaluates
> right-to-left, which is going to surprise some people who think they
> want to say
> -e -r $file
> when they really mean
> -r -e $file
It doesn't have to, of course. The test can be postponed and delegated
to the lexical first -X operator. A matter of letting -X behave
differently in -X context than in any other context, I guess.
> Now the interesting thing about the ~~ approach is that it naturally
> lends itself to
> given $file {
> when :x {...}
> when :r:w {...}
> when :r(0) {...}
> when :u | :g{...}
> default:
> }
> I suppose it's a little bit rude to grab all the pairs for testing
> against all the strings, so maybe we have to say
> given $file.test {...}
> $file.test ~~ :r&:w
> or maybe
> given $file.stat {...}
> $file.stat ~~ :r&:w
Perfect!
> BTW, I'm assuming the $file is either $filename or $filehandle there.
Which brings me to the following: can open please use the same kind of
$file, so that open $filehandle just checks $filehandle's mode and
returns $filehandle again? That way, every library function that accepts
a filename automatically also accepts an open filehandle, which has a
thousand and one benefits.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
On Fri, Apr 22, 2005 at 09:24:51AM +0200, Michele Dondi wrote: : Speaking of which, I like to think of (some) adverbs in terms of cmd line : switches, and maybe it's just me, but I think it would be extremely useful : to have a full set of tricky ones providing reasonable defaults : (user-overridable, of course), short enough to be easy to type; e.g: : : unlink :warn; # roughly equivalent to Perl5's : # unlink or warn "Could not remove `$_':$!\n"; The problem with that approach is also evident in Unix culture. How many different ways are there to ask for help, or to get verbose output, or to specify the output filename? How many different ways are there to specify input and output delimiters? -e means something very different to Perl than to rpm. Does this version of chown use -r or -R for recursion? Admittedly, some of these problems would have been reduced if Unix had gone with long option names to begin with. But a lot of these problems come from too many people in too many places inventing too many similar things without the benefit of a culture that encourages a common standard without forcing one. In Perl culture we must guard against the extremes of central control vs anarchy, and choose a middle path. And some of these things can be headed off by designing the interface differently. We wouldn't need a recursion option on chmod/chown/cp etc. if Unix had a notation for "all the files under this one". Similarly, if Perl has consistent warning and exception mechanisms that are easy to use and properly scoped, people are less tempted to make up one of their own. All that being said, we did design named parameters into Perl 6 so that an interface could have options. But people are quick to add options without thinking about the global consequences of name choice. I feel like there's a cultural solution there somewhere, but I don't know what it is, because that's the sort of thing cultures are better at inventing than I am. :-) Larry
Re: -X's auto-(un)quoting?
On Thu, 21 Apr 2005, Larry Wall wrote: : perl -lne 'print if -e :q' It seems to me that -e «$_» would handle most of these cases, as long as whitespace always comes in quoted so that you always end up with one word. I would say this is hardly the case for the kind of file lists I was referring to. Not that this is terribly relevant from a world wide perspective, I guess... That seems more general than a special option to -X ops. Speaking of which, I like to think of (some) adverbs in terms of cmd line switches, and maybe it's just me, but I think it would be extremely useful to have a full set of tricky ones providing reasonable defaults (user-overridable, of course), short enough to be easy to type; e.g: unlink :warn; # roughly equivalent to Perl5's # unlink or warn "Could not remove `$_':$!\n"; Michele -- Whoa! That is too weird! I asked around among the math faculty here and it turns out that _every one's_ wife is married to a mathematician! - Dave Rusin in sci.math, "Re: Genetics and Math-Ability"
