pop, push, reverse, sort, and splice on a multidimensional array
my int @a is shape(Int ; Int) = (1..10 ; 2..100 :by(2) ; 4); $x = pop @a push @a, $x; @b = sort @a; # etc I see two views to take with these cases. 1) flatten the array to one dimension, and act accordingly. or 2) assume my int @a is shape(Int ; Int); my @a is Array of Array of int; Mean exactly the same thing, as do @a[3;4] @a[3][4] And then operate the Perl 5 way, where C would return an array ref. #2 seems like the way to go, but I'm open to other suggestions. I'm especially interested in hearing people's view on how C should work with multi-dim arrays. -- Rod Adams
perl6-language@perl.org
I'm trying to define zip(), but can't come up with a signature for a
function that returns a lazy list of lvalues, but the list itself is not
lazy?
As a second matter, can you declare a type for the elements of a slurpy
array?
So far I have:
multi sub zip (Array [EMAIL PROTECTED]) returns List {
gather {
while any(@lists) {
for @lists -> @list {
take shift @list;
}
}
}
}
But I can't tackle the lvalue problem.
btw, I'm defining the semantics of some of several functions by simply
supplying a reference implementation.
Re: Auto generated methods (was Re:The S29 Functions Project)
Rod Adams <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>the method call in PIR can be written as:
>>
>> d = x."cos"() # normal method call
>> d = Float."cos"(x) # class method, argument shifted down
>> d = P6Num."cos"(x) # same
>> d = cos x # PIR opcode syntax [1]
>> cos d, x # PASM opcode syntax [1]
>>
>>There'll be a table of such builtins with name, namespace, signature, so
>>that the current opcodes can be transparently replaced by methods.
>>
>>
> This looks like it's taking
> multi method Num::cos (Num|Str +$base) returns Num
> and generating
> multi sub cos (Num $x, Num|Str +$base) returns Num
No. The above "lowlevel" C isn't aware of C nor of C<$_> and
nothing is autogenerated in Parrot. The C is something like:
class __parrot_core::Float {
multi sub cos(Float x) returns Float ...
}
This is presumably inherited by C (the Parrot PMC) and
bound to:
multi sub *cos(Num $x) returns Num
at the Perl6 level.
leo
Re: Auto generated methods (was Re:The S29 Functions Project)
Leopold Toetsch wrote:
No. The above "lowlevel" C isn't aware of C nor of C<$_> and
nothing is autogenerated in Parrot. The C is something like:
class __parrot_core::Float {
multi sub cos(Float x) returns Float ...
}
This is presumably inherited by C (the Parrot PMC) and
bound to:
multi sub *cos(Num $x) returns Num
at the Perl6 level.
That's all fine for the Parrot side of things, AFAICT.
But it doesn't answer my question about how Perl is going to
autogenerate methods, as alluded to in A/S12, and Larry's previous post.
For now, I'm assuming that I can define just the base multi sub, without
all the associated multi methods
-- Rod Adams
s/true/better name/
In #perl6, Freenode, after again having to explain that "true" is the opposite of "not" and NOT the value for "true", and that "false" doesn't exist, and that the real true value is "bool::true" and shouldn't be used much, and that no, it isn't "true", and no, "true" doesn't always return "bool::true", but despite its name can also return "bool::false", and then explaining everything again, we kind of agreed that "true" is a misleading name. In my opinion, it's the biggest violation of the whole least surprise thing in Perl 6's current design. Autrijus suggested "indeed" or "id", of which I like "indeed" better, because I'd like to continue using "id" with databases. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: s/true/better name/
On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: > Autrijus suggested "indeed" or "id", of which I like "indeed" better, > because I'd like to continue using "id" with databases. whether? -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me beats up some cheese: neeyah! pgpaPB3bemb5e.pgp Description: PGP signature
Re: [Pugs] Closing a file handle surprised the heck out of me
[EMAIL PROTECTED] wrote: On the other hand, we can alternatively specify that closing a file handle must force all thunks associated to it, i.e. in this case fill @lines with real data. Pugs can do that just fine, but I have no idea how parrot is to achieve that... But it gets worse. my $lines = [ =$fh ]; seek($fh, 0); my $lines2 = [ =$fh ]; close $fh; $lines2 must somehow remember that seek has happened. Miro
Re: s/true/better name/
On Tue, Mar 15, 2005 at 10:51:57AM +0100, Juerd wrote: : Autrijus suggested "indeed" or "id", of which I like "indeed" better, : because I'd like to continue using "id" with databases. "id" is too heavily overloaded with identifiers and identities and such. But "indeed" doesn't work right in context, "while indeed..." I'd go with either "istrue" or "so". "ok" is another possibility, though that seems to connote definedness more than truth. Larry
Re: s/true/better name/
On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: > I'd go with either "istrue" or "so". "ok" is another possibility, > though that seems to connote definedness more than truth. Hmm, "so" is so good. So can we make it so? :) Thanks, /Autrijus/ pgpVnDqeuQFYm.pgp Description: PGP signature
Re: s/true/better name/
Autrijus Tang skribis 2005-03-16 0:25 (+0800): > On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: > > I'd go with either "istrue" or "so". "ok" is another possibility, > > though that seems to connote definedness more than truth. > Hmm, "so" is so good. So can we make it so? :) So is great for Perl poetry too. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: s/true/better name/
On Tue, Mar 15, 2005 at 12:13:52PM +0200, Yuval Kogman wrote: : On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: : : > Autrijus suggested "indeed" or "id", of which I like "indeed" better, : > because I'd like to continue using "id" with databases. : : whether? That's an interesting possibility, though I think about half the people would misspell it. Maybe that's a feature. It works well for: $yesno = whether any(@foo) == @any(@bar); I don't mind it being long. I should point out I'm rethinking the idea of whether or not whether and not should be list operators. "not @foo" would have unexpected consequences if it forces list context, so I think we better let people hyper those manually if needed. I think we can leave "not" at the precedence of list operators without actually making it one, but maybe we should make a separate precedence level for it to keep list op precedence "pure". Larry
[Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
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<>)
--- Begin Message ---
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 C for the ease of including keywords
in C documentation. It's also B to I 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!
Markup can consist of C[[]]-delimited text such as C[[Kwid]] or
a prefixed C[[]]-delimited text such as C[C[Kwid]]. Possible
prefixes are:
=begin list
*= L
A structured link ala POD C[L<>]
*= B, I
Bold or italics
*= C
Code
=end list
Anywhere a C[[]] can be used, a C[{}] can also be used. This is
useful when you need to enclose unbalanced C[{], C[}], C{[},
or C{]} characters.
All formatting is introduced with C[=for] just as in POD, so:
=for html
works as you might expect. C[=begin] is similar, but introduces
a block, ended by C[=end]
=for html,xhtml,xml
=begin !html,xhtml,xml
You can't see the image, but it would be pretty!
=end !html,xhtml,xml
Notice the use of C[!format[,format...]] to indicate all formats
not listed.
"comment" is the null format, so you can always introduce a
C[=for comment] or C[=begin comment], but lines which start with
C[#] are always treated as comments anyway.
Lists are introduced with C[=begin list], which is a special
format. A list can be numbered, bulletted or defintion-style.
Each type is introduced differently, e.g.:
*1 numbered
* bullets
*= term
definition
Only a C[1] can follow the C[*]. So, your numbered list would
look like:
*1 First
*1 Second
*1 Third
This tells Kwid to number your items, but does not allow strange
things like:
*2 First prime
*3 Second prime
*5 Third prime
For that, you need C[*=]
Thoughts?
> Well, not everyone likes HTML (although I can't imagine why).
* It's hard for humans to read
* It imposes too much display-think on what should be content-think
* It is not a proper super-set of the other documentation formats.
XHTML addresses some of this, but still provides far
Re: [Pugs] Closing a file handle surprised the heck out of me
On Tue, Mar 15, 2005 at 12:46:49AM +0800, Autrijus Tang wrote: : On Mon, Mar 14, 2005 at 05:28:29PM +0100, Miroslav Silovic wrote: : > But it gets worse. : > : > my $lines = [ =$fh ]; : > seek($fh, 0); : > my $lines2 = [ =$fh ]; : > close $fh; : > : > $lines2 must somehow remember that seek has happened. : : That is fine because the three thunks are registered to the fh : in evaluation order. What will be more fun is if they are all : part of some other lazy lists, which may be accessed in some : unpredictable order. You could treat seek as a synchronization point like close. : : That is why lazy languages typically use some sort of typechecking to : avoid mixing computations with actions... :) Which is also what we're doing, except that we're hiding that fact from the user whenever we can rather than rubbing their nose in it. :-) Larry
Re: s/true/better name/
Larry Wall skribis 2005-03-15 8:41 (-0800): > On Tue, Mar 15, 2005 at 12:13:52PM +0200, Yuval Kogman wrote: > : On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: > : > Autrijus suggested "indeed" or "id", of which I like "indeed" better, > : > because I'd like to continue using "id" with databases. > : whether? > That's an interesting possibility, though I think about half the people > would misspell it. Maybe that's a feature. It works well for: > $yesno = whether any(@foo) == @any(@bar); Seeing it in an example, I love this suggestion. And re its spelling, that's a very good feature, because it'll slowly teach me how to spell this word. And when I know how to spell it, I can use it on IRC without dict(1)ing to see if I remembered correctly. This will eventually save me hours! :) > I should point out I'm rethinking the idea of whether or not whether and > not should be list operators. Nice use of both languages. I've wondered today how their being list ops would work in practice. Does it work like any(), all(), or is only one of the elements evaluated? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [Pugs] Closing a file handle surprised the heck out of me
On Tue, Mar 15, 2005 at 08:52:07AM -0800, Larry Wall wrote: > : That is fine because the three thunks are registered to the fh > : in evaluation order. What will be more fun is if they are all > : part of some other lazy lists, which may be accessed in some > : unpredictable order. > > You could treat seek as a synchronization point like close. True. So maybe the trick is define such a set of synchronization points for resources that has lazy/eager conflicts, instead of forcing eager context on RHS of all infix:<=>, especially because most assignments probably only involve simple COW copying, so it'd be sad to lose the laziness benefit. > : That is why lazy languages typically use some sort of typechecking to > : avoid mixing computations with actions... :) > > Which is also what we're doing, except that we're hiding that fact > from the user whenever we can rather than rubbing their nose in it. :-) As long as surprises can be minimized (or at least explained), that's entirely fine, I think. :) Thanks, /Autrijus/ pgpnyvrdLFRBW.pgp Description: PGP signature
Markup language-like features in Perl6?
I am aware of at least one program that adopts XML for (customizable/"skinnable") GUI descriptions. This has a sense for markup languages are typically "descriptive", i.e. they say how something IS as opposed to, say, procedural languages that let one implement something that DOES something[1]. Of course as far as GUIs are concerned, they provide an interface for "something that does something" as well, so one needs both charachteristics and in fact an OO approach is typically applied, which provides an IMHO excellent approximation to the concept of "describing how something IS also including details about the parts of it that DO something". However I have the impression that there's still "too much" to it. Granted, GUIs are intrinsically some order of complexity above textual IO, but I think that letting the language have intrinsic markup language(-like) features may make things much easier from the huffmanization POV in these regards. Now what I'm thinking about is a means of specifiying, say, "portions" in the source that ARE (something). By default they won't be executed at all, but they may provide useful hooks for a suitable module to assign a meaning to them, and of course they should also provide the link with "code that does something" (e.g. callbacks et similia). Of course I began talking about GUIs, but I wouldn't like to restrict everything to this particular aspect. Perl(6) is supposed to be a mutiparadigmatic language with means to be specialized and "strenghtened" into any of the supported paradigms. So I cannot see why a priori the markup language pardigm shouldn't fit in this picture. HOW to do it (efficiently/elegantly, etc.) is a whole another story... [1] Although this varies from language to language. If you come to think of TeX and its macro language you can see how approximative this claim is. Michele -- A question out of curiousity: who is this Green of Green's functions? Is he the same person of Green's theorem? :) Yes. He was also an early environmentalist; hence the current phrases "green" this and "green" that... - David C. Ullrich in sci.math, thread "Who is Green?"
Re: s/true/better name/
On Tue, Mar 15, 2005 at 05:57:57PM +0100, Juerd wrote: > And re its spelling, that's a very good feature, because it'll slowly > teach me how to spell this word. And when I know how to spell it, I can > use it on IRC without dict(1)ing to see if I remembered correctly. This > will eventually save me hours! :) One problem you may find with dict is that one common misspelling, "wether", is also a valid English word, which any decent word list should contain. (It's a castrated ram) Nicholas Clark
Re: s/true/better name/
Nicholas Clark skribis 2005-03-15 17:53 (+): > On Tue, Mar 15, 2005 at 05:57:57PM +0100, Juerd wrote: > > And re its spelling, that's a very good feature, because it'll slowly > > teach me how to spell this word. And when I know how to spell it, I can > > use it on IRC without dict(1)ing to see if I remembered correctly. This > > will eventually save me hours! :) > One problem you may find with dict is that one common misspelling, "wether", > is also a valid English word, which any decent word list should contain. > (It's a castrated ram) Dict uses dictionaries, not just word lists. It outputs the definition(s), so this misspelling is easily detected. I know both words exists. I just can't manage to remember which one is which, and maybe Perl 6 can help me :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Exists and Delete
Rod Adams wrote: How am I supposed to define a signature that says "A scalar that refers to a hash or array element, but do not evaluate or autovivify the element"? I'll make a guess: Ref of Int of Array. This assumes Int has a polymorphic subtype that allows pointing into arrays. But unfortunately you need two values to describe the reference: the index and the array. So it should be more like a pair: Ref of Pair[Int,Array]. my @array; my Ref of Int of Array $iref = 17 of $array; # 17 => @array perhaps $iref = "blahh"; say "@array[17]"; # prints blahh Or are these two are now strictly methods without functional forms? Sorry I don't know what you are asking for. What is then a method with functional form? Do you mean that the entries in an array are off-limits to the outside and can be accessed only by the subscripting methods? Regards, -- TSa (Thomas Sandlaß)
Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)
I agree. I think the biggest mistake Perl 6's documentation system could make is to make it Javadoc-style automatic. This is one of those weird, backwards, cultural decisions, where we actually want to make the programmer's life a little harder. When I (seldomly) progam in Java, I find it very hard to use any libraries, because all the libraries have good method-level documentation, but none of them has good interface (conceptual, not C)-level documentation. I basically have to understand how the library author organized his code in order to use his library. On the other hand, Perl has this wonderful module idiom of SYNOPSIS and DESCRIPTION. SYNOPSIS generally shows you how a very small program would use the library (the thing Java libraries are missing), and DESCRIPTION goes in detail about the things you need to know. The things you don't need to know you can get by reading the code. Hi Luke, I agree that SYNOPSIS and DESCRIPTION sections are really important and I would not want them to be lost - maybe these should be a requirement for uploading to CPAN6? I seldom program in Java too :-) But one of the few things I liked about Javadoc is the ability to traverse the interfaces of classes quickly - and this is tied to hypertext. Forget I used the J word --- what I'd like to see in the documentation system is the ability to quickly browse and traverse the linkages between modules and 'things'. The documentation requirements for Perl6 are a step up from Perl5. Perl6 programs will have 'backlinks' and relationships with a number of things: rules, grammars, classes, methods, roles, subs and traits etc. These in turn may have their own hierarchies. The structural aspects of the contract of a Perl6 class needs to be prominently and uniformly communicated. I think we need a hypertext browsing capability so that we can jump around the distilled contract of a class: both our own modules and each other's. In this way you could traverse the interlinkages between ALL things on CPAN6: "What grammar inherits from that? What modules use this grammar? What classes do this role? What programs test this class? What grammars inherit from this grammar?" I'm not advocating terse documentation - but I would like to add to the wishlist: * universal consistent hypertext code browsing both locally and on ~~ /CPAN6/. Nige
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman skribis 2005-03-15 11:46 (-0500):
> = heading level 1
> == heading level 2
> =begin list
I see this going wrong with =heading level 1 already. I like the numbers
in =headN too, by the way, as it makes inconsistencies easier to spot.
> 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:
L[] C[] I[] B[] are all hard to read. With <>, the weight is evenly
distributed, while with [], the weight is on the outside, next to that
capital letter that is just as large.
Visual comparison:
L[] C[] I[] B[] # I is worst
L<> C<> I<> B<>
So if [] is going to be used, may I suggest using lc letters with it
then?
l[] c[] i[] b[]
L[] C[] I[] B[]
L<> C<> I<> B<>
Still not great, but better IMO. Why are <> bad, by the way? Can't we
just change the meaning to be qq-like, that is: with nested content?
That means only for non-unicode >><< you need extra angle brackets.
Or maybe we introduce [] as an alternative for <>.
Also, how is [EMAIL PROTECTED] parsed? # I find this very hard to parse,
# visually
Likewise, %?INC{something}?
Two possible sources of inspiration for the whole documentation thing:
* Text::MetaMarkup
* Paragraphs CAN begin with a block level html tag, "h1: heading"
* Inline HTML tags can be used as "{b:bold}"
* Paragraph starting with * is a list
* Paragraph starting with # is comment
* Verbatim paragraphs simply start with "pre:"
* No support for tables yet
* PodTables
* See http://pugs.kwiki.org/?PodTables
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: s/true/better name/
Larry Wall wrote: On Tue, Mar 15, 2005 at 12:13:52PM +0200, Yuval Kogman wrote: : On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: : : > Autrijus suggested "indeed" or "id", of which I like "indeed" better, : > because I'd like to continue using "id" with databases. : : whether? That's an interesting possibility, though I think about half the people would misspell it. Maybe that's a feature. It works well for: $yesno = whether any(@foo) == @any(@bar); I don't mind it being long. I should point out I'm rethinking the idea of whether or not whether and not should be list operators. "not @foo" would have unexpected consequences if it forces list context, so I think we better let people hyper those manually if needed. I think we can leave "not" at the precedence of list operators without actually making it one, but maybe we should make a separate precedence level for it to keep list op precedence "pure". I don't see the point of making them list ops. Leaving them at that precedence level makes sense, but leave them unary. For a list version, you can write C or C to do the same thing. -- Rod Adams
Re: Exists and Delete
Thomas Sandlaß wrote:
Rod Adams wrote:
How am I supposed to define a signature that says "A scalar that
refers to a hash or array element, but do not evaluate or autovivify
the element"?
I'll make a guess: Ref of Int of Array.
This assumes Int has a polymorphic subtype that allows
pointing into arrays. But unfortunately you need two values
to describe the reference: the index and the array. So it should
be more like a pair: Ref of Pair[Int,Array].
my @array;
my Ref of Int of Array $iref = 17 of $array; # 17 => @array perhaps
$iref = "blahh";
say "@array[17]"; # prints blahh
Or are these two are now strictly methods without functional forms?
Sorry I don't know what you are asking for. What is then a method with
functional form? Do you mean that the entries in an array are off-limits
to the outside and can be accessed only by the subscripting methods?
What I'm asking is if we are going to continue allowing:
delete %x;
if exists %x { ... }
or make it where you instead have to say
%x.delete('foo');
if %x.exists('foo') { ... }
-- Rod Adams
Regards,
Re: Exists and Delete
Rod Adams skribis 2005-03-15 12:44 (-0600):
> %x.delete('foo');
> if %x.exists('foo') { ... }
Would renaming exists to has or hasa be a good idea, if it does indeed
exist only in method form?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
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 C for the ease of including keywords > in C documentation. It's also B to I 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
Re: Exists and Delete
On Tue, Mar 15, 2005 at 12:44:06PM -0600, Rod Adams wrote:
: What I'm asking is if we are going to continue allowing:
:
: delete %x;
: if exists %x { ... }
:
: or make it where you instead have to say
:
: %x.delete('foo');
: if %x.exists('foo') { ... }
They can always just be macros that translate the unary form to the
method. If you define them as term: and term: they
won't show up unexpectedly when the parser is looking for method names.
Larry
Re: Exists and Delete
On Tue, Mar 15, 2005 at 07:47:58PM +0100, Juerd wrote:
: Rod Adams skribis 2005-03-15 12:44 (-0600):
: > %x.delete('foo');
: > if %x.exists('foo') { ... }
:
: Would renaming exists to has or hasa be a good idea, if it does indeed
: exist only in method form?
I'd think that would be asking if the array has an *attribute* of
that name. Perl 6 objects aren't hashes...
Larry
Re: Exists and Delete
Larry Wall skribis 2005-03-15 11:20 (-0800):
> On Tue, Mar 15, 2005 at 07:47:58PM +0100, Juerd wrote:
> : Rod Adams skribis 2005-03-15 12:44 (-0600):
> : > %x.delete('foo');
> : > if %x.exists('foo') { ... }
> : Would renaming exists to has or hasa be a good idea, if it does indeed
> : exist only in method form?
> I'd think that would be asking if the array has an *attribute* of
> that name. Perl 6 objects aren't hashes...
That makes sense. I think %x ~~ 'foo' will be used more than
%x.exists('foo') anyway.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: The S29 Functions Project
On Mon, Mar 14, 2005 at 08:59:32AM -0800, Larry Wall wrote: > On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote: > : I ran into this problem while creating a mini-list of S29 functions > : (which Rod's work supercedes, I suspect, and I'm very glad he's taking > : this on). What are some guidelines we could use in deciding > : which functions are automatically in ::* ? Or is this just a case > : where we need to use past experience and best guesses as our guide? > * Another confounding factor is that memes tend to come in bundles, > and you'd kind of like to keep the bundles together. So my earlier > question really amounted to whether POSIX was really a valid > bundle of memes. (Probably not.) On the other hand, the trig > functions might well be a valid bundle, and we might want to > keep them all together either in * or Trig. To me it seems that a there are some groups of core builtins in Perl 5 that group conceptually quite well, and it's sensible to remove en mass, which are the builtins that aren't really useful in Perl 5 without loading an extension module. So all the socket related builtins aren't much use without the constants exported by Socket; and the System V IPC builtins aren't much use without the IPC::SysV, so they could quite easily be exported by that instead. But then it gets less obvious what other groups from the top of perlfunc.pod might manage a discrete exit from ::* without anyone noticing. So, no, I don't have an answer :-) Nicholas Clark
Re: The S29 Functions Project
At 07:59 PM 3/15/2005 +, you wrote: On Mon, Mar 14, 2005 at 08:59:32AM -0800, Larry Wall wrote: > On Mon, Mar 14, 2005 at 08:10:15AM -0600, Patrick R. Michaud wrote: > : I ran into this problem while creating a mini-list of S29 functions > : (which Rod's work supercedes, I suspect, and I'm very glad he's taking > : this on). What are some guidelines we could use in deciding > : which functions are automatically in ::* ? Or is this just a case > : where we need to use past experience and best guesses as our guide? > * Another confounding factor is that memes tend to come in bundles, > and you'd kind of like to keep the bundles together. So my earlier > question really amounted to whether POSIX was really a valid > bundle of memes. (Probably not.) On the other hand, the trig > functions might well be a valid bundle, and we might want to > keep them all together either in * or Trig. To me it seems that a there are some groups of core builtins in Perl 5 that group conceptually quite well, and it's sensible to remove en mass, which are the builtins that aren't really useful in Perl 5 without loading an extension module. So all the socket related builtins aren't much use without the constants exported by Socket; and the System V IPC builtins aren't much use without the IPC::SysV, so they could quite easily be exported by that instead. But then it gets less obvious what other groups from the top of perlfunc.pod might manage a discrete exit from ::* without anyone noticing. So, no, I don't have an answer :-) Nicholas Clark I've put the following note at the top of S29.pod (in an update I haven't posted yet). In Perl 6, all builtin functions belong to a named package. Not all functions are guaranteed to be imported into the global package C<::*>. In addition, the list of functions imported into C<::*> will be subject to change with each release of Perl. Authors wishing to "Future Proof" their code should either specifically import the functions they will be using, or always refer to the functions by their full name. -- Rod Adams
reset() and S29 -- obsoleted?
One function I noticed on the S29 list was reset(). With lexically scoped variables, reset is almost useless. "Perl in a Nutshell" calls it "vaguely deprecated". Can we remove the vagueness and deprcate it completely? Steve Peters [EMAIL PROTECTED]
Re: reset() and S29 -- obsoleted?
On Tue, Mar 15, 2005 at 02:39:06PM -0600, Steve Peters wrote: : One function I noticed on the S29 list was reset(). With lexically scoped : variables, reset is almost useless. "Perl in a Nutshell" calls it "vaguely : deprecated". Can we remove the vagueness and deprcate it completely? Yes, please. Larry
Re: reset() and S29 -- obsoleted?
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> On Tue, Mar 15, 2005 at 02:39:06PM -0600, Steve Peters wrote: LW> : One function I noticed on the S29 list was reset(). With lexically scoped LW> : variables, reset is almost useless. "Perl in a Nutshell" calls it "vaguely LW> : deprecated". Can we remove the vagueness and deprcate it completely? LW> Yes, please. i have seen p5 newbies ask about using it. oy!! 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: reset() and S29 -- obsoleted?
Larry Wall wrote: On Tue, Mar 15, 2005 at 02:39:06PM -0600, Steve Peters wrote: : One function I noticed on the S29 list was reset(). With lexically scoped : variables, reset is almost useless. "Perl in a Nutshell" calls it "vaguely : deprecated". Can we remove the vagueness and deprcate it completely? I hadn't thought about it yet. I almost definitely would have come to that conclusion. Yes, please. Done. -- Rod Adams
Re: The S29 Functions Project
On Tue, Mar 15, 2005 at 02:25:01PM -0600, Rod Adams wrote: : In Perl 6, all builtin functions belong to a named package. Not all : functions are guaranteed to be imported into the global package : C<::*>. In addition, the list of functions imported into C<::*> will be : subject to change with each release of Perl. Authors wishing to : "Future Proof" their code should either specifically import the : functions they will be using, or always refer to the functions by their : full name. Hmm, what I said was supposed to be policy for just the development release of 6.0.0. However, it's not that far off from the general case if you add something along the lines of: After 6.0.0 comes out, global aliases will not be removed lightly, and will never be removed at all without having gone through a deprecation cycle of at least a year. In any event, you can specify that you want the interface for a particular version of Perl, and that can be emulated by later versions of Perl to the extent that security updates allow. Interestingly, that last sentence means that different modules can have different views of * space. But really, that just falls out of ordinary module versioning, if you can warp your brain around to thinking of * as an ordinary versioned module. The long name of * just happens to include the Perl version number, and could presumably even include different "authors" if we ever fork Perl. Larry
Re: reset() and S29 -- obsoleted?
On Tue, Mar 15, 2005 at 05:44:07PM -0500, Uri Guttman wrote: : > "LW" == Larry Wall <[EMAIL PROTECTED]> writes: : : LW> On Tue, Mar 15, 2005 at 02:39:06PM -0600, Steve Peters wrote: : : LW> : One function I noticed on the S29 list was reset(). With lexically scoped : LW> : variables, reset is almost useless. "Perl in a Nutshell" calls it "vaguely : LW> : deprecated". Can we remove the vagueness and deprcate it completely? : : LW> Yes, please. : : i have seen p5 newbies ask about using it. oy!! There will probably be an emulation of it written in support of the translator, but we don't have to make it terribly easy to get at, and we can even require them to say: use DEPRECATED_PERL_5_FEATURES <__p5_resetmatch__ __p5_resetvars__>; up at the top. Of course it's no pain for the translator to insert something like that when it needs to. Larry
Re: The S29 Functions Project
Larry Wall wrote: On Tue, Mar 15, 2005 at 02:25:01PM -0600, Rod Adams wrote: : In Perl 6, all builtin functions belong to a named package. Not all : functions are guaranteed to be imported into the global package : C<::*>. In addition, the list of functions imported into C<::*> will be : subject to change with each release of Perl. Authors wishing to : "Future Proof" their code should either specifically import the : functions they will be using, or always refer to the functions by their : full name. Hmm, what I said was supposed to be policy for just the development release of 6.0.0. However, it's not that far off from the general case if you add something along the lines of: After 6.0.0 comes out, global aliases will not be removed lightly, and will never be removed at all without having gone through a deprecation cycle of at least a year. In any event, you can specify that you want the interface for a particular version of Perl, and that can be emulated by later versions of Perl to the extent that security updates allow. Interestingly, that last sentence means that different modules can have different views of * space. But really, that just falls out of ordinary module versioning, if you can warp your brain around to thinking of * as an ordinary versioned module. The long name of * just happens to include the Perl version number, and could presumably even include different "authors" if we ever fork Perl. "Add something along the lines of" was interpreted as "clip and paste into S29.pod". I wasn't meaning to imply that bindings would be changed willy-nilly in production, but I can see how that could be inferred from what I wrote. My main intention was that it *could* change over time. These whole paragraphs can be reworded later, possibly at the same time we sit down and figure out the policy of what gets imported into *:: when. -- Rod Adams
Re: lists in string context
On Sat, Mar 12, 2005 at 09:36:24PM +0100, Juerd wrote:
> Larry Wall skribis 2005-03-12 12:26 (-0800):
> > And arguably, the current structure of join is that the delimiter is
> > the invocant, so cat should be defined as
> > ''.join(@foo)
>
> This is what Python does. It does not make any sense to me, and I can't
> wrap my mind around it at all. Ruby-ish @foo.join('') seems more
> natural.
>
> Just like with how I prefer $fh.print($text) to $text.print($fh), I
> cannot explain WHY this is how my mind works.
I'm with you. In my opinion, it is weird to call a method against a
constant value; values aren't supposed to do things, they are supposed
to have things done to /them/. For similar reasons, it is only
slightly less weird to call a method on a variable when that variable
is simply a container for a constant value.
A variable that contains an object or "interface element" (e.g. a
filehandle), I can understand calling methods against that.
Ob flame retardant: I'm not saying that my opinion is necessarily
right, or the other way isn't valid. Just offering a thought on why
Juerd might have this feeling.
--Dks
Re: s/true/better name/
On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: > On Tue, Mar 15, 2005 at 10:51:57AM +0100, Juerd wrote: > : Autrijus suggested "indeed" or "id", of which I like "indeed" better, > : because I'd like to continue using "id" with databases. > > "id" is too heavily overloaded with identifiers and identities and such. > But "indeed" doesn't work right in context, "while indeed..." > > I'd go with either "istrue" or "so". "ok" is another possibility, > though that seems to connote definedness more than truth. It also breaks a huge percentage of the testing code that we would like to be able to automagically port from P5 to P6. --Dks -- [EMAIL PROTECTED]
