Re: RFC 303 (v1) Keep C, but make it work.

[Piers Cawley]

Alan Gutierrez <[EMAIL PROTECTED]> writes:

> On 27 Sep 2000, Piers Cawley wrote:
> 
> > Simon Cozens <[EMAIL PROTECTED]> writes:
> > 
> > > On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote:
> > > > Don't change "use less" to "use optimize".  We don't
> > > > need to ruin the cuteness.
> > > 
> > > "use less 'rolled_loops';" sounds really weird.
> > 
> > We obviously need to introduce a synonymous
> > C for when we want to be grammatically
> > correct. Or am I just being silly now?
> 
> C< use less 'recursion' > sounds just find to me.
> 
> The negation of C< use less 'rolled_loops' >, C< use more
> 'unrolled_loops' >, does not sound very weird at all. Weren't we
> planning on haveing a use more as an opposite of use less? If so,
> let cuteness prevail!

And this opens the door to stuff like C< no more 'rolled_loops' >. I'm
not entirely sure that that would be a good thing.

-- 
Piers

Re: RFC 344 (v2) Elements of @_ should be read-only by default

[Nicholas Clark]

On Mon, Oct 02, 2000 at 10:40:28AM +0100, Piers Cawley wrote:
> Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:

> > Unprototyped subs should not be allowed to modify their callers' data
> > simply by assigning to elements of the arg array.
> > 
> > =head1 COMMENTS ON FREEZE
> > 
> > This RFC generated no discussion in 3 days

I missed reading it. My fault.

> I'd just like to put in an 'ick' vote on this one. I might come up
> with something a little longer and more reasoned later, but I'm
> supposed to be writing shopping basket code.

Possibly part of the ick might be that with the current implementation plus
this, adding a prototype to foo to give sub foo($$); to allow
pass-by-reference stops you calling foo @bar with a 2 element array.
You'd now have to go &foo(@bar); which doesn't feel nice.

Subroutine attributes instead? Default to current behaviour,
use strict; and you have to specify (in some way, prototype, attribute...)
whether each function has read-write or read-only @_?

Nicholas Clark

Re: Expunge "use English" from Perl?

[Bryan C . Warnock]

On Wed, 27 Sep 2000, Nathan Wiger wrote:
> Yeah, I've never liked the _ syntax, I've always thought it was weird
> (to say the least). I think grouping file tests would be much cleaner. 

As long as you are okay with having to restat for 'or' clauses.
(There are work arounds, and supposedly 'this or that' is less common
for file tests.)

 -- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: Expunge "use English" from Perl?

[Jarkko Hietaniemi]

On Mon, Oct 02, 2000 at 07:32:42AM -0400, Bryan C. Warnock wrote:
> On Wed, 27 Sep 2000, Nathan Wiger wrote:
> > Yeah, I've never liked the _ syntax, I've always thought it was weird
> > (to say the least). I think grouping file tests would be much cleaner. 
> 
> As long as you are okay with having to restat for 'or' clauses.
> (There are work arounds, and supposedly 'this or that' is less common
> for file tests.)

A rather sweeping statement.  ANDing makes more sense for the
permissions checks, but ORing makes more sense for the type checks.
For example, I can imagine -f $foo || -l $foo being a rather common idiom.

>  -- 
> Bryan C. Warnock
> ([EMAIL PROTECTED])

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Jonathan Scott Duff]

On Sun, Oct 01, 2000 at 06:34:12AM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
> 
> Perl should use XML for documentation instead of POD

Wow.  

I'll just add my voice to the others.  POD is more readable than XML.
As Nathan Wiger said, just read the HTML vs the POD for the RFCs. 

But, why not suggest SDF instead of XML?  SDF addresses most of POD's
deficiencies whill still retaining readability.  (I don't have a URL
for SDF handy, but I'm sure a quick search on google.com would turn it
up)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Bart Lateur]

On Mon, 2 Oct 2000 08:29:09 -0500, Jonathan Scott Duff wrote:

>But, why not suggest SDF instead of XML?  SDF addresses most of POD's
>deficiencies whill still retaining readability.  (I don't have a URL
>for SDF handy, but I'm sure a quick search on google.com would turn it
>up)

http://www.mincom.com/mtr/sdf/


It is based upon POD, which might help in lowering the entry threshold.

-- 
Bart.

RE: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Garrett Goebel]

From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]]
> 
> On Sun, Oct 01, 2000 at 06:34:12AM -, Perl6 RFC Librarian wrote:
> > =head1 TITLE
> > 
> > Perl should use XML for documentation instead of POD
> 
> I'll just add my voice to the others.  POD is more readable than XML.
> As Nathan Wiger said, just read the HTML vs the POD for the RFCs. 

XML is not HTML. Someone could make DTD which defines XML elements using the
pod =commands. Then again, if you're using XML, why not have it keep track
of nested =head and get rid of =over and =back?

Some arguments for XML:

- Done right, it could be easier to write and maintain
- Why make people learn pod, when everyone's learning XML?
- Pod can be translated into XML and vice versa
- Standard elements could be defined and utilized with the
  same or greater ease than pod for build and configuration.


  Module::Name
  0.01
  short description
  
=head1 long description

  =head2 heading
  
foo
  
  Type in some text here...

  
  Eliott P. Squibb
  Joe Blogg
  none
  Distributed under same terms as Perl
  
define your own section
blab here
  



> But, why not suggest SDF instead of XML?  SDF addresses most of POD's
> deficiencies whill still retaining readability.  (I don't have a URL
> for SDF handy, but I'm sure a quick search on google.com would turn it
> up)

http://www.mincom.com/mtr/sdf/

Why change anything at all?  POD is good enough. Sure, it requires a
learning curve... but it is a small one. I'd never heard of SDF until you
mentioned it, but there's the "everyone else is doing it" argument form XML.
And XML/DocBook does look set to be the lingua franca documentation format.

In the end, all that I'd like to see is the ability to churn out DocBook
documentation from whatever intermediary notation is used. That doesn't
require changing anything, just adding a new pod2docbook tool. So while I
"like" the idea of adopting XML as an addition to POD... There's no driving
need that it fulfills.

Garrett

RE: Perl already allows XML for documentation (was Re: RFC 357 (v1) Perl should use XML for documentation instead of POD)

[Garrett Goebel]

From: John Porter [mailto:[EMAIL PROTECTED]]
> 
> It would be very detrimental to perl's performance to have to do an
> XML parse of every input source file.

if the parser can skip between: 

=pod

=cut


it can certainly be made to skip between: 

Re: RFC 358 (v1) Keep dump capability.

[Philip Newton]

On 1 Oct 2000, Perl6 RFC Librarian wrote:

> =head1 ABSTRACT
> 
> To simplify distribution of programs in binary form,
> support for dump should be kept.
> 
> =head1 DESCRIPTION
> 
> This would immensely aid distribution of code from one Linux, Windows,
> etc. machine to others without requiring all the recipients to be able
> to install Perl, compile and install modules required by the program,
> and configure their hosts so that Perl find the modules.  There are
> also times when pre-loading and pre-processing large amounts of data
> are desirable.

