Re: punie.g observation
On Tuesday 17 January 2006 16:50, Chris Dolan wrote:
> Allison et al.,
>
> I was looking at languages/punie/lib/punie.g in the current SVN head
> and got confused. I see:
>rule gprint { (print) \s* }
> and
>rule expr{ | }
>
> Doesn't that imply that "print print print print 1;" is a valid Punie
> program? Is that intentional? It seems to me that the gprint rule
> should instead contain "cexpr":
>rule gprint { (print) \s* }
"print print print print 1;" is certainly a valid Perl 5 program; it prints a
1 followed by 3 other things (which are defined to be true, and which happen
to also be the number 1). Digging on retroperl.cpan.org shows that it did
exactly the same thing on perl 1.0.0. So to answer your question, it's
probably intentional :)
Andrew
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On Monday 07 November 2005 03:51 pm, Juerd wrote: > Andrew Rodland skribis 2005-11-07 13:30 (-0500): > > If you want to get into personal beliefs, I think that function > > signatures are such a complexity quagmire -- and that they're line-noise > > ugly to boot. > > The nice thing about signatures is that they let you write what you > mean. This saves you an entire translation from what you mean to some > Perl code that manipulates @_. This translation is hard, and error > prone, as is the code that comes from it. Sorry, I wasn't clear here, so I hope you don't mind my cutting you off. What I meant wasn't "signatures are too much complexity" -- they're not; they're simply doing something useful -- but rather "too much complexity is getting thrown into signatures" to the point where the gain isn't so much, but the complexity starts creeping in, and you need a book just for everyday tasks. Combined with what seems to me like a thoroughly unreadable syntax, function signatures are starting to look like a brand new version of the regex mess that p6 ditched in favor of the more consistent, more readable patterns. I'm going to stop going on about this one way or another, but I just wanted to make myself clear first. Andrew
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On Monday 07 November 2005 09:26 am, Rob Kinyon wrote: > On 11/7/05, Michele Dondi <[EMAIL PROTECTED]> wrote: > > 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. > > [...] > Though, I do find the complexity reassuring. I like having the > options, even though I will never use them. The alternative is Perl5, > where you can do (almost) anything you could want, except you have you > jump through lots of hoops and you end up with something that works, > but really really slowly. No-one wants that. But it's not such a black-and-white thing. If 1 bit of complexity covers 90% of cases, 10 bits gets you 99%, 100 bits gets you 99.9%, and so on, where do you stop? Where do you say "okay, I think we're doing good enough, let's not add more complexity" ? Especially when that complexity isn't optional. I think that's really a common "fear", that Perl 6 is going well beyond that point of sensibility. If you want to get into personal beliefs, I think that function signatures are such a complexity quagmire -- and that they're line-noise ugly to boot. Andrew
Re: Compiling parrot with c++
On Thursday 27 October 2005 09:37 pm, Joshua Hoblitt wrote: > On Thu, Oct 27, 2005 at 11:22:40PM +0200, Leopold Toetsch wrote: > > On Oct 27, 2005, at 22:31, Nick Glencross wrote: > > >There are a few cases of -1 being assigned to unsigneds. Anyone know > > >if that's deliberate? > > > > Yup. Some special out-of-band values. > > I suspect that gcc4 will give a warning on that. Wouldn't UINT_MAX or > ULONG_MAX be slightly more correct? or ~0U / ~0UL. Again pretty much the same thing, but it shouts "magic value" loudest to me. Andrew
Re: Zcode interpreter release
On Wednesday 24 August 2005 04:26 pm, Amir Karger wrote:
> Several people pointed out that I didn't perldoc -f system. Sorry!
> Btw, even after reading the docs, I still don't understand why Perl
> would pass a cd command to a piece of the shell that can't understand
> it. Granted, I shouldn't do it anyway, because then Perl will exit the
> shell it created for the system() and my cd will be useless.
It's not "a piece of the shell"; it's no shell at all. Perl is trying to
execute /bin/cd (or rather, 'cd' somewhere in your search path), as provided
for by execvp. As to why perl does it; perl doesn't know or care that the
thing you're naming is a shell builtin; it simply tries to run what you told
it to. If you wanted to force it to work as a builtin, you could use
system('sh', '-c', 'cd /foo'); -- but as you've already noted, it wouldn't be
good for anything anyway.
Andrew
Re: Can a scalar be "lazy" ?
On Monday 22 August 2005 04:25 pm, Larry Wall wrote:
> On Tue, Aug 23, 2005 at 04:09:29AM +0800, Yiyi Hu wrote:
> [stuff]
> : Even if making scalar lazy might cause problem sometimes, Is it
> : possible to add a property which is like
> : my $var is lazy; to handle these situation?
>
> In Perl 6 you make lazy scalars by putting curlies around them:
>
> my( $s, $t ); $s = { "value t is $t" }; $t = "xyz"; print $s();
>
> Currently we also require the de-lazifying context to supply a
> postfix .() marker, but possibly that could be assumed in a string
> or numeric context.
>
> I really don't see much benefit in making it easier than that.
>
Agreed, especially since it would be a sort of false laziness (sorry to
confuse the term). It's easy to understand the rule that double quotes
interpolate when they're evaluated, once you learn the rule. Something like
the grandparent's "is lazy" would introduce a whole mess of rules regarding
what gets evaluated when, and in what scope. But there already exists a set
of such rules for curlies, and it only seems sane to use them rather than
adding more complexity.
Re: reduce metaoperator on an empty list
On Thursday 19 May 2005 10:51 pm, Sam Vilain wrote: > Edward Cherlin wrote: > > Here is the last answer from Ken Iverson, who invented reduce in > > the 1950s, and died recently. > > file:///usr/share/j504/system/extras/help/dictionary/intro28.htm > >[snip] > > Thanks for bringing in a little history to the discussion. Those links > are all local to your system; do you have internet reachable versions of > them? > These seem to be the original sources: http://www.jsoftware.com/books/help/dictionary/intro28.htm http://www.jsoftware.com/books/help/dictionary/d420.htm and so on. Front page is at http://www.jsoftware.com/books/help/dictionary/title.htm . I still haven't figured out what "J" is though.
Re: Whither "use English"?
On Tuesday 12 April 2005 07:42 am, David Cantrell wrote: > On Mon, Apr 11, 2005 at 03:42:25PM -0400, Aaron Sherman wrote: > > > I'm not even sure I like the *possibility* of using non-ascii letters > > > in identifiers, even. > > > > I think we already have Latin-1 in identifiers... > > more's the pity. > > > Let's see about UTF-8 > > pugs> my $??? = 1; > > undef > > pugs> $???; > > 1 > > I see a sequence of three question marks, there's no funny foreign > characters there. I have to confess to being surprised that $??? is > legal. If it helps any, the problem is somewhere betwen lists.develooper.com and your eyes; the missing doodad was U+0E81 LAO LETTER KO, which is pleasantly curvy.
Re: Second use of flattening
On Monday 04 April 2005 06:34 pm, Juerd wrote: > Terrence Brannon skribis 2005-04-04 18:45 (+): > > So, to avoid confusion with the common understanding of flattening in > > Perl, perhaps it should be called spreading or distributing. > > I agree. > > Likewise, "slurping" is probably best explained as collecting. I like this. I'd be tempted to suggest "scatter" / "gather", but that's probably a bit opaque to the average reader. How about describing them as "expand" / "collect" for a matched pair? That's got a legacy in math, and some mathematically-oriented languages. Andrew
Re: Units on numbers [was Re: S28ish]
On Monday 28 March 2005 05:48 pm, Craig DeForest wrote: > The problem with using the units(1) database is that it only deals with > multiplicative relations -- so, e.g., it won't handle temperature. [EMAIL PROTECTED]:~$ units 2084 units, 71 prefixes, 32 nonlinear units Among those "nonlinear units" are such units as tempF and tempC, defined as functions of a base unit tempK; units(1) seems to be at least decently capable with such things. --Andrew
Re: state vs my
On Saturday 04 December 2004 06:15 pm, Alexey Trofimenko wrote:
> oh! that it. I've found example which could make it clear to me
>
> sub test {
>return sub {
> for 1..3 {
> state $var = 1;
> print $var++
> }
>}
> }
>
> $a = test; $a() for 1..3; print ';'
> $b = test; $b() for 1..3;
>
> that could print, for different possible definitions of "state":
> 1) 123123123;123123123
> 2) 123456789;123456789
> 3) 123456789;101112131415161718
>
> looks like you meant third(!) variant.. but it doesn't make any sense for
> me.
The idea is that $var's _visibility_ is tied to scoping: it's only accessible
inside that set of braces, like a lexical. But its lifetime is like a package
variable. It's initialized once, and then it lives its life in peace. As
Larry said, you could emulate it by having a package variable and
lexicalizing it with "our", but if you're only going to use it as a state
variable, then why have it be potentially visible to the rest of the world?
So "state" gives you a variable with a permanent lifetime, but lexical scope.
It seems too simple to be wrong, to me :)
--hobbs
Re: Win XP problems
On Monday 08 November 2004 06:50 pm, Christian Lott wrote: > Having a little trouble with vim. > > I think the problem is that imc.vim.in needs to go through ops2vim. > > C:\parrot\editor>perl ops2vim.pl imc.vim.in imc.vim > Can't open imc.vim: No such file or directory at ops2vim.pl line 8, <> > line 85. > syn keyword imcOp > > C:\parrot\editor>perl ops2vim.pl imc.vim imc.vim.in > Can't open imc.vim: No such file or directory at ops2vim.pl line 7. > syn keyword imcOp > > C:\parrot\editor>perl ops2vim.pl imc.vim.in > syn keyword imcOp > > > > This is in the .NET window (MSVC). > > I'm placing these files into the /vimfiles directory which is adjacent > to the vim63 directory both of which are under the VIM directory. From editor/Makefile: imc.vim: imc.vim.in ../ops/*.ops cp -f imc.vim.in imc.vim perl ops2vim.pl ../ops/*.ops >> imc.vim so basically you want to feed all the 'ops' files into ops2vim.pl and then tack the output onto the end of imc.vim.in to make imc.vim. There are a bunch of other editor-relevant files there, check editor/README.pod for info; just replace ~/.vim with wherever\vimfiles, and ~/.vimrc with wherever\_vimrc. Cheers hobbs
Re: A..Z alternatives
On Tuesday 21 September 2004 07:18 pm, Thomas A. Boyer wrote: > Larry Wall wrote: > >Somebody needs to talk me out of using A..Z for the simple cases. > > > >Larry > > [ <> for array dimension placeholder ] > That might confuse users of languages that were not > C-syntax-influenced, who think that '*<>*' means "not equal". But > surely old Modula hacks like me are in a minority in the Perl world (and > Pascal programmers would never do Perl, would they? Algol, anybody?) So > maybe I'm the only one who runs the risk of that particular confusion. :-) What about BASIC? Aren't all the little kids today raised on BASIC? :) --Andrew
Re: No-C, no programming project: Some configure investigation
On Tuesday 07 September 2004 03:47 pm, Nicholas Clark wrote: > On Tue, Sep 07, 2004 at 10:52:01AM -0400, Aaron Sherman wrote: > > Seriously, I've never come across any system that lacked autoconf > > support AND which a high level language like those that would target > > Parrot, ran on. If you're referring to the number of systems that have > > autoconf supports Win32? Those win32 systems with a shell, C compiler, and the other various UNIX trappings that autoconf requires, yes ;) Andrew
(De-Lurk)
Hello, folks. Just wanted to let people know, I've been following parrot and reading the list for a while now, but just recently I finally co'd a copy of parrot and decided it was time that i actually did something with it. The first thing I did was do some work on making it nice in the editor of my choice; I'm the guy who just submitted a couple patches under editors/. But now I'm working on some small stuff, and I think I'm getting it. I'm not sure where I'm going with it yet, but I think that parrot is pretty smooth stuff, and hopefully I can learn enough to actually do something useful with it. We'll find out; I'm on my way into University right now. On a related note, is there a tasks grab-bag list anywhere, some stuff that isn't core work, but It Would Be Nice If, and someone like me could give a shot? Cheers --hobbs
Re: push with lazy lists
On Wednesday 14 July 2004 12:58 pm, Brent 'Dax' Royal-Gordon wrote: > Andrew Rodland wrote: > > So if we have @x = [1, 3, 5, 6 .. 9, 10 .. Inf, 42]; > > ... > > > 42 is just one number, so questions of indexing > > it are moot, but its "distance" from the left is Inf. So, there's no way > > to access the 42 by any positive index of @x, and no way to ever get it > > by successive "shift". > > Sure, but shouldn't @x[-1] give 42? Yeah. If I didn't write that, I certainly meant it. --Andrew
Re: push with lazy lists
On Wednesday 14 July 2004 04:55 am, Ph. Marek wrote:
> On Wednesday 14 July 2004 08:39, David Storrs wrote:
> > > To repeat Dave and myself - if
> > > @x = 1 .. Inf;
> > > then
> > > rand(@x)
> > > should be Inf, and so
> > > print $x[rand(@x)];
> > > should give Inf, as the infinite element of @x is Inf.
>
> Please take my words as my understanding, ie. with no connection to
> mathmatics or number theory or whatever. I'll just say what I believe is
> practical.
>
> > Does it even make sense to take the Infiniteth element of an
> > array?...after all, array indices are integers, and Inf is not an
> > integer.
>
> I'd believe that infinity can be integer, ie. has no numbers after the
> comma; and infinity is in the natural numbers (?), which are a subset of
> integers.
Infinity is outside of the numbers. When we speak of infinity we mean not some
particular "number" which is greater than all the other ones, but rather some
variable which has escaped the bounds of the finite and the numbers.
> [etc.]
> To summarize:
> @x= ('a', 5 .. Inf, 'b');
> $x[0] is 'a'
> $x['foo'] is 'a'
> $x[-1] is 'b'
> $x[2] is 6
> $x[2002] is 2006
> I believe these are clear and understandable.
>
> $x[Inf] is 'b'
> $x[-2] is Inf
> $x[-10] is Inf
> $x[-2] is Inf
> These would result in simply interpolating the indizes.
Personally I think it's a fairly bad idea to be able to index an array on Inf;
we have $x[-1] and such already to get the "right" side of an array, and I
think it makes more sense, especially in light of the fact that you can
reasonably ask for $x[-2], but not $x[Inf-1]. And, you might want to think of
it in terms of behavior. Not because I say cop out and go with whatever has
the easiest implementation, but because if the mechanism for array
subscripting is anything but simple, nobody will ever know if they've got it
right.
I think I agree that the conceptually neatest way to look at "fancy" lazyish
arrays is by using iterators. An iterator should be able to support at least
one of: getting elements in sequence from "left" to "right", getting elements
in sequence from the right to the left, and indexing straight into the middle
of things. "push" and "pop" work the obvious way based on this, and I suggest
that indexing should behave as though it's merely counting elements from
"left" or "right" by taking elements from the iterator, even if it skips
doing it for real for purposes of speed or other implementation fun.
So if we have @x = [1, 3, 5, 6 .. 9, 10 .. Inf, 42];
Then conceptually it's three (or maybe a little more) array-iterators on the
inside, and one smart meta-iterator that knows how to take elements from its
child iterators in order, and knows how to do the math to support indexing
when possible. As for the component iterators: [1, 3, 5] is like any regular
array, we know it can get its first, its last, or any one by index. And it
knows its length. Good. [6 .. 9], might be driven by a function that returns
{ $^index + 6 }. It knows how long it is, it can index in all three ways, and
it knows where it starts, which means we can convert an index on the outer
array into an index on this chunk. [10 .. Inf] is similar; again we can
generate it by a simple function, and come in from the right; but its
"length" is Inf, and if we ask it to iterate starting at the right, it should
return an endless stream of Inf. Similarly a lookup on any negative index
inside it should return Inf. 42 is just one number, so questions of indexing
it are moot, but its "distance" from the left is Inf. So, there's no way to
access the 42 by any positive index of @x, and no way to ever get it by
successive "shift". Overall I suggest
(all code is sequential)
$a = shift @x; # $a = 1; @x = [3, 5, 6 .. 9, 10 .. Inf, 42]
shift @x; shift @x; # @x = [6 .. 9, 10 .. Inf, 42]
$a = $x[0]; # 6
$a = $x[1]; #7
$a = $x[5]; # 10
$a = $x[-1];#42
$a = $x[Inf]; # No thanks
$a = $x[-2];# Inf
$a = pop @x;# $a = 42; @x = [ 6 .. 9, 10 .. Inf ]
repeat { $a = pop @x; } until $a != Inf; # Heat death
--Andrew Rodland < [EMAIL PROTECTED] >
Re: C style conditional statements
On Tuesday 11 May 2004 10:13 pm, Larry Wall wrote:
> On Tue, May 11, 2004 at 08:31:55PM -0400, Andrew Rodland wrote:
> : On Tuesday 11 May 2004 08:00 pm, Pedro Larroy wrote:
> : > Hi
> : >
> : > Is there any chance that in perl6 there will be the possibility to
> : > write if/else statements without {}s with the condition at the
> : > beginning?
> : Yes, I know that I'm diverting rather than strictly answering. My
> : personal opinion is that I can live with it, because I've shot myself in
> : that particular foot before, and that there are good reasons. My other
> : opinion is that I wouldn't mind if a particular rule in the grammar could
> : be enabled / disabled with "use strict 'braces'" either, as it is
> : somewhat unperlish to prevent footshooting for that sake alone.
>
> That's gonna be pretty unlikely. We've basically decided that, in
> terms of readability, it makes a whole lot more sense to get rid of
> the parens than the curlies, and you can't make both the parens and
> the curlies optional.
>
Aha. I knew that there was one important point that I was missing out on, and
that's the one. And that one does count as a "technical" reason for p6, if
not p5. Hope I've clarified, Pedro.
--Andrew
Re: C style conditional statements
On Tuesday 11 May 2004 08:00 pm, Pedro Larroy wrote:
> Hi
>
> Is there any chance that in perl6 there will be the possibility to write
> if/else statements without {}s with the condition at the beginning?
>
> Like
>
> if (condition)
> statement;
>
> In order not to break traditional C culture. Is there any technical
> reason why it wasn't done in perl5?
My understanding is that it was mostly a /(counter)?cultural/ decision, to
make dangling-else syndrome impossible. For the same reason "else if" is
spelled "elsif", so there doesn't have to be a special braceless exception
for "else".
It might also be wise to note that if your statement is really that simple and
important, you might be better off writing "statement if condition".
Yes, I know that I'm diverting rather than strictly answering. My personal
opinion is that I can live with it, because I've shot myself in that
particular foot before, and that there are good reasons. My other opinion is
that I wouldn't mind if a particular rule in the grammar could be enabled /
disabled with "use strict 'braces'" either, as it is somewhat unperlish to
prevent footshooting for that sake alone.
Cheers,
Andrew
Re: Arrays: Default Values
On Thursday 30 January 2003 06:49 pm, Andrew Rodland wrote: > On Wednesday 29 January 2003 09:52 pm, Rick Delaney wrote: > > On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote: > > > On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote: > > I'd also like to point out that ruby has defaults for hashes but > > assigning nil (the equivalent of undef) does not set the default; delete > > does. > > This makes more sense to me. > [yadda yadda] Just to tone it down a bit: * Yes, that is all my "humble opinion". * Whether or not you liked my proposal, I think there's definitely a communication breakdown between people who are thinking more or less the way I am, and people who are thinking the other. And probably we could figure more things out if we quit talking past each other, as I thinl some people definitely are. :) * Yes, Perl tends to be about letting the user decide whether they want to shoot themselves in the foot -- but it's also about letting them decide when they want to be 'safe' from their own potential stupidity, right? Cheers --hobbs
Re: Arrays: Default Values
On Wednesday 29 January 2003 09:52 pm, Rick Delaney wrote: > On Wed, Jan 29, 2003 at 01:54:10PM -0800, Michael Lazzaro wrote: > > On Wednesday, January 29, 2003, at 12:38 PM, Smylers wrote: > > > That would make the rule very simple indeed: > > > > > > Assigning C to an array element causes that element to take > > > the > > > array's default value. > > > > > > The effects of this are: > > > > > > * Assigning a particular integer to an array of int or Int always > > > does > > > what it looks like it's doing, irrespective of whether or not that > > > integer is zero or whether the array happens to have a default. > > > > > > * In an array of Int, attempting to store C will, by default, > > > actually store C. If the array has a different default > > > defined then that will be stored instead. > I'd also like to point out that ruby has defaults for hashes but > assigning nil (the equivalent of undef) does not set the default; delete > does. > This makes more sense to me. Say an array has a default. If we use an uninitialized slot in the array, we should get the default. Fine -- we have to initialize the thing anyway. But I think it's much saner to have this: * Have an 'undef' or 'unset' unary operator that sets the slot to the array's default (if there is one), and if there isn't then do whatever (either set to the 'default default' or undef, or actually delete the item if it's practical -- it's a minor detail, and not really my point.) * If we try to assign undef, or 0, or whatever, to a slot, then we put the closest thing to undef or 0 that we can, and not the default. Yes, there's some merit on checking whether we're actually assigning "real undef", and not just whatever undef converts into, but that also causes some problems with copying arrays and reading data in and out. Basically, I think it amounts to handling defaults on the setting end, rather than the getting end, which seems a lot more practical to me. I think that having @a[1]=0; print @a[1]; not print '0' is scary voodoo no matter what the reason, and I like having to undefine things with something other than assignment. Possible caveat(s): * Copying arrays. If we handle the "set to default" case sloppily, and then try to copy into an array which has a different default, then some items that were supposed to be 'undefined' are now defined and have the default from the source array. Not good. * Might be inconvenient if we want to dump out to some plain-text format and read back in, as we would have to write code that's explicitly aware of the existence of a default. I'm getting long-winded here, but what it seems like is: what some people seem to be thinking has a lot of potential for hidden action and foot-shooting. What I'm saying seems to me to be 'safer' but maybe less convenient in some situations. Hrm... I think both behaviors could be done without too much pain from user code wrapping an array (even an array of primitive types), so maybe it's a moot point anyway -- just give the user the choice whether they want to risk cutting off limbs with the swiss army chainsaw. Anyway, cheers and good discussion --Andrew "hobbs" Rodland < arodland at noln.com >
Re: Compiling to Parrot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 21 January 2003 07:16 am, Simon Wistow wrote: > On Tue, Jan 21, 2003 at 12:14:29PM +0100, K Stol said: > > LUA seems to be a very nice language, but how is this language to be > > used? Is it in combination with a C program one would write? Or could it > > be used as a stand alone application? In that case, it seems to me it > > would be interesting to have a LUA->Parrot (with IMCC in between) > > compiler. > > As I said, I only know it from a games context where it's used as the > basis for the scripting engine. AIUI it can be used a a standalone > language as well. > > From what I know it's specifically designed to be a portable, fast, > lightweight platform for extending platforms and providing a framework > for implementing domain specific languages. IIRC, it's also being used in some browsers (elinks, at least) as a lightweight stand-in for javascript. Not that anyone actually uses it, of course. - --hobbs -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+La/16xdpaulLLFURAhCQAJ9Brp3HKF97j2Ocgs3PbXQVf9tLBgCfX9pE c0n2Kb/mjg6ND7t5/gvX9FQ= =j0px -END PGP SIGNATURE-
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Friday 10 January 2003 11:42 am, Paul Johnson wrote: > Damian Conway said: > > Andy Wardley wrote: > >> The arrow is a special case. I don't read that first character > >> as '-', I think of the operator as one. I guess the visual cue forces > >> me to see it like that. > > > > I'm suggesting that ~> and <~ will be the same. > > I think that in part this may depend on the font being used. True. It looks horrid in misc-fixed-* (what I'm assuming Paul has in his xterm).
Re: L2R/R2L syntax (was Re: Everything is an object.)
On Thursday 09 January 2003 01:01 pm, Thom Boyer wrote:
> If you read ~> and <~ as "stuff this thingy into that doohicky", assignment
> makes perfect sense. They are plumbing connectors: sometimes they connect
> the water softener to the water heater (one device to another), and
> sometimes they connect to the water supply (a source) or the sink (a sink).
>
> I don't see that as an overcomplication, but as a very straightforward and
> obvious extension.
>
Agreed. I think that this is pretty nice.
> 3) "Do you care about readability at all? It seems to me that ~> and <~
> have no use except making perl 6 uglier and more complicated than it
> already is."
>
> I think ~> and <~ look pretty nice. They read well as a single symbol, they
> make good sense, they make it possible to say more directly exactly what
> your code means, they show the direction of data flow quite well, and the
> "ripply water" look emphasizes the plumbing analogy.
But you're missing the most important part!
I propose that these operators should be named "gozinta" ( ~>)
and "comezouta" ( <~ ), just so that we can say that perl has them. Not to
mention that the names work pretty well, for me.
Observe:
@a ~> map { ... } ~> grep { ... } ~> sort { ... } ~> @b;
@a gozinta map, which gozinta grep, then it gozinta sort, then it all gozinta
@b.
print sort { ... } <~ mymethod(42) <~ @b;
call sort on what comezouta calling mymethod(42) on what comezouta @b.
I think. Indirect objects are still somewhat confusing. :)
If I'm reading the info right on <~, then we want to make it clear that you
_don't_ put it between print and stuff you want to print, or in other words
that "this ain't cout".
Anyway, cool beans. :)
-- Andrew "hobbs" Rodland < arodland at noln dot com >
P.S. Delurk. Hi.
Re: Indeterminate math
On Monday 14 October 2002 20:20, [EMAIL PROTECTED] wrote: > Are Inf and NaN going to be standard in Perl 6? As long as we're traveling > down that road, how about i (the square root of -1), or Lukasiwiscean Null? > (Sorry if I sound sarcastic, I'm actually honestly curious.) > After much fighting with google to find the right spelling, it looks like "Lukasiewiczian NULL" is just the nifty NULL that SQL has, and the nifty ways that it affects logical and aggregate operations. Actually, something I wouldn't mind seeing in other languages -- I can't say if perl is one of those, but if it can be provided by expansion, that would be neato. Miko, did I get the right thing out of that? --hobbs P.S. Delurk.
Re: Regex query
On Sat, 21 Sep 2002 16:33:31 -0600 (MDT), Luke Palmer said:
> You know, the idea that square brackets are the only things that can
> make lists is starting to really appeal to me. Similar for squiggles
> and hashes. I don't know how many times in my early Perl5 days I did
> this:
> Since we now have an explicit flattening operator (unary *), there's
> no need to differentiate between a "real" list and a reference to one.
> We
> could extend it to sub calls:
>
> print["foo ", "bar"];
>
> But that would look like Mathematica, which would be creepy. It would
> be good to keep parens in sub calls (and declarations), but the
> details on how that unifies are wrinkly. Of course, they were never
> ironed anyway:
>
> print "foo ", "bar";
>
> So parens really do provide grouping, not list constructing. Thus,
> this can stay:
>
> print("foo ", "bar");
>
> It also provides a really nice visual clue: If and only if you see
> [], there's a list creeping around. Before, the "and only if" could
> not be included.
>
> Sure, it's not clean yet, but I presume it could be. Objections?
> Suggestions? Obsessions?
I really really like this. The list/precedence ambiguity can sometimes
cause some really nasty confusion... and there's something to be said
for matching the array-construction symbol with the array-lookup one,
and hash-construction with hash-lookup as well.
P.S. Delurk.
msg21842/pgp0.pgp
Description: PGP signature
