Re: Graphing tool for PerlGuts Illustrated
On 20/05/05 22:06 +0300, Yuval Kogman wrote: Hola, In PerlGuts Illustrated you have some very pretty diagrams... Could you please hint me on what you generated them with, so that I can use it for the forthcomming PugsGuts Illustrated? I used to sit next to Gisle at ActiveState. IIRC(AIDRC), he hand-hacked postscript files for those diagrams :P Cheers, Brian
Re: Inline::Pugs landed to Pugs tree
On 19/05/05 04:52 +0800, Autrijus Tang wrote:
An one-hour hack of mine proved fruitful. This is Perl 5 script,
calling into Perl 6 functions defined inline:
#!/usr/bin/perl
use Inline Pugs = '
sub postfix:! { [*] 1..$_ }
sub sum_factorial { [+] 0..$_! }
';
print sum_factorial(3); # 21
The implementation is in lib/Inline/Pugs.pm that comes with Pugs tree.
You'll need Inline.pm from CPAN to run the example above.
Patches, suggestions, etc welcome. :-)
Enjoy,
/Autrijus/
*evil grin*
An five-minute hack of mine proved fruitful. This is Perl 5 script,
calling into Perl 6 functions defined inline:
#!/usr/bin/perl
use pugs;
sub postfix:! { [*] 1..$_ }
sub sum_factorial { [+] 0..$_! }
no pugs;
print sum_factorial(3); # 21
The implementation is in lib/pugs.pm that comes with Pugs tree.
You'll need Inline.pm from CPAN to run the example above.
Patches, suggestions, etc welcome. :-)
Enjoy,
/ingy/
Re: ^method ?
On 15/05/05 11:17 -0400, Rob Kinyon wrote:
On 5/15/05, Juerd [EMAIL PROTECTED] wrote:
Autrijus Tang skribis 2005-05-15 19:28 (+0800):
On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote:
Or was your choice of words poor, and did you not mean to discuss the
dot's *default*, but instead a standard way to write the current
invocant?
I think what Rob suggested is that:
method ($foo)
means
method ($self: $foo)
Then I hereby apologise to Rob for my own poor choice of words.
I don't like the idea of having a normal identifier ever used by
default, except $_, which is already aliased to the invocant.
Autrijus is much more eloquent that (apparently) I can ever hope to
be. Thank you.
If I understand correctly, we're discussing what should happen if you
do something like .method($foo) within another method and if there
should be shorthand way of writing whatever it is.
Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
we should use $self wherever $?SELF would be used. $_ is still the
topic and would be the default invocant if you have .method($foo).
What I'm saying is that you can have
method ( Int foo ) {
$self.otherMethod( foo );
}
+1
FWIW, after reading this whole conundrum, I think that erring on the
side of pragmatism seems like the right choice. If I jump into some
source code and see:
$self.some_such();
I am going to feel right at home. No doubt about it.
As to *how* it works (by hook, crook, preclaration or macro etc), I
leave it to Larry to do the proper hand waving to make it fit in cleanly
(for some Wallian definition of clean).
Cheers, Brian
and it will DWIM. Just like Java, C++, and Javascript. (Yes, I'm using
JS as part of my argument.)
If you have
method ( Int foo ) {
.otherMethod( foo );
}
That would be
method ( Int foo ) {
$_.otherMethod( foo );
}
Just like expected.
Rob
S27 Draft
I've taken a shot at starting a Synopsis 27 as well: http://svn.openfoundry.org/pugs/docs/S27draft.pod Cheers, Brian
S26 Draft
Per autrijus request, I have written a preliminary Synopsis 26 -- Perl Documentation. For your ripping apart pleasures: http://svn.openfoundry.org/pugs/docs/S26draft.pod Cheers, Brian
Re: S26 Draft
On 10/04/05 09:58 -0400, Aaron Sherman wrote: On Sun, 2005-04-10 at 14:02 +0300, Yuval Kogman wrote: Please don't be lazy, everyone, and look at this: http://svn.openfoundry.org/pugs/docs/ There are some more drafts that should be reviewed, and more will probably follow. Can we please be rid of: http://svn.openfoundry.org/pugs/docs/advocacy/phd.png It's just rude, and Perl's public face should never be one of rudeness. Applied, thanks.
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 17/03/05 00:49 -0500, Aaron Sherman wrote: On Wed, 2005-03-16 at 13:42 -0800, Brian Ingerson wrote: Well, look over AJS Kwid, and see what you think. The bullet syntax you give could work fine as a replacement for what I demonstrate, but I think everything else is pretty much 1:1. Now it's just a matter of: do you make it Wikiish or PODish? Aaron, I think AJS Kwid is fine if it fits your brain. It doesn't fit mine in much the same way that Kwid doesn't fit yours, in much the same way that Pod doesn't quite fit either of ours. The interesting thing to me is that all 3 syntaxes map over the same data model and thus are easily interchangable. The other interesting thing is that all three could be supported without affecting the Perl5 or Perl6 syntax proper. Sam mugwump Vilain refers to each of these syntaxes as /Pod dialects/. He is working on more formally defining the common model or AST that these dialects map to. Given that, I am going to continue working on the Kwid dialect and developing the Kwid tools I have started. The ideas in AJS Kwid seem too different to incorporate without muddying the Kwid vision. I encourage you work on the AJS Kwid dialect too. I would guess that the Kwid tools I'm working on, when completed, could be easily adapted to AJS Kwid. Cheers, Brian PS All my work thus far is available in the pugs repository.
Re: s/true/better name/
On 17/03/05 04:40 +0800, Autrijus Tang wrote: On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote: whereas as a native English speaker would probably expect $x = whether($a or $b); So I'm thinking we'll just go back to true, both for that reason, and because it does syntactically block the naughty meaning of true as a term (as long as we don't default true() to $_), as Luke reminded us. But true() reads weird, and it does not read like an unary (or list) operator at all to me. As the bikeshedding is still going on, may I suggest aye()? It is the same length as not(), both are adverbs, and is rare enough to not conflict with user-defined subs. 'Tis a pity nobody suggested `tis()`. Cheers, Brian
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 12:00 -0500, Aaron Sherman wrote:
On Tue, 2005-03-15 at 13:48, Brian Ingerson wrote:
Aaron,
Upon reading this, it is unclear to me whether you have read about the
Kwid format or you are simply guessing that Kwid is the same syntax
used by Kwiki.
I read the Kwid documentation from the Pugs distribution in depth.
To create Kwid I carefully studied the POD information model
(the semantic tree that POD parses to). Kwid uses the exact same
info model. This means that switching between the two without
loss of information is possible.
I noted that in my original message.
This makes the Kwid experiment much less risky
Risk was not my concern. My concern was a Wiki-like model which is
inconsistent with many of the goals of POD. POD is intended to be PLAIN
OLD documentation.
I think consistency with goals is fine, but consistency with the data
model is more important. POD has a very nice data model that maps well
to other formats. It is really well done. So logic stands that any
format which can map cleanly to POD and yet offer an advantages to the
author is a benefit to the author without needing to retool the
extensions. Further any dialect can be converted to any other without
information or structure loss.
POD's syntax is certainly good enough, but doesn't match the way that
people commonly write structured prose; especially in this era of text
based formatting such as in wikis. POD's syntax /elegance/ also tends to
break down into workarounds too fast in edge cases.
NOTE: POD does have some minor warts in the data model, but they can be
fixed later on.
Kwid breaks this model of simplicity by introducing unique boundary
characters for many types of operations, and by making the overall
presentation more complex.
Let's look at an example and explore the rationale:
Pod uses this syntax Bbold stuff which is fine, but it is a very
common idiom to use *bold stuff* outside of Pod. Usenet posts, email,
irc, etc. People use this, they grok it, and lots of tools grok it as
well. (I'm thinking irc clients as an example).
So how do we get *there* formally and avoid making a mess where * is
just supposed to be an asterisk?
Kwid does this by formally changing
X...
into
{X...X}
Where `X` is any Pod code like `B`, `I` or `C`. Since there are only 3
codes in common use (ignore `L` for a second), Kwid thus uses {*bold*}
{/italic/} and {`code`}.
This has a subtle but significant advantage over X The difference
is that instead of the ending marker being '' it is 'X}', which is
orders of magnitude less likely to show up in the content being escaped.
This means you avoid the X ... mess almost entirely.
But the better part of this is that the Kwid forms can be relaxed to
drop the curlies in most cases. This technique uses the principle of
hugging. So you can say *$a = $b * $c* and get the bolded equation
since the middle * isn't hugging anything. Hugging is a nontrivial
heuristic, but let's just say it Does The Right Thing. And if you aren't
sure just say {*$a = $b * $c*}. ie, just add some curlies to what you
already have.
*Bold* and /italics/ are rather obvious, intuitive and commonly used.
Backticks for `code` was chosen because backticks are rarely used in
code. Except of course when writing about Kwid itself. But to get
C`code` you just go to the curlies: {``code``}. Simple. Backticks also
seem to be right visually, but that's just my opinion.
For L..., I decided to use the very common wiki idiom of [...] for a
link. Everything in the `...` is the same as Pod.
I is purely subjective whether Kwid's overall presentation is more or
less complex than Pod's. Kwid attempts to elegantly move towards the
modern internet era of social software, with the hope that those
participating in those arenas might feel more at home.
While I appreciate several features of Kwid, I feel that it should not
replace POD without first adopting a POD-like simplicity.
Some people have argued that Kwid is only a syntactic change to
Pod. I would argue that they are correct.
They are demonstrably wrong. You cannot Parse Kwid correctly by changing
the syntax of a POD parser.
For example, the behavior of
* foo
bar
The behaviour of this is completely consistent. You may need to reread the
perlkwid document for it has recently changed.
ie
* foo
bar
* baz
boom
matches
* foo bar
* baz boom
matches
.list
* foo bar
* baz boom
.list.
The explicit `.list` is only needed when the parser cannot guess from
the context.
...
I would encourage those interested in further fleshing out Kwid to join
irc://irc.freenode.net/#kwid where all of this is actively being
discussed.
Cheers, Brian
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 13:30 -0500, Aaron Sherman wrote: On Wed, 2005-03-16 at 12:25, David Storrs wrote: I quite like as the bracketing characters. They are visually distinctive, they connect well with their adjacent C/X/L/etc without visually merging into it (compare Lfoo with L[foo]), and in the circumstance that you want to bracket an unbalanced bracket, you just double (triple, whatever) up and add some space: C $x $y Looks pretty clear to me. You are confusing aesthetics with usability. Yes, the above looks clear, but then I have to type C and just to tell the POD parser that there might be unbalanced or characters in my string. You're failing to apply Larry's rules of Perl 6. Huffman and the easy things easy, while hard things are possible principles demand that a common case not require copious extra gunk, and noting could be simpler than: C[$x $y] is about as B[easy] as it gets in [Perl] vs: C $x $y is about as Beasy as it gets in L[Perl|perl] without going full Wikish: [=$x $y] is about as *easy* as it gets in [Perl] vs Kwid: `$x $y` is about as *easy* as it gets in [Perl] Did you really read `perlkwid.kwid`? There is simply no mention of `[=...]` as a markup option, which makes me wonder where you got it from? However, saving a couple of keystrokes and cleaning up the above text is inconsequential compared to the massive savings in terms of taking advantage of the legions of people who are learning Wiki syntax these days. Making POD *more* Wiki-like without sacrificing useful features of POD is invaluable in terms of tech writers and other non-Perl-programmers writing useful docs in POD! Well said! Cheers, Brian
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 14:33 -0500, Aaron Sherman wrote:
On Wed, 2005-03-16 at 14:17, Brian Ingerson wrote:
Kwid does this by formally changing
X...
into
{X...X}
Ok, where is THAT proposal?! I'm reading the doc that's in
doc/perlkwid.kwid in the pugs source tree. Hmmm... odd, I just did an
update and it's GONE now... was I looking at some phantom doc that had
an old spec for Kwid?!
Sorry, it has been moved around the pugs source tree a bit. It is
currently swinging from the documentation branch:
ext/Pugs-Documentation/perlkwid.kwid
Where `X` is any Pod code like `B`, `I` or `C`. Since there are only 3
codes in common use (ignore `L` for a second), Kwid thus uses {*bold*}
{/italic/} and {`code`}.
FYI, it turns out that at least one modern format,
[Markdown|http://daringfireball.net/projects/markdown/syntax], uses
backticks for code. Markdown doesn't really map to the Pod space very
well, but it has a few gems...
Well, I'm personally not fond of the bare-bracketting with {}, but as
long as it's not a stand-alone /italic/ like it was in the original doc,
that sounds fine. Why {/foo/} is more readable than I[foo], I'm not
sure... but I'll try to take your word for it.
In short you don't need to worry about I[[ $foo[3] ]]. Since the ending
marker is '/}', you only ever need to worry about escaping anything but
'/}' itself. I might as well show how that would be done:
{/foo \/} bar/}
{{/foo /} bar/}}
{/foo { /} } bar/}
Those are 3 possible ways to make Ifoo /} bar. Note that '{ ' and ' }'
are the asis or leave me alone indicators. But the real point is
that '/}' is rather unlikely to ever show up in italics outside this
discussion.
For L..., I decided to use the very common wiki idiom of [...] for a
link. Everything in the `...` is the same as Pod.
There, I think you're making a small mistake, but not a huge one. I'd
separate out magical wiki-like [foo] from pedantic, pod-like L[foo] so
that you can get either one. Wiki's [foo] is like a URN, where POD's
L[foo] is more in tune with a relative URL.
So I will give a little extra info on this...
The idea is to DWIM and there is a lot you can do with the `[...|.../...]`
syntax. Pod's strict syntax is:
Ltext|resource/section
/Text/ is obviously the text that should render. /Resource/ can be a
local manpage (ie another Pod document) and then /section/ is a section
in that doc. If /resource/ is empty, the current document is assumed.
/Resource/ can also be a fully qualified url and in that case section
does not apply.
For some reason Pod does not allow Ltext|url but there seems to be no
obvious reason. (This is the the only major thing where Kwid strays from
Pod's info model).
I am not certain what use case `L[...]` could get you that isn't already
covered by `[...]`.
While I appreciate several features of Kwid, I feel that it should not
replace POD without first adopting a POD-like simplicity.
Some people have argued that Kwid is only a syntactic change to
Pod. I would argue that they are correct.
They are demonstrably wrong. You cannot Parse Kwid correctly by changing
the syntax of a POD parser.
The behaviour of this is completely consistent. You may need to reread the
perlkwid document for it has recently changed.
Apparently.
ie
* foo
bar
* baz
boom
matches
* foo bar
* baz boom
matches
.list
* foo bar
* baz boom
.list.
Hrm...
How, then do you differentiate:
* Bullet list.
1. Numbered list.
Other
Term/definition lists
? In POD, that would be:
=item *
Bullet list
=item 1
Numbered list.
=item Other
Term/definition lists
This makes no sense in html and perlpod says:
* And perhaps most importantly, keep the items consistent: either
use =item * for all of them, to produce bullets; or use
=item 1., =item 2., etc., to produce numbered lists; or use
=item foo, =item bar, etc. -- namely, things that look
nothing like bullets or numbers.
In Kwid, therefore, this:
* Bullet list.
+ Numbered list.
- Other
Term/definition lists
would produce 3 single item lists. You can obviously switch types in sublists:
* Bullet list.
++ Numbered list.
* another bullet
-- Other
Term/definition lists
I would encourage those interested in further fleshing out Kwid to join
irc://irc.freenode.net/#kwid where all of this is actively being
discussed.
Sorry, no access to IRC at work. If the specification of core pieces of
P6 are being done off-list, why is there a list?
Honestly this project was started as an /experiment/ and was not
intended to distract p6l. Kwid requires no extra input from the language
side as long as:
=kwid
...
=cut
is ignored by the interpreter. This turns out
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 16/03/05 14:56 -0500, Aaron Sherman wrote: On Wed, 2005-03-16 at 14:24, Brian Ingerson wrote: vs Kwid: `$x $y` is about as *easy* as it gets in [Perl] Did you really read `perlkwid.kwid`? Yes, and can you please stop asking that question? I read it several times, and you're starting to get just this side of insulting. If I got something wrong, fine, say so. Stop trying to dismiss everything else I've said by suggesting that I'm completely uninformed. Aaron, /please/ take no offense. I just don't understand where you picked `[=...]` up other than that is the (hated) syntax artifact of the original `CGI::Kwiki`. I don't recall ever using it in regards to Kwid. I'm sure there's a reasonable explanation. :) There is simply no mention of `[=...]` as a markup option, which makes me wonder where you got it from? I got it from that document or so I thought. Since it's now deleted, I'm no longer sure. Having a reference again would be nice. It's hard to have a conversation about a document that does not exist. In my first mail of the thread I pointed to it: http://svn.openfoundry.org/pugs/ext/Pugs-Documentation/perlkwid.kwid As I said in my last mail, it has moved around a bit, so pardon our dust. Ok, that said PLEASE DO NOT USE UNBALANCED CHARACTERS TO DELIMIT! Please, for the love of all that is valid input to any scanner / parser anywhere, do not re-introduce quoting hell. Really. Please. Don't. I'll buy you a beer. I swear, just put the unbalanced operator down and step back. A beer is tempting... Sorry, but I use POD specifically because it makes my life simple. Introducing unbalanced quotes into it would remove that functionality. A few examples: And then I says, `Mabel,' I says, `shut up.' The ``` character is no longer used. And of course, TONS of Gnu documentation which uses the TeX-friendly: This is the way you ``quote'' things. No problem with this example. `` doesn't /hug/ anything so it shows up asis. Cutting and pasting LaTeX doesn't mess anything up in this regard. But really, you'll likely refactor it to: This is the way you quote things. Since `` and '' don't do anything for you in either Pod or Kwid. Cheers, Brian
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron, Upon reading this, it is unclear to me whether you have read about the Kwid format or you are simply guessing that Kwid is the same syntax used by Kwiki. It is not the same format at all. Kwid is merely /inspired/ by Kwiki, which in turn is inspired by the (more usenix) features of modern wiki languages. It is more fair to say that Kwid is much more inspired by Pod than Kwiki. Please read what is considered to be the de facto spec: http://svn.openfoundry.org/pugs/ext/Pugs-Documentation/perlkwid.kwid carefully and recomment. A few notes. To create Kwid I carefully studied the POD information model (the semantic tree that POD parses to). Kwid uses the exact same info model. This means that switching between the two without loss of information is possible. This makes the Kwid experiment much less risky, since it will be trivial to convert in either direction. As to the syntax, care has been taken to ensure that all the corner cases are covered. And also covered elegantly. Some people have argued that Kwid is only a syntactic change to Pod. I would argue that they are correct. :) But this does not mean it is not an important change. Kwid has an emphasis on minimizing the markup, and using the markup one might use to discuss programming in everyday email. This is hard to do in POD, but very easy to do in Kwid. Thus a bug win. It is also wrong to imply that important semantic changes cannot be made in the future. Things like introspection and transclusion. But that is not the current concern. In reality, Kwid does vary ever so slightly in semantics from POD. But only in cases where POD seemed to have a wart. For instance Kwid allows named hyperlinks: [The Pugs Source|http://svn.openfoundry.org/pugs]. Cheers, Brian On 15/03/05 11:46 -0500, Aaron Sherman wrote: Wherein I propose (to the wrong list, sigh) a re-envisioning of Kwid in a more POD-like form. I did leave out some POD markup forms. Assume that, if I did not mention them, then I think they should keep the same prefix character (e.g. X) Content-Description: Forwarded message - Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT) From: Aaron Sherman [EMAIL PROTECTED] Date: Tue, 15 Mar 2005 11:43:39 -0500 To: Stevan Little [EMAIL PROTECTED] Cc: perl6-compiler@perl.org Subject: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT) X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) On Tue, 2005-03-15 at 09:37, Stevan Little wrote: On Mar 15, 2005, at 12:54 AM, Nigel Hamilton wrote: There is a need for a higher level 'structural' documentation that hypertext is well suited to cover - something that spans more than one module. This will be especially important for CPan6 and connecting versions, and modules into bigger 'packages'. Agreed as well. It would be nice if CPAN6 or CP6AN or FreePAN (or whatever it will eventually be called) have a more sophisticated linking/documentation system which goes beyond the actual single module. I even think this would be possible in the current CPAN if we could get the L construct fixed, but that is another issue. Actually, I don't think that's at all another issue. It's the core of what you're talking about. L gives you the ability to link, and in several different ways. It's also broken in Perl 5, which makes a replacement sound attractive, but fixing it solves for much of that need. Taking a cue from the wiki world makes sense to me. Kwid is almost ideal as far as I can tell in that it: a) Does everything POD does b) Is backward compatible with Perl 5 in that it can be ignored by the parser in the same way. c) Makes many things easier Now, it does need some tweaking, I think, but nothing too severe. It just makes a few things harder, and a few other things non-POD-like for no particular reason. I like CPOD for the ease of including keywords in Cperl documentation. It's also Btrivial to Irecognize all markup quickly (visually or programmaticly). Kwid /on the other hand/ makes it a bit harder to [=find] that markup, and is *thus* not quite as easy to de-parse visually. I'd be thrilled if we just changed the .-introduced things to =-introduced things: = heading level 1 == heading level 2 =begin list * You don't really need the begin * But it doesn't hurt * and it allows some(code()) to appear inside a list item. * Hmmm =end list And then replaced [...] and [=...] and /.../ and *...* with their more POD-like: L[...], C[...], I[...] and B[...] with a bare [foo] working as a I have no idea what I'm linking to, but do the right thing sort of wikiness, where L[...] is a more structured, POD-like link. For example: = Proposed Kwid Changes == Introduction It is my I[goal] to introduce an easier to use (for [POD] users) version of [Kwid], and impose it B[mercilessly] on the heathen masses!
Config Variables
Hi all,
I'm hacking on pugs. I've added a Config.hs which is generated from the
build system's perl's Config.pm. This allows me to expose the Perl6 magical
variable $?OS.
There are a lot of other config values that seem like they don't really need
their own global. Things like 'privlib' and 'installsitearch'.
How about a config hash %?CONFIG for these.
%?CONFIG{'privlib'}
%?CONFIG{'installsitearch'}
Or would %*CONFIG be better?
Cheers, Brian
Re: Config Variables
On 03/03/05 11:25 -0800, Larry Wall wrote: On Thu, Mar 03, 2005 at 09:30:03AM -0800, Brian Ingerson wrote: : Hi all, : : I'm hacking on pugs. I've added a Config.hs which is generated from the : build system's perl's Config.pm. This allows me to expose the Perl6 magical : variable $?OS. ... In fact, what I think we're dealing with are lots proxies for different software and hardware objects. In fact, $?OS probably shouldn't return the OS name. It should return an object describing the compiler's OS. We were starting to make some distinctions such that the name is $?OSNAME $*OSNAME Larry, At first I was overwhelmed by your reply, but it's soaking in... :) My goal in the short term is to create an environment where regular folks can start writing and installing and sharing Perl6 modules. It's a lot of hacky work on various subsystems. And one thing I need is config info. Unfortunately, pugs has no object support yet. It probably will in the next week or two. In the meantime I'll just wing it with an eye towards the future. Thanks for the mind expanding reply. Cheers, Brian
use only The::Finest = 1.23;
AND CAVEATS * There is currently no way to install documentation for multiple modules. * This module only works with Perl 5.6.1 and higher. That's because earlier versions of Perl don't support putting objects in @INC. AUTHOR Brian Ingerson [EMAIL PROTECTED] COPYRIGHT Copyright (c) 2003. Brian Ingerson. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See http://www.perl.com/perl/misc/Artistic.html
Re: In defense of zero-indexed arrays.
On 05/12/02 02:45 -0800, Michael G Schwern wrote: I'm going to ask something that's probably going to launch off into a long, silly thread. But I'm really curious what the results will be so I'll ask it anyway. Think of it as an experiment. So here's your essay topic: Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 will benefit most users. Do not invoke legacy. [1] With languages like Perl that have negative subscripts, using a zero base gives continuity. @INC[-2..2] should continue to DWIM. Cheers, Brian
Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)
On 04/11/02 17:52 -0800, [EMAIL PROTECTED] wrote:
[Note to all: yes, this is me, despite the weirdities of the quoting
and headers. This is how it looks when I using mutt out of the box,
because I haven't yet customized it like I have pine. But I do like
being able to see my own Unicode characters, not to mention everyone
else's. If you don't believe this is me, well, I'll just tell you that
I live on a tropical island near Antarctica, my social security number
is 987-65-4321, and my mother's maiden name was the same as my maternal
grandfather's maiden name. Or something like that... --Ed]
Mutt?
I'm using mutt and I still haven't had the privledge of correctly viewing one
of these unicode characters yet. I'm gonna be really mad if you say you're
also using an OS X terminal. I suspect that it's my horrific OS X termcap
that's misbehaving here.
Aargh!
Brian
On Mon, Nov 04, 2002 at 02:25:08PM -0800, Michael Lazzaro wrote:
On Monday, November 4, 2002, at 11:58 AM, Larry Wall wrote:
You know, separate streams in a for loop are not going to be that
common in practic, so maybe we should look around a little harder for
a supercomma that isn't a semicolon. Now *that* would be a big step
in reducing ambiguity...
Or more than one type of supercomma, e.g:
for @x I @y I @z - $x I $y I $z { ... }
to mean:
for @x ; @y ; @z - $x ; $y ; $z { ... }
That almost works visually.
- vs -
for @x § @y § @z - $x § $y § $z { ... }
to mean:
for @x - $x {
for @y - $y {
for @z - $z {
...
}
}
}
;-)
Glad you put the smiley. I think the latter is much clearer.
But at the moment I'm thinking there's something wrong about any
approach that requires a special character on the signature side.
I'm starting to think that all the convolving should be specified
on the left. So in this:
for parallel(@x, @y, @z) - $x, $y, $z { ... }
the signature specifies that we are expecting 3 scalars to the sub,
and conveys no information as to whether they are generated in parallel
or serially. That's entirely specified on the left. The natural
processing of lists says that serial is specified like this:
for @a, @b, @c - $x, $y, $z { ... }
Of course, parallel() is a rotten thing to have to say unless you're
into readability. So we could still have some kind of parallizing
supercomma, mabye even P (U+2225 PARALLEL TO). But let's keep it
out of the signature, I think. In other words, if something like
for @x P @y P @z - $x, $y, $z { ... }
is to work, then
@result = @x P @y P @z;
has to interleave @x, @y, and @z. It's not special to the Cfor.
In the case of Cfor, of course, the compiler should feel free to
optimize out the actual construction of an interleaved array.
I suppose it could be argued that P is really spelled »,« or some such.
However,
@result = @x »,« @y »,« @z;
just doesn't read quite as well for some reason. A slightly better
case could be made for
@result = @x `|| @y `|| @z;
The reason we originally munged with the signature was so that we
could do weird things with differing numbers of streams on the left
and the right. But if you really want a way to take 3 from @x, then
3 from @y, then 3 from @z, there should be something equivalent to:
for round_robin_by_3s(@x, @y, @z) - $x, $y, $z { ... }
Fooling around with signature syntax for that rare case is not worth it.
This way, the Cfor won't have to know anything about the signature other
than that it expects 3 scalar arguments. And Simon will be happ(y|ier)
that we've removed an exception.
Ed, er, Larry
utf and ebcdic
On 04/11/02 12:12 -0800, [EMAIL PROTECTED] aka Larry Wall wrote: If you want trigraph support, you'll have to put use encoding 'ugly-american'; at the top of your files. ;-) ;-) ;-) Otherwise, it'll be one-character ?fancyops? all the way. Mmm, I view one-character Unicode operators as more of an escape hatch for the future, not as something to be made mandatory. But then, I'm one of those ugly Americans. Of course, I also think I'm allowed to be a little inconsistent in forcing things like »op« on people. After all, there's gotta be some advantage to being the Fearless Leader... On one hand I really respect your fearlessness to go where no language author has gone before. No matter what happens, I pretty sure you'll be remembered for it. ;) On the other hand I'm wondering what happens to the ebcdic platforms and the like. Will it even work to have core modules written in non ascii and expect them to translate to ebcdic? I suppose you'll have to convert them to trigraphs as part of the installation. Just wondering if you've thought through the support issues for platforms that by their definition won't be using utf ever. FWIW, ebcdic *does* have the cent sign! Cheers, Brian
Re: UTF-8 and Unicode FAQ, demos
On 04/11/02 14:09 -0800, Austin Hastings wrote: --- Rafael Garcia-Suarez [EMAIL PROTECTED] wrote: Austin Hastings wrote in perl.perl6.language : What we've got is an encoding problem at the MUA level. Mark Reed says my mailer (Yahoo!) tagged a message containing high-bit characters as US-ASCII. Several people the other day reported on the differences in UTF8 vs. Latin-1 handling among pine, elm, and other mailers. Not only the MUA level. Usually source code is written in a lowest common denominator of ascii, even for languages that allow unicode identifiers (Java) or markup. That's because source code is handled by parsers, documentation extractors, pretty printers, diff(1), patch(1), version control software, and (you said it) various internet clients. That's why some people may still prefer to continue using pure ascii even though then think that unicode operators are cool. (Esp. if they are under the influence of FUD : use PHP ! it's ascii compliant !) Yeah, but ActiveState does Perl, and Microsoft owns ActiveState, so we've got the kings of FUD on our side for a change. Joy. Speaking of FUD, that's simply not true, nor tasteful IMO. AS has done a handful of short-term contacts for MS, and that's the extent of their relationship. FWIW, AS also does as much or more Unix development as Windows development. They also employ some people who have individually advanced Perl more than you'll ever know. Perl6 will do more to address the real technical issues of electronic communication between Americans and French-speakers than anything else. (Primarily because Perl hackers want to talk to each other, but no French-speaker wants to talk to an American ;-) You're Italian, aren't you ? Actually, an American who's been ignored in many places. :-) =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: [RFC] Perl6 Operator List, Take 5
On 30/10/02 15:33 -0500, Mark J. Reed wrote: On 2002-10-30 at 12:23:53, David Wheeler wrote: This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David Larry's mail was *marked* as UTF-8, but by the time I got it it had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore. My mailer understand UTF-8 just fine, and so does vim (which I used to look at my spool file to check for encoding oddities); in my copy of his message, there's just nothing there. All I can think is that some MTA along the way - possibly our very own Exchange server - stripped them out. Wait. So you mean that a French quote isn't a question mark? I take back all those things I've said about the French in the last 24 hours. Cheers, Brian
Re: [RFC] Perl6 Operator List, Take 5
On 30/10/02 13:41 -0800, David Wheeler wrote: On Wednesday, October 30, 2002, at 01:35 PM, Graham Barr wrote: On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: --- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s And I didn't see them in Austin's message, but I see them in yours. Your mailer did the right thing, it looks like. And I see white question marks over black diamonds on a white background. Of course the OS X termcap is imfamous. Cheers, Brian
Re: Persistance of superpositions?
On 29/10/02 16:05 -0500, Buddha Buck wrote: I was wondering... How persistant are superpositions? How pervasive are they? Speaking of persistence, I just realized I'll need to start thinking about YAML serializations of superpositions. My first cut at it would be: --- letters: !super [0, 1, 2] digits: !super - 0 - 1 - 2 ... Cheers, Brian
Re: Wh[ie]ther Infix Superposition ops
On 29/10/02 14:47 -0500, Dan Sugalski wrote: At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote: This is why I am nervous about introducing terms like eigenbunny, etc. Oh, I dunno, I kind of like it. Of course, now my kids want eigenbunny slippers... (Though the trouble with those is they may or may not be keeping your feet warm--you can never tell) Oh! I just remembered the ultimate word for a container. It's cozy, of course! Every eigenbunny needs a supercozy! Cheers, Brian
Re: Persistance of superpositions?
On 29/10/02 13:26 -0800, Brian Ingerson wrote: On 29/10/02 16:05 -0500, Buddha Buck wrote: I was wondering... How persistant are superpositions? How pervasive are they? Speaking of persistence, I just realized I'll need to start thinking about YAML serializations of superpositions. My first cut at it would be: --- letters: !super [0, 1, 2] letters: !super [a, b, c] even! Cheers, Brian
Re: Wh[ie]ther Infix Superposition ops
On 29/10/02 09:58 -0800, Larry Wall wrote: On Tue, 29 Oct 2002, Jonathan Scott Duff wrote: : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote: So I would look favorably on finding a replacement for superposition. How about christmasgift or gift? You don't know what it is until you open it. It could be any, all or none of what you expected. How about envelope? (noun) Or better yet pocket. What has it gots in its pocketses my precious? To keep that QM feel you could call it a hotpocket. Cheers, Brian
Re: Persistance of superpositions?
On 30/10/02 08:36 +1100, Damian Conway wrote: Brian Ingerson wrote: Speaking of persistence, I just realized I'll need to start thinking about YAML serializations of superpositions. My first cut at it would be: --- letters: !super [0, 1, 2] digits: !super - 0 - 1 - 2 ... Not quite. You also need to discriminate the *type* of the superposition: Oh right. I was thinking that Cany and friends were operations, not types. Oops. YAML type-URIs are made up of a type-family with an optional format: !domain.com/type#format and: !int is shorthand for: !yaml.org/int#dec So I'm wondering if any|all|one|none can be formats of !super? And if so, should there be a default format? letters: !any [0, 1, 2] digits: !all - 0 - 1 - 2 names: !one [Brian, Ingy, Mr Inline] sane: !none - Larry - Damian - Brian ... Here are some options: --- # !yaml.org/any letters: !any [a, b, c] # !yaml.org/super#all digits: !super#all - 0 - 1 - 2 # !perl.yaml.org/one (Perl specific types) names: !perl/one [Brian, Ingy, Mr Inline] # (Yes, this dwims :) # !perl.yaml.org/super-none (longer type name, no format) sane: !perl/super-none - Larry - Damian - Brian ... It might be more forward thinking to allow any|all|one|none into the yaml.org type repository. !perl/glob is staying right where it is, thank you ;) Cheers, Brian
Fw: [Yaml-core] Summary of the IRC session
This is an interesting tidbit from a longer posting by Oren Ben-Kiki, the YAML specification author. Thought I'd pass it on. - Forwarded message from Oren Ben-Kiki [EMAIL PROTECTED] - From: Oren Ben-Kiki [EMAIL PROTECTED] Date: Thu, 5 Sep 2002 11:28:12 +0300 To: [EMAIL PROTECTED] Subject: [Yaml-core] Summary of the IRC session X-Mailer: Internet Mail Service (5.5.2653.19) - I'm impressed by the fact that this is almost identical to Perl's type system - and we arrived at it independently. Either Larry Wall was extremely lucky, he had a working crystal ball that told him this type system would be good for Yaml, or this approach is right in some deep way (for scripting languages) and he merely arrived at it as an inevitable result. Of course this made our life easier because we had it in front of us, while he more-or-less invented it from scratch (AFAIK). I don't want to start a language war here or anything, and Parrot is supposed to run Python and Ruby programs as well anyway... I'm just rather surprised by this result. If you would have asked me a year back my bet would have been that we'd end up being more traditional and Perl would be the odd man out. In fact when I first encountered bless I thought it was a horrible hack; now I want to bless Larry for getting it right. Either way, YAML makes a *perfect* fit for Parrot now. Way to go!
Re: New vtable methods
On 18/08/02 16:06 -0400, Dan Sugalski wrote: Okay, here's two new vtable methods freeze(PMC) - Responsible for freezing a PMC to the current freeze data stream. Throws an exception on error thaw(PMC) - A class method that thaws a PMC from the current thaw data stream Both of these should use the freeze/thaw API--I'll get that defined and out shortly. If I want to provide YAML serialization support at the Parrot level, would I be able to simply override these methods? Cheers, Brian
PATCH - Allow assemble.pl to read from STDIN
Hi all,
I'm new to Parrot and Perl6. I hope this is an ok way to submit a patch.
---
- Allow assemble.pl to read from STDIN
- Use the '-' symbol to indicate STDIN
- Made invocation failures/usages behave more correctly
- Minor refactorings in this code section
Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemble.pl,v
retrieving revision 1.82
diff -u -r1.82 assemble.pl
--- assemble.pl 18 Jul 2002 02:13:27 - 1.82
+++ assemble.pl 1 Aug 2002 09:25:00 -
-1047,35 +1047,33
sub process_args {
my ($args,$files) = _;
- for (my $count = 0; $count ARGV; $count++) {
-my $arg = $ARGV[$count];
-
+ while (my $arg = shift ARGV) {
if($arg =~ /^-(c|-checksyntax)$/) { $args-{-c} = 1; }
elsif($arg =~ /^-E$/) { $args-{-E} = 1; }
-elsif($arg =~ /^-(o|-output)$/) { $args-{-o} = $ARGV[++$count]; }
-elsif($arg =~ /^-(h|-help)$/) { Usage(); }
-else {
- push $files,$arg;
-}
- }
- unless($files) {
-print STDERR No files to process.\n;
-Usage();
+elsif($arg =~ /^-(o|-output)$/) { $args-{-o} = shift ARGV; }
+elsif($arg =~ /^-(h|-help)$/) { Usage(); exit 0; }
+elsif($arg =~ /^-./) { Fail(Invalid option '$arg'\n); }
+else { push $files,$arg; }
}
- for($files) {
-next if -e $_;
-print STDERR File '$_' does not exist.\n;
+ Fail(No files to process.\n) unless($files);
+ Fail(File '$_' does not exist.\n) for grep { not (-e or /^-$/) } $files;
+}
+
+sub Fail {
+print STDERR _;
Usage();
- }
+exit 1;
}
sub Usage {
print _EOF_;
+
usage: $0 [options] file [file...]
-E Preprocess input files and terminate processing
-h,--help Print this message
-o,--output Write file
-c,-checksyntax Check syntax only, do not generate bytecode
+
_EOF_
}
Re: ANNOUNCE: Inline 0.23 (Mix Perl and C w/o XS)
Sam Tregar wrote:
On Fri, 18 Aug 2000, Graham Barr wrote:
So it is a security issue then as it needs somewhere to cache these
object files, and anyone must be able to do it.
The place it stores its objects is configurable, so it's only a security
problem if you make it one! I'd say its more a configuration problem
since you need to carefully think about where that place should be and set
the appropriate permissions.
Again, extension modules using Inline install their executable code in
$Config{installsitearch} *only*. Only the sysadmin can install there,
presumably.
For normal users writing scripts, the executables will get installed
under the first one of the following places that is a valid directory
and is writable:
- $ENV{PERL_INLINE_BLIB}
- $ENV{HOME}/.blib_I/
- $ENV{HOME}/blib_I/
- $bin/blib_I/
(where $bin is the script directory returned by FindBin.pm)
- ./blib_I/
- /tmp/blib_I/
If none of those exist, Inline will attempt to mkdir one of following:
- $bin/blib_I/
- ./blib_I/
Failing that, Inline will croak. Of course the user can directly specify
the install location as well, using Inline::Config.
I can see that /tmp/blib_I/ could be a security hole and should probably
be removed. Other than that it seems secure. If I'm missing something,
please let me know. (In detail)
Brian
[EMAIL PROTECTED]
Re: ANNOUNCE: Inline 0.23 (Mix Perl and C w/o XS)
Hi all,
This is Brian Ingerson (the Inline.pm author). My coworker, Colin Meyer,
tipped me off to this thread. I thought I'd throw in a few tidbits to
make sure everyone's on track. But first of all, make sure to RTFM.
(Because I put a lot of effort in explaining it there) The latest copy
is:
http://search.cpan.org/doc/INGY/Inline-0.23/Inline.pod
Inline.pm is meant to be a reasonable alternative to XS. I thought of
the idea at the Conference, after one of Damian's Parse::RecDescent
talks. It is this module (and Digest::MD5) that make it possible.
As some of you have figured out, Inline takes a C source code string (or
file or snippet...) as an argument to a 'use' statement. An MD5 digest
fingerprint is taken of that source code and used to produce a unique
shared object name, such as:
main_C_example001_pl_3a9a7ba88a8fb10714be625de5e701f1.so
Then that module is searched for in one of several possible places
starting with the INSTALLSITEARCH directory of @INC. If it isn't found
then a build area is generated, a build performed, and the result is
DynaLoaded for immediate execution. The next time the script or module
is run, the shared object will already exist, and the code will just
run. If the C source is modified, the fingerprint will change, and the
object gets recompiled. Viola.
(NOTE: For speedy startup, the compile time stuff is AutoLoaded only
when a build needs doing.)
If the Inlined code is part of a distributed extension module, there is
a trick to make it compile into the './blib/' library during the "make
test" of the installation. Then, when "make install" is performed, the
shared object gets moved into the INSTALLSITEARCH part of @INC. See the
doc.
It is true that Inline only supports a minimal number of default
typemaps (void, int, long, double, char*, SV*). I don't intend to change
it without good reason. This is because these are the native types of
Perl scalars. Mapping anything else is a hack, IMO. These types allow
you to call C functions like you would call Perl subs. If you want to
pass other things like refs, then you need to do the mapping yourself.
This makes sense to me. That said, I could easily be convinced to start
a Inline::C::Typemaps helper class.
Here are some of Inline's strong points:
- Easy transition between Perl-space and C-space. (For Perl programmers)
- Elimination of the awareness of compiling. (as long as the code
compiles :-)
- Easier to maintain. (Less files)
- Reduction of the learning curve of XS. (For us mortals)
- Easy way to write high-performance extension modules.
- Works everywhere that Perl itself is compiled. (So far...)
- Intends to support other programming languages besides C.
Here are some faults:
- Doesn't scan header files to autogenerate a Perl API like XS does (But
how many times in ten does that work first-time anyway?)
- Very slow on MSWin32 using Visual C++.
- your complaint here
No more insecure than having your own LIB directory, although the prospect of
every user having their own copy of every C extension doesn't sound too
great. Perhaps we can modify it so that it checks an @INC as normal.
Extension modules using Inline, always put their executable code in @INC
(INSTALLSITEARCH). And the build dir is always './blib_I'.
For developing with Inline, the most common place for Inline to create a
temporary build/install area is in the directory where the script
resides (using FindBin.pm) under the subdir 'blib_I'. Other choices
include '~/.blib_I', '$ENV{PERL_INLINE_BLIB}/blib_I', '/tmp/blib_I',
etc. Inline trys to do the most sensible thing. You can always specify
an exact location with Inline::Config.
It's just an idea for us to play with - I'm by no means suggesting we want to
use it as-is.
I'm flattered that you're considering it - I'm by no means intending to
leave it as-is. :-)
In parting, I'll be glad to answer any further queries, and would be
honored to work with you guys to turn this into something great for
Perl.
Brian Ingerson
[EMAIL PROTECTED]