You're kidding, right? Have you ever used this capability? If so, you
should have spoken up when the RFC to remove 'dump' was distributed.

As far as I know, it's rather difficult to turn a core dump into an
executable, so I don't think it "immensely aids distribution of code". I'm
willing to be proved wrong, though; if someone can provide a recipe to do
so and/or point out somewhere this is used, I'd be interested.

> =head1 IMPLEMENTATION
> 
> RFC 267 wants dump eliminated mainly because it is a common name for
> user subroutines, bit also because it can be accomplished with a kill
> signal. I really do not care if dump is renamed, but I believe keeping
> the capability is in perl's interest for greater acceptance and use.

Funny, most other languages don't have a 'dump' command, yet that doesn't
stop them from being accepted. Maybe you want a way to get free-standing
executables; well, there's an RFC for that, too. I just don't think dump
is the road to that.

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Glenn Linderman]

Damien Neil wrote:

> Having said that, I'm not fond of writing XML/HTML by hand.  I'd far
> rather write an author-friendly language and have that translated to
> XML.

Indeed, this is the key problem with human use of XML.  HTML was originally
simple enough to be human writable, its later, more powerful incarnations
start losing that (but you can always use a subset for simple things, and
XML never had human writable simplicity and never will.

--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
   -- Will Rogers



NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Damien Neil]

On Mon, Oct 02, 2000 at 09:21:51AM -0700, Glenn Linderman wrote:
> Indeed, this is the key problem with human use of XML.  HTML was originally
> simple enough to be human writable, its later, more powerful incarnations
> start losing that (but you can always use a subset for simple things, and
> XML never had human writable simplicity and never will.

XML is intrinsically no more or less difficult to write than HTML.
Comparing XML to HTML is pointless, however; they are not the same
thing.  Rather, compare XML to SGML, and specific XML DTDs (XHTML,
for example) to HTML.

XHTML is certainly no more difficult to write than plain HTML.  The
only real difference is that tags like  become  -- hardly
a major difference.  Indeed, I would consider the XHTML version to
be a bit simpler to understand.

- Damien

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Bart Lateur]

On Mon, 2 Oct 2000 10:51:28 -0700, Damien Neil wrote:

>> XML never had human writable simplicity and never will.
>
>XML is intrinsically no more or less difficult to write than HTML.

The problem with XML is that it is so unforgiving; I think somebody
already mentioned that. Improperly nested tags, or one character it
doesn't recognize... and the parser says "nyet".

-- 
Bart.

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Peter Scott]

At 03:53 PM 10/2/00 +0200, Bart Lateur wrote:
>On Mon, 2 Oct 2000 08:29:09 -0500, Jonathan Scott Duff wrote:
>
> >But, why not suggest SDF instead of XML?  SDF addresses most of POD's
> >deficiencies whill still retaining readability.  (I don't have a URL
> >for SDF handy, but I'm sure a quick search on google.com would turn it
> >up)
>
> http://www.mincom.com/mtr/sdf/
>
>
>It is based upon POD, which might help in lowering the entry threshold.

Agreed.  Let's not throw out the baby with the bathwater on this RFC; 
there's much to commend a proposal that allows enhanced documentation 
formatting within a script.  I know that for 90% of the stuff we write, 
it's so short that simply-formatted comments and POD will do, but there's a 
whole world of software that uses things like cascading requirements 
documents, design and delivery reviews, white papers, etc, i.e., "large 
systems," of the type that are seldom written in Perl but which in 
principle could be.

As long as we're designing something to stand the test of time for maybe 
five years or more, we can think a little bigger than usual.  I don't use 
an IDE - unless you count Emacs - but the one feature that I've been 
panting for in my editor for a good 15 years that might induce me to do so 
would be the ability to independently collapse comment blocks of arbitrary 
size within my code to small labelled icons.  Click on an icon, and it 
expands into comments explaining the code at hand; click again, and it 
collapses so you can see the code.  Or it might pop up another window with 
a technical paper explaining the algorithm.  People have suggested Emacs 
outline mode for this but it doesn't come close.

Oops, got a bit carried away by the fantasy there.  Anyway, a sufficiently 
extensible POD could allow the creation of such a thing.  Granted, if your 
tool is a text editor that doesn't understand such comments, you might not 
like receiving one from someone unless they ran it through some kind of 
converter, but that shouldn't preclude the ability to construct the technology.

How about just standardizing a syntax for embedding different languages and 
ensuring that   perl can find where the block ends, he asked with some 
trepidation.  Eg,

... perl ...
=pod language=SDF boundary=VERYLONGSTRINGYOUGETTHEIDEA

... SDF ...

VERYLONGSTRINGYOUGETTHEIDEA
... perl ...

Not that this should stop us from improving POD as well...
--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD

[John Siracusa]

On 10/2/00 1:56 PM, Bart Lateur wrote:
> The problem with XML is that it is so unforgiving; I think somebody
> already mentioned that. Improperly nested tags, or one character it
> doesn't recognize... and the parser says "nyet".

Kind of like Perl, huh... ;)

(this is a feature, not a bug! :)
-John

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Russ Allbery]

Garrett Goebel <[EMAIL PROTECTED]> writes:

> 
>   Module::Name
>   0.01
>   short description
>   
> =head1 long description
> 
>   =head2 heading
>   
> foo
>   
>   Type in some text here...
> 
>   
>   Eliott P. Squibb
>   Joe Blogg
>   none
>   Distributed under same terms as Perl
>   
> define your own section
> blab here
>   
> 

Wow, that's completely unreadable.  That's more unreadable than *roff.

(This is due to the fundamental flaw in SGML syntax, namely that at a
glance it's impossible to distinguish the tags from the content because
the delimiters are horribly constructed and you need too many tags.  This
is a fundamental flaw in the entire way that SGML syntax was designed, and
I don't think it's possible to fix.  As far as I'm concerned, *any*
SGML-derived markup language is write-only and usable only as an output
format.  It's slightly more readable than PostScript, and that's about all
I can say for it.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Tad McClellan]

On Mon, Oct 02, 2000 at 07:56:45PM +0200, Bart Lateur wrote:
> On Mon, 2 Oct 2000 10:51:28 -0700, Damien Neil wrote:
> 
> >> XML never had human writable simplicity and never will.
> >
> >XML is intrinsically no more or less difficult to write than HTML.
> 
> The problem with XML is that it is so unforgiving; I think somebody
> already mentioned that. Improperly nested tags, or one character it
  
> doesn't recognize... and the parser says "nyet".
  ^  


I read that as "the machine will tell me when I messed up".

I'd rather have a machine tell me than have to figure it
out myself. I think I claim some of the Good Laziness there  :-)


If we want data we can process, we first need data we can parse.

We would have that with XML, we could have that with POD. Just
publish the grammar for POD documents.


-- 
Tad McClellan  SGML consulting
[EMAIL PROTECTED] Perl programming
Fort Worth, Texas

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Dan Sugalski]

