Re: The last shall be last
Richard Proctor [EMAIL PROTECTED] writes:
Conflict with last LOOP? Hm, the context should be enough to
distinguish them, no? (Hey, maybe they can be unified somehow --
last -1 to skip to the penultimate pass through the loop? =P)
That could be generalised, next +1 skipping next iteration, next
-1 redo this iteration, first redo the iteration from the
beginning etc.
Ah, so then we could do stuff like this:
for (10 .. 1000 :by(10)) {
given { # I imagine the topic will be picked up here automagically.
when 10 { do_something(); }
when 20 { do_something_else(); }
...
}
next +(10 * (int rand(100) - 50))
}
Any sufficiently advanced technology can be used for evil :-)
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: A..Z alternatives
Andrew Rodland [EMAIL PROTECTED] writes:
What about BASIC? Aren't all the little kids today raised on BASIC? :)
I don't know about the kids _today_, but for about twenty years
starting circa 1980 most home computers came with exactly one
programming language tool, and it was BASIC -- line-number BASIC
initially and QBasic later. A lot of the programmers who cut their
teeth on BASIC never made the transition to C, because C as a language
is so primitive compared to BASIC (not in terms of absolute
capabilities or performance but in terms of the amount of abstraction
provided) that it felt like stone knives and bearskins. Perl came
along and is actually even more high-level than BASIC, and a number of
us picked it up and never looked back.
aside--
(As for me, in between BASIC and Perl I also picked up Inform and
Emacs Lisp, which are also much higher-level languages than C. I
tried on two separate occasions to make myself learn C (plus two
_additional_ attempts at C++) before I finally realized I don't
actually *want* to maintain legacy code written in a low-level
language, anyway. I also tried Python and PHP, but they didn't
take because I kept thinking how much easier things are in Perl.)
--backtotopic
So yeah, there are a lot of BASIC-influenced people writing Perl code.
However, I don't think using for something other than not-equal is
going to be a big deal. Perl5 doesn't use for not-equal either,
and picking up a differently-named operator or two is *NOT* the hard
part of learning a different programming language. It's the paradigm
differences that will get you, and Perl6 is going to stand in good
stead there because it supports most of the paradigms out there to one
degree or another.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Ordinals, Hashes, and Arrays, oh my
Jonathan Lang [EMAIL PROTECTED] writes:
ISAM?
From the RDBMS world, a kind of index I think, or something along
those lines. MySQL for example has a type of table called MyISAM.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: What Requires Core Support (app packaging)Z
Adam D. Lopresto [EMAIL PROTECTED] writes:
On Sat, 18 Sep 2004, Jonadab the Unsightly One wrote:
The question is whether any of that needs to be core, and I'm
starting to strongly think it doesn't. I was about to say that perl
should only go trying to figure out that the file is an archive if
you pass it an appropriate command-line argument, but then I
realized that argument could well be -MPAR (or such).
If by core you mean language core, and if the module in question
would be in the core distribution, then I can mostly go along with
that (with one caveat, below). And on some platforms the Perl
installer could associate certain extensions (perhaps .par) with
perl -MPAR or whatever so that launching the thing Just Works.
Since most of the point of such a mechanism would be to allow people
who just have Perl installed to automagically run these
programs-in-an-archive that include all the modules they use in their
nice neat package, it would be unfortunate to require something extra
to be installed to make that work. Thus, this module should go in the
core distribution, along with the new and improved CPAN.pm equivalent.
So in one sense I would consider this core functionality, in the
sense that it's something Perl needs to be able to do out of the box,
but I can agree that it doesn't need to be in the _language_ core.
Except that the module will be prepending the contents of the archive
to @INC, which implies that @INC needs to be able to contain more than
just directories on the system-level filesystem -- it needs to be able
to contain tied directories that are simulated by modules, or
something along those lines. The core might have to have some hooks
for that.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Synopsis 9 draft 1
John Macdonald [EMAIL PROTECTED] writes:
If a int1 (or int2 or nybble or other sub-addressable sized value)
is being referred to, a similar issue arises since most machines
these days have byte addressing, but do not have bit addressing. If
you can't refer directly to it, the value will have to be extracted
and re-inserted to provide is rw access.
I surely must be misunderstanding what you're saying... the way I
read that, you're suggesting that it will matter to Perl -- not only
to the compiler but even to user code -- how the underlying hardware
addresses its memory. I really hope that's not the case.
I thought Parrot would take care of all that fiddly platform-dependent
stuff so that Perl doesn't have to know or care about it. Perl6 code
shouldn't have to even *know* whether it's running on a big or little
(or middle) endian system, how many bits wide the BUS is, how many
bits are in an integer, whether there's a math coprocessor, whether
the instruction set is RISC or CISC, how many CPUs there are, what
kind of filesystem the underlying OS has, or whether the underlying
GUI is Win32 or Aqua or GTK or Qt. Perl6 code shouldn't have to know
that stuff *even* to call libraries written in another language; even
the compiler shouldn't have to know about it. Parrot should have a
wrapper API thingydo that makes it Just Work.
That's the point of having a VM, or such was my understanding.
I don't think I'm dreaming the impossible here, because Inform seems
to manage this stuff just fine, with either of the VMs it compiles to
(except for the parts about calling libraries written in other
languages, and having a GUI; Inform doesn't support those things).
You can write the code and compile it on a DOS system, stick the
binary on an ftp server, and J. Random Nerd can download it, and
assuming he has the appropriate version of the VM for his system, it
will run your code -- whether his system is SPARC/Solaris or Nintendo
Gameboy, your code will never know the difference; as far as your code
is concerned, it's running on the z-machine. Parrot should be like
that (except that Parrot's minimum requirements for the underlying
system will have to be a little higher, because we want to support
things like disk I/O and allocating more RAM after the program starts
running).
So if the underlying hardware doesn't know how to write a single byte,
then Parrot should have workaround code for that. Perl shouldn't even
need to know about it.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Synopsis 9 draft 1
Aaron Sherman [EMAIL PROTECTED] writes:
It took us some time discussing this... we weren't sure what tense
you were using. At first we thought it might be the past subjective,
but after a while, we decided to coin a new tense: the vapor tense. ;-)
Actually, it's not new at all; there's already a quite established
terminology for that tense. It's called the prophetic past.
HTH.HAND.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Synopsis 9 draft 1
Larry Wall [EMAIL PROTECTED] writes:
int1, int2, int4, int8, int16, int32, int64, uint1, uint2, uint4,
uint8, uint16, uint32, uint64, num32, num64, num128, complex32,
complex64, complex128, ...
Well, all that is harmless enough, as long as I don't ever have the
misfortune to inherit maintenance of any code that *uses* those
lowlevel types.
We are also getting a holds whatever size number you put in it, up to
the limits of available system resources type, right? Good.
say @x = @x[]; # prints @x = 1 2 3
Nice. Until now I wasn't sure I liked the new interpolation rules,
but this looks good.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Pipeline Performance
Luke Palmer [EMAIL PROTECTED] writes:
That's actually a very good idea. That's why Perl 6 has it :-)
sub MediansBy5 ([EMAIL PROTECTED]) {
gather {
while @list = 5 { # there's no .length; it's .elems
take (sort @list.splice(0,5))[2];
}
}
Cgather returns a list of everything that was Ctaken inside of it.
It does this by building a coroutine out of its argument, so it works
lazily.
Okay. I have to go back and reread what has been said about coroutines now.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Pipeline Performance
Rod Adams [EMAIL PROTECTED] writes:
One solution I see to this would be to have a lazy return of some
kind, where you can send out what results you have so far, but not
commit that your execution is over and still allow further results to
be posted. For lack of better word coming to mind, I'll call a lazy
return Cemit.
Example above becomes:
sub MediansBy5 ([EMAIL PROTECTED]) {
while @list.length = 5 {
emit (sort @list.splice(0,5))[2];
}}
That has a certain elegance.
It is worth noting that emit is shorter than return, so people are
going to be tempted to use it when they don't really need the
laziness. Obviously it won't be a full substitute for return because
by definition it doesn't have the (often desirable) side-effect of
terminating the current function. But I can see people writing things
like this...
sub foo (some arguments) {
do_stuff();
emit some value(s);
}
At the right brace there there is (if I understand correctly what
hasn't changed from Perl5) an implicit return, which returns the value
of the last evaluated thing in the block, which in this case would be
the emit. So, a couple of questions:
1. What if anything do you propose is the evaluation value of emit?
2. Should a subsequent implicit return behave differently than usual
if some values have already been emitted?
If the answer to question 1 is a more-or-less nonexistant value, then
question 2 might lose its importance.
One other question: Would emit behave differently if the sub is
called in a non-list context, such as void context or a scalar
context?
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: What Requires Core Support (app packaging)
Juerd [EMAIL PROTECTED] writes:
Most worlds don't use file extensions, except for humans.
You exaggerate their lack of importance. File extensions don't matter
to most operating system *kernels*, but they are nevertheless
important for more than just Windows:
* They are of critical importance on Apache-based webservers.
* They instruct command-line tab completion for some shells. This
IMO is a biggie, and would be even bigger if more shells were
smarter. (eshell has a leg up here.)
* They matter somewhat to many *nix applications, such as Emacs and
Gimp. When I say matter somewhat, I mean that the app
understands what the extension means, and so in the absense of the
extension you have to give the app additional information to
compensate.
* They matter to most GUI file managers in the *nix world. I
personally don't use GUI file managers, but some people do.
* They matter somewhat in the VMS world, though not as much as under
Windows I think.
* They matter in the OS/2 world, if anyone is still using that. Also
DOS, with the same caveat.
* On Mac OS X the extension matters for files that don't have
filetype/creator codes attached to them yet (unless the file is
coming from a source that supplies content-type, such as from a web
server or as an email attachment, in which case the content-type
instructs the addition of filetype/creator codes).
The only OS I know of where file extensions are *totally* not used is
Archimedes. It doesn't allow them at all, from what I understand.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Progressively Overhauling Documentation
Mark Overmeer [EMAIL PROTECTED] writes:
Oops, someone starts the holy war (again). Wether you put the docs
in begin or end of the file, or intermixed with the code has a lot
to do with your personal background.
Sorry for the late reply, but I can't let this stand without further
elaboration: intermixing the POD with the functions is something some
of us would really like to do, but in Perl5 the evil stupid whitespace
rules of POD make it impracticable, because it horks over the
indentation (and thus the legibility) of the whole program.
If we fix nothing else about POD in Perl6, it is *imperative* that it
become possible to indent the POD to at least the same level as the
code. Otherwise POD will never become a viable substitute for the
extensive comment blocks it ought to displace.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Return with no expression
Alexey Trofimenko [EMAIL PROTECTED] writes:
I wanna ask, could be there in perl6 any difficulties with
recognizing C:: as part of C... ?? ... :: ... and C:: as
module sigil? Does it involve some DWIM?
Among other things, the ?? will tip off the parser that it's looking
for an expression followed by the :: operator, so under normal
conditions the namespace-oriented :: will never be mistaken for the ::
that goes with ??, because the parser won't be looking for that kind
of :: except after a ??.
It may be though that if you need to put the namespace-oriented ::
between a ?? and its corresponding ::, you might need parentheses:
my $foo = $bar ?? ($baz::wibble) :: $baz::quux; # This is clear and good.
Otherwise...
my $foo = $bar ?? $baz::wibble :: $baz::quux; # This is more questionable.
The parser _might_ try to pair the first :: with the ??, in which case
it's going to get confused -- probably when it tries to figure out
what wibble is, or definitely when it hits the second :: -- and would
then have to either backtrack or complain. (Complaining is easier;
backtracking is DWIMmier and arguably more Perlish in the long run but
could be added in the post-6.0 era if desired; turning a former error
into something valid is usually considered to be backward-compatible.)
But that case -- using the namespace :: between ?? and :: -- should be
the only situation where any ambiguity could arise over ::, and so it
seems reasonable to require (or at least strongly recommend) the
parentheses in that case.
I am assuming here that we don't need to have a unary or binary ??
operator. That would complicate matters rather substantially.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: - as - with automatic is rw
Juerd [EMAIL PROTECTED] writes:
Sick would be if - were introduced to make the variable write-only ;)
Sicker still would be if - were introduced to make the variable
neither readable nor writeable. HTH.HAND.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: enhanced open-funktion
Juerd [EMAIL PROTECTED] writes:
Not a problem, assuming that these are named arguments as in:
open :r, $file;
open :w, $file;
open :rw, $file;
open :r :w, $file; # Hmm...
I like this approach. :a seems a probable replacement for $file
then; one imagines that :a would be mutually exclusive with certain
other options.
No, translations don't work in programming.
They can, at least in theory, but it's a separate issue, one that need
not concern us here at present. And if you did l6e the programming
language itself, the changes would be more complex than merely
substituting a few keywords; depending on locale you'd want to have
inflected keywords -- and if the notion of having those in Perl
doesn't set your brain to hurting, just think about combining them
with continuations inside of a self-modifying string eval.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: This week's summary
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes:
[surreal numbers]
Care to explain what those are, O great math teacher?
Surreal Number theory was an attempt in the latter half of the
twentieth century to unify several existing sets of numbers (including
the complex numbers, generalized epsilon numbers, and cardinalities)
into a single notation and define addition and multiplication
operations on them that would be isomorphic to the standard addition
and multiplication on the complex numbers. Knuth's book on them is
very interesting and a good read.
I don't know whether surreal numbers ever really caught on in the
mainstream mathematics community or lead to any real advances in
number theory. Most undergraduate math curricula don't seem to teach
them as near as I can tell, except perhaps in the collateral reading.
One problem with them is that the notation is rather unwieldy. They
are interesting conceptually, however, despite their apparent lack of
practical usefulness, and serve as a proof of concept for the notion
of a unified number theory, although in practice the group theory of
modern algebra seems to unify things better, IMO.
Hey, you asked.
Surreal numbers in Perl would be way more cool than practical.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Why do users need FileHandles?
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes:
hopefully without dependencies on external non-Perl things like gcc).
Don't think it'll be possible for modules that have C components,
I'm really hoping Perl6 will be sufficiently powerful that C
components won't be needed or wanted.
Oh, and here's me resisting the urge to suggest that use ought to
automatically install from the CPAN anything that isn't present, as
a core behavior right out of the box.
Security nightmare.
*shrug*
Running untrusted code (Perl or otherwise) on your system that you
haven't examined first is inherently a security nightmare. If it
wants to download things from wherever and install them it can
(assuming that you're running under an account that has privileges to
install or at least has its own install location just for that
account), and that's not all it can do, not by a longshot.
Or did you mean that someone might compromise the CPAN in order to
compromise all the systems downloading stuff from it? Again, that's
already true now, in theory. (More likely, a single mirror would be
compromised. One would hope it would be discovered quickly.)
However, I wasn't serious about making use automatically install.
Well, not altogether serious. CPAN.pm or something like it is really
almost good enough, and what it lacks can be added in without any
change to the behavior of use. Installing once before you use is
really not a very large burden in the scheme of things.
I was, however, very pleased to hear that we won't have to reinstall
half the contents of the CPAN every time we upgrade Perl or Parrot.
Definitely looking forward to that improvement.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Why do users need FileHandles?
JOSEPH RYAN [EMAIL PROTECTED] writes:
Well, that's what all of the ruckus is about. There is a strong
leaning towards including *no* builtin modules with the core.
Surely, at bare minimum, there must be something included in core to
allow things that are not in core to be easily installed, the
equivalent of what CPAN.pm is for Perl5 (hopefully even better, and
hopefully without dependencies on external non-Perl things like gcc).
I could live with very little else in core, but the means to install
whatever is not in core is essential; that's the thing that allows
everything else to be made optional -- because it can be installed
easily enough.
Oh, and here's me resisting the urge to suggest that use ought to
automatically install from the CPAN anything that isn't present, as a
core behavior right out of the box.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: String interpolation
Michele Dondi [EMAIL PROTECTED] writes:
Well, it seems that there's still a big confusion/indecision about
the default behaviour. But then an interesting point, and one that
has already been raised, is that it should be somehow possible to
customize string interpolation bu means of e.g. adverbs (fortunately
we don't have true literal strings but rather quote-like
operators), attributes and god know what else!
I rather like the notion of putting the adverb on the q operator and
its kin (qq, qx, ...)
print q :literal The value of $foo is . $foo . \n;
:literal might be poorly huffman coded, and q (as opposed to qq or
whatever) might already default to not interpolating scalars, but the
above demonstrates the syntax. One nice thing about this is it still
allows for arbitrary characters to be used to delimit the quote:
print qq :scalarcontext (There are @foo elements in [EMAIL PROTECTED]);
Again, :scalarcontext isn't the point, just an illustration of the syntax.
This syntax also would give us symetry with the match operators...
$foo = qr :baz !blah$!;
$bar =~ m :quux $foo; # I forget: is =~ still spelled as in Perl5?
Here also, with qr you could use whatever adverbs you use with any of
its brethren quoting operators, to interpolate or not interpolate
various stuff, and then you could still use whatever pattern-match
adverbs you like with the match operator.
Now it should be stressed that the problem is twofold here: one
aspect is chosing the best default for some hopefully reasonable
meaning of best
Sure, but allowing the default to be overridden with adverbs doesn't
hinder the ability to choose a nice default.
and the other one is providing a slim syntax for the alternate
behaviour(s); i.e. IMHO it would be unreasonable to require the
users to type something like
:with_method_interpolation
One would hope an adverb that useful would be shorter, sure. Maybe
something along these lines, if we can conscion it...
$foo = qq :i($) Woo $hoo;
$bar = qq :i@ . ($boo.hoo @wibble);
Here i stands for interplate, $ for scalars, @ for arrays, . for
methods. If this is deemed too cryptic, perhaps something in between
this and the excessive verbosity of :with_method_interplation is in
order.
It's slightly bothersome that :i would mean interplate for quoting
but case-insensitive for matching, but since case-insensitivity
doesn't seem sensible for quoting that might not matter. I thought
about :int for interpolation, but too many people would think integer,
probably, and :itpl is just too C-like in its unpronounceability and
complete lack of obvious meaning. (What's an i-tuple?) :terp or
:iterp would make people think interpreter rather than
interpolate, I fear, and when we move up to :terpolate we're getting
long. The only synonym I can think of for interpolate is evaluate,
and I'm not certain :eval would mean the right thing to everyone.
each time they want it. But maybe certain delimiters for qq may
already provide that... (or would that be a bad idea?)
I don't think which _delimiters_ you choose should have any impact on
how the interpolation is done (except as regards the delimiters
themselves; if you choose $ as your delimiter, you're going to have a
hard time interplating scalars, obviously).
IMO, the difference between q and qq should have to do with which
adverbs are turned on by default.
As a related side note, is it possible to use multi-char delimiters in
Perl6? I mean, a la:
qq...;
I would worry that you'd be getting and at the beginning and
end of your string. IMO, there are enough characters in ASCII that
for any short quotation you ought to be able to find one character you
can use as a quote delimiter. For longer quotations, we have
heredocs.
Speaking of which, that raises another question: can we apply adverbs
to heredocs?
if (somecondition()) {
$foo = :indent(5) FOO;
blah, blah
blah, blah
blah, blah
FOO
}
Parsing concerns might constrain that to this:
if (somecondition()) {
$foo = :indent(5) FOO;
blah, blah
blah, blah
blah, blah
FOO
}
Which is still better than the bletcherous Perl5 way:
if (somecondition()) {
$foo = FOO;
blah, blah
blah, blah
blah, blah
FOO
}
I've found myself wrapping long quotations in their own subroutines
(that just contain a heredoc and return a string) at the bottom of the
file in Perl5 just to keep my indentation sane. There ought to be
some way around this problem for POD, too. Perhaps POD could have its
own quote operator...
sub foo {
qp :indent(5) FOOPOD;
Put some POD here.
FOOPOD
...
}
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: String interpolation
Correct me if I'm wrong, but, by analogy with $foo.bar(), ...
No Yes
-- ---
@foo@foo[1]
%bar%bar{a} or %bar«a»
$foo.bar$foo.bar()
foofoo(1)
@foo@foo.join( )
Yes?
/me idly wonders whether map and grep and sort could be made into
methods on the array class and chained together and interplated as
such...
print @foo.map({[$_,wibble($_)]}).sort([EMAIL PROTECTED] cmp @$b[1]}).map([EMAIL
PROTECTED]);
Ugh, that looks horrible. Of course, one could probably define a
.schwartz() method on the array class and do the above thusly...
print @foo.schwartz({wibble($_)},{$a cmp $b});
That doesn't buy you the flexibility to throw in extra steps (like a
grep in the middle), but it sure is easier to read.
Of course one could argue that sensible people would assign the
processed list to an array variable first and then interplate that...
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: String interpolation
Johan Vromans [EMAIL PROTECTED] writes:
Larry Wall [EMAIL PROTECTED] writes:
: my $d=a;
: print --$d--{my $d = b }--$d--\n;
Yes, that is correct.
I'm afraid things like this will keep many popular editors and IDEs
from implementing perl6 support...
Then maybe people will switch to more capable editors.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: push with lazy lists
Ph. Marek [EMAIL PROTECTED] writes:
This is obviously some new definition of Inf of which I was not
previously aware.
Well, after reading my sentence one more, I see what may have caused
some troubles. Inf is not in N; but *in my understanding* it fits
naturally as an extension to N, that is, Inf is (or can be) integer
as is after N...
This won't be written in math books, I know.
Actually, it's discussed to death in math books, but math books deal
with Inf in ways Perl isn't prepared to do. If you want to treat
infinities as numbers, then you have to be prepared to have different
infinities.
Also, if that were the case, 0..Inf would be a finite list. (It is
trivial to prove that 0..N is a finite list with finite cardinality
for all natural numbers N. So if you set N equal to Inf, 0..Inf would
have finite cardinality, if Inf is a natural number.)
If I extend the natural numbers N with Inf to a new set NI (N with
Inf)
The problem is, NI is not a group with respect to addition for any
definition of addition of which I am aware. Translated from mathese
to English, that means NI isn't terribly useful or meaningful or
interesting. J and R and C (i.e., the integers and the reals and the
complex numbers) are much more worthy of consideration, because they
form groups with respect to addition.
It is possible to construct a group that includes infinities, but NI
isn't it, and for Perl purposes it doesn't seem necessary.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: scalar subscripting
Larry Wall [EMAIL PROTECTED] writes:
And if we do that, I guess that means that $«file».ext could be
made to work as a replacement, which seems conceptually clean if you
don't think about it too hard.
Now that you put it that way, $( $file ).ext doesn't seem so bad, the
visually-distracting double $ notwithstanding.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: enhanced open-funktion
Luke Palmer [EMAIL PROTECTED] writes:
my $fh = open $filename :excl;
Can we please not name it with a random character generator? How
about something that communicates what it does in some fashion, at
least well enough to function as a mnemonic?
my $fh = open $filename :rw :noreplace;
If :noreplace is too lengthy, how about :create or :new or :safe or
something?
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: enhanced open-funktion
Larry Wall [EMAIL PROTECTED] writes:
1 .. (some_big_hairy_expression)
^:by(3)
But we'd have to pay really close attention to how indenting is
done. Maybe we should just pass this suggestion on to Guido... :-)
Yes, please leave column-alignment tricks to Python. I don't even
like the fact that indentation is significant in POD, to the extent
that I've given up on the idea of putting the documentation with the
code in Perl5 (the whole point of POD, so I thought), because of the
havoc it wreaks on the indentation.
1 .. (some_big_hairy_expression) :by(3)
seems fine to me. The parens should keep the adverb from applying to
anything inside of them, and so assuming that the parens themselves
don't take adverbs[1], then the adverb applies to the preceding
operator, in this case the range operator.
I think that should be the rule: the adverb should apply to the
closest preceding thing that can take adverbs. That's a simple rule,
and it's _approximately_ similar to how it works in English, most of
the time (except that in English we also allow the adverb to come
before the thing it modifies, or in some cases to modify the entire
clause, and a few other complications not worth going into ATM).
So, then, with something like
open $( $file ).log :follow;
We have to decide whether quotes are allowed to take adverbs; if they
are, then that has to be written differently:
open ($file . .log) :follow;
Which in some ways looks cleaner anyway.
(As far as :follow goes, I'm imagining something like tail -f does,
but I'm currently not prepared to argue for the inclusion of such a
feature; it's just an example of an adverb.)
OTOH, do quotes constructs really need to be able to take adverbs? A
negative answer allows the parens above to go away, and it seems like
it would play okay with most things. Certainly, in the case of
pattern matching, it is not the quoting character that takes the
adverb:
m :i /foo/
The adverb attaches to the m (or the s or whatever). And if we're
still to have qq and its kin, they could take adverbs in the same
fashion, presumbaly:
qw :pairs (a A b B c C);
qq :xyzzy Some Arbitrary String;
q :plugh {Another String};
It seems to me that thus it is not strictly necessary for regular
quotes to be able to take adverbs directly, since qq and so on can.
(We'd probably be losing the ability to use colon as the quoting
character. To me, that seems better than having Some String :adverb
attach the adverb to the quote marks. Maybe I'm just odd.)
Someone will doubtless point out that quotes are just a special kind
of circumfix operator. Do circumfix operators need adverbs, though?
I'm *really* hoping that parentheses don't need them[2]. Aren't those
theoretically just circumfix operators too (if you squint)?
Larry suggested that maybe only binary operators need adverbs. I'm
not sure about that. But I'm leaning toward thinking that circumfix
operators, at least, don't need them.
---
Footnotes:
[1] No. Just say no.
[2] ibid.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: push with lazy lists
Austin Hastings [EMAIL PROTECTED] writes:
Half of all numbers in [0, Inf) are in the range [Inf/2, Inf). Which
collapses to the range [Inf, Inf).
It's not that simple. By that reasoning, 10% of all numbers in
[0,Inf) would be in [Inf/10,Inf), also reducing to the range
[Inf,Inf). For that matter, 99% of them would be in [Inf/100,Inf),
which would reduce to [Inf,Inf). But you can't do that kind of
arithmetic with Inf. You're trying to pretend you're working with a
natural number or a specific real, when in fact it's a cardinality (or
a class of cardinalities, or an infinite set of cardinalities, or
something along those lines). If you want to do addition and
multiplication on Inf, you have to redefine addition and
multiplication to get away from the CPU's finite arithmetic, and you'd
also need to treat Inf more completely than Perl does. (Perl treats
all infinities as the same, which is (mathematically speaking)
patently rediculous, because for practical purposes it never matters
to most software, and if somebody wants to clone Mathematica they'll
be writing their own math library anyway.)
It would be *nice* to have this stuff properly supported in a
programming language, sure, but it would also be a ton of work and can
probably wait for at least Perl7.
Oh, and the hardware available to most folks isn't up to the challenge
of picking a properly random number between 0 and Inf yet, either.
Most of the time it wouldn't fit in RAM. Predicting when this
challenge will be overcome is left as an exercise to the reader.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: push with lazy lists
David Storrs [EMAIL PROTECTED] writes:
Does it even make sense to take the Infiniteth element of an array?
No. At best, it would be undefined, so we could define it to return
undef.
I think I would prefer if using Inf as an array index resulted in a
trappable error.
Or that, yeah.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: push with lazy lists
Ph. Marek [EMAIL PROTECTED] writes:
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.
[...]
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.
If that were the case, 0/Inf would == 0.
Also, if that were the case, 0..Inf would be a finite list. (It is
trivial to prove that 0..N is a finite list with finite cardinality
for all natural numbers N. So if you set N equal to Inf, 0..Inf would
have finite cardinality, if Inf is a natural number.)
This is obviously some new definition of Inf of which I was not
previously aware.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: scalar subscripting
Larry Wall [EMAIL PROTECTED] writes:
No, just currently wrong. :-) I changed my mind about it in A12,
partly on the assumption that $object.attr would actually be more
common than $file.ext,
Speaking of which, what's the cleanest way to interpolate filenames
with a fixed extension now? ${file}.ext ? $file\.ext ?
Also, I guess that if $foo.bar is taken as a method call, then
$file.$ext is going to be trouble also, is that right? An error?
Or will it treat the value of $ext as the name of a method, or maybe
look for a method starting with $ ?
but also because a bogus method call is likely to be noticed sooner
than bad output data, and because noticing goofs sooner rather than
later is often construed to be a good thing. (Though this attitude
can be taken to extremes--see static typing.)
Quite. Perl6 is last I checked moving in the direction of giving a
more informative error message later, rather than a syntax error
sooner, which IMO is a good thing. Not that this is a case of that,
but it demonstrates that noticing sooner isn't necessarily always the
best way to go. (Static typing is certainly an annoying limitation,
and I'm sure there are other examples.)
However, while it's a shame not to be able to interpolate $file.ext,
I can certainly see the argument for $object.method being a common
case, one that I imagine I'll use quite often.
Of course, this leaves open the question of whether there are any
fairly common filename extensions that happen to be spelled the same
as a method on Perl6's string class, that might ought to have a
warning generated... Are there any three-letter methods on the
string class? (Maybe there shouldn't be, in the core language...)
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: = brother
Luke Palmer [EMAIL PROTECTED] writes:
strange, but :shift«value» looks a little more noisy to me than
shift = 'value',
For some reason, it looks that way to me, too.
Me three.
Perhaps:
:shift« value »
I *think* that's better...
To me, that's even worse. My brain sees spaces within the value, even
though I technically know that the operator throws them out.
To me, :shift value looks somewhat better (if it means the same
thing...), but I still like the old = syntax even more, perhaps
because I'm accustomed to it; assuming it still DWIM it's what I'll
probably continue to use, personally.
%hash = ( :key«value»
:key2«value»
:key3
key4 = 'value',
'key5','value',
«key6 value key7 value» )
Did I make mistakes here?
I don't think so.
In terms of maintainability, I'd rather see any given chunk of code
pick a syntax and stick with it for at least long enough to complete
one entire assignment, for crying out loud. (No, I don't think the
language should enforce that; I just think it would be better practice
in almost all cases.)
Though that probably isn't what the OP was asking.
:foo« bar »
:ziph« zam »
:split« spork »
Although I'll admit that looks a little strange.
A little. It's better than not lining up, IMO.
ah.. sorry about messing up all question in one post, but I have
one more:) if key could be of any type, not only strings, than
what will be with numeric keys? would they be converted to strings
automatically?
It's Perl: what's the difference?
There are probably subtle differences hiding in the pathological
corner cases, but they are probably not important, IMO. The more
important reason not to flatten hashkeys into strings is so that
references and objects can be used as hash keys without loss of
information.
Say you have an object that numerifies to 42 but stringifies to
The answer to the ultimate question of life, the universe, and everything.
Now it suddenly matters whether hash keys get autostringified or not.
FWIW, if they did I could have lived with that just fine. (You can
always keep a copy of the reference in the value, along with whatever
else you're storing there, in an anonymous hash or array; this is not
one of the limitations of Perl5 that bugs me.) But it will be
important to know one way or the other.
If the = stringifies where another syntax does not, that will IMO not
be a bad thing. MTOWTDI. But I'm not going to get excited about it
one way or the other, assuming it's well-documented, which I'm sure it
will be.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: The .bytes/.codepoints/.graphemes methods
Luke Palmer [EMAIL PROTECTED] writes:
Or, god forbid, a word?
m:base/que mas/
We're not mathematicians: we're allowed to use more than one letter
in a row to designate something :-)
Well, if it were *me*, *I* would have voted for keeping the core
language 100% pure ASCII, untainted by rogue untypeable characters...
So naturally :base is fine by *me*...
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: The .bytes/.codepoints/.graphemes methods
Austin Hastings [EMAIL PROTECTED] writes:
I think this is something that we'll want as a mode, a la
case-insensitivity. Think of it as mark insensitivity.
Makes sense to me, but...
Maybe it can just roll into :i?
It will probably get used in _conjunction_ with case-insensitivity
quite a lot, but I suspect people will want to be able to use one
without the other.
Since mark-insensitivity is probably mostly a non-issue in the ASCII
world, it would probably be a better candidate than average for being
turned on using a unicode character, if we're running low on letters
for designating these rules.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: This week's summary
The Perl 6 Summarizer [EMAIL PROTECTED] writes:
Different OO models
Jonadab the Unsightly One had wondered about having objects
inheriting behaviour from objects rather than classes in Perl 6.
Urgle. I've completely failed to explain myself so as to be
understood. That wasn't at *all* what I had in mind.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: undo()?
Juerd [EMAIL PROTECTED] writes:
I thought temp replaced local.
temp is dynamic scoping, the same thing as Perl5's local.
Hypotheticals are the ones that turn permanent if everything succeeds
according to plan but revert to the old value if stuff fails -- a
rollback mechanism, basically. I was just about to mention
hypothetical scoping wrt undo but for some reason did not.
In fairness to the undo suggestion, there is a significant difference:
to use hypotheticals to revert you have to plan the reverting when (or
before) you make the change. I think continuations work this way also
(except that they don't just revert one thing). This sounds like a
no-brainer (i.e., you're writing the code that uses undo so obviously
you planned at coding time to do the reversion) until you think about
putting references into the mix; with undo you could revert an
arbitrary item.
One thing worth noting about .undo is that retrofitting it later would
not break backward-compatibility at the language level. It would be
one heck of a messy change under the hood, but any user who wasn't
using it wouldn't have to even know about the change.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: undo()?
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] writes:
Actually, I think you're underestimating the little guys. After
all, if they rolled back *all* of your changes, all they could do
was repeatedly execute the same code!
Except that you can pass the continuation some arguments, possibly
including functions, closures, or even other continuations, which
would rather complicate matters.
But Luke's explanation makes sense of some things I previously
couldn't make sense of.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: if not C, then what?
Jonathan Lang [EMAIL PROTECTED] writes:
Strictly from a grammatical perspective, I'd be much more comfortable with
C, then instead of Cthen as the perl equivelent of the C-style comma:
have the then keyword change the preceeding comma from a list
constructor to an expression combiner. From a parsing perspective,
though, this would be a nightmare.
Parsing Perl was nightmarish already before work started on Perl6. If
we wanted a language that's easy to parse, we'd be using lisp, or
maybe assembly language.
Still, I'm not sure what the comma adds, other than extra[1]
punctuation.
This is different from its use in conditional sentences, since in that
case the protasis (if clause), being an introductory subordinate
clause, is usually set off from the rest of the sentence via a comma,
whether or not then is used to introduce the apodosis (then
clause). It is common to see a comma before then for this reason,
but that is entirely a different use (and meaning) of then.
Come to think of it, the frequent use of then in conditionals might
make it a bad choice for use in another way.
Actually, the whole purpose of the C-style comma is to allow you to place
multiple expressions in a place that's only designed to take one, such as
the various divisions within a loop control set (loop ($i = 0, $j = 1; $i
10; $i++, $j*=2) {...}). For something like this, you might be better
off doing something like
last($a, $b, $c)
(where last is a sub that takes a list of arguments, evaluates them one at
a time, and returns the value of the last one). Unfortunately, last is
already in use by perl; so you'd have to think up another name for the
sub, such as final.
Oh, like lisp's progn (except that final is a better name for it).
Perl5 programmers have been known to use xor for this, though of
course that is not the intended use of xor.
where C[-] is read as followed by. You could even set up a
right-to-left version, C[-], but why bother?
Oh, for aesthetic symetry, of course ;-)
[1] Do one thing then do another is valid SWE I think. then is not
a coordinating conjunction like and; it's a special adverb of
sorts, in a similar category with because (except that because
is a subordinator; whereas, then does coordinate; but it is not
a conjunction) or so (although so often is treated like a
conjunction and takes the comma, which is an odd little wrinkle --
but it does not always do this). then can function as a
coordinating adverb (like consequently and nonetheless and so on);
in the case wherein it joins whole independent clauses it is
preceded by a semicolon (as in She went to the store; then she
came home. -- if there were a comma in this case it would be
after then, not before), but it can also be used to coordinate
the parts of a compound part of speech, e.g., a compound verb with
the subject expressed only once (if at all; in the imperative mood
the subject need not be expressed); in that case no punctuation is
needed, as in She went to the store then came home. This last
usage most closely fits the proposed way of using it in Perl, as
in (you) Go to the store then come straight home.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: if not C, then what?
David Storrs [EMAIL PROTECTED] writes:
e.g., is this legal?
sub infix:before ( $before, $after ){ ... }
I should HOPE it would be legal to define infix:before. Some of us
don't want to use untypeable characters every time we want to define
an operator that doesn't conflict with the core language.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: if not C, then what?
Jonathan Lang [EMAIL PROTECTED] writes:
For the record, I was mentally parsing this example as:
pray_to $_;
sacrifice $virgin for @evil_gods;
So was I, FWIW.
The precedence of Cthen isn't very intuitive to me.
Is that an argument for changing its precedence, or for leaving it out
of the core language?
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: undo()?
Luke Palmer [EMAIL PROTECTED] writes:
Oh no! Someone doesn't understand continuations! How could this
happen?! :-)
Yes, well, I've only just started reading up on them recently...
A continuation doesn't save data. It's just a closure that closes
over the execution stack
Ah. That helps a lot. For some reason, I hadn't realize that yet
from reading about them in Dybvig.
You could make the programmer specify which variables he wants delta
data for, and then any *others* wouldn't keep it and wouldn't be
undoable.
A much more useful way to do this would be:
use undo $foo $bar $baz ;
my $foo = 41;
my $state = undo.save;
$foo++; $foo.undo($state); # or perhaps $state.remember;
That seems reasonable to me.
I don't want to think about what happens when you write:
use undo $state ;
Something terribly inefficient, I suppose. There could be a warning
in the documentation about that.
Or something could try to be clever and detect this sort of thing; I'm
not entirely certain whether that's equivalent to the halting problem,
but either way it sounds like all kinds of excitement, or something.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Next Apocalypse
Austin Hastings [EMAIL PROTECTED] writes:
Of course, how hard can it be to implement the .parent property?
.parent and also .children, plus .moveto and .remove (which doesn't
actually destroy the object but sets its parent to undef, basically,
cleaning up the .children property of its parent), and a couple of
extra routines for testing ancestor relationships and stuff, but...
You'll want it on just about everything, though,
Right, it would be less useful if not all objects had it. Although it
would be easy enough to implement a class of container object that
implemented the forest and each contained a .node which could hold
some other kind of object. That adds a layer of indirection, but it
would allow for organizing arbitrary objects using the forest.
In Inform any object with no parent is on the forest floor, but it
would be easier to implement I think by making the forest floor an
object, and having all of the forest-container objects be located
there by default and having .remove move them there. Then the forest
floor's .children would take care of the ability to iterate over all
the toplevel objects.
This approach has the advantage of not needing any changes in core.
Maybe I just won't sweat it. A lot of the things Inform programmers
do with the object forest can be done in Perl in other ways, combining
hashes and references and arrays and stuff (stuff Inform doesn't
really have per se; well it has (statically-sized) arrays, and it sort
of fakes references... but it's not the same). Properties are the
thing that was harder to get around a lack of, and we're getting those :-)
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: The .bytes/.codepoints/.graphemes methods
Dan Sugalski [EMAIL PROTECTED] writes:
Hmm. Suppose that I have a system that is friendly to 80 byte
records. I want to output meaningful strings, so I want to
partition a buffer into 80-ish byte substrings, but preserve any
graphemes (i.e., store the data in a legible format).
How would I do that?
You don't. Or if you do, you do it with a lot of pain, sweat, and
annoying hard work. 80 bytes gets you somewhere between three (And
this may be a *high* estimate--there may be circumstances where 80
bytes is insufficient for *one* grapheme) and 80 graphemes.
This isn't something that can be made generically easy.
It's no worse than implementing word wrap. Someone will of course
implement it as a generic routine, something along the lines of
my @line = breakunicodestringintobytebufferchunks(
string = $string,
chunksize = 80,
keeptogether = 'graphemes',
extremelongparts = 'split',
# 'split' will try to split it at a mostly-reasonable
# place if possible, similar to word wrap that looks
# for syllable boundaries.
# 'truncate' would do the same but drop the second part,
# rather than putting it in the next line.
# 'skip' would drop the whole grapheme out.
# 'allow' would create a line longer (in bytes) than
# the chunksize, which is what a lot of word wrap
# algorithms do, but would not work if you really
# have to fit in a fixed-byte-size buffer. It would
# of course put the thing on a line by itself though,
# to minimize the overflow.
);
There are reasons for doing this, e.g. if you've got Unicode text to
send via a network protocol with an octet-oriented RFC, or if you're
interacting with some legacy C code that has fixed-size buffers.
Someone will write the routine to do as well as can be expected, and
it'll be put on the CPAN, and people who need this sort of thing will
use it.
I don't think the language needs to be designed around it though.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: The .bytes/.codepoints/.graphemes methods
Austin Hastings [EMAIL PROTECTED] writes:
A couple of alternatives:
substr.bytes($string, 2, 4) = $substitute;
Well, that's arguably better than bsubstr.
substr($string.bytes, 2, 4) = $substitute;
I could live with that, although it doesn't allow mixing units.
(Someone will pop in here and say that's to be construed as a
feature.)
# Make it a pragma
use String(bytes);
substr($string, 2, 4) = substitute;
I think a pragma should set the default unit for the current lexical
scope, at least. (The default, in the absense of the pragma, is an
open question; at worst the default could be to throw an exception if
units aren't specified; personally I think throwing exceptions willy
nilly is unPerlish.)
# Make it a global mode
set_string_mode(bytes);
substr($string, 2, 4) = substitute;
I don't like this. It's no more useful than the pragma but has bigger
caveats.
# Make it an object mode
$string.access_mode(bytes);
substr($string, 2, 4) = $substitute;
Wouldn't this add extra operations all over the place?
The word bytes is clearly much too long, though, much less
graphemes or codepoints. I thought about this:
substr($string, 2b, 4b) = $substitute;
Problems with:
substr($string, 0b, 1b) = $substitute;
Is that binary or bytes? Also:
I figured it would conflict with something.
substr($string, $start b, $end b) = $substitute;
Looks unintuitive.
*shrug*. I chose it because I thought the other way around looked
unintuitive:
substr($string, b $start, b $end) = $substitute;
That looks like calling a function -- which *is* what's going on,
under the hood, but the other way around looks like tagging on units,
which seems more natural to me.
With presumably g and c for graphemes and codepoints, but I rather
suspect that might conflict with some other existing syntax (though I
can't think of anything in particular).
0c? 0x16c ?
Ick, yes, I missed that. (I was thinking only of numbers specified in
decimal.) I knew there'd be something.
codes and graphs is better than codepoints and graphemes, at least.
In certain (IMO large) sectors of the Perl community, string
processing is just about all the work there is. I submit that there
needs to be a way to drive the token length to 0: either a pragma,
or a global mode, or a type definition.
A pragma should set the default, IMO. I think what we're talking
about here is what the syntax would be for using a unit other than the
default, or for specifying the units if you haven't used the pragma to
set the default.
You could coin the abbreviation ligs, for Language Independent
Graphemes. Then some ingenious rascal can create a pragma or
whatever that allows $str.b, $str.c, $str.g, and $str.l for
fans of terseness.
As opposed to 'ligs' meaning ligatures? Fraught with peril. :-)
I thought about that, but figured it wasn't a big deal; there are
*lots* of abbreviations with more than one possible interpretation,
and you just deal with having to know which one is meant. However, it
was then pointed out that it would actually be ldgs, which IMO is
unpronounceable and ugly. So something else is needed for those.
*shrug*. Make up a word. Call them woohickies for all I care and
abbreviate it woo or just w.
I like graphemes for the default because I hate and fear
graphemes. The whole *code thing just crawls right in my ear, so
having the language transparently support it would be a win.
I can see the logic in that. Personally I don't care what the default
is. Almost none of my code will need to care one way or the other,
and that which does can use the pragma.
Have the implications of the bytes/codepoints/graphemes/woohickies
distinction for the regular expression engine been discussed already?
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: if, loop, and lexical scope
John Williams [EMAIL PROTECTED] writes:
$b = 'a';
my $b ='b' , print $b\n;
print $b\n;
Which seems to show that the my $b doesn't actually come into
scope until the end of the statement in which it is defined.
The comma operator doesn't guarantee order of operation because it's
building (or not bothering to build, in this case) a list. I wouldn't
have been terribly surprised if the expression before the comma were
optimized out entirely, since the comma operator is in void context,
which is theoretically a form of scalar context in Perl5 IIRC.
People who think in terms of statements often get mixed up when they
put complex expressions in void context, expecting them to be treated
as statements. print(2+3)*7; is another example. Perl doesn't have
statements in the same sense that Pascal does. It has expressions.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: The .bytes/.codepoints/.graphemes methods
Juerd [EMAIL PROTECTED] writes:
substr($string, 2 but graphemes, 4 but bytes);
I think but even makes sense, if substr defaults to something.
That could be combined with a smart substr that only needs the units
once (err, only needs a position object for one of the args) and knows
how to conver the other number to the same units (err, same type of
position object):
substr($string, 2, 4 but bytes);
This would still allow for specifying units on both if you for some
reason wanted them different (which, as Dan S points out, sounds like
a bad idea, on the face of it).
:bytes is shorter than but bytes, though.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Next Apocalypse
Dan Sugalski [EMAIL PROTECTED] writes:
Sure, no big deal. Also, don't forget the trival matter of moving
from a class-based object system
No, the object system in question is still class-based. The object
forest is orthogonal to that.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: undo()?
Michele Dondi [EMAIL PROTECTED] writes:
I must say I've still not read all apocalypses, and OTOH I suspect
that this could be done more or less easily with a custom function
(provided that variables will have a method to keep track of their
history, or, more reasonably, will be *allowed* to have it), but I
wonder if Perl6 may include a builtin undo() function to recover
values prior, say, to the last assignement (or push() or,
etc. etc.[*])
Hmmm...
If we have $foo.undo(), then we will want a multi-step undo to go with
it, probably $foo.undo($n), with $n able to be negative for redo. Are
we prepared to give the mouse that cookie? (This is not intended as a
rhetorical question; I suspect people will stake out both positions.)
I heard a rumour we were getting continuations (a la Scheme). They
wouldn't be tied to a specific variable like what you propose, but
they would allow the state of the entire process to be rolled back to
an earlier point, or something along those lines. Of course, the
overhead issues are different. You don't have to start keeping delta
data just because a continuation _might_ be taken; you keep it when a
continuation _has_ been created, and then you use it if the
continuation is ever called (or such is my limited understanding).
With .undo() you would have to keep all the delta data all the time if
.undo() is used at all. You could try to only keep it for specific
variables that are used with .undo(), but that probably falls apart if
references are brought into the mix.
Could be *mightily* inefficient with RAM. Of course, you only take
that hit if you ever use .undo()
You could make the programmer specify which variables he wants delta
data for, and then any *others* wouldn't keep it and wouldn't be
undoable.
use undo foo bar baz; # Or use the funny characters I can't type.
my $foo++; $foo.undo(); # Undoes the increment.
my $quux++; $quux.undo(); # Throws an exception or something.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: The .bytes/.codepoints/.graphemes methods
Larry Wall [EMAIL PROTECTED] writes:
That all has to be looked at anyway. What does 5 mean when you
pass it to substr, anyway?
I was just going to ask about substrings, and then didn't because I
figured that had been hashed out already and I'd missed it...
(I've been trying to make it assume some implicit unit based on the
current lexical scope's Unicode level, but issues remain.) We have
magical string positions that have different numeric values
depending on what units you view them as, but at what point does a
number like 5 get translated to such a magical string position?
It would be possible to have right-associative operators (that bind at
least more tightly than comma and possibly very tightly) and convert a
number to one of these objects, so that we can do stuff like this:
substr($string, 2 bytes, 4 bytes) = $substitute;
Then if you pass a plain number to substr it could either assume
something (possibly generating a warning) or spit an error, depending
on some feature of the current lexical scope.
The word bytes is clearly much too long, though, much less
graphemes or codepoints. I thought about this:
substr($string, 2b, 4b) = $substitute;
With presumably g and c for graphemes and codepoints, but I rather
suspect that might conflict with some other existing syntax (though I
can't think of anything in particular).
And I can't think of another abbreviation that would be remotely
intuitive.
There's also the possibility of bsubstr and so on, but that leads us
down the path of C, having a hillion bajillion functions with names
like fgets, stoi, and fstrnclost. Having sprintf is quite enough of
that, IMO.
I dunno--it reads pretty well. Maybe these'll be heavily enough
used that we should Huffmanize them down a bit:
$str.bytes
$str.codes
$str.graphs
$str.letters
codes and graphs is better than codepoints and graphemes, at least.
Though letters is a bit inadequate to describe language-dependent
graphemes, since it also divides any non-letters...I suppose we
could go with .characters if we don't mind forcing a heavily
overloaded word in one particular direction, culturally speaking.
Except, I'd kinda like to keep them starting with different letters.
(And maybe .chars should be reserved to mean whatever the default
unit is in the current lexical scope, as with substr() above.)
You could coin the abbreviation ligs, for Language Independent
Graphemes. Then some ingenious rascal can create a pragma or whatever
that allows $str.b, $str.c, $str.g, and $str.l for fans of terseness.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Next Apocalypse
Dan Sugalski [EMAIL PROTECTED] writes:
Speaking of objects... are we going to have a built-in object
forest, like Inform has, where irrespective of class any given
object can have up to one parent at any given time,
Multiple parent classes, yes.
Not remotely the same thing.
Parent objects, no.
Oh, well.
and be able to declare objects as starting out their lives with a
given parent object, move them at runtime from one parent to
another (taking any of their own children that they might have
along with them), fetch a list of the children or siblings of an
object, and so forth?
Erm I don't think so. I get the feeling that Inform had a
different view of OO than we do.
I was asking mainly because Perl6 was moving in that general
direction. Having compile-time traits but also being able to tag
properties on at runtime is very Inform-like. Inform's object model
also fits pretty well with Perl's notions of context, things like
being able to treat someobject.someproperty as a value and not care
whether it's actually a value (the more common case) or whether it's
really a routine that returns a value each time (the more flexible
case), for example; in Perl6 this will be accomplished more likely by
returning an object that has the desired numerify routine so that the
caller can just assume it's a number and not get surprised, but that
amounts to ultimately the same flexibility.
So I was just wondering about the _other_ useful feature of Inform's
object model, the object forest. However, this is the sort of thing
that could be added to a later version without breaking any existing
code.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: definitions of truth
Paul Hodges wrote:
Do note that I realize I can check it. It's just that for no reason I
can quite define, my C background wants a null byte to be FALSE without
any special chicanery on my part when checking. I can live with the
fact it isn't going to be, it just seems odd to me.
If that seems odd to you, the implications of Perl's being an
expression-based rather than a statement-based language will
probably give you nightmares (strange nightmares about void
context...)
I believe, from the way you asked your question, that you don't have
the right mental map to make it comfortable. As I see it, at least,
with respect to what you're asking about testing, Perl has strings
and integers, but not 'characters'.
Perl has scalars, and they can be any of the above.
No. A Perl scalar can't store a character per se. It can store
the ordinal value of the character as a number, or it can store a
string of length one, but neither of those is the same thing as
storing a character directly...
Consider this test in Perl:
if \0 {...}
Its equivalent in C is this:
if () ...
That can't be right. If anything it's got the two languages
flipped, but that's still not quite right either. Apples and
orange leotards.
But it isn't. The perl is passing a zero -- just a fairly obscure one.
No, \0 isn't zero. It may become zero if you translate it from
certain character sets (e.g. ASCII) to its numeric collating code
(and this is what ord does, but ord is not one of the more
frequently-used builtins, because that's just not something you
need to do very much in Perl; 90% of the times I've seen ord used
were in deliberatly obfuscated code), but otherwise it's a character,
not a number. Under more normal conditions it would numerify to
zero only for the same reason C would also numerify to zero.
I just thought that the special value of an ASCII 0 fit well into that
~arbitrary~ set, just as the special value of an ASCII 48 does. It's
just a mindset, as several folk have said, but hey, I'd be ok if 0 was
true because it wasn't the explicit boolean value of FALSEthough
I'm REALLY glad Perl doesn't do that. :)
Lisp does this -- anything that's not nil is effectively true (err, t).
It works for lisp, but it wouldn't play nicely in Perl due to some
other differences.
lol -- C doesn't have strings, but Perl does?
As a fundamental data type, he meant. C doesn't have strings in the
same sense that Perl doesn't have characters. Some languages have both,
you know, and so the character A is not the same thing as the string
A and would be stored in a variable with a different type. (I'm
thinking here of Pascal.) A C variable can store a character directly,
such that afterward the answer to what is in this variable is such
and such a character. In Perl the answer would be a string. Going
the other way around, Perl can store Hello, World in a scalar, and
if you then ask the question, What's in $hello ? the answer is
The string 'Hello, World', whereas, in C the answer would really be
A pointer to a character.
You can say that each is capable of emulating the functionality of
the other, and you'd be right insofar as that you'd be talking about
Turing equivalence, but there are still important differences in
terms of paradigm; the way data are stored and handled has major
implications for how we think in the language. One of the implications
of Perl's way of doing things is that the ASCII character corresponding
to decimal 0 is not special in any particular way. If I'd been doing
something with split// to process some binary data, I'd have known to
check for 0, but if any *other* character (including binary null)
had tested false and prematurely ended my loop (or whatever) I'd have
been highly weirded out and probably made a comment to the effect of,
In the name of all that is sane, WHY?
Yes, Perl's strings are cleaner and more prettily wrapped, because they
are an interpretive subset of scalars and the way they're defined. Perl
was written in C, and uses the same internal bits at some point.
That's an implementation detail. A good rule of good design is
that implementation details don't show through generally.
Now, with all of that said, it should also be noted that in Perl 6 it
will probably be possible to create a pragma that will cause things
to work rather differently, so that you can have \0 evaluate to
false in boolean context in your lexical scope. I'd advise against it.
Re: definitions of truth
Paul Hodges wrote: So a null byte is still Boolean true. Ugh, yarf, ack, etc. But as long as I know -- easy enough to check explicitly. But just tell me thisam I the only guy who thinks this *feels* wierd? It doesn't feel weird to me, but my previous languages of choice were fairly high-level (GW-BASIC, Pascal, Inform, QBasic, and Emacs lisp). I never really got very deeply into C. But explain something to me: under what circumstances would you be checking for any data at all _except_ a binary null? What are you writing, a disassembler?
Re: definitions of truth
In Perl5, the following values are FALSE: undef, '0', 0, and ''. What you fail to note is that each of these is false for a reason. undef is false so that you can test an object for truth; if it is undef it obviously contains no data, so it's false. 0 is false so that you can test numbers for truth. '' is false so that you can test strings for truth. The really special case is '0', which is false for arcane (but very sensible) reasons. Okay, so it's binary data. So is 0 and 0, if you look at it that way. The difference here is that there is no normal circumstance wherein you would get a binary null if there's no data. The only situation I can think of that even comes close would be if you were reading null-terminated strings from a C or Assembler program out of some kind of binary file, and in that case you'd almost certainly split on binary null, so you'd get if there were no data in a given string, and that would be false as per the existing rules. Perl is a pragmatic language; things are true (or false) for good reasons, so that you can do various things easily. I realize the internal representations are different, but the programmer shouldn't have to care about that. When are you going to run into binary nulls if you're NOT mucking about with internal representations? I just figure that if my bit of $data = contains one byte, and I'm checking that $data for boolean truth, You can always check the number of bytes (or characters), and it'll be false in boolean context if it's zero: mumblefrotz(\$data) while length $data; So my question is this, with apology for the ramble aside from P6's other changes, is a single null byte of binary data still going to register as TRUE, or will it now be what seems to me the more sensible FALSE? As I understand it, the addition of properties in Perl6 (See the Apocalypse 12 article) allows for even undefined values to be true if you choose to make them so.
Re: definitions of truth
Larry Wall wrote: What do you mean by length? For a string, it obviously either means number of bytes or number of characters. Pick one, document it, and let people who want the other semantic use a pragma. I don't think it matters which one you pick as default, as long as it's clearly documented.
Re: definitions of truth
Juerd wrote: That we already have. 0 but true. (perldoc -f fcntl) It's 1 but false that's really special :) No, what's really special is the ability to return entirely different things in string versus numeric context, like the magic $! does in Perl5. That, or interesting values of undef :-)
Re: unicodian monospace fonts for windows(?)
but now i have this issue: I'm coding on Windows, there's already two
unicode compliant monospace fonts: Lucida Console and Courier New. And I
do not like both of them, (f.e. in Courier { and ( looks almost the
same, and lucida has too crude letters). Until now I used to use Fixedsys
(which can display « ± ¦ », but not ¥, for example)
So I have a question - does anyone know the place where I can get free
monospace unicode font for windows, good for programming?
Have you tried Andale Mono (from Microsoft's Core Fonts for the Web,
corefonts.sourceforge.net) or Bitstream Vera Sans Mono (available from
I think the FSF)?
Re: Next Apocalypse
Dan Sugalski [EMAIL PROTECTED] writes:
Next Apocalypse is objects, and that'll take time.
Objects are *worth* more time than a lot of the other topics.
Arguably, they're just as important as subroutines, in a modern
language.
Speaking of objects... are we going to have a built-in object forest,
like Inform has, where irrespective of class any given object can have
up to one parent at any given time, which can change at runtime, and
be able to declare objects as starting out their lives with a given
parent object, move them at runtime from one parent to another (taking
any of their own children that they might have along with them), fetch
a list of the children or siblings of an object, and so forth?
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: E6: assume nothing
Luke Palmer [EMAIL PROTECTED] writes:
A synonym of:
delete %h{foo};
would be
%h{foo} = nonex;
This has the potential, if not documented exactly right, to create
bogus expectations. Consider...
$s = %h{foo} = nonex;
After deleting the foo key (and its value, if any) from %h this then
probably procedes to autovivify it when evaluating it as an rvalue; if
so, that may break the programmer's expectation, but if not, what is
assigned to $s -- obviously you can't assign nonex, because it isn't a
value. Do we mutate it to undef? Throw a runtime exception? Remove
the entry for $s from the symbol table?
undef, odd though it is, is a value of sorts. Not a terribly
meaningful value in many contexts, but a value. And it knows how to
stringify, numify, et cetera. The proposed nonex would do none of
those things, at least not without first autovivifying, at which point
it would no longer be nonex.
However, it might be possible to write the documentation so that it's
clear nonex isn't really a value, just syntactic sugar for deleting
the corresponding key.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Junctions Set Theory
Abhijit A. Mahabal [EMAIL PROTECTED] writes:
On the other hand, if you wanted to say true for all except exactly
one value, I can't think of a way.
Easy. The following two statements are equivalent:
F(x) is true for all but exactly one x
(not F(x)) is true for exactly one x
The only additional possibility that can't be phrased in terms of the
four given is the complex generalised case:
F(x) is true for at least n but not more than m values of x
So for example you could have a list of fifty values for x and test
whether the condition is true for at least ten but not more than
fourty of them. (Or, x could be the condition; you could have a list
of fifty conditions and test whether between twenty and thirty of them
were true.) My guess is, however, that the frequency with which
anyone would use such a capability would not be overwhelming.
It would be great for obfuscation, though, particularly if some of the
conditions had side effects with an impact on the value of the other
conditions to be tested... That would be sufficiently interesting
that it's almost a shame I can't think of a real reason to request
such a feature, since I rather doubt anyone's going to much fancy
implementing it just for obfuscatory value ;-)
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Perl 6's for() signature
John Siracusa [EMAIL PROTECTED] writes:
Did this ever get resolved to anyone's satisfaction? While reading
EX6, I found myself wonder exactly what for() would look like in
Perl 6 code...
A for loop[1] is basically syntax sugar for a while loop. In general,
where foo, bar, baz, and quux are expressions, the following are equivalent:
for (foo; bar; baz) { quux }
foo; while (bar) { quux; baz }
If Perl6 has enough syntax-sugar ability to let you turn the former
into the latter, then you don't need to worry about for's signature.
[1] Of course I mean a C-style for loop.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Perl 6's for() signature
Luke Palmer [EMAIL PROTECTED] writes:
Yes, it's possible to have two routines with the same name which
differ by signature... however, in Perl 6, Cfor has only one
signature, and it's the one above. The Cfor loop you are thinking
of is spelled Cloop,
Oh, yes, forgot about that.
To the contrary, Cwhile and Cif take only a single expression in
scalar context, whereas Cfor takes a list in flattening list
context.
*light dawns*
That's what I get for trying to start reading in the middle of a
thread, I guess.
Methinks that a signature should be able to call for a code block
in braces, and when it's called the signature after that code
block should be optional.
You mean s:2nd/signature/semicolon/ ?
Yes, that was a thinko. I thought I typed semicolon there.
This has already been discussed at length. The answer is um. :-)
I see.
So far documented, the semicolon is only optional when the closing
brace is the only thing on the line. Don't worry, Larry's got a
handle on this one, and I don't think it needs further discussion.
Cool.
Fooey, English is weird, let's stick with Perl.
Hmm, that last quote seems a little odd when placed next to your
signature... :-)
What, my little pathetic attempt at a JAPH? It's only even slightly
hard to follow if you don't understand closures. Nothing like some of
the clever monstrosities I've seen floating around on the net.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Perl 6's for() signature
Abhijit A. Mahabal [EMAIL PROTECTED] writes:
There is another problem beyond efficiency: the P6 list semantics is lazy.
The following is valid P6, AFAIK:
for 1 .. Inf {
print $_;
last when 10;
}
Yeah, but that's a foreach loop, despite the fact that foreach is
spelled for in your example. foreach loops have a different
signature from for loops. (P6 does make it possible to have two
routines with the same name that differ by signature, right? ISTR
seeing something about that in one of the Apocalypses[1].)
And then most of the proposed methods (including popping off [EMAIL PROTECTED])
would not work.
foreach loops take their only code block in the braces; you don't have
the code block inside the parens to worry about in that case, like you
would in a for loop. Thus, foreach loops are no harder to implement
than while or if, signature-wise.
my_for 1 .. 5 { something }
and not have to write:
my_for 1 .. 5 {something };
Ah, that's another matter, but you need that to implement while and if
as well. Methinks that a signature should be able to call for a code
block in braces, and when it's called the signature after that code
block should be optional. (And it needs to be optional whether the
code block is the last thing in the signature or not; else, how would
one implement map and grep and sort?)
A question I haven't fully thought through: should a closing brace
_ever_ need to be followed by a semicolon? Because, if not, then we
could do this...
my $foo = sub { do_stuff() } # -- Note no semicolon..
my $baz = {
my @bar;
more_stuff(@bar)
yetmorestuff(@bar)
[EMAIL PROTECTED] } # -- Here also.
Would that have any nasty consequences I haven't thought about?
---
[1] I _think_ that's the right plural.
*apocalupt + s + es = apocalupses, transliterated apocalypses.
But my third declension is a little rusty and I'm not certain
about that first s being added to the root to form the noun stem.
It's a sufficiently unusal word imported to English recently
enough that the plural would be formed like in the original
language, yes? But then why isn't the singular apocalypsis?
Fooey, English is weird, let's stick with Perl.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Aliasing an array slice
David Storrs [EMAIL PROTECTED] writes: my $r_slice = [EMAIL PROTECTED]; @$r_slice = qw/ a b c d e /; print @a; # 0 a b c d e 4 5 This seems right to me. It would take approximately no time to get used to this semantic, IMO. # Note that it does NOT modify in rvalue context [/me recoils at the very idea] @a = @start; $r_slice = [EMAIL PROTECTED]; print @a; # 0 1 2 3 4 5 print @$r_slice; # 0 1 2 3 shift @a; # (*) print @a; # 1 2 3 4 5 print @$r_slice; # 1 2 3 Just to clarify: @$r_slice would point to specific elements of @a, _not_ the the xth through the yth element, is that what you're saying above? That is, although in the example above it initially pointed to the first four elements, it after the pop points to the first three, because one of the four is no longer in the array; it does _not_ now point to the now-current first four elements. Does this imply, though, that it's pointing to specific elements, and if so doesn't that imply that elements can be inserted into the original array in-between them... print @a;# 0 1 2 3 4 5 print @$r_slice; # 0 1 2 3 splice @a, 2, 0, 6; # 0 1 6 2 3 4 5 After that, does @$r_slice contain (0,1,2,3) (the same elements of @a as before), or does it contain (0,1,6,2,3) (the elements from the first one it contained before to the last one it contained before)? I can reason either way, but it needs to be nailed down, and there might be good reasons (which I'm not thinking of just now) to do it one way or the other. (*) There should probably be a suppressable warning emitted here, I can go along with that.
Re: Aliasing an array slice
Jonadab the Unsightly One [EMAIL PROTECTED] writes: Does this imply, though, that it's pointing to specific elements, Wow, I wasn't paying attention to what I was thinking there. Obviously it points to specific elements, because the subscripts used to create a slice don't have to be sequential or even in order. I (theoretically) knew that... print @a;# 0 1 2 3 4 5 print @$r_slice; # 0 1 2 3 splice @a, 2, 0, 6; # 0 1 6 2 3 4 5 print @$r_slice; # 0 1 2 3 splice @a, 1, 1, 7; # 0 7 6 2 3 4 5 print @$r_slice; # 0 7 2 3 Am I now thinking clearly?
Re: Perl6 Daydreams (on topic but frivolous)
Iain Truskett [EMAIL PROTECTED] writes: * Jonadab the Unsightly One ([EMAIL PROTECTED]) [01 Jul 2003 23:41]: Iain Truskett [EMAIL PROTECTED] writes: Not the only one. And with Parrot being able to execute Z-code, it might be sane to port Inform to Parrot! Did you mean port Inform to run on Parrot, or port Inform to compile to parrot? The former. That shouldn't be too hard, once Parrot is essentially complete. Inform is _fairly_ portable. Not extremely portable like z-code, but fairly portable. I was thinking more of Parrot being a portable interactive fiction platform for reading and creating games. I can see the advantage in having Inform run on Parrot, so that games could be created anywhere. Currently Inform only runs on a relative handful of major platforms (RISC OS, most POSIX systems, Win32, DOS, Mac classic, Amiga, OS/2, and a couple of others I think.) Various people have expressed interest on getting it to run on various handheld devices, but the only such effort I know about succeeding is the Psion 5, though the folks in rec.arts.int-fiction would know better; I've been out of touch with the IF community lately. For reading/playing games, I don't think it makes sense to try to compete with the existing, established virtual machines. The z-machine is the veritable holy grail of portability. Every month it seems somebody releases a new z-machine for Yet Another Obscure Platform. z-code runs on everything from Gameboy to Emacs.
Re: Perl6 Daydreams (on topic but frivolous)
Iain Truskett [EMAIL PROTECTED] writes: Not the only one. And with Parrot being able to execute Z-code, it might be sane to port Inform to Parrot! Did you mean port Inform to run on Parrot, or port Inform to compile to parrot? If the former, that should be no problem. If the latter, I'm not sure what the advantage would be. The z-machine is quite a good deal more portable than Parrot, so Parrot could never replace it. Parrot _could_ be used as a replacement for glulx, but I can't think of any compelling reason to do that. Most of the capabilities that Parrot has that glulx lacks are things that Inform wouldn't be able to exploit anyway. (For those who don't know, the Inform language, due to its focus on extreme portability, is unable to assume various things, such as the existence of a filesystem, the ability to allocate memory at runtime, and so forth. It's not a general-purpose language, obviously.)
Re: printf-like formatting in interpolated strings
This was a few days ago, but I just noticed Tim Bunce's comment about
the way other languages do it and thought of the way it is in another
language I know (one that a lot of people don't know), so I'm chiming
in briefly...
Austin Hastings [EMAIL PROTECTED] writes:
How about a pre- or user- defined function that just does sprintf?
The values are $( sprintflike($format-string, @values))
Inform has something like this (though printing is overall very
different than in Perl). There are some functions defined by the
standard library, but any function can be used. It works like this
(in Inform):
! Print stuff according to the usual rules:
print foo, bar, some constant string, baz;
! Print an object using its short name (which may be a
! routine, in which case it is run and is expected to print
! the appropriate thing, or a string):
print (name) foo;
! Print an object, but use the article in addition to the
! short name. (The object can override the article, and
! objects with the proper attribute don't use one, so this
! is not the same as expressly printing the):
print (the) foo;
! Same thing, but capitalise the article:
print (The) foo;
! There are some other predefined formatting routines, but here
! is the general case...
! Pass the object to the quux routine, which is expected to print it
! in some fashion:
print (quux) foo;
The parentheses are not the right syntax for Perl, obviously.
This does come in really handy when interpolating objects into
sentences...
Object thief Thief somewhere
with react_before [;
Insert:
move noun to self;
You attempt to put , (the) noun, into (the) second,
, but , (the) self, snatches it away.;
! That looks better with inform-mode syntax highlighting.
OtherAction:
do_stuff();
],
other_properties values, ! Elided here for brevity.
has proper animate;
I suspect an analagous feature would be really convenient in Perl.
If you can make the mental transition from the way Inform does things,
using the object's properties (which may be strings, routines,
whatever, depending on the object) to format it is not really very
different from using a format string to sprintf it. Either way, some
piece of metainformation (which property to use, or the format
string), when applied to a specific item, produces results that look a
certain way.
Hmmm... waitasec, now that I think about the above, we actually have
it, pretty much, even in Perl 5...
$noun-{parent}=self; UpdateObjectTree(noun);
print You attempt to put , the(noun), into the(second),
, but , the(self), snatches it away.\n;
return 1;
Okay, the syntax is ugly, but isn't the Perl6 core going to be
flexible enough to allow syntactic sugar to be built on top? So,
can't this be done outside of core? In particular, isn't it going to
be easier in Perl6 to jump into and out of strings, so that the
combination of double quotes and commas can be reduced to a character?
ISTR something like that in one of the Apocalypse articles. Or was
that for regexes? I get strings and regexes confused...
Oh, and of course in Perl the routines would have to return the
strings rather than printing them, but that's definitely the Perlish
way to do it.
Re: Perl6 Daydreams (on topic but frivolous)
Miko O Sullivan [EMAIL PROTECTED] writes:
- I'm looking forward to more Pure Perl modules. I frankly admit
that I don't like coding in C. Every time I download a module that
has compiled C code I feel like I'm stuck in some place where I want
to play baseball and everybody else wants to play cricket.
Amen to that. My dream is that Perl will become powerful enough that
XS will be totally unnecessary and can be dropped altogether in Perl7.
The feature I'm most looking forward to in Perl6 is the improved
object model. One of my first languages was Inform (which has a full
object forest model, classes and objects that inherit from multiple
classes, superclasses (so a class or a string or a routine is an
object (though it is not an Object because it is a Class or a String
or a Routine)), default values (set by the programmer) for common
properties, instance objects that can override the defaults and the
class values, an advanced concept of what objects are in scope from
the perspective of another object, the ability to invoke a given
property of a given object without knowing whether it is a routine (in
which case the return value is used) or a value, and assorted other
niceties), so I got spoiled early in terms of what objects are
supposed to be like. Perl6 promises abilities that will allow most of
this functionality (if not all of it) to be duplicated in Perl
relatively painlessly; doing some of it in Perl5 would require
horrible amounts of effort, to say nothing of the nasty
{$obj-{prop}}() syntax it would lead to.
