hashes and subs [was: Re: Problem with dwimmery]
On Thu, 22 Dec 2005, TSa wrote:
Luke Palmer wrote:
Recently, I believe we decided that {} should, as a special case, be
an empty hash rather than a do-nothing code, because that's more
common.
Hmmm, OTOH a hash is a special kind of function, so it may also be
convenient to think of { item = 1, other_item = 2 } as a special syntax
for specifying a function from the UI POV, although it is obvious that the
internal representation must be different.
In that case it should be allowed to dereference a hash(ref) with .() in
addition .{} - possibly through a promotion behind the scenes, but that
would lead us very far away in the direction of another language that is
not Perl after all.
In fact on a deeper thought, (even in Perl6, in which the difference is
more blurred for conversions happen automatically in most
interesting/practical cases) one must still distinguish between a hash and
a hashref. Which is yet another reason not to take too seriously what's
hinted to above...
So I why not just trash this mail instead of sending it? you may ask!
But it may also raise some interesting meditation, so I'm definitely
posting it...
Michele
--
I guess I was saying that of the infix characters we had available to
choose, dot is the only one anybody uses. All the others are dotless,
so our attempts would be pointless, period.
- Luke Palmer in p6l, Re: $1 change issues ...
Re: Problem with dwimmery
On Thu, 22 Dec 2005, Juerd wrote:
while $x-- some_condition($x) {}
Here, while is being passed a hash
Why? Doesn't while's signature specifically prescribe a sub there, and
if it does, then wouldn't it be just a bit too silly to stick to {}
being a hash?
Well, as hinted in my other mail, a hash is a _function_ and it _may_ have
sense to stick a hash there, provided a suitable while() providing
suitable (no pun intended!) additional dwimmery is defined. Since I cannot
think of any that would gain us anything that we can't already do quite
easily and that would be intuitively clear about what it's doing...
probably it's not a good idea at all. But the point it that it may be
feasible and somebody may actually do it!
Michele
--
I understand that it is possible to express the number of ways of
having k bishops on an n*n board such that they are not attacking each
other as a combinatorial formula [...]
Why would bishops attack one another? Oh--over homosexuality perhaps?
- George Cox in sci.math [edited]
Structured data format [was: Re: Problem with dwimmery]
On Thu, 22 Dec 2005, Darren Duncan wrote: On a separate but related matter, I'm in the position of wanting to do something unusual, which is create a data file format whose content is executable perl code that defines a data structure, a hash of whatever. Kind of like how XML works except that Perl can natively parse it. On an even more separate but related matter, I've been desiring to stuff in the already multiparadigmatic nature of Perl6 markup language(-like) features myself. Not data that represents markup-language text. Stuff in the code that _is_ as opposed to stuff that _does_ (something), and specifies a structure, but links nicely with other stuff that actually does something. I had been thinking of this especially in connection with GUIs or more generally even-driven programming, but I don't think it should be limited to those respects. It would just be nice to have it available in our syntactical/semantical toolbox. Since I have not clear/definite ideas about both the effective usefulness of such a beast nor about how it could actually look like, I didn't receive much attention, but if you're interested you look up markup in the archives... Michele -- Meany other hackers halve trouble remembering witch is witch to. I'm all ways perfectly rite thou. - Luke Palmer in p6l, s/true/better name/
Array/list transformations.
This is not a substantial issue regarding Perl 6, but is more a minor feature curiosity/meditation. It was inspired some time ago by this PM node: http://perlmonks.org/?node_id=509310 I was wondering if in addition to push(), pop() etc. there could be be rot() and roll() methods that would act upon lists (not modifying them) like thus: (qw/aa bb cc dd ee/).rot(2) # qw/cc dd ee aa bb/ (qw/aa bb cc dd ee/).rot()# qw/bb cc dd ee aa/ = same as .rot(1) (qw/aa bb cc dd ee/).roll(2) # qw/dd ee aa bb cc/ = same as .rot(-2) (qw/aa bb cc dd ee/).roll() # qw/ee aa bb cc dd/ = same as .roll(1) ... etc. Also I wonder if one will be able to push(), pop(), etc. array slices as well whole arrays. A' la my @a=qw/aa bb cc dd ee/; my $s=pop @a[0..2]; # or [0,2] or just [0] for that matters! # $s='cc'; # @a=qw/aa bb dd ee/; = same as what I can do with slice() Not terribly necessary, but indeed consistent IMHO. Michele -- you'll see that it shouldn't be so. AND, the writting as usuall is fantastic incompetent. To illustrate, i quote: - Xah Lee trolling in clpmisc, perl bug File::Basename and Perl's nature
Iterating over complex structures
In Perl 5 Cfor is quite natural for iterating over lists and arrays.
Cwhile is preferred for filehandles. With lazy evaluation this
difference has been eliminated in Perl 6 so that while still TMTOWTDI
(TAEMWTDI!) this kind of iterations will be more consistent.
But in Perl 5 to navigate complex structures one needs ad-hoc solutions.
I wonder if something is planned in Perl 6 as a means to do that through a
syntactically convenient construct with ad-hoc-isms pluggable in in the
form of suitable hooks (e.g. .on_node( { code; ... } ), etc.) that would
work in most cases.
Please do not ask me what I have in mind, for I'm not really sure. I know
in advance that suitable modules may be written instead but I would like a
single builtin keyword. And I'd like to hear the opinion of the
Knowledgeable Ones(TM) here.
Suppose I want to navigate a tree and print out info contained in each of
its leaves along with info gathered from the position in the tree of the
list itself? Can I do it in a universal manner as hinted above that
would work for other situations as well?
PS: By complex structure here I mean a [AH]o[AH]o[AH]... or somesuch
with arbitrary nesting levels. Objects would do if they had sufficient
navigational info (e.g. parent(), next(), havechild(), etc.) i.e. if they
conformed to some probably not yet established interface.
Michele
--
I wish Sun would sort their versioning out
and have their marketing department shot.
- tomazos in PerlMonks.
Re: handling undef better
On Fri, 16 Dec 2005, Darren Duncan wrote: An undefined value is NOT the same as zero or an empty string respectively; the latter two are very specific and defined values, just like 7 or 'foo'. [snip] Therefore, I propose that the default behaviour of Perl 6 be changed or maintained such that: You have very strong arguments, but I think that Perl becoming more solid should not come at the expense of practicity. Indeed the single warning I most often happen to have to (locally) disable is 'uninitialized'. Granted, a C //0 or C //'' is even shorter, in production code that is, and clearly specifies what one expects, but (i) people may still trust the data they're working on and prefer the other way round, (ii) they may still want to chunk up quick'n'dirty one-liners (still expect to be not strict- and not warnings-safe). Michele -- Have you ever stopped to consider that what is crashing your Perl is sitting between the keyboard and chair? - Sherm Pendley in clpmisc, Re: Perl IDE (edited)
RE: handling undef better
On Sat, 17 Dec 2005, Darren Duncan wrote: Undef means don't know, which is distinct from zero, because in the latter case we explicitly have a value of zero. But when we don't know we can, and generally do, make reasonable _guesses_. Experience has shown that 0 or '' according the context are ehm, not only reasonable, but even good guesses that work most of the time. So much that we can safely rely on them. Or if they don't, then it's easy to explicitly take care of that particular undef like you suggest. Also, let undef be an I don't know as much as you like: still you can't negate that it is invariably associated psychologically with a feeling of 'nothingness' - indeed it's nothing else; or possibly anything else at the same time... Michele -- Gavin: Oliver, my father used to say that a man can never outdo a woman when it comes to love and revenge. - The War of the Roses (1989)
Re: handling undef better
On Sat, 17 Dec 2005, Darren Duncan wrote:
Actually, I don't like autovivification either, and wish there was a pragma
to make attempts to do it a fatal error; it smacks too much of using
variables that weren't declared with 'my' etc. I prefer to put in the
What has the latter to do with autovivification? Luke was referring to
autovivification in the sense of, say, complex data structures. In Perl 5
we can (strict-)safely write
my $x;
$x-{foo}[42][2005]{bar}='quux';
Would you like to have to explicitly and verbosely declare the shape of
the structure held in $x instead?
Michele
--
People can parse multi-dimensionally. Computers cannot... yet.
- chromatic in p6l, Re: Parsing indent-sensitive languages.
Re: handling undef - second draft
On Sat, 17 Dec 2005, Darren Duncan wrote: 1. I accept the proposal that we just make another class that implements the SQL concept of a null value, perhaps named Null or SQL::Null, rather than Somebody else suggested the nicely huffmanized 'nil', which IMHO sounds definitely interesting, although I guess I still prefer the current behaviour... Michele -- How can one prove the consistency of field?? How to prove that there are no self contradiction?? How can one prove the consistency of wombat?? How to prove that there are no self contradiction?? - Robin Chapman in sci.math
[OT?] Quote (was: Re: handling undef better)
On Mon, 19 Dec 2005, Michele Dondi wrote: You have very strong arguments, but I think that Perl becoming more solid should not come at the expense of practicity. Indeed the single warning I Speaking of which: | The connection between the language in which we think/program and the | problems and solutions we can imagine is very close. For this reason | restricting language features with the intent of eliminating programmer | errors is at best dangerous. -- Bjarne Stroustrup Michele -- A painting in a museum hears more ridiculous opinions than anything else in the world. - Edmond de Goncourt
Re: statement_controlfoo()
On Wed, 30 Nov 2005, Piers Cawley wrote: $fh = open '', 'quotefile' or fail; $fh.print 'EOQ' Hmmm... 1/sqrt(2) * ( |Perl5 + |Perl6 ) ? ;-) (I thought '' C. were gone...) Michele -- We can only see a short distance ahead, but we can see plenty there that needs to be done. - Alan Turing
Re: type sigils redux, and new unary ^ operator
On Wed, 23 Nov 2005, Peter Scott wrote: It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n. IMHO the former is much more useful and common. Mathematically (say, in combinatorics or however dealing with integers) when I happen to have to do with a set of $n elements chances are to a large extent that it is either 0..$n or 1..$n; 0..$n may lead to confusion since it it actually has $n+1 elements. Michele -- My fiancee asked me to do invitations, and she's going to get it done the right way -- the TeX way. Good choice. One would never want to go through the same thing again for a divorce. Better than rings and vows. - David Kastrup in comp.text.tex, Re: Simple Wedding Invitations in LaTeX2e
Re: implied looping (was: Re: type sigils redux, and new unary ^ operator)
On Wed, 23 Nov 2005, Ruud H.G. van Tol wrote:
for ^5 { say } # 0, 1, 2, 3, 4
The 'for' can go if a list (and also an array) would imply looping, when
it is positioned next to a block:
a. say (0..4);
b. { say; say } (0..4);
I'm not really sure: while I like it for its conciseness -and in
particular I've often desired a very short, but clear, way to say: do
this #n times- IIUC (Perl6 new rules for blocks/closures and
dereferencing) this is only one dot or even whitespace away from passing a
list into an anonymous sub. Which may be confusing after all...
The problem (if any!) does not persist for the postponed block form. But
as far as code like
^5 { do_it };
is concerned, it is even _too_ concise, and I'd prefer some additional
syntactical indication about what's going on. For my tastes,
^5: { do_it }; # But then also 5: { do_it }; [*]
would be perfect, were not the colon already taken for a bazillion other
uses...
OTOH if I remember correctly there should be (provision for) a Cxx
variant that takes a closure and executes it over and over again.
[*] Or 5 - { do_it }; but I strongly suspect this would interfere with
pointy subs.
Michele
--
I am a deeply religious nonbeliever.
This is a somewhat new kind of religion.
- Albert Einstein
Re: statement_controlfoo() (was Re: lvalue reverse and array views)
On Mon, 21 Nov 2005, Larry Wall wrote: I would like to publicly apologize for my remarks, which were far too harsh for the circumstances. I can only plead that I was trying to be far too clever, and not thinking about how it would come across. No, to be perfectly honest, it was more culpable than that. I had a niggling feeling I was being naughty, and I ignored it. Shame on me. I will try to pay better attention to my conscience in the future. Oh, I'm not the person you were responding to, and probably the less entitled one to speak in the name of everyone else here, but I feel like doing so to say that in all earnestness I'm quite sure no one took any offense out of your words. Despite the slight harshness, they're above all witty. Just as usual: and that's the style we all like! Michele -- La vita e' come una scatola di cioccolatini: un regalo banale. - scritta su un muro, V.le Sabotino - Milano.
Re: This week's summary = Perl 6 perlplexities
On Tue, 15 Nov 2005, The Perl 6 Summarizer wrote: Perl 6 perlplexities Michele Dondi worries that the increase in complexity of some aspects of Perl 6 is much bigger than the increase in functionality that the complexity buys us. In particular Michele is concerned that the Perl 6 parameter passing and signature stuff is going to be a big loss. People mostly disagreed with him. Rob Kinyon made a remark that chimed strongly To be sure, I never intended to claim that signature stuff is going to be a big loss, and I hope that I didn't. First of all I chose it solely as an example. Then the sense that I was trying to convey is that 90% of what has already been stuffed in it will already be the best thing since sliced bread, and that trying to fit the remaining 10% of all fancy types of parameter passing may not really make it better hence resulting in a _possible_ loss. Michele -- premature optimization is the root of all evil - Tad McClellan in clpmisc, Re: Whats the variable holding the dir seperator?
Re: What's the latest on Iterators?
On Sat, 12 Nov 2005, Larry Wall wrote: For example, this is guaranteed to have the side effect of running out of memory before it starts to print anything: print **1...; Speaking of which I wonder if it can be detected and cause an error to be emitted. Which is to say, if it is possible for the compiler to determine that a list is potentially infinite (i.e. no stopping mechanism, e.g. a last is present anywhere[*]) and being flattened at the same time. Since there may be some convoluted and intricated way to stop it, of course there should also be a pragma to locally disable the feature, of course... [*] Of course there may still be some code (boiling down to something) like last if 0; and the list would still be infinite and exhaust memory like the above, but one cannot expect the compiler to be smart enough to detect (all) cases like that, as fundamentally I think it reduces to the halting problem. Michele -- Shit Happens! - the predator, Predator 2 (1990)
Re: proposal: rename 'subtype' declarator to 'set'
On Fri, 11 Nov 2005, Eric wrote: I think 'subset' might be a nicer colour for this bikeshed. For an [snip] Ehh. By that definition arn't all sets subsets? Anyway I didn't see It depends on the axiomatic model of your choice. Speaking of which it is perhaps not terribly OT to discuss here which one to mimic for Perl6 -provided that it is sensible/advisable/useful to mimic one axiomatic set theory at all-: a class based one (a' la Goedel-Bernays) or a Universe based one? Michele -- The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. - Ninety-Ninety Rule
Re: Test Case: Complex Numbers
On Fri, 11 Nov 2005, Jonathan Lang wrote: That wasn't the intent; the intent was to define a something-or-other Ccomplex that represents the fact that whatever does this sometimes behaves like a complexRectilinear and other times behaves like a complexPolar. Even the underlying information (the attributes involved) may vary from role to role, though what those attributes represent ought to be the same regardless of which role is in use. I must say that I didn't follow the discussion very much. But this makes me think of this too: the two representations are handy for different calculations. It would be nice if they somehow declared what they can do better (or at all) and have the union take care of which one's methods to use. In another situation, one may implement a system for doing integer arithmetics say in base twelve, and in this case one may have an union to decide to use its .division() method to perform division by three, possibly holding a flag telling that the most accurate status is that held in it. Michele -- Caro Bongo questa ? la civilt?: hai tutto quello che non vuoi, quando non ti serve. - Toto' Tarzan
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Fri, 4 Nov 2005, Juerd wrote: Whatever, the new system by contrast seems to me to be at least 400% more complex, but it won't buy me 400% more functionality. It will buy you 400% in saving typing, 4000% in less debubbing and 4% in maintainability(==readability). Of course drawing any figure on such loose terms as I did in the first place is not serious and I didn't meant it to be, using them more for illustrational purposes reflecting my own perception. But the point is: are you sure that you have a 40k% gain in readability? That's quite a number!! And the impression I have, that I'm trying to stress once more (but the last time!) is that trying to stuff everything in the signature system is not increasing it any more and that a _slightly_ simpler one would do instead. On Fri, 4 Nov 2005, Rob Kinyon wrote: So, for a bit of extra complexity, I get peace of mind for myself and my users. The point being, and I'm stressing it once again but no more than once, that maybe we're adding two bits of extra complexity, whereas just one bit not only would have been enough, but would have bought you even more peace of mind. Then again: this is a _feeling_ I got e.g. by reading the appearently endless discussions about the specifications of sub parameters, which seem to ensue inherent technical difficulties having to do with the attempt _conciliate_ too many different paradigms. Michele -- If memory serves, Prof. Hermann Zapf considered using Palatino for his wedding invitation (but reconsidered and used one of his wife's designs instead --- there's a lesson in that I guess). - William Adams in comp.text.tex, Re: Simple Wedding Invitations in LaTeX2e
Re: This week's summary
On Fri, 4 Nov 2005, The Perl 6 Summarizer wrote: Slightly tangentially to this, Dan Sugalski blogged a couple of weeks ago about his successes and failures with Parrot. The comments are worth reading -- there's a fair few more or less well founded complaints about the way the Perl 6 project has been managed, many of which seem already ^^^ ^^^ to have been addressed. Certainly the design process is rather more visible now. Comments that made me thought about the need for the verb to damanage, when I first read them! ;-) Michele -- Did I get that right? I know what I said, but I don't see how I can answer questions about how it seemed to you. Such propositions are independent of my axioms. - Dave Seaman in sci.math, Re: Is zero even or odd?
Re: $_ defaulting for mutating ops
On Wed, 2 Nov 2005, John Williams wrote: surprises including operandless operators. Including mutating operandless operators. What is s/// after all? Or is there a good reason for an asymmetry between different classes of operators? Well, s/// is a term, for one thing. It is not so much an operator, as it is a subroutine with really strange syntax, and the side-effect of changing the $_ variable. You need to use an operator to get it to affect a different variable. While others have pointed out that this is not that much of a difference from a strictly technical pov, I'll say that this is a good point! But since I _still_ like the proposal, differently from the person who made it in the first place, maybe consistency could be re-gained allowing the smart match operator to perform esoteric forms of mutation, e.g. $var ~~ ++; # Ouch, and how 'bout $var++ instead? ;-) At least this would help in the direction of curing the fear that P6 won't be just as suited for obfuscation as P5 is... Michele -- I agree with Tore; it's sort of a Zen question. If you have to ask, it means you won't understand the answer. If you know enough to understand the answer, you won't need the question. - Joe Smith in clpmisc, Re: Perl neq Python
Re: $_ defaulting for mutating ops
On Wed, 2 Nov 2005, Rob Kinyon wrote: I think the difference comes from the Principle of Least Surprise. The various operators being discussed in this thread are all operators which are in languages that have common use - C, C++, Java, the .Net stack, etc. Regexen and the various built-ins are generally considered to be Perl-specific, so if they're weird, this is just a Perl-ism. The PoLS doesn't apply. I still don't buy the argument. At least in principle PoLS does apply for a newbie may be surprised to know that certain operators act implicitly on $_ and certain other don't. And yes: there are lots of languages having (e.g.) a ++ operator, mostly derived from C. But Perl's C++ already allows an extended syntax wrt that of those other languages, that is: I'm not really sure, but I don't think that in C you can do (the equivalent of) C($u*=5)++ - not that you need it that often, granted! But it is backwards compatible with the standard usage. Now letting aside other reasons why the proposal should not be accepted, if it where, it would not be disruptive of current behavior. You could have $_++ *and* bare ++. And newbies learn early enough that $_ is the implicit topicalizer in Perl; moreover ++ will still look intuitively enough like the incrementing op. So I think it won't be that difficult for them to understand what's going on, the biggest remaining doubt being whether it's ++$_ or $_++. But that's just, say, a clpmisc or PM post away and anyway it will be in the docs (no, I know it won't, but that's not the point...) Yes, from a consistency point of view, ALL operators should default to $_ or some other sensible item ($*STDIN for , etc). However, the PoLS does need to guide our decisions. Hmmm, it's so difficult for me to keep up with P6, but I *think* has been phased out in favour of prefix unary C=. Michele -- you look around what do you see? I'll tell you what I see is a world belonging to me - Pennywise, Living For Today.
Perl6 perlplexities [was: Re: $1 change issues...]
On Thu, 20 Oct 2005, Nate Wiger wrote:
just to be sure we're on the same page: You say that the thing that
is going to hinder migration to Perl 6 is the fact that it's different
from Perl 5.
Intentionally trite oversimplification. My problem is that it's
different in some ways which are not truly useful, and that cause
unnecessary relearning/rewriting/incompatibilities.
I've waited long before answering this mail because I wanted to see more
along the way of the Perl6 fears thread.
Now the observation above gives me a chance to express my own
perlplexities. I'm not bothered by the changes in themselves nor am I
concerned by the necessary (or not)
relearning/rewriting/incompatibilities.
thepoint
But there's an observation I can't help doing: it seems to me that the
ratio of increase in the complexity of (some aspects of) the language _is_
_much_ _bigger_ than that in the functionality such complexity is supposed
to provide.
/thepoint
Let me explain: we all know that Perl5 has a very simple parameter passing
mechanism for subs and an even more rudimentary {prototyping,signature}
mechanism that one actually seldom uses. With this simple mechanism one
can implement or fake quite a lot of parameter passing paradigms.
It seems to me that this covers at least 90% of one's common needs. But
for simple subs in Perl6 I will probably still use @_; err... that or the
new pointy subs which are indeed so cool! Whatever, the new system by
contrast seems to me to be at least 400% more complex, but it won't buy me
400% more functionality.
Quite similarly the old OO support was so light to the point of being
immaterial, so that many people even thin it plainly sucks. But in
retrospect it was amazing to note how many OO paradigms and techniques one
coudl get out of simple, tiny, appearently innocent function called
bless()! Of course these implied lots of workarounds and hacks, be them
damn sexy hacks, but hacks: ok, granted! But the new system is what? 10k%
more complex? The question is: does this buy me all that 10k% more
functionality, or would have been a _simpler_ design, say only 1k% more
complex be enough?
It is always amazing, both in a programming language (or CS) context and
in totally unrelated ones, when from a simple scheme you can draw a rich,
huge set of consequences. But of course is not in Perl's nature an aim for
extreme simplicity; nothing to say... Perl5 is full of inconsistencies
in the form ad hoc dwimmeries and magic, while Perl6 already cures them by
trying to make them into structural magic of a globally more coherent
and consistent framework. But it's still my impression that it's pushing
in quite _too_ much structural complexity as well.
This is fundamentally the _only_ perlplexity about Perl6 I have...
Of course this is only a meditation and I know that I'm not knowledgeable
enough to be fully aware of all the implications of some aspects I've
touched upon in this writing, and thus I'm not expecting it to change or
influence the direction of evolution of language (re-)design. Just wanted
to let you all know.
Michele
--
Ira Kane: You wouldn't understand.
Dr. Allison Reed: No, how could I? I'm just a humorless ice queen in
desperate need of a good humping.
Ira Kane: Oh... you heard that, huh?
Dr. Allison Reed: Loud and clear.
- Evolution, Ivan Reitman
Re: Perl6 perlplexities [was: Re: $1 change issues...]
On Fri, 4 Nov 2005, Juerd wrote:
for simple subs in Perl6 I will probably still use @_
You'd be a fool to do so, with the sole exception of list manipulation,
[snip]
Compare:
sub dosomething { @_[0] blah @_[1] }
sub dosomething ($a, $b) { $a blah $b }
sub dosomething { $^a blah $^b }
Ouch! I take back my words... (should've thought of it better!)
The @_ solution is really the most ugly and hard to type of the three
possibilities.
I currently only rarely use @_ *directly*. I Cshift and assign a lot
instead. Indeed both are still unnecessarily complex and I once gain take
back my word.
I'm still convinced my remark _partly_ applies in the sense that the
overall impression is that a vast majority of most common needs is
addressed by a *subset* of the current features and trying to stuff all
them in has brought in quite a lot of discussions of which I'm not even
sure if they've all settled down.
Michele
--
[are there] Any areas of mathematical knowledge or skills that we lost?
Yes, but I don't remember what they are.
- Kevin Foltinek in sci.math [edited]
Re: syntax-variants, RPN (was: Re: $_ defaulting for mutating ops)
On Wed, 2 Nov 2005, Ruud H.G. van Tol wrote: http://www.nntp.perl.org/group/perl.perl6.language/17556 I understand that Perl6 allows blocks with changed/enhanced syntax, so it is or will become possible (to add it) as if it was in the core language. Do I understand that right? Something as simple as a 'use RPN' in a block? (assuming that someone created such an RPN-pre-processor or -compiler) Indeed this is what that we all know. Of course the possibility of doing so will depend on the possiblity of building up suitable RPN syntax consistent with the rest of the syntax. Michele -- E' molto piu' facile affrontare il lutto, il disonore e la perdita della propria anima - che questo tipo di fame prolungata. - Joseph Conrad, Cuore di Tenebra.
Re: $_ defaulting for mutating ops
On Thu, 3 Nov 2005, Sam Vilain wrote: That being said, there are probably other more pressing reasons that ops should not accept $_ as default; I would guess, for a start, it makes determining semantics very difficult. Does ++; mean postfix:++ or prefix:++ ? If we had it, I think we would be more interested in it for incrementing $_ than for its return value, so it wouldn't make such a huge difference. However I find myself using $var++ much more often than ++$var, and I'm biased to think this is the general situation: if it is actually so, then the choice should fall on the former. If my impression is just a personal artifact... oh, don't mind! Michele -- Billy: I'm scared Poncho. Poncho: Bullshit! You ain't afraid of no man! Billy: There's something out there waiting for us, and it ain't no man. We're all gonna die. - Predator (1987)
Re: $_ defaulting for mutating ops
On Fri, 28 Oct 2005, Ruud H.G. van Tol wrote: Or RPN-like: $x #= 2* 1+ 3/; Being a big fan of RPN myself (and considering it quite natural), I'd appreciate very much such a feature. I had asked myself about RPN features in P6, albeit in a probably unreasonable fashion: http://www.nntp.perl.org/group/perl.perl6.language/17556 Michele -- [about penis-enlargement spam] Suppose you (applies to male readers only!) had taken advantage of every offer of the above type received, and all had worked as claimed. Estimate how long it would be. - Derek Holt in sci.math (slightly edited)
Re: should roles be parameterized?
On Sat, 29 Oct 2005, Christopher D. Malon wrote: For the non-mathematically inclined: A field is a set with two binary operations, + and *. Under either operation (+ or *), the set is an abelian (= commutative) group, and a field has a distributive property: a * (b + c) = a*b + a*c. An easy example is the set of real numbers, with + being addition and * being multiplication. Not exactly. With the exception of _the_ trivial case (up to a natural isomorphism there's only one!) a field is _not_ a multiplicative group wrt its multiplication, given that the identity for the addition can't have a multiplicative inverse. This is of some relevance of so called Universal Algebra in which some commonly used structures (e.g. a group, a ring) can be described in terms of sets of n-ary operations obeying a set of algebraic identities, whereas certain other just as common structures (e.g. a field) can't - and a more complex approach is needed. This may be of some interest here too, since there's been some talking about the algebra of methods of a role that any class which Cdoes that role guarantees to obey by doing so. So this should take into account the possibility of algebrai relations not defined everywhere, which may bring a new level of complexity in realistic situations... Michele -- I'm finding now in my 40s that the less makeup I wear, the better. I think softer is better as you get older. With everything. Except men. - Kim Cattrall
Re: $_ defaulting for mutating ops
On Fri, 28 Oct 2005, John Williams wrote: But IMHO the reduction in typing for this relatively minor issue is not really worth the surprise to newbies at seeing operandless operators. I don't buy that argument as newbies are already exposed to all sorts of surprises including operandless operators. Including mutating operandless operators. What is s/// after all? Or is there a good reason for an asymmetry between different classes of operators? Michele -- = (But it is impossible to even imagine an operating-system which would = not crash before the sun has burned all of its hydrogen, let alone not = crash before the end of the universe.) I find it hard to imagine an operating system which would not crash before the end of the week - Gerry Myerson in sci.math
Re: crossing lists
On Thu, 27 Oct 2005, Darren Duncan wrote: Not sure if this matter was resolved on a previous discussion, but here goes Definitely is has been discussed at least once, that I know, for I asked this myself, but from a somewhat more mathematical pov. You can find a copy of my mail here: http://www.nntp.perl.org/group/perl.perl6.language/17807 What I'm not yet sure about is whether this would be better as something resembling the zip() operator or a hyper-operator. Definitely it's somthing different from zip() as the latter is more the computational incarnation of the mathematical (category theoretical) concept of a coproduct, whereas the missing operator would be that of a product. Michele -- * Non ? per te, ? per Mariangela. Le si ? fermato il ciclo. * Le si ? rotta la bicicletta! Ma che stiamo a fare una tragedia? * Non ce l'ha pi?! * Glielo hanno rubato? Ma Porca puttana! - Fantozzi subisce ancora
Re: Ways to add behavior
On Wed, 26 Oct 2005, Rob Kinyon wrote:
I'd like to take this moment and point to my somewhat hand-wavy
metamodel proposal from last week. When Stevan and I were talking
about this, we called it a quark. Atom also works quite nicely,
but quarks are cooler.
They're also colorful. Does this mean we will have a colour trait? But
most importantly, who is supposed to be $Muster_Mark?
Seriously, quark was originally chosen as a name because of the
appearance of _three_ (somewhat mysterious) objects. Now it would
indeed be cool to borrow the term in a CS context, especially in Perl, but
it would be better suited in a naturally ternary (say,
{property,structure}-wise) context.
Michele
--
Il tempo e' denaro, ma anche il denaro e' denaro.
- William Gibson, L'accademia dei sogni.
Re: txt vs OO [was: Re: Proposal to make class method non-inheritable]
On Tue, 25 Oct 2005, Larry Wall wrote: But we're trying to design the OO features (indeed, all of Perl 6) such that you can usefully cargo cult those aspects that are of immediate interest without being forced to learn the whole thing. It's not the number one design goal, but it's right up there. So you're talking about a positive, tame form of cargo cult, giving the latter a good name... Michele -- you need a brain hack. or a brain of any sort. try a nematode first. the small incremental improvement won't be such a shock. then you can graduate to segmented worm brains. - Uri Guttman in clpmisc, Array Sort Using Regex Matching Fails
Re: Perl 6 fears
On Mon, 24 Oct 2005, H.Merijn Brand wrote: FEAR: Perl6 will not be able to fix the stigma of just a scripting language or line noise perl5 has never been just a scripting language But sadly enough it is often _perceived_ as such. And also like line noise, as the person you're answering to correctly states: an opinion we all beg to differ, I suppose, but a widespread one indeed... Michele -- you'll see that it shouldn't be so. AND, the writting as usuall is fantastic incompetent. To illustrate, i quote: - Xah Lee trolling in clpmisc, perl bug File::Basename and Perl's nature
txt vs OO [was: Re: Proposal to make class method non-inheritable]
On Fri, 14 Oct 2005, Stevan Little wrote: I think Perl 6's OO system has the potential to be to OO programming what Perl 5, etc was to text processing. This, I believe, is in large part due to Sorry for replying so late. Thought it seems appropriate to post this in this time of Perl 6 fears and rants threads... Well, the point is that it is interesting to note that text processing is an _application area_, whereas OO programming is a programming language paradigm. Despite the intro above, this is not meant to be a rant or to express a fear. But it is intended to raise a meditation. After all, being known for text processing capabilities may be somewhat restictive and not faithful of Perl's (including Perl 5) full potentiality, but OO programming is somewhat immaterial either, the only relevance being the suitability for big projects management. Michele -- Ira Kane: If I was a giant nasty alien bird in a department store, where would I be? Harry Block: Lingerie. Ira Kane: Not you, the bird. Harry Block: Lingerie. - Evolution, Ivan Reitman
Re: $_ defaulting for mutating ops
On Tue, 25 Oct 2005, Rob Kinyon wrote:
On 10/25/05, Juerd [EMAIL PROTECTED] wrote:
I think it'd be great if +=, ~=, +=, ++, etc, could all assume $_ on
their LHS when there is no obvious operand.
[snip]
Especially bare ++ would be useful, I think.
Did you post this specifically to anti-address the fear that P6 will
be more line-noise-ish than P5? :-p
No, to address the fear that P6 won't be just as suitable for
{obfuscation,golfing} as P5 is and that it would spoil those cultures.
Incidentally I think it'd be great too.
Michele
--
Free software, not just Linux, is a major problem for Microsoft.
It's a big mistake thinking they don't understand free software, or its mechanics.
They understand it all too well, and they don't like it - not one little bit!
- Eddy Macnaghten
Pronouns [Re: $_ defaulting for mutating ops]
On Tue, 25 Oct 2005, Juerd wrote:
Reducing line noise isn't my goal, though. I feel that the implicit
defaulting to $_ makes Perl a more natural and elegant language, and
would like this principle being extended to these operators.
Indeed, both the implicit defaulting to $_ AND the availability of $_
itself. Which occasionally makes me desire even more pronouns. After all
in a natural language like English we have 'it', 'them', 'we', etc... now
it's obvious that
(i) we can't hope nor desire a full correspondence,
(ii) there _already_ are some analogues of _some_ of the above, but
somewhat more limited in usefulness wrt $_.
Now, one that I've sometimes desired is a two level $_, i.e. a variable,
say, $__ referring to the _second next_ enclosing lexical scope. I am
aware that in this vein one may ask a third analogue and so on, but let's
face it: $_ already covers 95% of cases, my hypothetical var would cover I
guess a remaining 4.5% of cases, and who cares for the rest? E.g.:
for @vert {
put_point $_, $__ for @horiz;
}
Note: I am aware that P6 will already provide other ways to do it, but
this is not in contrast with Perl's TMTOWTDI-ness. I expect it to be
useful enough in nested {map,grep}'s.
Michele
--
you look around what do you see?
I'll tell you what I see is a world belonging to me
- Pennywise, Living For Today.
Re: Pronouns [Re: $_ defaulting for mutating ops]
On Tue, 25 Oct 2005, Juerd wrote:
Michele Dondi skribis 2005-10-25 17:05 (+0200):
Now, one that I've sometimes desired is a two level $_, i.e. a variable,
say, $__ referring to the _second next_ enclosing lexical scope. I am
aware that in this vein one may ask a third analogue and so on, but let's
face it: $_ already covers 95% of cases, my hypothetical var would cover I
guess a remaining 4.5% of cases, and who cares for the rest? E.g.:
for @vert {
put_point $_, $__ for @horiz;
}
I find $__ confusing, and prefer $OUTER::_, which already exists.
Hmmm... maybe you're right that $__ is too huffmanized (and hence
confusing) but $OUTER::_ is somewhat too few...
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, Re: Who is Green?
Re: txt vs OO [was: Re: Proposal to make class method non-inheritable]
On Tue, 25 Oct 2005, Stevan Little wrote:
Well, the point is that it is interesting to note that text processing
is an _application area_, whereas OO programming is a programming
language paradigm.
Allow me to clarify.
Perl 5 (and below) are known by outsiders (non-perl users) as being a really
good language for processing text. Ask any friend you know who has had little
or no exposure to Perl and they will probably tell you this. Of course they
will also tell you that it is all line noise, etc, etc etc. This is the most
common perception of Perl by those people who have (for the most part) never
encountered it.
ack!
I think that Perl 6 may become like that for OO. When people who have never
used or encountered Perl 6 talk about it, they will say, I've never used it,
but I hear it has lots of really cool OO features. Just as now they the same
thing re: text-processing.
I see your point. And I admit I slightly misunderstood you. In any case
people who don't know Perl and think it's great for text processing may be
eventually become interested in it if they will have to do... ehm... text
processing.
But even if Perl will gain a name for it's cool OO features, will it
become an actual interest for someone if he/she has to do... OO stuff?!?
The basic idea being that one is attracted by a language or another if its
features are well suited for some specific application he/she has in mind.
Not for its features as an abstract thing.
Also, Perl6 OO capabilities are already above the top of my head. But
maybe that's just me. Whatever, I guess that the {casual,average}
programmer may be scared by its richness and complexity.
After all, being known for text processing capabilities may be somewhat
restictive and not faithful of Perl's (including Perl 5) full
potentiality,
Of course not, Perl is also used for CGI, but you can do that better with
Java now (which is a real language cause it's compiled)
Of Perl is IMHO even _too_ known for CGI.
but OO programming is somewhat immaterial either, the only relevance
being the suitability for big projects management.
The idea that OO is only relevant for big projects is just as silly as saying
that Perl is only good for text processing.
ack. I was oversimplifying.
Sure I would not use OO to write a small utility script, but the modules I
access in the script would probably be written using OO. And those may be
very small modules too, but their re-usability is greatly enhanced by various
OO features (encapsulation, ability to compose-into or use within another
class, etc etc etc). This kind of thing (IMHO) is why so many people are
being drawn to Python and Ruby. Hopefully Perl 6 can draw them back.
Also, some methods will be very handy even for non-patently-OO blocks,
e.g. the .pos() one which will replace the somewhat ad hoc pos() function
or the .subst() one (or whatever it is called, I can't remember exactly)
which hopefully will get rid of the why doesn't s/// work inside a map()
question...
Michele
--
Have you ever stopped to consider that what is crashing
your Perl is sitting between the keyboard and chair?
- Sherm Pendley in clpmisc, Re: Perl IDE (edited)
Re: Pronouns [Re: $_ defaulting for mutating ops]
On Tue, 25 Oct 2005, Juerd wrote:
for (1..9) - $n { # ought to be more than enough
eval qq[
macro prefix:\$_$n { \${ OUTER:: x $n }_ }
];
}
And then you can use $_1 .. $_9. I think $_1 is much clearer than $__,
but I think neither is needed in the standard language.
Can I beg to differ any more? (Implicit answer: no, I can't!)
Michele
--
The trouble with engineers is that given the problem of knocking down
a stack of 100 bricks, they will start at the top, and work all
day removing them one at a time, while the mathematician will, after
a momemt's thought, remove the bottom brick and be done with it.
The trouble part, is having to brook the noise of the engineer
boasting about how much harder he worked while one is trying to
think about the next problem.
- Bart Goddard in sci.math
Re: new sigil
On Sat, 22 Oct 2005 [EMAIL PROTECTED] wrote: If we find a lot of yen signs as zip-operators in the standard library, Japanese would have a big question: Give up either Perl6 or Windows. Which do we need? And I suppose the answer Hmmm, begins to sound interesting... ;-P Michele -- voices you're letting voices tell you what to do when you yourself don't know - Pennywise, Come Out Fighting.
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, 20 Oct 2005, Luke Palmer wrote: Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to Perl 6 from some non-Perl 5 language is going to be more comfortable with dot. (Also, I did like the arrow notation, but) how cool would be @cool=grep -cool, @misc; # if compared to @cool=grep .cool, @misc; # ? Michele -- Jack Burton: This is Jack Burton in the Pork Chop Express, and I'm talkin' to whoever's out there. - Big Trouble in Little China (1986)
Re: Y [was: Re: new sigil]
On Thu, 20 Oct 2005, Rutger Vos wrote: _one_ charachter. But Y, compared to ¥, is one charachter only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the official one?!? Do you even need to ask? It's because it *looks cool* :) Does it? Guillemets _do_ look kool, but I don't by the argument for the Yen symbol... Michele -- Is e+pi a rational or irrational number? Yes, it is. - Robert Israel in sci.math, Re: A Number Problem
Y [was: Re: new sigil]
On Thu, 20 Oct 2005, Juerd wrote: All non-ASCII operators have ASCII equivalents: ¥ Y « » Speaking of which the advantage of, say, « over is that the former is _one_ charachter. But Y, compared to ¥, is one charachter only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the official one?!? Michele -- Commander Helena Braddock: So, where is everybody? Melanie Ballard: Yeah, Friday night, the whole place should be packed. A whole twelve hours before sun up and there's money to burn, whores to fuck and drugs to take. - Gosts of Mars (2001)
Re: new sigil
On Thu, 20 Oct 2005, Larry Wall wrote:
: c| or C| maybe.
[snip]
: if $foo eq c|d { ... }
Other suggestions welcome.
| maybe? And what will we make | do?
Michele
--
Se non te ne frega nulla e lo consideri un motore usa e getta, vai
pure di avviatore, ma e' un vero delitto. Un po' come vedere un
cavallo che sodomizza un criceto!!!
- Cesare/edizioni modellismo sas in it.hobby.modellismo
Re: zip: stop when and where?
On Tue, 4 Oct 2005, Eric wrote: I'd just like to say that I find B a bit misleading because you couldn't tell that the first list ended, it could just have undef's at the end. I Well, OTOH undef is now a more complex object than it used to be, so there may be cheap workarounds. Of course one would still like reasonable defaults and dwimmeries on commonly used idioms... Michele -- Darl MacBride, is that you? They said over at Groklaw that the folks at SCO were trying to discredit Open Source. SCO, a company traditionally run by Mormons, but they had to downsize the second m? Well, they still have M for capital. - David Kastrup in comp.text.tex, Re: Is Kastrup...
Re: my $key is sensitive;
On Tue, 4 Oct 2005, Rafael Garcia-Suarez wrote: language like C. So, such a sensitive modifier could be added, but its precise meaning would be highly dependent on the underlying implementation. It would be of interest more to a perl programmer than to a Perl programmer. Like keys() as an lvalue in Perl5. Michele -- Having taken a look at that: bleech. Thanks for the constructive feedback Ben. :-) - Paul Marquess to Ben Morrow in clpmisc
Re: Sort of do it once feature request...
On Wed, 21 Sep 2005, Joshua Gatcomb wrote: I have mocked up an example of how you could do this in p5 with some ugly looking code: You may be interested to know that this has had an echo at http://www.perlmonks.org/index.pl?node_id=493826 mostly misunderstood in the replies, IMHO. Basically the idea is that not unexpectedly if you want a workaround TIMTWOWTDI already in Perl5. But what is conceptually interesting would be the possibility, In L~R's much better phrasing than mine, of modifying the optree or (P6's equivalent) as the code is running. The only ad-hoc solution given there that is really along these lines is Diotalevi's one at http://www.perlmonks.org/index.pl?node_id=493947 which -not completely undexpectedly either- made my head hurt... ;-) Michele -- Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote.
Re: Sort of do it once feature request...
On Wed, 21 Sep 2005, Joshua Gatcomb wrote: Cheers, Joshua Gatcomb a.k.a. Limbic~Region Oops... I hadn't noticed that you ARE L~R... Michele -- Your ideas about Cantorian set theory being awful suffer from the serious defect of having no mathematical content. - Torkel Franzen in sci.math, Re: Die Cantor Die
Sort of do it once feature request...
Every time I've desired a feature for Perl6 it has turned out that either
it was already planned to be there or I have been given good resons why it
would have been better not be there.
Now in Perl(5) {forum,newsgroup}s you can often see people doing stuff
like
my @files=grep !/^\.{1,2}/, readdir $dir;
Letting aside the fact that in the 99% of times they're plainly
reinventing the wheel of glob() a.k.a. File::Glob, there are indeed
situations in which one may have stuff like
for (@foo) {
next if $_ eq 'boo';
# do something useful here
}
whereas they know in advance that Cif can succeed at most once (e.g. foo
could really be Ckeys %hash).
Or another case is this:
while () {
if (@buffer MAX) {
push @buffer, $_;
next;
}
# ...
shift @buffer;
push @buffer, $_;
}
in which one wouldn't like the Cif condition to be tested any more after
it first evaluated false. Now efficiency is seldom a real issue in all of
these situations, and in the rare cases in which it is one may adopt
alternative strategies, like prefilling @buffer (with apparent referal to
the previous example). In some cases one could need refactoring into subs
to avoid duplication of code, but then the original logic may have been
more clear intuitively to start with...
Whatever, I feel slightly uncomfortable psychologically with the idea of
something that will be tested even when it's not necessary. So now I
wonder if Perl6 is already expected to provide syntactical sugar enough to
do what I want: which something easy enough to type to make a portion of
code (behave like it) silently evaporate(ed) after a condition has been
verified for the first time (or, say, n times). I think this is similar
to the functionality of macros, but as I said, this should be -to be
really useful- only a moderate bunch of keystrokes away from the code that
doesn't employ it...
Michele
--
I just said it was my conjecture. That doesn't mean I think it's right. :-)
- Larry Wall in p6l, Subject: Re: What do use and require evaluate to?
How 'bout .ortho, .para? [was Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)]
(Sorry for replying _so_ late...) On Tue, 9 Aug 2005, Larry Wall wrote: I kinda like Autrijus's idea that meta just means guts. In classical Greek, meta just means with. The fancy philosophical meaning of aboutness isn't there, but is a backformation from terms such as metaphysics. Metaphysics is just what you study along with physics. Well, I have always been told that the bakinformation regards the term metaphysics coming from the title of the related book by Aristotle, which in fact happened to have that title because it came _next to_ the physics one... More on topic, a pun on other prefixes (especially in the context of Chemistry) suggests we may have .para, .ortho, as well? Could we find a semantic meaning for them? They may have to do with classes behaving parallely (both subclasses of a class higher in hyerarchy?) or othogonally (guaranteed to take actions in full independence of the current one) to .meta; well, it was just an idea... Michele -- i need to know what type of math and how much math a surgeon uses. How about asking what type of surgery and how much surgery a mathematician uses? - Robin Chapman in sci.math
Re: Messing with the type heirarchy
On Wed, 27 Jul 2005, [ISO-8859-1] TSa (Thomas Sandla?) wrote: value to carry on a useless imaginary part. And Complex should consistently return undef when compared to other Nums or Complexes. And the Compare role My 0.02+0.01i: in mathematics it is commonly used to write e.g. z3 to mean z is real AND as a real number is less than 3. Michele -- Might I suggest you take nice strong draught of hemlock before you post again? I think we'll all be much better off... You are besmearing the memory of Sokrates. - David Kastrup in comp.text.tex, Re: Is Kastrup...
Re: User-defined infix subs/methods?
On Wed, 13 Jul 2005, Ingo Blechschmidt wrote: no, if I understood Larry correctly, you can of course write a nice grammar-modifying module, but other modules you use() still use Perl 6's standard grammar. E.g.: Ah, then of course I would have never expected things to be different at all. If you wanted the compiler to parse SomeOtherModule.pm using Ruby's grammar, you'd have to write: use Grammar::Ruby; reuse SomeOtherModule So that, after all, I don't think it would be much used since if SomeOtherModule was thought to be parsed according to Grammar::Ruby, it would take care of using it in the first place, I guess. Unless, of course, SomeOtherModule could be parsed correctly -and hopefully behave differently- under two or more different grammars, in which case it would be funny to see the effects of, say, use Grammar::Ruby; reuse SomeOtherModule; use Grammar::hq9plus; reuse SomeOtherModule; # ... which reminds me of good'ol' GEB... Michele -- Never attribute to malice that which can be adequately explained by stupidity - Hanlon's Razor
Re: User-defined infix subs/methods?
On Tue, 12 Jul 2005, Larry Wall wrote: Good, I'd forgotten about that. Which means that it's even harder for someone to compile a module in a strange dialect, since they'd essentially have to write their own version of use that forces recompilation (reuse, if you will). And the harder we make it to write reuse, the better. IIUC this will introduce a certain degree of asymmetry though, in that in some sense p6 will be extremely generous in giving users the ability to use whatever dialect/syntax modification they like in their programs but just at the same time it will try to make it hard for them to do so when refactoring code into suitable modules. Ain't it so? Michele -- Either of these mechanisms should be available in IE (after sacrificing a suitable animal to XP SP2, I suppose). - Alan J. Flavell in clpmisc, Re: character encoding in CGI.pm
Re: method calls on $self
On Sat, 9 Jul 2005, Robin Redeker wrote: I wasn't thinking 'cool', I was thinking 'visually distinctive and mnemonic'. I actually think o. is cooler. Yes, i would like o. more too. At least it doesn't introduce a completly meaningless '/' preceded by a '.'. Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_ like it! Thus, how about making '/' less meaningless, i.e. more meaningful, in more general situations?!? Michele -- Bunch of slack-jawed faggots around here! This stuff will make you a god damnned sexual Tyrannosaurus, just like me! - Blain, Predator (1987)
Re: new mailing list: perl6-general?
On Tue, 14 Jun 2005, [iso-8859-2] BÁRTHÁZI András wrote: Where should I ask, that what's PGE means? Yes, I know, it's Parrot Grammar Engine, and I know what it is, but a beginnner maybe not. And I think that Which makes me think that first or later it may be worth to start a FAQ for questions like these even if they're not frequently asked. And indeed a perl6-general may be a starting point for writing one. Michele -- Is e+pi a rational or irrational number? Yes, it is. - Robert Israel in sci.math, Re: A Number Problem
Re: Empty hash
On Thu, 2 Jun 2005, Stuart Cook wrote:
On 6/1/05, Luke Palmer [EMAIL PROTECTED] wrote:
Should {} be an empty hash rather than an empty code?
Given that an empty hashref is probably much more useful than an empty
block, I propose that {} be an empty hash and {;} be an empty block.
Speaking of which, maybe this may be getting in the too-extreme
territory, but taking into account that a hash _is_ a function, it
wouldn't be that bad to blur the distinction between a hash and code, from
a UI perspective. How should one do it? Oh, but then I don't have the
slightest idea...
Michele
--
DAX ODIA ANCORA
- Scritta su diversi muri milanesi
Re: reduce metaoperator on an empty list
On Wed, 1 Jun 2005, Luke Palmer wrote: $ordered = [] @array; If @array is empty, is $ordered supposed to be true or false? It certainly shouldn't be anything but those two, because is a boolean operator. I read that (mathematically) as for all i, for all j such that j-i=1, a_ia_j, which is certainly satisfied by an empty list. Michele -- Why should I read the fucking manual? I know how to fuck! In fact the problem is that the fucking manual only gives you theoretical knowledge which is useless in practice ;) - Giuseppe Oblomov Bilotta in a bunch of usenet groups.
Re: reduce metaoperator on an empty list
On Wed, 1 Jun 2005, Luke Palmer wrote: I read that (mathematically) as for all i, for all j such that j-i=1, a_ia_j, which is certainly satisfied by an empty list. Yep, it sure is. Now tell Perl to read it that way for any operator. Should _I_?!? ;-) I wonder what a logic-oriented programming language a' la prolog would say in this case. Now, Perl6 is supposed to support similar features too - maybe the right(TM) answer could be along that way... Michele -- primordinarily concerned with providing ... Neat word! - Donald Arseneau in comp.text.tex
Re: Sets (was: Reductions, junctions, hashslices, and cribbage scoring)
On Thu, 26 May 2005, Patrick R. Michaud wrote: The continuing exchanges regarding junctions, and the ongoing tendency by newcomers to think of them and try to use them as sets, makes me feel that it might be worthwhile to define and publish a standard CSet class and operations sooner rather than later in Perl 6 development. This might reduce the tendency to confuse junctions I fully second that. You can search the archives for my own thoughts on the subject. Michele -- you'll see that it shouldn't be so. AND, the writting as usuall is fantastic incompetent. To illustrate, i quote: - Xah Lee trolling in clpmisc, perl bug File::Basename and Perl's nature
Re: (OT) Re: Perl development server
On Tue, 24 May 2005, wolverian wrote: Portuguese: cebola Finnish: sipoli Italian: cipolla (since nobody has mentioned it yet) Michele -- It was part of the dissatisfaction thing. I never claimed I was a nice person. - David Kastrup in comp.text.tex, Re: verbatiminput double spacing
Re: (OT) Re: Perl development server
On Tue, 24 May 2005, Herbert Snorrason wrote: Icelandic: laukur (Incidentally, none of you will ever guess how to correctly pronounce that.) Incidentally, would 'laukurdottir' be a proper Icelandic offence? :-) Michele -- Me too. If it's any comfort, just think of the design of Perl 6 as a genetic algorithm running on a set of distributed wetware CPUs. We'll just keep mutating our ideas till they prove themselves adaptive. - Larry Wall in p6l, Re: Adding linear interpolation to an array
Re: Perl development server
On Tue, 24 May 2005, wolverian wrote:
On Tue, May 24, 2005 at 03:44:43PM +0200, Juerd wrote:
But I like the newly suggested feather better, as it can relate to
pugs AND parrot.
Feather is best one thus far, I think. I like carrot too; it's more
playful. I equate Pugs with fun a lot.
Hmmm, but has 'carrot' anything to do with perl6 C any more, well, apart
s/p(?=arrot)/c; # obviously
(BTW: how would that be in p6?)
Also, while I'm not fond of the vast majority of vegetables, I like onions
as an ingredient of many other good meals ('meal' is not the correct
English word for what I mean, but the correct term eludes me ATM). But can
you say the same thing of carrots?!?
Michele
--
I once heard someone say, the sum of the reciprocals
of the known primes is less than 4 - and it will always be.
- Gerry Myerson in sci.math, Re: Summation of Reciprocals of Primes
Re: reduce metaoperator on an empty list
On Wed, 18 May 2005, Matt Fowles wrote:
All~
What does the reduce metaoperator do with an empty list?
Interesting. Mathematically an empty sum is zero and an empty product is
one. Maybe each operator {c,s}hould have an associated method returning
its neutral element for [] to use it on empty lists, so that it would
probably return undef on empty lists.
Just my 2 Eurocents,
Michele
--
It was part of the dissatisfaction thing. I never claimed I was a
nice person.
- David Kastrup in comp.text.tex, Re: verbatiminput double spacing
Re: reduce metaoperator on an empty list
On Wed, 18 May 2005, Rob Kinyon wrote:
1) undef (which may or may not contain an exception), or
2) some unit/identity value that is a trait of the operator,
depending on whether or not people think (2) is actually a good idea.
I would think that the Principle of Least Surprise points to (1),
I don't think so. I, for one, would expect [+]; to return zero and [*]; to
return 1. But that's only because I {trust,expect} perl(6) to be smart
enough to DWIM.
Michele
--
\renewcommand\labelitemi{\textcolor{yellow}{\textbullet}}
would change the colour of the first-level bullet, and improve the
document so's i can't see the bullets.
- Robin Fairbairns in comp.text.tex
Re: Cmmposition binop
On Thu, 5 May 2005, Stuart Cook wrote:
What I refer to now is something that takes two {coderefs,anonymous
subs,closures} and returns (an object that behaves like) another anonymous
sub, precisely the one that acts like the former followed by the latter
(or vice versa!).
Do you mean like the mathematical 'f o g'?
Indeed.
Michele
--
Have you noticed that people whose parents did not have children, also
tend not to have children.
- Robert J. Kolker in sci.math, Re: Genetics and Math-Ability
Re: Perl 6 Summary for 2004-04-26 through 2005-05-03
On Tue, 3 May 2005, Matt Fowles wrote: Perl 6 Summary for 2004-04-26 through 2005-05-03 ^^ ^^ Wow! Michele -- Why should I read the fucking manual? I know how to fuck! In fact the problem is that the fucking manual only gives you theoretical knowledge which is useless in practice ;) - Giuseppe Oblomov Bilotta in a bunch of usenet groups.
Re: reduce metaoperator
On Wed, 4 May 2005, Larry Wall wrote: I propose that reduce become a metaoperator that can be applied to any binary operator and turns it syntactically into a list operator. I second that. By all means! (But I thin it would be desirable to have a 'plain' reduce operator as well) Michele -- The reason I want to do this is that I am drawing up legal documents, and sometimes when I send out to a client I want to have a footnote to explain some point of godawful convoluted legal prose (why don't I just write it clearly in the first place??! Different topic) - DrMemory in comp.text.tex, Re: Footnotes: turning them on/off
Re: -X's auto-(un)quoting?
On Thu, 21 Apr 2005, Larry Wall wrote: : perl -lne 'print if -e :q' It seems to me that -e «$_» would handle most of these cases, as long as whitespace always comes in quoted so that you always end up with one word. I would say this is hardly the case for the kind of file lists I was referring to. Not that this is terribly relevant from a world wide perspective, I guess... That seems more general than a special option to -X ops. Speaking of which, I like to think of (some) adverbs in terms of cmd line switches, and maybe it's just me, but I think it would be extremely useful to have a full set of tricky ones providing reasonable defaults (user-overridable, of course), short enough to be easy to type; e.g: unlink :warn; # roughly equivalent to Perl5's # unlink or warn Could not remove `$_':$!\n; Michele -- Whoa! That is too weird! I asked around among the math faculty here and it turns out that _every one's_ wife is married to a mathematician! - Dave Rusin in sci.math, Re: Genetics and Math-Ability
Re: embedding languages in Perl 6
On Wed, 20 Apr 2005, [ISO-8859-2] BÁRTHÁZI András wrote: I'm just wondering, if the following would be possible with Perl 6 or not? XML $a=elemselemContent #1/elemelemContent #2/elem/elems; [snip] The ideas coming from Comega, the next version of CSharp(?). Here's an intro about it: Some time ago I asked a somewhat related question that you can find under the subject Markup language-like features in Perl6?. It didn't raise much feedback, though. And I should have expanded on the subject, but never found the time to do so. Michele -- I agree with Tore; it's sort of a Zen question. If you have to ask, it means you won't understand the answer. If you know enough to understand the answer, you won't need the question. - Joe Smith in clpmisc, Re: Perl neq Python
-X's auto-(un)quoting?
Are the -X functions still going to be there? I definitely hope so! However, to come to the actual question, it has happened to me to have to do, in perl5 that is: perl -lne 's/^//;s/$//;print if -e' or (less often) perl -lne '$o=$_;s/^//;s/$//;print $o if -e' Ok: no much harm done (to my fingertips). But then, talking about huffmanization, could a standard adverb be provided for -X's to the effect of specifying that the passed filename is quoted, say in double (or if sensible in single) quotes: for I find that to be a common filelist format. Ideally, what I'd like to do is perl -lne 'print if -e :q' Michele -- Mary had a little lamb;/Its fleece was green as limes. And every even number greater than two/Is the sum of two primes. - Robert Israel in sci.math, Re: all math problems reduce to linguistics
Re: Perl 6 Summary for 2005-04-12 through 2005-04-19
On Tue, 19 Apr 2005, Matt Fowles wrote:
Python on Parrot
^^
Kevin Tew wondered what the state of pyrate was. Sam Ruby provided a
general explanation.
(I'm not on all of the lists, so this may have come out before and I just
ignore it, but...) this is a pun, isn't it?!?
Michele
--
sub printpages
{
return;
}
This sub is the best code you have written so far.
- A. Sinan Unur in clpmisc, Re: Free source guestbook - unfinished
Re: Whither use English?
On Mon, 11 Apr 2005, Juerd wrote: Seriously, is there some reason that we would not provide a Language::Russian and Language::Nihongo? Given Perl 6, it would even [snip] Because providing it leads to its use, and when it gets used, knowing English is no longer enough. I have some code that uses Dutch variable names. When I show that code to people who can't read any Dutch, they have a hard time finding out Which reminds me of the TeX format ConTeXt which is (told to be) somehow more powerful and modern wrt LaTeX, but has a much narrower user base, and IIRC is expressedly design to support localized user interfaces, the only existing one should actually be ductch. I'd be curious to know if and how this works amongst ConTeXt users... Michele -- [...] is like requiring to play tennis with a square ball. Which admittedly makes the game more interesting. - Giuseppe Oblomov Bilotta in comp.text.tex (edited)
Re: .method == $self.method or $_.method?
On Thu, 17 Mar 2005, Larry Wall wrote: really short alias for $self. Suppose we pick o for that, short for object. Then we get self calls of the form: o.frobme(...) How 'bout ..frobme(...)? Or would it be a hell to tell from C..? (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!) How 'bout a single underscore? _.frobme()?!? Michele -- L'amava come si ama qualcosa che e' necessario alla vita. La odiava come si odia chi tradisce. - Laura Mancinelli, Gli occhi dell'imperatore
Re: .method == $self.method or $_.method?
On Thu, 17 Mar 2005, Larry Wall wrote:
:o.frobme(...)
:
: How 'bout ..frobme(...)? Or would it be a hell to tell from C..?
: (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!)
:
: How 'bout a single underscore? _.frobme()?!?
Thought about those in the night, but they don't strike me as visually
distinct enough. They just look like someone stepped on the front
of your expression.
But then do 'c' and 'o'? They're too identifier-like IMHO to be
psychologically associated with something 'special'. It kind of reminds me
of some fortran code I saw (I don't know fortran) and I could hardly cope
with those 'c'omments...
(However I would be favourable to {one,two} letter(s) long builtin
functions/operators, when they are frequently used (think huffmanization)
and talking about language design in general.
Michele
--
Your right, I didn't think of that at all, but still, who's gonna go into
the temp internet folder and create a cookie? At least not most users.
Of course *most* users aren't going to do that. *Most* users aren't
trying to hack your site! You don't program securely for *most* users -
you program securely for the few users who *are* trying to be malevolent.
- Paul Lalli in clpmisc, Re: free source authentication script
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: Adding linear interpolation to an array
On Thu, 10 Mar 2005, [UTF-8] Thomas Sandla~_ wrote: 'Co' means together like in coproduction. And 'contra' is the opposite 'Streaming of digestive byproducts'? ;-) Sorry for the OT - couldn't resist! This pun first occurred to me wrt (cathegorical) coproducts... Michele -- SILVIO CLEPTOMANE - Scritta su un muro, Via F. Sforza, Milano
Re: Sets vs Junctions
On Mon, 21 Feb 2005, Jonathan Lang wrote: There are a couple of problems: first, a hash's keys are limited to strings; a set ought to be able to handle a wider range of data types. Well, if I had learnt something about Perl6 it is that it is no longer necessarily so. Michele -- It's also amazing how much use Larry's getting out of his colon. (The character, obviously). - The Perl 6 Summarizer.
Re: Sets vs Junctions
On Tue, 22 Feb 2005, Larry Wall wrote: On Mon, Feb 21, 2005 at 10:32:15PM -0800, Jonathan Lang wrote: : ...then you've got the notion of Fuzzy Logic Sets, where the key would be [snip] But using values for degree of membership is an interesting idea. On the other hand, if we ever have numeric datatypes with built-in error bars, those could generalize to keys with an associated certainty of some sort, and then you can leave the values out of it. In which case a junction might have varying degrees of likelihood varying between noneness and allness. It's all too powerful for a Pooh like me, though... :-) OTOH all these discussions seem to imply that there is some demand (by me, for one!) for a set-like builtin data-type as well as for the already existing hashes and junctions and of course for interoperability between any two of them, e.g. in terms of automatic conversions where needed, etc. Or maybe for an ancestor data type of all three of them that can be specialized to any? (I don't think this option is viable, but that final remark is intriguing in this sense...) Michele -- - if using perl on Unix isn't that simple as on PCs It is not PC to use PC to mean Windows box. :-) - Brian McCauley in clpmisc, Re: Using perl over network (NFS)
Re: Sets vs Junctions
On Sun, 13 Feb 2005, Jonathan Lang wrote:
If we want Sets in Perl, we should have proper Sets.
I'll agree, depending on what you mean by proper. I'd be interested in
having some means to perform set operations in perl6: unions,
intersections, differences, membership checks, and subset/superset checks.
Well, one point to look at the issue is that the keys of a hash alread are
a set. In some sense you get sets with an additional unavoidable feature
(the values).
Talking Perl6, which has a type system, it becomes suddenly possible to
have hashes of whatever type of values one may want. For example one may
implement a good approximation to a set with an hash of 1-bit integers; I
don't know if there will be a built in one-value-only data type, and I
wouldn't see for it any other use than this.
OTOH the set of subsets of a given set A can be put in bijective
correspondence with {0,1}^A, in which case using 1-bit integers may have
some sense from this perspective.
Again, using arbitrary integers (also in Perl5) you automatically have
multisets, i.e. unordered lists.
In any case I, for one, would like real sets as builtin data types. I
understand that some features of them are already provided by other data
types and I find junctions to be of an extreme interest. It would be nice
thus, if all these data types could be linked is some elegant way. E.g.
there should be an immediate, and possibly automatic way to turn a set
(whatever it would) be into a junction or a hash (with certain
predefined values) where needed.
As a last observation, hashes, which are from the UI POV the counterpart
of mathematical functions, could be based on (the counterpart of
mathematical) sets, whereas they're being based on a somewhat orthogonal
concept, i.e. that of ordered pairs. Of course this approach is
interesting too, but it would be nice to have both...
Mind you, I _like_ Junctions, and I'd rather not toss them out in order
to make room for Sets. I'd rather have both if possible.
Me too!
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: Fun with junctions (was Sets vs Junctions)
On Mon, 14 Feb 2005, Michele Dondi wrote: Speaking of which, while I think that methods on the implicit topicalizer and the C.= assignement operator are indeed cool, I wonder if any provision will be made for a convenient stand in for whatever is on the left side of an assignment operator, e.g. I got no answer... does this mean this is utter nonsense? Michele -- SILVIO CLEPTOMANE - Scritta su un muro, Via F. Sforza, Milano
Re: Fun with junctions (was Sets vs Junctions)
On Sat, 12 Feb 2005, Damian Conway wrote: @xyz = uniq @xyz; or better still: @xyz.=uniq; Speaking of which, while I think that methods on the implicit topicalizer and the C.= assignement operator are indeed cool, I wonder if any provision will be made for a convenient stand in for whatever is on the left side of an assignment operator, e.g. @xyz=uniq _; # indirect object notation (I guess that _ won't be taken for filhandles any more, I don't know if it's already taken for something else...) Michele -- The trouble with engineers is that given the problem of knocking down a stack of 100 bricks, they will start at the top, and work all day removing them one at a time, while the mathematician will, after a momemt's thought, remove the bottom brick and be done with it. The trouble part, is having to brook the noise of the engineer boasting about how much harder he worked while one is trying to think about the next problem. - Bart Goddard in sci.math
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Wed, 9 Feb 2005, Larry Wall wrote: roadblocks thrown in their way. That's true not only for LP, but also for FP, MP, XP, AOP, DBC, and hopefully several other varieties ^^ ^^^ ^^ ^^^ 1. 2. Ehmmm... sorry for the ignorance, but... 1. Functional Programming (right?) 2. Aspect Oriented Programming (right?) What about the others? Well, I know about Google (and I'll try ASAP in any case), but I fear those acronyms could be just a little bit too generic, although probably including also 'programming paradigm' as search keys would help. Michele -- Whoa! That is too weird! I asked around among the math faculty here and it turns out that _every one's_ wife is married to a mathematician! - Dave Rusin in sci.math, Re: Genetics and Math-Ability
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
On Tue, 8 Feb 2005, Matt Fowles wrote: pipe dreams Juerd wondered if he could mix = and == in a sane way. The answer appears to be no. Once you bring in == you should stick with it. Huh?!? It doesn't seem to me that the answer is 'no'. In fact C == is supposed to be yet another operator, albeit somewhat a special one. If I got it right the answer is actually 'yes': what Larry suggested is that it would be _stylistically_ better to stick with it once it is used in the first place. Michele -- Ah, but the REAL myster is -- did Pythagoras really discourage eating beans because they resembled human testicles? Or is that another myth? I always thought it was because of their musical qualities. - Robert Israel in sci.math (slightly edited)
Re: = vs == [was: Perl 6 Summary for 2005-01-31 through 2004-02-8]
On Wed, 9 Feb 2005, Larry Wall wrote: Yes, you can certainly intermix them as long as you keep your precedence straight with parentheses. Though I suppose we could go as far as to say that = is only scalar assignment, and you have to use == or == for list assignment. That would be...interesting...to Yes, it would indeed be interesing, but... it would also be really kinda too much! Michele -- I agree with Tore; it's sort of a Zen question. If you have to ask, it means you won't understand the answer. If you know enough to understand the answer, you won't need the question. - Joe Smith in clpmisc, Re: Perl neq Python
Re: Reality check
On Fri, 4 Feb 2005, Juerd wrote:
Does this make sense?
my @words = gather {
for =(open '/usr/share/dict/words' err die) {
.=chomp;
next if /-[a-z]/;
/$re/ and take { word = $_, score = %scores{ .letters }.sum };
}
} == sort { .score } is descending, { .word.length }, { .word };
With some effort I managed to understand _which_ sense it should make up
to this:
} == sort { .score } is descending, { .word.length }, { .word };
I mean: everything of what is gather()ed gets 'piped' into sort() which
sorts according to C { .score } . But what are the other args to it
supposed to mean? (Sorry for being dense!)
Michele
--
i need to know what type of math and how much math a surgeon uses.
How about asking what type of surgery and how much surgery
a mathematician uses?
- Robin Chapman in sci.math
Re: Auto My?
On Mon, 20 Dec 2004, James Mastros wrote: OTOH, I realize now you can do that with zip in P6, in which case you do have a mention of the whole variable to stick a my on -- Cmy %foo = zip(@keys, @values); I think Cmy [EMAIL PROTECTED] = @values; reads better though, even though looking at it literally, you're attempting to lexicalize an element. But dealing with a natural language, or with a programming language that is so strongly inspired by natural languages it doesn't seem so mandatory to have to look at it literally. I don't know if it will be eventually chosen so, but since (even intuitively speaking) you can't lexicalize an element of an aggregate, an alleged attempt to do so could perfectly well be Perl's lingo for what some people already think to be a logical way to interpret it... Michele -- The trouble with engineers is that given the problem of knocking down a stack of 100 bricks, they will start at the top, and work all day removing them one at a time, while the mathematician will, after a momemt's thought, remove the bottom brick and be done with it. The trouble part, is having to brook the noise of the engineer boasting about how much harder he worked while one is trying to think about the next problem. - Bart Goddard in sci.math
Re: Classes with several, mostly unused, attributes
On Wed, 15 Dec 2004, Abhijit Mahabal wrote: #!/usr/bin/perl -e $x = 1; Is this supposed to work? I would tend to consider it counter intuitive... #!/usr/bin/perl v6; $x = 1; Incidentally, and on a totally OT basis, I've noticed that Perl6 is supposed to have v-strings. But (current) 'perldoc perldata' warns that they won't be there after 5.8: taking all this into account I wonder wether this would be a wyse choice. I mean: maybe it hasn't been such a good thing to introduce them in the first place, but now that they're there, it may be even worse to remove them... Michele -- The amount of repetition repetition isn't that great. - Ignacy Sawicki in comp.text.tex thread Bug in FeynMF's Queues?
Re: flip flop xx Inf
On Fri, 3 Dec 2004, Larry Wall wrote: On Sat, Dec 04, 2004 at 01:11:30AM +0100, Juerd wrote: : What happens to the flip flop operator? Will .. in scalar context remain : the same? I don't think so. It's definitely a candidate for a longer Huffmanization simply in terms of frequency of use. On top of which, almost no Perl 5 programmers even know what it does. Plus it's Well, I have the vague feeling that you may have some more experience with Perl than I do, however such a claim seems a bit exaggerate to me. For example I do know what it does and even though I consider myself to be at most an advanced beginner rather than an expert, I think that I use it correctly and to great advantage, when I do use it, that is... For sure it can't be just me!! Michele -- DAX ODIA ANCORA - Scritta su diversi muri milanesi
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, 3 Dec 2004, Larry Wall wrote:
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the input construct.
Hmm.
while () {...}
for .lines {...}
Looks like a wash to me.
Partly it does. The point is that not only the is simple, but that it
is also visually distinctive, which is important IMHO.
Obviously the new proposal of unary C= is just as good from this point
of view...
: Replacing that with something that not only is object oriented, but on
: top of that also LOOKS object oriented is bound to be a loss. It's
: going to be that bit longer to write, and not the least bit easier to
: understand.
Really? I dare you to show those two lines to any random
computer-literate but non-Perl-speaking stranger and see which one
they understand better.
Of course they'd understand better the latter, but I think that there's a
limit to non-Perl-speaking-people-friendship. After all this may be useful
for learning perl, but learning it to a good degree would always involve
getting acquainted with quite a lot of typical idioms, so this does not
make much of a point IMHO, provided that when a typical user becomes
familiar with those idioms he can perceive (i) how good they look in
source code (ii) how useful they result in practice.
It's all cargo cult at that level anyway, so whether it looks OO or not
is really completely immaterial to its usability.
Indeed it's not *purely* a matter of looking OO, but of looking yet
another more-or-less alphabetic string (yes, even with a prepended point:
it's just not as markedly distinctive!). As I said, is deeply etched in
Perl programmers' cortex as an input operator. In other words it may well
be cargo cult, but not in a totally negative acceptation: I mean... till
it works, and works well as it currently does!
And I don't buy the nuclear blackmail argument either. I'll start
worrying about people switching to Python and Ruby when those languages
get a clue about how natural languages work. As far as I know, there's
OTOH, as a side note, but not a totally unrelated one, I guess, one should
pay some attention not to exaggerate following natural languages
principles in designing programming languages: granted, I appreciate their
pervasiveness in (current) perl and indeed probably this is one of the
reasons I love it. But I think that there are some natural limits to this
as well: AFAIK any attempt to overcome them was basically a failure. We
want the *right* mixture of conciseness, intutivity, clarity instead. In
this sense a construct like
while () {
...
}
really doesn't resamble any natural language construct as far as I can
see, but indeed it's an idiom that perl programmers easily become familiar
with and like to use... well, I think so!
Michele
--
I hold a square measuring 10x10 metres away from a person who is standing
100 metres away.
I ask them to shoot the square with a high-accuracy gun.
Don't stand there holding the square when they are shooting...
- Robert Israel in sci.math, Re: Scaling
Re: state vs my
On Fri, 3 Dec 2004, Brent 'Dax' Royal-Gordon wrote: Larry Wall [EMAIL PROTECTED] wrote: So optimizing to a state variable won't necessarily help your loop overhead, but it could help your subroutine overhead, at least in Perl 5, if Perl 5 had state variables. Best you can do in Perl 5 is an our variable with an obscure name. my $x if 0; I know it's *going* away, but it hasn't *gone* away yet. Personally I'm glad this is going away. I'm not bothered by the caveats of the docs: it's the construct itself that somehow strikes me as innatural, to the point that I've never been bitten in the neck by using it inadvertently for I would have never ever though about doing so... In fact a declaration is fundamentally a way to introduce an object to be used subsequently, and the fact that it can be used also in the same statement in which it is declared doesn't make things really different. So how can I *declare* something depending on a condition?!? I can branch over a condition to execute either one block or another *within* which things can be declared or some such. Not the other way round... 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 on sci.math, thread Who is Green?
Re: iterators and functions (and lists)
On Sun, 5 Dec 2004, Matthew Walton wrote: At least we had the sense to call them subroutines instead of functions. Of course, that also upset the mathematicians, who wanted to call them functions anyway. Go figure. That might be because the mathematicians haven't heard of a variant of a function which is allowed to have side effects yet. More or less BS for, from the point of view of a mathematitian (i.e. from the point of view of Mathematics), you still have true functions, they're either not just the *same* function each time, or the same function with some arguments/parameters set to different values (that in the implementation are passed implicitly rather than explicitly), which are fundamentally the same thing after all (up to an isomorphism, that is). Michele -- I find the line I am not pestering anybody, I am asking questions on usenet. That's what usenet is for. a classic. It's like I am not talking to you, I am just opening and closing my mouth while standing close to you. That's what a mouth is for. - David Kastrup, on comp.text.tex (slightly edited)
Re: specifying the key Type for a Hash
OT On Mon, 6 Dec 2004, Luke Palmer wrote: Well, there's always domain and range, if we want to be mathematical. [snip] What you want here is domain and codomain. Which leads me to believe that you don't want either. For the record, in most connections range would be just as good. Indeed codomain, especially from the algebraic/categorial point of view is sounds somehow better. /OT Michele -- [ standard bull-shit snipped ] Your friend, Nathan the Great Age 11 The best of your postings is the backside. Please let the front also blank in the future. - Rainer Rosenthal in sci.math, Re: Cantor Paradox :-)
Re: iterators and functions (and lists)
On Mon, 6 Dec 2004, Larry Wall wrote: to return an infinite list, or even return 0..., 0...; to return a surreal list. Either of those may be bound to an array Hope not to bark something utterly stupid, but... if one iterates over such a list, may it be that on the first Clast one really starts over from the second 0? Well, unless some adverb is given to the point that one really has to last :everything # or somesuch... Michele -- Some time ago,I managed to wipe out almost all of /usr/bin while doing some cleaning (don't drink and root...:-) - Predrag Ivanovic in CRUX mailing list
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004, Brent 'Dax' Royal-Gordon wrote: I like this in general. However... Larry Wall [EMAIL PROTECTED] wrote: * Since we already stole angles from iterators, «$fh» is not how you make iterators iterate. Instead we use $fh.fetch (or whatever) in scalar context, and $fh.fetch or @$fh or $fh[] or *$fh in list context. I believe you tried this one a couple years ago, and people freaked out. As an alternative, could we get a different operator for this? [snip] Any other suggestions, people? I think I will miss angles... well, at least for some time. Of the proposal above I like best @$fh, since it's the one that most conveys the idea of syntactic sugar for iteration while still being fundamentally intuitive. Michele -- Se, nella notte in cui concepi' il duce, Donna Rosa, toccata da divina luce, avesse dato al fabbro predappiano invece della fica il deretano, l'avrebbe presa in culo quella sera Rosa sola e non l'Italia intera. - Poesia antifascista
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004, Austin Hastings wrote: How about just having C system() return a clever object with .output and .err methods? interesting... Michele -- Windows shuts down automaticaly giving an count down. what could be the problem Windows? - Le TeXnicien de surface in comp.text.tex
Re: Hyper Here-Docs? (was: Re: angle quotes for here-docs ?)
On Thu, 25 Nov 2004, Larry Wall wrote: On Thu, Nov 25, 2004 at 11:59:21AM -0600, Rod Adams wrote: : Seeing the « in the context of a here-doc made me think can you do a : » here-doc? Nope, you can only hyper operators, not terms. Incidentally, just like mathematically (albeit slightly loosely) an element of a set can be thought of as a function from any singleton, would it be possible for Perl 6 to provide a fast (under the syntactical point of view) way to promote a term to a function returning it? Michele -- Not really. It was an insider joke. If you need to ask, you won't get the answer. I never said I was a nice guy. - David Kastrup in comp.text.tex, Re: \slash and /
Re: Hyper Here-Docs? (was: Re: angle quotes for here-docs ?)
On Tue, 30 Nov 2004, David Christensen wrote:
Incidentally, just like mathematically (albeit slightly loosely) an
element of a set can be thought of as a function from any singleton,
would it be possible for Perl 6 to provide a fast (under the syntactical
point of view) way to promote a term to a function returning it?
What's wrong with the perl 5:
sub mysub($x) {
return sub { $x }; # the sub{$x} is the construct
}
?
Michele
--
The amount of repetition repetition isn't that great.
- Ignacy Sawicki in comp.text.tex
thread Bug in FeynMF's Queues?
Re: Hyper Here-Docs? (was: Re: angle quotes for here-docs ?)
On Tue, 30 Nov 2004, Abhijit Mahabal wrote:
or the perl6
$xsub = { $x };
Sorry, I was missing the obvious...
Michele
--
[...] is like requiring to play tennis with a square ball.
Which admittedly makes the game more interesting.
- Giuseppe Oblomov Bilotta in comp.text.tex (edited)
Re: S13: Deep operators
OT
On Wed, 24 Nov 2004, David Ross wrote:
I have been studying PERL 5 core and modules to identify options and
issues for meta-architectures and automated code generation. PERL 6
documents and discussion provide insight essential to effectively using
PERL 5 and preparing for PERL 6.
[snip]
developing in PERL struggling to catch up. The conceptual and concrete
Funny to notice how you could study PERL{5,6} so much still failing to
realize that there's not such a thing as PERL. See
perldoc -q 'difference between perl and Perl'
OT
No offense intended,
Michele
--
Your right, I didn't think of that at all, but still, who's gonna go into
the temp internet folder and create a cookie? At least not most users.
Of course *most* users aren't going to do that. *Most* users aren't
trying to hack your site! You don't program securely for *most* users -
you program securely for the few users who *are* trying to be malevolent.
- Paul Lalli in clpmisc, Re: free source authentication script
Re: Will _anything_ be able to truly parse and understand perl?
On Thu, 25 Nov 2004, Adam Kennedy wrote: I thought it was about time I brought some concerns I've been having lately to the list. Not so much on any particular problem with perl6, but on problems with perl5 we would seem to have the opportunity to fix but aren't. (So far as I can tell). So why not discussing this somewhere else? (e.g. clpmisc) One of the biggest problems I have had with perl5 is that nothing, not even perl itself, can truly actually parse Perl source. By this, I mean parse False: [Nothing but] perl can parse Perl. (Tom Christiansen) Michele -- # This prints: Just another Perl hacker, seek DATA,15,0 and print q... DATA; __END__