At 04:39 PM 10/1/00 -0700, Peter Scott wrote:
>At 04:53 PM 10/1/00 -0400, Dan Sugalski wrote:
>>At 11:33 AM 10/1/00 -0700, Peter Scott wrote:
>>>But, setting aside my visceral reaction to changing array bases, you 
>>>have precisely the same problem here that has scuppered my intent to 
>>>file an RFC for hashes with fixed keys; how do you apply the attribute 
>>>to anonymous, let alone autovivified, arrays?  If I say
>>>
>>> my @a :base(1);
>>>
>>>then what of $a[1][1]?  How to specify that the second level array also 
>>>has a base of 1?  Without it looking really ugly?
>>
>>Well, it'd be reasonable for autovivified arrays and hashes to inherit 
>>the properties of their parent, so if you had:
>>
>>   my int @foo;
>>
>>and accessed $foo[1][2], that new autovivified array would be of type int.
>
>Well, okay.  This works better in the case of arrays, where it is much 
>more likely that the programmer wants homogeneity, than in 
>hashes.  Consider a typical multicolumn database-type hash like:

[Snip]

>Clearly each level does not want the same restriction on its keys.

Yep. Neither would you want it for arrays of hashes or hashes of arrays. 
(Though I do realize that's rather nonsensical) A 'nopropagate' attribute 
might be in order, but that's kinda icky looking. Maybe forcing a 
'propagate' attribute if you want the keys (or whatever) to propagate down 
would be better.

>But the fact that my pet whim isn't supported by this proposal shouldn't 
>detract from the advantages in other situations.

But it is an important thing to keep in mind. An idea that's 80% useful but 
20% annoying needs rework.

>>As for anonymous hashes and arrays, there's no reason outside of 
>>appearance that you coudn't tack on attributes after the closing 
>>array/hash constructor:
>>
>>   my $foo = [] : int;
>
>Looks good.  What are the chances of the internals supporting user-defined 
>attributes?  What would the API look like?

Well, yeah, it'll sort of have to if we allow user-defined types. If you do:

   my Dog $spot : male;

then the Dog package needs to be able to fetch the attributes. I've no idea 
how that'd look--perhaps an attributes() function, a method in UNIVERSAL, 
or something like that.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Tom Christiansen]

>No-one ever did suggest adding « and » to the list of matched delimiters
>that q() etc support, did they? :-)

I did.

>Does Unicode define bracket pairings for character sets? 

$ grep ^Prop /usr/local/lib/perl5/5.6.0/unicode/Props.txt

does not seem very helpful, but this may not be much of a proof.

--tom

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Tom Christiansen]

>- Done right, it could be easier to write and maintain

Strongly disagree.

>- Why make people learn pod, when everyone's learning XML?

Because it is simple.  It is supposed to be simple.
It is not supposed to do what you want to do.
In fact, it is suppose to NOT DO what you want to do.

>- Pod can be translated into XML and vice versa

Then do that.

>- Standard elements could be defined and utilized with the
>  same or greater ease than pod for build and configuration.

>
>  Module::Name
>  0.01
>  short description
>  
>=head1 long description
>
>  =head2 heading
>  
>foo
>  
>  Type in some text here...
>
>  
>  Eliott P. Squibb
>  Joe Blogg
>  none
>  Distributed under same terms as Perl
>  
>define your own section
>blab here
>  
>

That is an excellent description of why THIS IS COMPLETE 
MADNESS.  

--TOM

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Tom Christiansen]

>XML is intrinsically no more or less difficult to write than HTML.

Wrong.

>Comparing XML to HTML is pointless, however; they are not the same
>thing.  

Wrong.  And you only say that because you will not like the answer.

Go back to the posted example and count bytes of data versus
bytes of meta data.  

I guarantee you that you will drive people away with this crap.

And the sum result is less docs.  

No thanks.

''TOM

Re: RFC 327 (v2) C<\v> for Vertical Tab

[Jacob Davies]

On Sun, Oct 01, 2000 at 10:24:58AM +0200, Bart Lateur wrote:
> difficult feature, is a lot harder than this kind of simple, er, shit.

Actually, when I was first programming Perl after coming from C I was
tripped up by this very difference, and didn't quite understand why \v
wasn't an escape.

I forget what I was using it for.  I certainly haven't used vertical tab
in a long time, and even back then I was probably using it for an escape
sequence or something similar rather than as a tab.  Perhaps there's
a good reason it wasn't included, perhaps someone reading this thread even
knows what that reason is.  Perhaps not, and it would actually be a good
idea to include it in Perl 6 to avoid the kinds of (small) problems I had
with it.

Referring to this RFC as "shit" just because it's simple seems rather harse.
If the big RFCs are like creating new tools in your toolkit, or radically
changing the way they work, this one is like taking out an old tool and filing
off a sharp point from the handle so it doesn't poke you next time you use it.
I can't see that as a bad thing.

-- 
Jacob Davies
[EMAIL PROTECTED]

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Tom Christiansen]

>The problem with XML is that it is so unforgiving; 

No, the problem is verbosity.

''tom

Re: 184 (v3): Perl should support an interactive mode

[Christian Soeller]

 
> 
> Very little discussion was generated by this RFC. Several people noted that perl -de 
>42 and the Perl shell psh already provide some
> of what the RFC requests; this is noted in the RFC. 
> 
> The RFC is not being withdrawn, since 2 other people expressed (mild) interest in 
>it. 

I'd like to add that multiline shell capabilities would be *extremly*
useful for the perldl shell (as already noted by the author) and
pdl-porters emphatically support this RFC.

If Python can do it Perl6 should be able to do it as well. In the very
least multi-line sub definitions. Anything less would be disappointing.

  Christian

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Damien Neil]

On Mon, Oct 02, 2000 at 01:24:37PM -0600, Tom Christiansen wrote:
> >XML is intrinsically no more or less difficult to write than HTML.
> 
> Wrong.

I beg your pardon?


> >Comparing XML to HTML is pointless, however; they are not the same
> >thing.  
> 
> Wrong.  And you only say that because you will not like the answer.
> 
> Go back to the posted example and count bytes of data versus
> bytes of meta data.  

Did you read what I wrote?

XML is like SGML.  It specifies a generic means of writing structured
text; it says nothing about what that structure is.  In particular,
neither XML nor SGML specifies a particular set of tags.  HTML is a
particular SGML dialect; as such, it can only be compared to a specific
XML dialect, not XML as a whole.

  This is XML.

It is also SGML.  It is not, obviously, HTML.

  This is HTML.
  This is XHTML.

No difference, really.  You do see differences with things like the
 tag; SGML allows the DTD to define certain tags as being atomic,
and XML does not.  This means that  must be written as  in
XHTML.

Now, if you want to compare an XML DTD like DocBook to HTML, you have
a point.  DocBook contains whole heaping piles of complexity.  I'd
certainly rather write HTML than DocBook by hand.


> I guarantee you that you will drive people away with this crap.

What?  I don't think people should be writing either XML or HTML
as the source documentation format.  I said that, quite clearly.

 - Damien

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Johan Vromans]

Jonathan Scott Duff <[EMAIL PROTECTED]> writes:

> I'll just add my voice to the others.  POD is more readable than XML.

Don't forget: more _writable_ as well.

-- Johan

RE: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Garrett Goebel]

From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
> 
> >- Done right, it could be easier to write and maintain
> 
> Strongly disagree.

Ok, you disagree. There are differing opinions here. Can we agree to
disagree? Or must all people who believe XML is easier to write and maintain
leave the room? 

Oh... and don't forget to mention or acknowledge areas where a common ground
might be reached. Lets only focus on negative things shall we?

Garrett Goebel wrote:
> In the end, all that I'd like to see is the ability to
> churn out DocBook documentation from whatever intermediary
> notation is used. That doesn't require changing anything,
> just adding a new pod2docbook tool. So while I "like" the
> idea of adopting XML as an addition to POD... There's no
> driving need that it fulfills.

Before I was strongly in the "why bother" camp. Now I'm shifting toward the
"why not let people chose?". The change of heart is probably an irrational
response to hearing all dissenting opinions crapped on. Give me 24 hours and
I'll probably be back to "why bother".

Horror of horrors: why not support both? Long live: TMTOWTDI. If XML
documentation fails to thrive, cut it from Perl 6.1. If both thrive, keep
'em. As everyone has said XML can be converted to pod and vice versa. Pod
tools could be made to coexist with XML.

The more militantly people state TIOMWTDI (There Is Only My Way To Do It),
the more I hear the opinions of others in a postive light. I agreed and do
agree that there is no driving need to support use of xml to annotate
scripts. But to quote you out of context concerning your violent opposition
to anything other than pod:

> I guarantee you that you will drive people away with this crap.

 
Tom Christiansen wrote:
> >- Standard elements could be defined and utilized with the
> >  same or greater ease than pod for build and configuration.
> 
> >
[...]
> >
> 
> That is an excellent description of why THIS IS COMPLETE 
> MADNESS.  

Being able to parse for well-definedness, DTD validation, and schema
constraints are postive things. Also, I imagine it'd be easier for xml to
grow to meet future unforeseen needs.

I find debugging pod to be a nuisance and the error messages to be vague and
unhelpful. Then again, pod is so darn easy it doesn't talk long to debug
anyway.

Just because XML wouldn't win any contests for brevity or beauty doesn't
qualify it for being commited to a sanitarium.

Garrett

RE: RFC 357 (v1) Perl should use XML for documentation instead of POD

[John Barnette]

Garrett Goebel (Today):
> Horror of horrors: why not support both? Long live: TMTOWTDI. If XML
> documentation fails to thrive, cut it from Perl 6.1. If both thrive, keep
> 'em. As everyone has said XML can be converted to pod and vice versa. Pod
> tools could be made to coexist with XML.

But why extend the syntax for such a niche application?

* POD can be easily converted to XML.
* POD can contain XML.
* Advanced concepts that POD cannot contain that the XML junkies
  might want to be used can be embedded. (=for XML)

An interested party could easily write another pod2* that did the job
using the XML-specific sections. (podxml2man, maybe?)

I'm struggling to see; is there anything here we can't already do?

~ j.

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Nicholas Clark]

On Mon, Oct 02, 2000 at 02:44:56PM -0600, John Barnette wrote:
> But why extend the syntax for such a niche application?
> 
>   * POD can be easily converted to XML.
>   * POD can contain XML.
>   * Advanced concepts that POD cannot contain that the XML junkies
> might want to be used can be embedded. (=for XML)

Now, if I could use POD to get the job done more lazily, but switch to XML
if I needed something more than pod can do (tables more sophisticated than
can be tersely expressed in monospace ASCII being the only one so far)
then I'd be happy. Oh, and my code would be more likely to be documented
full stop than if I had to fight XML.

I speak only for myself here. (oh, and my boss, who thought the same)

Nicholas Clark

RE: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Myers, Dirk]

> >  same or greater ease than pod for build and configuration.
> > 
> > >
> [...]
> > >
> > 
> > That is an excellent description of why THIS IS COMPLETE 
> > MADNESS.  

Maybe I'm reading too much into the comment, but I thought the big deal was
that the example given was not only verbose, but wouldn't parse correctly:

(from the section you elided:)

> > >  Eliott P. Squibb
> > >  Joe Blogg

Whoops.   We need a  tag there.

> Just because XML wouldn't win any contests for brevity or beauty doesn't
> qualify it for being commited to a sanitarium.

True.  And the fact that the example wasn't written properly isn't a
conclusive proof that it's not easy to do. But it isn't exactly an
encouraging sign, either.

Dirk

P.S. Isn't this all supposed to be done, now?

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[John Siracusa]

On 10/2/00 4:44 PM, John Barnette wrote:
> * Advanced concepts that POD cannot contain that the XML junkies
>  might want to be used can be embedded. (=for XML)

Yeah, but then you get =for HTML, =for XML, =for 3DHOLOGRAM, whatever. No
one does that because no one wants to make 50 versions of the table they
have in their docs, one for each document type they happen to be able to
think of at the moment.  The do it in ASCII art an are done with it because
they realize the futility of making 5 different versions.  POD is supposed
to be the common format that can be transformed into other representations.
Instead, you have to add the different representations yourself if you do
anything remotely complex.

People are looking for POD alternatives because doing complex things in POD
is so hard and/or annoying.  And those that do add neat little =for HTML
bits so their docs look nice in pod2html or whatever are basically
pigeonholing themselves in the land of HTML.  What everyone wants here is
some standard format that is rich enough to be converted to anything: a
format that can handle complex items like tables and hyperlinks and embedded
images and all that good stuff.  "It can be done" in POD, but there are so
many varying ways to do it that it creates a barrier to users. So people
stick to Plain Old POD, sans fancy =for business, 90% of the time.

XML is probably not the answer, but I really do think POD needs to evolve
along with the rest of Perl.

-John

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Bart Lateur]

On Mon, 2 Oct 2000 13:54:47 -0400, Tad McClellan wrote:

>> Improperly nested tags, or one character it
>> doesn't recognize... and the parser says "nyet".
>
>I read that as "the machine will tell me when I messed up".
>
>I'd rather have a machine tell me than have to figure it
>out myself. I think I claim some of the Good Laziness there  :-)

That's not my experience with XML::Parser. It gives some weird error
message, mentions a line number and a column number that doesn't even
exist... and that's it. It's not very helpful. You usually don't even
get any output so you can see where and how you messed up.

It's the same Good Laziness that tells me it's no good.

-- 
Bart.

RE: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Garrett Goebel]

From: Myers, Dirk [mailto:[EMAIL PROTECTED]]
> 
> Maybe I'm reading too much into the comment, but I thought 
> the big deal was that the example given was not only
> verbose, but wouldn't parse correctly:
> 
> (from the section you elided:)
> 
> > > >  Eliott P. Squibb
> > > >  Joe Blogg
> 
> Whoops.   We need a  tag there.

Yes, and it'd be patently obvious to the parser where the problem is and
easier to generate a specific and meaningful warnings to boot.

Not to mention if you use a gui editor incorporated color coding, it'd be
easier to read and see errors. Emacs cPerl doesn't handle pod very well...
anyone know why that is?


> True.  And the fact that the example wasn't written properly isn't a
> conclusive proof that it's not easy to do. But it isn't exactly an
> encouraging sign, either.

Can you see the problematic extra space here? No... I didn't think so...

=pod

=head1 Header
 
=cut

Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD

[Greg Williams]

>XML, on the other hand, uses & as the escaping mechanism, helping
>a reader sort-out deeply-nested escapings.

...

>POD has a good advantage in that it's design allows for it to
>embed well into code.  If documentation is to be alongside
>code, a direction to consider is to have the Perl
>program be an XML document itself, with the code inside of it,
>between designated tags.  This would allow for the entire
>Perl program/document to be rendered in a unified manner, using
>one tool, and conforming to one meta-language, XML.

By making a Perl program an XML document, the programmer is forced to 
read the XML.  It should be noted that XML isn't supposed to be read 
by a person - it is meant to be read by a computer.  The W3C document 
"XML in 10 points" states this as point three.

 From http://www.w3.org/XML/1999/XML-in-10-points :
>XML files are text files, as I said above, but even less than HTML 
>are they meant to be read by humans. They are text files, because 
>that allows experts (such as programmers) to more easily debug 
>applications, and in emergencies, they can use a simple text editor 
>to fix a broken XML file.


.greg
-- 
Greg Williams| If you wish to live a life free from sorrow,
Cnation  | think of what is going to happen as if it had
[EMAIL PROTECTED] | already happened.

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Tad McClellan]

On Mon, Oct 02, 2000 at 10:59:46PM +0200, Bart Lateur wrote:
> On Mon, 2 Oct 2000 13:54:47 -0400, Tad McClellan wrote:
> 
> >> Improperly nested tags, or one character it
> >> doesn't recognize... and the parser says "nyet".
> >
> >I read that as "the machine will tell me when I messed up".
> >
> >I'd rather have a machine tell me than have to figure it
> >out myself. I think I claim some of the Good Laziness there  :-)
> 
> That's not my experience with XML::Parser. It gives some weird error
> message, mentions a line number and a column number that doesn't even
> exist... and that's it. It's not very helpful. You usually don't even
> get any output so you can see where and how you messed up.
> 
> It's the same Good Laziness that tells me it's no good.


That is a deficiency in XML::Parser (a tool) not with XML.

I find that nsgmls (with an XMLified SGML Declaration) does
a good job. I always check XML data with nsgmls first.

(nsgmls is an SGML parser, not a XML parser, but I've never
 come across bad XML that it lets by...
)



XML::Parser gives bad messages, so XML is bad.

The Blue Screen Of Death is bad, so computers are bad?



[  Puhleeeze don't think that I am defending XML over POD. I am
   firmly in the POD camp. So many others are in that camp, that
   I just haven't added my Me too! ('til now :-)
]


-- 
Tad McClellan  SGML consulting
[EMAIL PROTECTED] Perl programming
Fort Worth, Texas

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Nathan Wiger]

Dan Sugalski wrote:
>
> Well, yeah, it'll sort of have to if we allow user-defined types. If you do:
> 
>my Dog $spot : male;
> 
> then the Dog package needs to be able to fetch the attributes. I've no idea
> how that'd look--perhaps an attributes() function, a method in UNIVERSAL,
> or something like that.

There's two ways I've proposed in different RFC's. The first one
utilizes a more general framework; the second one depends on C
being used. A UNIVERSAL:: method wouldn't work because you've got to get
attributes from arrays and hashes as well. We'd probably just need an
attributes() builtin for retrieval to work really smoothly (but the
RFC's just reference attributes::get, the current method).

Anyways, here's the ideas from RFC's 337 and 319; input is still
welcome:

--

RFC 337: Common attribute system to allow user-defined,
 extensible attributes

=head1 IMPLEMENTATION

The easiest way I see is to change the C pragma into a
pre-declaration pragma instead, something like:

   package Foo;
   use attributes fluffy => 'DEFAULT',
  size => \&SIZE_ATTR,
  UNKNOWN => \&ATTR_HANDLER;

So, the declaration of C<:fluffy> on an instance of C would just
result in it being stored as text retrievable via C or
some other means. On declaration of C<:size('big')>, though, the
C sub from the class would be called. That is,
a reference to the variable being altered would be the first arg, and
the attribute arguments would be passed in by value.

Any unknown attributes would be thrown to the C sub, which
would take the name of the attribute as the first arg, and then the
other args would look like any other handler. For example:

   my Foo $bar :baz('likely');  # Foo->ATTR_HANDLER('baz', \$bar,
#   'likely')

The name of the unknown attribute is the first arg so it can easily be
shifted off.

In both scenarios, the attributes should always be retrievable at a
later time. However, the declaration of an attribute should also be able
to trigger the execution of a specific sub that can make changes to
internals (perhaps through the C pragma), to the data for
that object, or something else.

Note that you could even add a C pragma that
dictated you could only use predeclared attributes. This could help
catch mistyping of important ones:

   package Parallel;
   use attributes slippery => \&FALL_OFF;

   package main;
   use strict 'attrs';
   my Parallel $bar :slipery;# raise exception

Here, we've caught a typo that might result in badness later.



RFC 319: Transparently integrate C

=head2 Passing arguments

Since many Cd variables require that extra arguments be passed,
this RFC proposes two ways of doing this. Either could be used,
depending on a person's preference:

=head3 The general attribute style

In the attribute style, extra arguments are simply specified as
attributes, which are then passed into the C function as
a hashref of values. So this:

   my Apache::Session %session :Transaction;

Would be the same as this in Perl 5:

   tie %session, 'Apache::Session', { Transaction => 1 };

A bare attribute is assumed to be a switch and is simply given a value
of "1". Note that attributes allow you to specify arguments, too, so
this:

   my Dog $spot :coat('shiny') :bark('rough') :mean;

Would result in the following call:

   Dog->TIESCALAR($spot, { coat => 'shiny', bark => 'rough',
   mean => 1 });

This form has the benefit that it makes user-defined variables appear as
transparent as builtins, and also gives the C constructors easy
access to the attributes declared.

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Peter Scott]

At 03:15 PM 10/2/00 -0700, Nathan Wiger wrote:
>Dan Sugalski wrote:
> >
> > Well, yeah, it'll sort of have to if we allow user-defined types. If 
> you do:
> >
> >my Dog $spot : male;
> >
> > then the Dog package needs to be able to fetch the attributes. I've no idea
> > how that'd look--perhaps an attributes() function, a method in UNIVERSAL,
> > or something like that.
>
>There's two ways I've proposed in different RFC's. The first one
>utilizes a more general framework; the second one depends on C
>being used. A UNIVERSAL:: method wouldn't work because you've got to get
>attributes from arrays and hashes as well.

Maybe I'm just being dense, but why shouldn't arrays and hashes inherit 
attributes from UNIVERSAL?  tie()ing an array is really just like being 
able to call object methods on it distinct from its members, no?  So arrays 
and hashes could be objects too.  Hmm, am I saying that I should be able to 
write @array->method()?

There again, maybe it's just this head cold I've got.

--
Peter Scott
Pacific Systems Design Technologies

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Nathan Wiger]

> >There's two ways I've proposed in different RFC's. The first one
> >utilizes a more general framework; the second one depends on C
> >being used. A UNIVERSAL:: method wouldn't work because you've got to get
> >attributes from arrays and hashes as well.
> 
> Maybe I'm just being dense, but why shouldn't arrays and hashes inherit
> attributes from UNIVERSAL?  tie()ing an array is really just like being
> able to call object methods on it distinct from its members, no?  So arrays
> and hashes could be objects too.  Hmm, am I saying that I should be able to
> write @array->method()?

I think under tie this is *exactly* what we should be aiming for. I
think this is awesome.

However, making it a UNIVERSAL method also dictates that this:

   my SomeType @a :someattr;

*must* be either:

   1. a builtin type
   2. tied

To get its attributes back out. I'm not sure this is going to always be
true. In particular, what if SomeType was like "int", and you were just
trying to assert that each individual element was going to be SomeType?

If these problems were resolved, then I must admit to having a perverse
softspot for being able to say:

   my packed @bits :long;
   %attrs = @bits->attributes;

I dunno...I like the way that looks for some reason... ;-)

-Nate

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Dan Sugalski]

At 03:32 PM 10/2/00 -0700, Nathan Wiger wrote:
> > >There's two ways I've proposed in different RFC's. The first one
> > >utilizes a more general framework; the second one depends on C
> > >being used. A UNIVERSAL:: method wouldn't work because you've got to get
> > >attributes from arrays and hashes as well.
> >
> > Maybe I'm just being dense, but why shouldn't arrays and hashes inherit
> > attributes from UNIVERSAL?  tie()ing an array is really just like being
> > able to call object methods on it distinct from its members, no?  So arrays
> > and hashes could be objects too.  Hmm, am I saying that I should be able to
> > write @array->method()?
>
>I think under tie this is *exactly* what we should be aiming for. I
>think this is awesome.
>
>However, making it a UNIVERSAL method also dictates that this:
>
>my SomeType @a :someattr;
>
>*must* be either:
>
>1. a builtin type
>2. tied
>
>To get its attributes back out. I'm not sure this is going to always be
>true. In particular, what if SomeType was like "int", and you were just
>trying to assert that each individual element was going to be SomeType?

Then the int package would Do The Right Thing, of course. :) Just because 
they're provided types doesn't mean we won't be using the standard methods 
on them. (Though granted we may push a lot of the twiddly details into the 
main perl compile since we'll already know them--no reason to be 
unnecessarily dynamic)

And even if the int/float/str/bigint/bigfloat types aren't really modules, 
there's no reason the core can't fake it to look like they are...

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Dan Sugalski]

At 03:23 PM 10/2/00 -0700, Peter Scott wrote:
>At 03:15 PM 10/2/00 -0700, Nathan Wiger wrote:
>>Dan Sugalski wrote:
>> >
>> > Well, yeah, it'll sort of have to if we allow user-defined types. If 
>> you do:
>> >
>> >my Dog $spot : male;
>> >
>> > then the Dog package needs to be able to fetch the attributes. I've no 
>> idea
>> > how that'd look--perhaps an attributes() function, a method in UNIVERSAL,
>> > or something like that.
>>
>>There's two ways I've proposed in different RFC's. The first one
>>utilizes a more general framework; the second one depends on C
>>being used. A UNIVERSAL:: method wouldn't work because you've got to get
>>attributes from arrays and hashes as well.
>
>Maybe I'm just being dense, but why shouldn't arrays and hashes inherit 
>attributes from UNIVERSAL?  tie()ing an array is really just like being 
>able to call object methods on it distinct from its members, no?  So 
>arrays and hashes could be objects too.  Hmm, am I saying that I should be 
>able to write @array->method()?

Sure, why not? I'd love to be able to throw things into the HASH package 
now and do %foo->something. Not often, mind, but occasionally...

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Peter Scott]

At 03:32 PM 10/2/00 -0700, Nathan Wiger wrote:
> > Maybe I'm just being dense, but why shouldn't arrays and hashes inherit
> > attributes from UNIVERSAL?  tie()ing an array is really just like being
> > able to call object methods on it distinct from its members, no?  So arrays
> > and hashes could be objects too.  Hmm, am I saying that I should be able to
> > write @array->method()?
>
>I think under tie this is *exactly* what we should be aiming for. I
>think this is awesome.

RFC 82 would probably prefer that this have a component-wise interpretation :-)

>However, making it a UNIVERSAL method also dictates that this:
>
>my SomeType @a :someattr;
>
>*must* be either:
>
>1. a builtin type
>2. tied
>
>To get its attributes back out. I'm not sure this is going to always be
>true.

It must be my sinuses.  I don't get that at all.  Firstly, @a can't be tied 
before that statement since you only just declared it; the tie would have 
to follow.  Secondly, if the declaration declares @a as belonging to class 
SomeType, then unless SomeType.pm is perverse enough to override the 
attributes() method, why won't @a->attributes go through to 
UNIVERSAL?  Whether or not SomeType is builtin?

Or are we talking apples and oranges and the above declaration is intended 
to declare that any *member* of @a is of SomeType, never mind the array 
itself?

>  In particular, what if SomeType was like "int", and you were just
>trying to assert that each individual element was going to be SomeType?
>
>If these problems were resolved, then I must admit to having a perverse
>softspot for being able to say:
>
>my packed @bits :long;
>%attrs = @bits->attributes;
>
>I dunno...I like the way that looks for some reason... ;-)

Me too.
--
Peter Scott
Pacific Systems Design Technologies

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Nathan Wiger]

> >However, making it a UNIVERSAL method also dictates that this:
> >
> >my SomeType @a :someattr;
> >
> >*must* be either:
> >
> >1. a builtin type
> >2. tied
> >
> >To get its attributes back out. I'm not sure this is going to always be
> >true.
> 
> It must be my sinuses.  I don't get that at all.  Firstly, @a can't be tied
> before that statement since you only just declared it; the tie would have
> to follow.  Secondly, if the declaration declares @a as belonging to class
> SomeType, then unless SomeType.pm is perverse enough to override the
> attributes() method, why won't @a->attributes go through to
> UNIVERSAL?  Whether or not SomeType is builtin?
> 
> Or are we talking apples and oranges and the above declaration is intended
> to declare that any *member* of @a is of SomeType, never mind the array
> itself?

Yes, I think that second sentence hits the point. Currently, there's
ambiguity as to whether or not a type declaration on an array/hash means
to be applied element-wise or whole-component-wise.

If it's the latter, then there's no problem. And I suspect that's how
we'd want it to play out. I was just raising the concern that with the
current ambiguous non-definition of types (it's "conceptware" at this
point :), it could mean either one.

I pushed a lot of these issues in RFC 319 and 337, which would let you
say something like:

   my Pet @pets :mean; # integrated implicit tie
   @pets->attributes('mean')   # "true", like 'can'

Although, if we got verb tenses right I'd really like that to be:

   $spot->has('meanness');

:-)

-Nate

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Peter Scott]

At 03:55 PM 10/2/00 -0700, Nathan Wiger wrote:
> > Or are we talking apples and oranges and the above declaration is intended
> > to declare that any *member* of @a is of SomeType, never mind the array
> > itself?
>
>Yes, I think that second sentence hits the point. Currently, there's
>ambiguity as to whether or not a type declaration on an array/hash means
>to be applied element-wise or whole-component-wise.
>
>If it's the latter, then there's no problem. And I suspect that's how
>we'd want it to play out. I was just raising the concern that with the
>current ambiguous non-definition of types (it's "conceptware" at this
>point :), it could mean either one.
>
>I pushed a lot of these issues in RFC 319 and 337, which would let you
>say something like:
>
>my Pet @pets :mean; # integrated implicit tie
>@pets->attributes('mean')   # "true", like 'can'

I may be raining on your RFC 337 parade here (sorry I didn't get to it 
earlier - travel), but I think it entirely reasonable to want to specify a 
type for an array different from the type of thing it contains.  But what 
syntax will you use?  If I make one up for the sake of illustration:

 my DogPound(Dog) @kennel :homeless;

then @kennel->municipality, but $kennel[37]->breed.  Make sense, or should 
I just go back to bed?

--
Peter Scott
Pacific Systems Design Technologies

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[Nathan Wiger]

> I may be raining on your RFC 337 parade here (sorry I didn't get to it
> earlier - travel), but I think it entirely reasonable to want to specify a
> type for an array different from the type of thing it contains.  But what
> syntax will you use?  If I make one up for the sake of illustration:
> 
>  my DogPound(Dog) @kennel :homeless;
> 
> then @kennel->municipality, but $kennel[37]->breed.  Make sense, or should
> I just go back to bed?

In short: I don't see that as a problem. RFC 337 and 279 together
explicitly say that this syntax should now be viable:

   my Pet @pets;
   $pets[0] :fluffy = "kurt";# assign explicit attribute
   my Dog $pets[1] :mean = "spot";   # re-type a specific element

It's unchartered territory. But I don't see why it wouldn't work. The
only troublesome one is that last one, since it requires re-lexicalizing
the scope, which has no meaning for individiual array/hash elements
currently. So perhaps an alternate syntax:

   $pets[1] :type('Dog') = "rufus";  # re-typing

(with :type being a special builtin attribute) would be needed. Most of
this is in RFC 279 (except that :type thing, I just thought of that :-).

-Nate

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[John Porter]

Nathan Wiger wrote:
> I pushed a lot of these issues in RFC 319 and 337, which would let you
> say something like:
> 
>my Pet @pets :mean; # integrated implicit tie
>@pets->attributes('mean')   # "true", like 'can'

Blech.

exists @pets:mean  # true

-- 
John Porter

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

[John Porter]

Peter Scott wrote:
> 
> Maybe I'm just being dense, but why shouldn't arrays and hashes inherit 
> attributes from UNIVERSAL? 

I think, rather, they should inherit from some other root class,
since UNIVERSAL is for blessed things.


> Hmm, am I saying that I should be able to 
> write @array->method()?

Of course you already can, just not with that syntax:

scalar(@array)
$#array
keys(%hash)
values(%hash)

etc. etc.

-- 
John Porter

By pressing down a special key  It plays a little melody

Re: RFC 339 (v1) caller->eval BLOCK

[David L. Nicol]

Greg Williams wrote:

> as I remember, the C pragma, when used, would simply act as if the 
>enclosing scope were not in place, enabling such things as:
> if ($ints) {
>   no scope;
>   use integer;
> }


Hmm.  C could be implemented in terms of the rfc 340 C like
so:

  $scope_out_here = with;
  if ($ints) {
 with $scope_out_here {use integer}
  };


C is about subroutine calls.




-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
"After jotting these points down, we felt better."

Re: "0", true or false? (was: PERL6STORM #0052)

[David L. Nicol]

Bart Lateur wrote:

> Bitwise and, or and xor do distinguish strings from numbers, and return
> entirely different kinds of results. Why can't anything else?

Absolutely.  There is such a thing as Too Much Convenience.  I think
BOOL as a context or an accessor method should be separate from STRING and
NUMBER so that if you know, you can suggest which behavior you want out
of a particular scalar variable, or stick with the misguidable default.



-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
"After jotting these points down, we felt better."

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

[Adam Turoff]

On Mon, Oct 02, 2000 at 03:36:20PM -0500, Garrett Goebel wrote:
> From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
> > >- Done right, it could be easier to write and maintain
> > 
> > Strongly disagree.
> 
> Ok, you disagree. There are differing opinions here. Can we agree to
> disagree? 

No.

Agreeing to disagree about this is like agreeign to implement Perl
with three parts C, two parts Eiffel, two parts Python and one part
Objective C.  TMTOWTDI can't always be invoked simply because this
project is named Perl.

> Or must all people who believe XML is easier to write and maintain
> leave the room? 

There are huge cultural, technical and practical limitations for
Perl to adopt XML as a documentation syntax, or code all docs in
=xml...=cut blocks.

If you want to use XML, Latex, Texinfo or raw *roff for your docs,
then by all means do so.  Understand that Perl can't be made to
magically ignore embedded Texinfo, and Perl contributors realistically
can't be made to understand/patch/correct multiple markup formats.

This is why we invented POD.  This is why we use POD.
 
> Horror of horrors: why not support both? Long live: TMTOWTDI. If XML
> documentation fails to thrive, cut it from Perl 6.1. 

XML docs *have* failed to thrive among those who document Perl.
They have failed to thrive among that group for over two years,
especially since all that's missing is someone thinking about a
definitive POD->XML conversion.  (Sorry, I'd chip in, but I'm a
little busy this week.)

> > That is an excellent description of why THIS IS COMPLETE 
> > MADNESS.  
> 
> Being able to parse for well-definedness, DTD validation, and schema
> constraints are postive things. 

And none of them *require* XML.  There's no reason why POD can't be
well-defined, validated and schema correct.

Z.

Re: RFC 339 (v1) caller->eval BLOCK

[Greg Williams]

At 18:43 -0500 2000/10/02, David L. Nicol wrote:
>Hmm.  C could be implemented in terms of the rfc 340 C like
>so:
>
>   $scope_out_here = with;
>   if ($ints) {
>  with $scope_out_here {use integer}
>   };
>
>C is about subroutine calls.

Interesting!  I have a few questions (meandering thoughts) though 

The example in the RFC gives:

 sub A{
 my $A = shift;
 return with;
 };

 $context1 = A(3);
 print "$context1";  # something like CONTEXT(0XF0GD0G)
 print "$A" with $context1;  # prints 3
 with $context1{print "$A"}; # same thing


This implies that &A is now something akin to a closure, correct? 
That is to say, the meaning of C becomes changed by the 
presence of C so that $A is something in between a 
lexical scoped to &A and a lexical scoped around &A ({ my $A; sub A 
{} }).  $A is held in existence by the presence of the context 
object.  Presumably $A would 'go out of scope' and be destroyed at 
the same time as the associated context object?  This worries me, but 
I admit it's neat ;)

What is more worrying to me is this: with a C pragma, you 
can only go up /your/ scope.  Consider this:

 package Nasty;
 my $context;
 {
 package Unsuspecting_Package;
 $context = with;
 }
 use integer with $context;

Spooky action at a distance to be sure!  Also, integer (and others) 
is a compile time issue.  Using C can be easily (it would 
appear) implemented for compile-time since it's merely another 
pragma.  On the other hand, C strikes me as more of a run-time 
beast.  (at this point, I'm not sure if I have any idea of what I'm 
talking about, so excuse me if this has digressed into rambling :)

So I like the idea of C, but am not sure it is compeltely 
suitable for invoking pragmata such as integer.

.greg
-- 
"Push to test."

"Release to detonate."

Re: RFC 339 (v1) caller->eval BLOCK

[David L. Nicol]

Greg Williams wrote:

> Interesting!  I have a few questions (meandering thoughts) though 
> 
> The example in the RFC gives:
> 
>  sub A{
>  my $A = shift;
>  return with;
>  };
> 
>  $context1 = A(3);
>  print "$context1";  # something like CONTEXT(0XF0GD0G)
>  print "$A" with $context1;  # prints 3
>  with $context1{print "$A"}; # same thing
> 
> This implies that &A is now something akin to a closure, correct?

I'm not sure how perl5 differnetiates btn closures and non-closures,
I thought it just defered certain aspects of scope destruction.


> That is to say, the meaning of C becomes changed by the
> presence of C so that $A is something in between a
> lexical scoped to &A and a lexical scoped around &A ({ my $A; sub A
> {} }).  $A is held in existence by the presence of the context
> object.  Presumably $A would 'go out of scope' and be destroyed at
> the same time as the associated context object?  This worries me, but
> I admit it's neat ;)

Yes, thus the warning about memory leaks.

> What is more worrying to me is this: with a C pragma, you
> can only go up /your/ scope.  Consider this:
> 
>  package Nasty;
>  my $context;
>  {
>  package Unsuspecting_Package;
>  $context = with;
>  }
>  use integer with $context;
> 
> Spooky action at a distance to be sure!  Also, integer (and others)
> is a compile time issue.  Using C can be easily (it would
> appear) implemented for compile-time since it's merely another
> pragma.  On the other hand, C strikes me as more of a run-time
> beast.  (at this point, I'm not sure if I have any idea of what I'm
> talking about, so excuse me if this has digressed into rambling :)


I agree.  If we were to allow run-time changing of aspects of basic reality
(I think we should, if we can, and we can)  then every time we do it
a flag gets set telling Perl to throw out its cache of jump tables and reread
the instructions.  Or the cache just gets thrown out.  What if 

use integer

and similar pragmata  not only change aspects of eval() but also throw out all
the previous work.  In that context.

Or maybe it would have no effect at all:

use real;
sub pi_teration{
# one iteration of some pi-finidng algo
...
};
use integer;
# did I or did I not just hork my pi_iteration routine?


 
> So I like the idea of C, but am not sure it is compeltely
> suitable for invoking pragmata such as integer.

it depends on what is and waht is not "within" a context.  That is
a question I would like to defer.


-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
"After jotting these points down, we felt better."

Re: Conversion of undef() to string user overridable for easy debugging

[David L. Nicol]

Jarkko Hietaniemi wrote:

> This reminds me of a related but rather opposite desire I have had
> more than once: a quotish context that would be otherwise like q() but
> with some minimal extra typing I could mark a scalar or an array to be
> expanded as in qq().  For example doubling the $ and @? $$foo, @@bar?
> This comes in handy when you are generating big blocks of code on the
> fly but only tiny parts of it needs to be interpolated.  Unfortunately
> the margin of my monitor is not enough to describe this wonderful idea
> in a form of a RFC.


$qqdString =~ s/\[(\w+)\]/defined($vars{$1})?$vars{$1}:"[$1]"/ge;



-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
"After jotting these points down, we felt better."

Re: Conversion of undef() to string user overridable for easy debugging

[Jarkko Hietaniemi]

On Mon, Oct 02, 2000 at 09:17:31PM -0500, David L. Nicol wrote:
> Jarkko Hietaniemi wrote:
> 
> > This reminds me of a related but rather opposite desire I have had
> > more than once: a quotish context that would be otherwise like q() but
> > with some minimal extra typing I could mark a scalar or an array to be
> > expanded as in qq().  For example doubling the $ and @? $$foo, @@bar?
> > This comes in handy when you are generating big blocks of code on the
> > fly but only tiny parts of it needs to be interpolated.  Unfortunately
> > the margin of my monitor is not enough to describe this wonderful idea
> > in a form of a RFC.
> 
> 
>   $qqdString =~ s/\[(\w+)\]/defined($vars{$1})?$vars{$1}:"[$1]"/ge;

I'm sorry but that didn't quite make my heart leap with joy :-)

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: "0", true or false? (was: PERL6STORM #0052)

[Nathan Wiger]

"David L. Nicol" wrote:
> 
> Bart Lateur wrote:
> 
> > Bitwise and, or and xor do distinguish strings from numbers, and return
> > entirely different kinds of results. Why can't anything else?
> 
> Absolutely.  There is such a thing as Too Much Convenience.  I think
> BOOL as a context or an accessor method should be separate from STRING and
> NUMBER so that if you know, you can suggest which behavior you want out
> of a particular scalar variable, or stick with the misguidable default.

See RFC 159 - BOOLEAN, STRING, and NUMBER are the three main methods.

-Nate

Re: RFC 344 (v2) Elements of @_ should be read-only by default

[Piers Cawley]

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:

> This and other RFCs are available on the web at
>   http://dev.perl.org/rfc/
> 
> =head1 TITLE
> 
> Elements of @_ should be read-only by default
> 
> =head1 VERSION
> 
>   Maintainer: John Tobey <[EMAIL PROTECTED]>
>   Date: 28 Sep 2000
>   Last Modified: 1 Oct 2000
>   Mailing List: [EMAIL PROTECTED]
>   Number: 344
>   Version: 2
>   Status: Frozen
> 
> =head1 ABSTRACT
> 
> Unprototyped subs should not be allowed to modify their callers' data
> simply by assigning to elements of the arg array.
> 
> =head1 COMMENTS ON FREEZE
> 
> This RFC generated no discussion in 3 days

I'd just like to put in an 'ick' vote on this one. I might come up
with something a little longer and more reasoned later, but I'm
supposed to be writing shopping basket code.

-- 
Piers